Migration of FreeIPA from one virtualization environment to another.
by Srikanth Reddy
Currently our FreeIPA is running as a container on a virtual machine in VmWare environment. Now we are changing the virtualization environment from VmWare to Cloudstack, As part of this we need to migrate our FreeIPA from VmWare to Cloudstack environment. I need the best approach to do this FreeIPA server and data migration. If you could point me to any articles or documentation regarding this it would be much helpful for me.
Thanks in advance :)
8 months, 1 week
Unable to change ID View
by Jeremy Tourville
At one point we tried working with the id view feature in IPA. As a result of that, our user group now shows up like this: 861201183(xt_sa(a)gsil.org). Prior to the change in IPA this group showed up as 861201183(gsil_sa(a)gsil.org). I believe I have everything deleted in the GUI that would have caused the ID view to change but despite this the group still shows up as xt_sa instead of gsil_sa. How can I get this changed back?
8 months, 1 week
Disable all sssd caching
by Ranbir
Hello Everyone,
Is there a flag to disable all caching in sssd? I know we shouldn't
disable the various caches. However, I'm working on isolating a problem
we're seeing between our firewall and AD.
The firewall has a plugin that monitors AD for session information.
When a login occurs, the firewall is supposed to see that and then
allow the user to login to hosts inside of a protected network.
We have a trust between AD and IPA. Logins to the IPA enrolled server
with an AD account always works. But, quite often login from that host
to a host inside the protected network fails. When we look on the
firewall for live sessions, no session info for that user is found.
Obviously, that's why the firewall blocked access.
My hunch is one or more of sssd's caching parameters is/are the source
of the issue. Thus, I'm wondering if there's a way to quickly disable
the caching.
Thanks,
--
Ranbir
8 months, 1 week
Kerberos logs / TGS
by Ole Froslie
Hi,
I am working on getting the logging for FreeIPA set-up properly.
I have a test server (testy) running.
This server/host is under control of FreeIPA.
I have a user group defined for test users, and a host group for test servers.
There is a HBAC rule to ensure that the members of testing group has only access to the test servers.
This works fine, but I have a question regarding the logs.
Scenario 1:
User : test2 is member of the testusergroup and should be granted access to the test server.
This works as expected, test2 is authorized to login to server and the log (var/log/krb5kdc.log) looks like this.
Sep 18 14:55:19 idm1.myrealm.net krb5kdc[287272](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) my.ip.adress.xx: NEEDED_PREAUTH: test2(a)MYREALM.NET for krbtgt/MYREALM.NET(a)MYREALM.NET, Additional pre-authentication required
Sep 18 14:55:19 idm1.myrealm.net krb5kdc[287272](info): closing down fd 11
Sep 18 14:55:19 idm1.myrealm.net krb5kdc[287272](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) my.ip.adress.xx: NEEDED_PREAUTH: test2(a)MYREALM.NET for krbtgt/MYREALM.NET(a)MYREALM.NET, Additional pre-authentication required
Sep 18 14:55:19 idm1.myrealm.net krb5kdc[287272](info): closing down fd 11
Sep 18 14:55:19 idm1.myrealm.net krb5kdc[287271](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) my.ip.adress.xx: ISSUE: authtime 1695041719, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha1-96(18)}, test2(a)MYREALM.NET for krbtgt/MYREALM.NET(a)MYREALM.NET
Sep 18 14:55:19 idm1.myrealm.net krb5kdc[287271](info): closing down fd 11
Sep 18 14:55:19 idm1.myrealm.net krb5kdc[287271](info): TGS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) my.ip.adress.xx: ISSUE: authtime 1695041719, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha1-96(18)}, test2(a)MYREALM.NET for host/testy.myrealm.net(a)MYREALM.NET
Sep 18 14:55:19 idm1.myrealm.net krb5kdc[287271](info): closing down fd 11
In this log, I see the AS_REQs and then the TGS_REQ for obtaining the TGS.
Scenario 2:
User : test2 is not a member of testusergroup anymore and should not be granted access to the test server.
This also works as expected, when logging in with correct password, test2 is denied service with message "Connection closed by ...."
This is great, but I would like to see this happening in the log:
The log looks like this:
Sep 18 14:58:09 idm1.myrealm.net krb5kdc[287271](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) my.ip.adress.xx: NEEDED_PREAUTH: test2(a)MYREALM.NET for krbtgt/MYREALM.NET(a)MYREALM.NET, Additional pre-authentication required
Sep 18 14:58:09 idm1.myrealm.net krb5kdc[287271](info): closing down fd 11
Sep 18 14:58:09 idm1.myrealm.net krb5kdc[287272](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) my.ip.adress.xx: NEEDED_PREAUTH: test2(a)MYREALM.NET for krbtgt/MYREALM.NET(a)MYREALM.NET, Additional pre-authentication required
Sep 18 14:58:09 idm1.myrealm.net krb5kdc[287272](info): closing down fd 11
Sep 18 14:58:09 idm1.myrealm.net krb5kdc[287271](info): AS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) my.ip.adress.xx: ISSUE: authtime 1695041889, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha1-96(18)}, test2(a)MYREALM.NET for krbtgt/MYREALM.NET(a)MYREALM.NET
Sep 18 14:58:09 idm1.myrealm.net krb5kdc[287271](info): closing down fd 11
Sep 18 14:58:09 idm1.myrealm.net krb5kdc[287272](info): TGS_REQ (8 etypes {aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), UNSUPPORTED:des3-hmac-sha1(16), DEPRECATED:arcfour-hmac(23), camellia128-cts-cmac(25), camellia256-cts-cmac(26)}) my.ip.adress.xx: ISSUE: authtime 1695041889, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha384-192(20), ses=aes256-cts-hmac-sha1-96(18)}, test2(a)MYREALM.NET for host/testy.myrealm.net(a)MYREALM.NET
Sep 18 14:58:09 idm1.myrealm.net krb5kdc[287272](info): closing down fd 11
In this log, I see the same AS_REQ as expected with no failure, since I am using correct password , and the same kind of TGS_REQ
My question is:
When FreeIPA is handling the service authorization through the use of HBAC rules, why does it issue a similar TGS?
Or is it different?,
How does the actual authorization fail between the client and the server/service itself?
Is it the content of the TGS ?
I know I can see failed login in the logs of the server it self, but I would like to see everything that goes on in the FreeIPA logs.
regards
Ole Frøslie
Com4
8 months, 1 week
A-record creation in during ipa-client-install
by dweller dweller
Hello everyone. I need some insight on a particular issue.
Is it true that the command 'ipa-client-install' won't automatically add an A-record for the new host, even when dyndns is set to True for the zone? Currently, I can only seem to create an A-record during host enrollment when I use the '--enable-dns-update' option. Is this the intended behavior or am I perhaps making a mistake, and the 'ipa-client-install' command should attempt to add an A-record by default?
I have attached the log of the 'ipa-client-install' command for reference:
https://pastebin.com/2Bbs55Ja
8 months, 1 week
What is the correct way to make schema changes across all replicas?
by Joshua Hoblitt
Hi Folks,
At the moment, I'm investigating using pwm to allow user password reset
self service. pwm requires a schema change to add its own attributes.
I'm afraid I've never been clear on what the correct procedure is for
make schema changes and I've been unable to find a blurb on this in the
RH IdM docs.
There seems to be a couple of possible ways of going about this using
ldapmodify or dropping ldif files directly under
/etc/dirsrv/slapd-<foo>/schema. However, that requires templating the
ldif with server specific changes.
Seeing as the files under /usr/share/ipa appear to be templated via
ipa-ldap-updater and the man page states:
Additionally, ipa-ldap-updater can update the schema based
on LDIF files. Any missing object classes and attribute types are
added, and differing ones are updated to match the
LDIF file. To enable this behavior, use the
--schema-file options. Schema files should be in LDIF format, and
may only specify attributeTypes and objectClasses attributes of
cn=schema.
I attempted to template the pwm schema changes as follows:
dn: cn=schema
objectclass: top
objectclass: ldapSubentry
objectclass: subschema
cn: schema
aci: (target="ldap:///cn=schema")(targetattr !="aci")(version
3.0;acl "anonymous, no acis"; allow (read, search, compare) userdn =
"ldap:///anyone";)
aci: (targetattr="*")(version 3.0; acl "Configuration Administrators
Group"; allow (all)
groupdn="ldap:///cn=admins,cn=groups,cn=accounts,$SUFFIX";)
aci: (targetattr="*")(version 3.0; acl "Configuration
Administrator"; allow (all)
userdn="ldap:///uid=admin,cn=users,cn=accounts,$SUFFIX";)
aci: (targetattr = "*")(version 3.0; acl "SIE Group"; allow (all)
groupdn = "ldap:///fqdn=$FQDN,cn=computers,cn=accounts,$SUFFIX";)
attributetypes: ( 1.3.6.1.4.1.35015.1.2.1 NAME 'pwmEventLog' SYNTAX
1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'user defined' )
attributetypes: ( 1.3.6.1.4.1.35015.1.2.2 NAME 'pwmResponseSet'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'user defined' )
attributetypes: ( 1.3.6.1.4.1.35015.1.2.3 NAME 'pwmLastPwdUpdate'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE X-ORIGIN 'user
defined' )
attributetypes: ( 1.3.6.1.4.1.35015.1.2.4 NAME 'pwmGUID' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' )
attributetypes: ( 1.3.6.1.4.1.35015.1.2.4 NAME 'pwmToken' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE X-ORIGIN 'user defined' )
attributetypes: ( 1.3.6.1.4.1.35015.1.2.6 NAME 'pwmOtpSecret'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'user defined' )
attributetypes: ( 1.3.6.1.4.1.35015.1.2.7 NAME 'pwmData' SYNTAX
1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'user defined' )
objectclasses: ( 1.3.6.1.4.1.35015.1.1.1 NAME 'pwmUser' DESC '' SUP
top AUXILIARY MAY ( pwmEventLog $ pwmResponseSet $ pwmLastPwdUpdate
$ pwmGUID $ pwmToken $ pwmOtpSecret $ pwmData ) X-ORIGIN 'user
defined' )
However, trying to use `ipa-ldap-updater` in this manner suggested by
the manpage fails:
# ipa-ldap-updater --schema-file ./99pwm.ldif
Unexpected error - see /var/log/ipaupgrade.log for details:
IOError: [Errno socket error] [Errno -2] Name or service not known
The ipa-ldap-updater command failed. See /var/log/ipaupgrade.log for
more information
The error message is complaining about the socket... which I've
confirmed from the ipaupgrade.log is the correct path to the dirsrv
socket (and dirsrv is otherwise functioning).
Is this an abuse of, or bug in, ipa-ldap-updater? Is it possible to
simply drop templated ldif files under /usr/share/ipa/ and have them be
processed similarly to /usr/share/ipa/updates/?
Any guidance would be greatly appreciated.
-Josh
--
8 months, 1 week
Certs expired, CA Unreachable
by Evan G
Good afternoon.
We currently have FreeIPA v4.6.8 running on CentOS7. We have tried many of the solutions posted on this mailer however none have helped us bring the environment back online. Our current situation is as follows:
- We have a single master / single CA with a total of 4 FreeIPA (2 in each site) servers in production.
- Replication is not working between the master and secondaries.
- The FreeIPA admin account password is working and we are able to kinit as admin
- We can bring the IPA services online by rolling the clock back to before the HTTP cert expired, however the CA refuses to sign any of our cert requests -- giving a Kerberos authentication error when CURL'd
- We are able to login to the HTTP interface with the services up and date rolled back, however we are unable to issue a new cert, we receive a 500 error in reaching the CA
Happy to provide any other requested info but we've been troubleshooting this for 3 days straight and we're coming up empty on every avenue.
8 months, 1 week
FreeIPA UID/GID Integration with Storage & Trusts
by Jeremy Tourville
We are running IPA ver 4.9.11
We are trying to integrate our storage system (from a large, well known vendor who shall be nameless) with our existing AD/IPA setup. We presently have a one way trust established with AD and it's working well. All of our user objects are in AD.
We need the ability have synchronized UID/GID across all systems so that permissions do not cause issues or problems for our users. We'd like to know if creating a two way trust could enable IPA to write back UID/GID attributes to AD?
We also know another approach is to create POSIX attributes in AD for every user and establish an AD trust with POSIX attributes. We also have a few other options to make this work but wanted to exhaust any possibilities within IPA first as they would be the easiest to implement.
Thanks for feedback!
8 months, 2 weeks
