6.9. Authentication

OpenLDAP and 389 Directory Server treat the grace logins differently. 389 Directory Server treats them as "number of grace logins left" while OpenLDAP treats them as "number of grace logins used". Currently the SSSD only handles the semantics used by 389 Directory server. As a result, when using OpenLDAP server, the grace password warning might be incorrect.

The Identity Management server does not write the initial user password correctly to password history. As a consequence, when a new Identity Management user is created and a password is generated for him, the first time that user changes the password, the value of the first password is disregarded when the password policy plug-in checks the password history. This means that user can "change" the initial password to the same value as the previous one, with no regards to the configured password history. Password history is applied correctly to all subsequent password changes.

When an Identity Management server installed on Red Hat Enterprise Linux 6.2 is updated to the version provided by Red Hat Enterprise Linux 6.4 or 6.5, the new pbac permission "Write DNS Configuration" is created without any of the required object classes. Consequently, the permission may not show up on the Identity Management Web UI permission page or when the --sizelimit parameter is used for the CLI permission-find command. The permission is still accessible using the command line when the --sizelimit option is not specified. To work around this problem, run the following command on the server to trigger the DNS permission update process again and fix the list of permission object classes:

]# ipa-ldap-updater --ldapi /usr/share/ipa/updates/40-dns.update

This problem can also be avoided when a Red Hat Enterprise Linux 6.4 or 6.5 replica is installed or when an Identity Management server is reinstalled or upgraded.

Identity Management administration framework API contains two checks to verify that a request on its API can be passed further:

However, the Identity Management server performs the checks in an incorrect order: first, the attribute and parameter check is done and after that, the API version check is done. As a consequence, when a new client (for example, Red Hat Enterprise Linux 6.5) runs the ipa administration tool against a server with an earlier operating system (for example, Red Hat Enterprise Linux 6.4), the command returns a confusing error message; for example, instead of stating API compatibility, ipa outputs the following message:

]$ ipa user-show admin
ipa: ERROR: Unknown option: no_members

The ipa-replica-manage tool contains a bug in the re-initialize command causing the MemberOf task to fail with an error under certain circumstances. When the ipa-replica-manage re-initialize command is run for a Windows Synchronization (WinSync) replication agreement, it succeeds in the re-initialization part, but fails during execution of the MemberOf task which is run after the re-initialization part. The following error is returned:

Update succeeded
Can't contact LDAP server

However, the error is harmless as running the MemberOf task is not required in this case.

SSSD fails if the entryUSN attribute of sudo rules is empty. As a result, processing of sudo rules stops instead of proceeding. To work around this problem, if the server contains any other USN-like attribute, the user can set the attribute in the configuration file using:

ldap_rootdse_last_usn = attr_name
ldap_entry_usn = attr_name

ipa-adtrust-install, an Identity Management Active Directory Trust configuration tool, does not explicitly specify authentication mechanism when performing Active Directory Trust configuration changes. When the user specifies the default LDAP authentication mechanism other than the expected default (for example, by setting the SASL_MECH configuration option to GSSAPI in the LDAP configuration file for the root user, .ldaprc), ipa-adtrust-install will not use the expected authentication mechanism and will fail to configure some of the parts of the Active Directory Integration feature, a crash of samba daemon (smbd) can occur or the user will be unable to use the feature. To work around this problem, remove any user default settings related to LDAP authentication mechanism from the .ldaprc file. The ipa-adtrust-install installer will then successfully configure the Active Directory integration feature.

The Identity Management installer configures all integrated services to listen on all interfaces. The administrator has no means to instruct the Identity Management installer to listen only on chosen interfaces even though the installer requires a valid interface IP address as one installation parameter. To work around this problem, change service configuration after Identity Management installation.

Identity Management LDAP permission manipulation plugin validates subtree and filter permission specifiers as mutually exclusive even though it is a valid combination in the underlying LDAP Access Control Instruction (ACI). Permissions with filter and subtree specifiers can be neither created nor modified. This affects for example the Add Automount Keys permission which cannot be modified.

In some cases the certificates tracked by certmonger are not cleared when running the ipa-server-install --uninstall command. This will cause a subsequent re-installation to fail with an unexpected error.

The ssh_cache utility sets the DEBUG level after it processes the command-line parameters. If the command-line parameters cannot be processed, the utility prints DEBUG lines that are not supposed to be printed by default. To avoid this, correct parameters must be used.

