Red Hat Training
A Red Hat training course is available for Red Hat Enterprise Linux
第 40 章 Authentication and Interoperability
bind-dyndb-ldap
component, BZ#1139776- 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 thenamed
daemon to resynchronize data after each MODRDN operation. In an Identity Management (IdM) cluster, restart thenamed
daemon on all IdM replicas. ipa
component, BZ#1187524- The
userRoot.ldif
andipaca.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. 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.
ipa
component, BZ#1186352- 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.
ipa
component, BZ#1188195- 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
ipa
component, BZ#1189034- 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 executeipa 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, executeipa 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. ipa
component, BZ#1193578- 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 theudp_preference_limit
option to0
in the/etc/krb5.conf
file. ipa
component, BZ#1170770- 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 theipa 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 theipa trust-add
command. ipa
component, BZ#988473- 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 theTrusted Admins
group and this group should have relative identifier (RID) 512 assigned. To ensure this, run theipa-adtrust-install
command and then theipa group-show admins --all
command to verify that theipantsecurityidentifier
field contains a value ending with the-512
string. If the field does not end with-512
, use theipa group-mod admins --setattr=ipantsecurityidentifier=SID
command, where SID is the value of the field from theipa group-show admins --all
command output with the last component value (-XXXX) replaced by the-512
string. sssd
component, BZ#1024744- 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.
sssd
component, BZ#1081046- 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 specifyingad_enable_gc=False
in thesssd.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. sssd
component, BZ#1103249- 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.
sssd
component, BZ#1194345- 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 thesssd-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 thegetent passwd user
command shows the POSIX attributes. Note that running theid user
command might not show the POSIX attributes even if they are set properly. samba
component, BZ#1186403- 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.