3.8. Authentication

When using the Identity Management WebUI in the Internet Explorer browser, you may encounter the following issues:

When Identity Management is installed with its CA certificate signed by an external CA, the installation is processed in 2 stages. In the first stage, a CSR is generated to be signed by an external CA. The second stage of the installation then accepts a file with the new signed certificate for the Identity Management CA and a certificate of the external CA. During the second stage of the installation, a signed Identity Management CA certificate subject is validated. However, there is a bug in the certificate subject validation procedure and its default value (O=$REALM, where $REALM is the realm of the new Identity Management installation) is never pulled. Consequently, the second stage of the installation process always fails unless the --subject option is specified. To work around this issue, add the following option for the second stage of the installation: --subject "O=$REALM" where $REALM is the realm of the new Identity Management installation. If a custom subject was used for the first stage of the installation, use its value instead. Using this work around, the certificate subject validation procedure succeeds and the installation continues as expected.

When a user is migrated from a remote LDAP, the user's entry in the Directory Server does not contain Kerberos credentials needed for a Kerberos login. When the user visits the password migration page, Kerberos credentials are generated for the user and logging in via Kerberos authentication works as expected. However, Identity Management does not generate the credentials correctly when the migrated password does not follow the password policy set on the Identity Management server. Consequently, when the password migration is done and a user tries to log in via Kerberos authentication, the user is prompted to change the password as it does not follow the password policy, but the password change is never successful and the user is not able to use Kerberos authentication. To work around this issue, an administrator can reset the password of a migrated user with the ipa passwd command. When reset, user's Kerberos credentials in the Directory Server are properly generated and the user is able to log in using Kerberos authentication.

In the Identity Management webUI, deleting a DNS record may, under come circumstances, leave it visible on the page showing DNS records. This is only a display issue and does not affect functionality of DNS records in any way.

The Identity Management permission plug-in does not verify that the set of attributes specified for a new permission is relevant to the target object type that the permission allows access to. This means a user is able to create a permission which allows access to attributes that will never be present in the target object type because such attributes are not allowed in its object classes. You must ensure that the chosen set of attributes for which a new permission grants access to is relevant to the chosen target object type.

The ipa-client package does not install the policycoreutils package as its dependency, which may cause install/uninstall issues when using the ipa-client-install setup script. To work around this issue, install the policycoreutils package manually:

~]# yum install policycoreutils

Updating the Identity Management LDAP configuration via the ipa-ldap-updater fails with a traceback error when executed by a non-root user due to the SASL EXTERNAL bind requiring root privileges. To work around this issue, run the aforementioned command as the root user.

With netgroups, when adding a host as a member that Identity Management does not have stored as a host already, that host is considered to be an external host. This host can be controlled with netgroups, but Identity Management has no knowledge of it. Currently, there is no way to use the netgroup-find option to search for external hosts.

Also, note that when a host is added to a netgroup as an external host, rather than being added in Identity Management as an external host, that host is not automatically converted within the netgroup rule.

Because a permission does not provide write access to an entry, delegation does not work as expected. The 389 Directory Server (389-ds) distinguishes access between entries and attributes. For example, an entry can be granted add or delete access, whereas an attribute can be granted read, search, and write access. To grant write access to an entry, the list of writable attributes needs to be provided. The filter, subtree, and other options are used to target those entries which are writable. Attributes define which part(s) of those entries are writable. As a result, the list of attributes will be writable to members of the permission.

The manpage entry for the ldap_disable_paging option in the sssd-ldap man page does not indicate that it accepts the boolean values True or False, and defaulting to False if it is not explicitly specified.

Identity Management relies on the LDAP schema to know what type of data to expect in a given attribute. If, in certain situations (such as replication), data that does not meet those expectations is inserted into an attribute, Identity Management will not be able to handle the entry, and LDAP tools have do be used to manually clean up that entry.

Identity Management sudo commands are not case sensitive. For example, executing the following commands will result in the latter one failing due to the case insensitivity:

~]$ ipa sudocmd-add /usr/bin/X
⋮
~]$ ipa sudocmd-add /usr/bin/x
ipa: ERROR: sudo command with name "/usr/bin/x" already exists

Identity Management and the mod_ssl module should not be installed on the same system, otherwise Identity Management is unable to issue certificates because mod_ssl holds the mod_proxy hooks. To work around this issue, uninstall mod_ssl.

When an Identity Management server is installed with a custom hostname that is not resolvable, the ipa-server-install command should add a record to the static hostname lookup table in /etc/hosts and enable further configuration of Identity Management integrated services. However, a record is not added to /etc/hosts when an IP address is passed as an CLI option and not interactively. Consequently, Identity Management installation fails because integrated services that are being configured expect the Identity Management server hostname to be resolvable. To work around this issue, complete one of the following:

As a result, the Identity Management server can be installed with a custom hostname that is not resolvable.

Upgrading SSSD from the version provided in Red Hat Enterprise Linux 6.1 to the version shipped with Red Hat Enterprise Linux 6.2 may fail due to a bug in the dependent library libldb. This failure occurs when the SSSD cache contains internal entries whose distinguished name contains the \, character sequence. The most likely example of this is for an invalid memberUID entry to appear in an LDAP group of the form:

memberUID: user1,user2

memberUID is a multi-valued attribute and should not have multiple users in the same attribute.

If the upgrade issue occurs, identifiable by the following debug log message:

(Wed Nov  2 15:18:21 2011) [sssd] [ldb] (0): A transaction is still active in
ldb context [0xaa0460] on /var/lib/sss/db/cache_<DOMAIN>.ldb

remove the /var/lib/sss/db/cache_<DOMAIN>.ldb file and restart SSSD.

When a group contains certain incorrect multi-valued memberUID values, SSSD fails to sanitize the values properly. The memberUID value should only contain one username. As a result, SSSD creates incorrect users, using the broken memberUID values as their usernames. This, for example, causes problems during cache indexing.

Two Identity Management servers, both with a CA (Certificate Authority) installed, use two replication replication agreements. One is for user, group, host, and other related data. Another replication agreement is established between the CA instances installed on the servers. If the CA replication agreement is broken, the Identity Management data is still shared between the two servers, however, because there is no replication agreement between the two CAs, issuing a certificate on one server will cause the other server to not recognize that certificate, and vice versa.

The Identity Management (ipa) package cannot be build with a 6ComputeNode subscription.

On the configuration page of the Identity Management WebUI, if the User search field is left blank, and the search button is clicked, an internal error is returned.

Active Directory performs certain LDAP referral-chasing that is incompatible with the referral mechanism included in the openldap libraries. Notably, Active Directory sometimes attempts to return a referral on an LDAP bind attempt, which used to cause a hang, and is now denied by the openldap libraries. As a result, SSSD may suffer from performance issues and occasional failures resulting in missing information.

To work around this issue, disable referral-chasing by setting the following parameter in the [domain/DOMAINNAME] section of the /etc/sssd/sssd.conf file:

ldap_referrals = false