Show Table of Contents
Chapter 40. Authentication and Interoperability
- The latest version of the
bind-dyndb-ldapsystem plug-in offers significant improvements over the previous versions, but currently has some limitations. One of the limitations is missing support for the LDAP rename (MODRDN) operation. As a consequence, DNS records renamed in LDAP are not served correctly. To work around this problem, restart the
nameddaemon to resynchronize data after each MODRDN operation. In an Identity Management (IdM) cluster, restart the
nameddaemon on all IdM replicas.
ipaca.ldiffiles, from which Identity Management (IdM) reimports the back end when restoring from backup, cannot be opened during a full-server restore even though they are present in the tar archive containing the IdM backup. Consequently, these files are skipped during the full-server restore. If you restore from a full-server backup, the restored back end can receive some updates from after the backup was created. This is not expected because all updates received between the time the backup was created and the time the restore is performed should be lost. The server is successfully restored, but can contain invalid data. If the restored server containing invalid data is then used to reinitialize a replica, the replica reinitialization succeeds, but the data on the replica is invalid.No workaround is currently available. It is recommended that you do not use a server restored from a full-server IdM backup to reinitialize a replica, which ensures that no unexpected updates are present at the end of the restore and reinitialization process.Note that this known issue relates only to the full-server IdM restore, not to the data-only IdM restore.
ipa (slapi-nis)component, BZ#1157757
- When the Schema Compatibility plug-in is configured to provide Active Directory (AD) users access to legacy clients using the Identity Management (IdM) cross-forest trust to AD, the 389 Directory Server can under certain conditions increase CPU consumption upon receiving a request to resolve complex group membership of an AD user.
- When you restore an Identity Management (IdM) server from backup and re-initalize the restored data to other replicas, the Schema Compatibility plug-in can still maintain a cache of the old data from before performing the restore and re-initialization. Consequently, the replicas might behave unexpectedly. For example, if you attempt to add a user that was originally added after performing the backup, and thus removed during the restore and re-initialization steps, the operation might fail with an error, because the Schema Compatibility cache contains a conflicting user entry. To work around this problem, restart the IdM replicas after re-intializing them from the master server. This clears the Schema Compatibility cache and ensures that the replicas behave as expected in the described situation.
- Both anonymous and authenticated users lose the default permission to read the
facsimiletelephonenumberuser attribute after upgrading to the Red Hat Enterprise Linux 7.1 version of Identity Management (IdM). To manually change the new default setting and make the attribute readable again, run the following command:
ipa permission-mod 'System: Read User Addressbook Attributes' --includedattrs facsimiletelephonenumber
ipa host-del --updatednscommand does not update the host DNS records if the DNS zone of the host is not fully qualified. Creating unqualified zones was possible in Red Hat Enterprise Linux 7.0 and 6. If you execute
ipa host-del --updatednson an unqualified DNS zone, for example, example.test instead of the fully qualified example.test. with the dot (.) at the end, the command fails with an internal error and deletes the host but not its DNS records. To work around this problem, execute
ipa host-del --updatednscommand on an IdM server running Red Hat Enterprise Linux 7.0 or 6, where updating the host DNS records works as expected, or update the host DNS records manually after running the command on Red Hat Enterprise Linux 7.1.
- Kerberos libraries on Identity Management (IdM) clients communicate by default over the User Datagram Protocol (UDP). Using a one-time password (OTP) can cause additional delay and breach of Kerberos timeouts. As a consequence, the
kinitcommand and other Kerberos operations can report communication errors, and the user can get locked out. To work around this problem, make communication using the slightly slower Transmission Control Protocol (TCP) default by setting the
- Hosts enrolled to IdM cannot belong to the same DNS domains as the DNS domains belonging to an AD forest. When any of the DNS domains in an Active Directory (AD) forest are marked as belonging to the Identity Management (IdM) realm, cross-forest trust with AD does not work even though the trust status reports success. To work around this problem, use DNS domains separate from an existing AD forest to deploy IdM.If you are already using the same DNS domains for both AD and IdM, first run the
ipa realmdomains-showcommand to display the list of IdM realm domains. Then remove the DNS domains belonging to AD from the list by running the
ipa realmdomains-mod --del-domain=wrong.domaincommand. Un-enroll the hosts from the AD forest DNS domains from IdM, and choose DNS names that are not in conflict with the AD forest DNS domains for these hosts. Finally, refresh the status of the cross-forest trust to the AD forest by reestablishing the trust with the
- Access control to Lightweight Directory Access Protocol (LDAP) objects representing trust with Active Directory (AD) is given to the
Trusted Adminsgroup in Identity Management (IdM). In order to establish the trust, the IdM administrator should belong to a group which is a member of the
Trusted Adminsgroup and this group should have relative identifier (RID) 512 assigned. To ensure this, run the
ipa-adtrust-installcommand and then the
ipa group-show admins --allcommand to verify that the
ipantsecurityidentifierfield contains a value ending with the
-512string. If the field does not end with
-512, use the
ipa group-mod admins --setattr=ipantsecurityidentifier=SIDcommand, where SID is the value of the field from the
ipa group-show admins --allcommand output with the last component value (-XXXX) replaced by the
- The OpenLDAP server and the 389 Directory Server (389 DS) treat grace logins differently. 389 DS treats them as the number of grace logins left, while OpenLDAP treats them as the number of grace logins used. Currently, SSSD only handles the semantics used by 389 DS. As a result, when using OpenLDAP, the grace password warning can be incorrect.
accountExpiresattribute that SSSD uses to see whether an account has expired is not replicated to the global catalog by default. As a result, users with expired accounts can be allowed to log in when using GSSAPI authentication. To work around this problem, the global catalog support can be disabled by specifying
sssd.conffile. With this setting, users with expired accounts will be denied access when using GSSAPI authentication. Note that SSSD connects to each LDAP server individually in this scenario, which can increase the connection count.
- Under certain circumstances, the algorithm in the Privilege Attribute Certificate (PAC) responder component of the SSSD service does not effectively handle users who are members of a large number of groups. As a consequence, logging from Windows clients to Red Hat Enterprise Linux clients with Kerberos single sign-on (SSO) can be noticeably slow. There is currently no known workaround available.
- The SSSD service uses the global catalog (GC) for initgroup lookups but the POSIX attributes, such as the user home directory or shell, are not replicated to the GC set by default. Consequently, when SSSD requests the POSIX attributes during SSSD lookups, SSSD incorrectly considers the attributes to be removed from the server, because they are not present in the GC, and removes them from the SSSD cache as well.To work around this problem, either disable the GC support by setting the
ad_enable_gc=Falseparameter in the
sssd-ad.conffile, or replicate the POSIX attributes to the GC. Disabling the GC support is easier but results in the client being unable to resolve cross-domain group memberships. Replicating POSIX attributes to the GC is a more systematic solution but requires changing the Active Directory (AD) schema. As a result of either one of the aforementioned workarounds, running the
getent passwd usercommand shows the POSIX attributes. Note that running the
id usercommand might not show the POSIX attributes even if they are set properly.
- Binaries in the samba-common.x86_64 and samba-common.i686 packages contain the same file paths but differ in their contents. As a consequence, the packages cannot be installed together, because the RPM database forbids this scenario.To work around this problem, do not install samba-common.i686 if you primarily need samba-common.x86_64; neither in a kickstart file, nor on an already installed system. If you need samba-common.i686, avoid samba-common.x86_64. As a result, the system can be installed, but with only one architecture of the samba-common package at a time.