It is possible to specify the enumerate=true value in the sssd.conf file to access all users in the system. However, using enumerate=true is not recommended in large environments as this can lead to high CPU consumption. As a result, operations like login or logout can be slowed down.

The Identity Management server processes Kerberos Password Expiration Time field as a 32-bit integer. If Maximum Lifetime of a user password in Identity Management Password Policy is set to a value causing the resulting Kerberos Password Expiration Time timestamp to exceed 32 bits and to overflow, the passwords that are being changed are configured with an expiration time that lies in the past and are always rejected. To ensure that new user passwords are valid and can be changed properly, do not set password Maximum Lifetime in Identity Management Password Policy to values that would cause the Kerberos Password Expiration Time timestamp to exceed 32 bits; that is, passwords that would expire after 2038-01-19. At the moment, recommended values for the Maximum Lifetime field are numbers lower than 9000 days.

When reconnecting to an LDAP server, SSSD does not check it was re-initialized during the downtime. If the server was re-initialized during the downtime and was filled with completely different data, SSSD does not update its database. As a consequence, the user can get invalid information from SSSD. To work around this problem:

In environments where entropy is scarce, the kadmind tool can take longer to initialize after startup than it did in previous releases as it attempts to read data from the /dev/random file and seed its internal random number generator (RNG). Clients which attempt to connect to the kadmin service can time out and fail with a GSS-API or Kerberos error. After the service completely finishes initializing itself, it will process messages received from now-disconnected clients and can log clock-skew or decrypt-integrity-check-failed errors for those connections. To work around this problem, use a service such as rngd to seed the system RNG using hardware sources of entropy.

The Identity Management server in Red Hat Enterprise Linux 6.3 introduced a technical preview of SELinux user mapping feature, which enabled a mapping of SELinux users to users managed by the Identity Management based on custom rules. However, the default configured SELinux user (guest_u:s0) used when no custom rule matches is too constraining. An Identity Management user authenticating to Red Hat Enterprise Linux 6.5 can be assigned the too constraining SELinux user in which case a login through graphical session would always fail. To work around this problem, change a too constraining default SELinux user in the Identity Management server from guest_u:s0 to a more relaxed value unconfined_u:s0-s0:c0.c1023:

kinit admin
ipa config-mod ipaselinuxusermapdefault=unconfined_u:s0-s0:c0.c1023

An unconfined SELinux user will be now assigned to the Identity Management user by default, which will allow the user to successfully authenticate through graphical interface.

When attempting to view a host in the web UI, the following message can appear:

Certificate operation cannot be completed: Unable to communicate with CMS (Unauthorized)

Attempting to delete installed certificates through the web UI or command-line interface can fail with the same error message. To work around this problem, run the following command:

~]# yum downgrade ipa-server libipa_hbac libipa_hbac-python ipa-python ipa-client ipa-admintools ipa-server-selinux

When upgrading the ipa-server package using anaconda, the following error message is logged in the upgrade.log file:

/sbin/restorecon:  lstat(/var/lib/pki-ca/publish*) failed:  No such file or directory

This problem does not occur when using yum.

In the Identity Manager subdomain code, a User Principal Name (UPN) is by default built from the SAM Account Name and Active Directory trust users, that is user@DOMAIN. The UPN can be changed to differ from the UPN in Active Directory, however only the default format, user@DOMAIN, is supported.

Sometimes, group members may not be visible when running the getent group groupname command. This can be caused by an incorrect ldap_schema in the [domain/DOMAINNAME] section of the sssd.conf file. SSSD supports three LDAP schema types: RFC 2307, RFC 2307bis, and IPA. By default, SSSD uses the more common RFC 2307 schema. The difference between RFC 2307 and RFC 2307bis is the way which group membership is stored in the LDAP server. In an RFC 2307 server, group members are stored as the multi-valued memberuid attribute which contains the name of the users that are members. In an RFC2307bis server, group members are stored as the multi-valued attribute member (or sometimes uniqueMember) which contains the DN of the user or group that is a member of this group. RFC2307bis allows nested groups to be maintained as well.

When encountering this problem:

If the workaround does not work, add ldap_group_member = uniqueMember in the sssd.conf file, delete the cache file and restart SSSD.

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

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.

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