It is not possible to change the uidNumber or gidNumber of a user when using SSSD. SSSD caches the authentication information; when the user is deleted and re-added with a new uidNumber number, then SSSD attempts to reuse the cached object for the new user, which fails wit this error:
Cache file [/tmp/krb5cc_1866400007_wPJrHJ] exists, but is owned by [1866400007] instead of [1866400008].
SSSD does not support the LDAP password expiration controls, so it does not support password expiration notifications or warnings. The 389 Directory Server instance used by Identity Management does support these controls.
In the directory, calling hash_create() with an initial table size of 65536 will corrupt memory. With the default parameters, the corruption can occur if the initial table size larger than 1024.
The way that Active Directory performs referrals is different than the way that the OpenLDAP libraries (used by the 389 Directory Server instance in Identity Management) performs referrals. Intermittently, Active Directory may return a referral during an LDAP bind attempt that is denied by the OpenLDAP libraries. This can cause performance problems, information loss, or for SSD to go offline.
To work around this, set this parameter in sssd.conf:
ldap_referrals = False
This disables referral chasing in SSSD.
SSSD does not support the LDAP password expiration controls, so it does not support password expiration notifications or warnings. The 389 Directory Server instance used by Identity Management does support these controls.
When updating the list of object classes for a user or group entry, it is possible to delete object classes which are required by IPA. The UI and CLI do not prevent the required object classes from being deleted, but adding a user or group after the change will fail with object class violations.
The previous and next buttons are not displayed in the UI if the number of entries returned is larger than the configured size limit.
When an IPA 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, IPA server installation fails because integrated services that are being configured expect the IPA server hostname to be resolvable.
There are two ways to work around this issue:
Run the ipa-server-install without the --ip-address option and pass the IP address interactively.
Add a record to /etc/hosts before the installation is started. The record should contain the Identity Management server IP address and its full hostname (the hosts(5) man page specifies the record format).
Searches can be performed on attributes that are not displayed in the UI. This means that entries can be returned in a search that do not appear to match the given filter. This is especially common if the search information is very short, which increases the likelihood of a match.
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.
The IPA information is stored in a separate LDAP directory than the certificate information, and these two LDAP databases are replicated separately. It is possible for a replication agreement to be broken for one directory and working for another, which can cause problems with managing clients.
For example, an IPA server and replica have a function replication agreement between their IPA databases, but the replication agreement between their CA databases is broken. If a host is created on the server, the host entry is replicated over to the replica — but the certificate for that host is not replicated. The replica is aware of the client, but any management operations for that client will fail because the replica doesn't have a copy of its certificate.
The CA replication agreement can be recreated using the ipa-csreplica-manage utility.
Installing the IPA client fails if the 32-bit packages are installed on a 64-bit system because equired NSS dependencies are not installed.
If any previous version of Red Hat Enterprise IPA or the Identity Management tech preview are installed, they must be uninstalled before the latest version of Identity Management can be installed and configured. Otherwise, there are problems connecting to the Identity Management LDAP server.
It should be possible to reconnect a replica to a master IPA server (meaning, to create a new replication agreement), using the ipa-replica-manage connect command. However, once a connection between a replica and server is deleted using ipa-replica-manage del, a new connection cannot be created. It fails with this error:
unexpected error: list index out of range
When a replica is uninstalled, the ipa-replica-manage list command still lists the replica as being in the server topology.
The ipa-replica-manage script manages both replication agreements betweenn IPA servers and synchronization agreements between an IPA server and an Active Directory server.
The force-sync, del, and re-initialize subcommands with ipa-replica-manage do not work when managing sync agreements, so these operations fail when run against an Active Directory server.
The uidNumber and gidNumber attributes on Active Directory user entries are not synced over to IPA.
The IPA server cannot be installed on a machine with a dual NIC. When two DNS A records exist for the same hostname, the installer fails with this error:
Server host name [server1.example.com]:
Warning: skipping DNS resolution of host server1.example.com
The domain name has been calculated based on the host name.
Please confirm the domain name [example]:
Unable to resolve IP address for host name
Please provide the IP address to be used for this host name:
