Chapter 40. Authentication and Interoperability

The latest version of the bind-dyndb-ldap system 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 named daemon to resynchronize data after each MODRDN operation. In an Identity Management (IdM) cluster, restart the named daemon on all IdM replicas.

The userRoot.ldif and ipaca.ldif files, 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.

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 facsimiletelephonenumber user 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

The ipa host-del --updatedns command 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 --updatedns on 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 --updatedns command 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 kinit command 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 udp_preference_limit option to 0 in the /etc/krb5.conf file.

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-show command 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.domain command. 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 ipa trust-add command.

Access control to Lightweight Directory Access Protocol (LDAP) objects representing trust with Active Directory (AD) is given to the Trusted Admins group 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 Admins group and this group should have relative identifier (RID) 512 assigned. To ensure this, run the ipa-adtrust-install command and then the ipa group-show admins --all command to verify that the ipantsecurityidentifier field contains a value ending with the -512 string. If the field does not end with -512, use the ipa group-mod admins --setattr=ipantsecurityidentifier=SID command, where SID is the value of the field from the ipa group-show admins --all command output with the last component value (-XXXX) replaced by the -512 string.

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.

The accountExpires attribute 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 ad_enable_gc=False in the sssd.conf file. 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=False parameter in the sssd-ad.conf file, 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 user command shows the POSIX attributes. Note that running the id user command 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.