Este contenido no está disponible en el idioma seleccionado.
Appendix A. Troubleshooting Identity Management
A.1. Installation Issues
A.1.1. Server Installation
The server installation log is located in
/var/log/ipaserver-install.log. The IdM logs, both for the server and for IdM-associated services, are covered in Section 28.1.4, “Checking IdM Server Logs”.
A.1.1.1. GSS Failures When Running IPA Commands
Immediately after installation, there can be Kerberos problems when trying to run an
ipa-* command. For example:
ipa: ERROR: Kerberos error: ('Unspecified GSS failure. Minor code may provide more information', 851968)/('Decrypt integrity check failed', -1765328353)
There are two potential causes for this:
- DNS is not properly configured.
- Active Directory is in the same domain as the IdM server.
A.1.1.2. named Daemon Fails to Start
If an IdM server is configured to manage DNS and is set up successfully, but the
named service fails to start, this can indicate that there is a package conflict. Check the /var/log/messages file for error messages related to the named service and the ldap.so library:
ipaserver named[6886]: failed to dynamically load driver 'ldap.so': libldap-2.4.so.2: cannot open shared object file: No such file or directory
This usually means that the bind-chroot package is installed and is preventing the
named service from starting. To resolve this issue, remove the bind-chroot package and then restart the IdM server.
[root@server ~]# yum remove bind-chroot # ipactl restart
A.1.2. Replica Installation
A.1.2.1. Certificate System setup failed.
If the replica installation fails on step 3 ([3/11]: configuring certificate server instance), that usually means that the required port is not available. This can be verified by checking the debug logs for the CA,
/var/log/pki-ca/debug, which may show error messages about being unable to find certain entries. For example:
[04/Feb/2016:22:29:03][http-9445-Processor25]: DatabasePanel comparetAndWaitEntries ou=people,o=ipaca not found, let's wait
The only resolution is to uninstall the replica:
[root@ipareplica ~]# ipa-server-install --uninstall
After uninstalling the replica, ensure that port 7389 on the replica is available, and retry the replica installation.
A.1.2.2. There are SASL, GSS-API, and Kerberos errors in the 389 Directory Server logs when the replica starts.
When the replica starts, there can be a series of SASL bind errors recorded in the 389 Directory Server logs stating that the GSS-API connection failed because it could not find a credentials cache:
slapd_ldap_sasl_interactive_bind - Error: could not perform interactive bind for id [] mech [GSSAPI]: error -2 (Local error) (SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credentials cache file '/tmp/krb5cc_496' not found)) ...
The replica is looking for a credentials cache in
/tmp/krb5cc_496 (where 496 is the 389 Directory Server user ID) and cannot find it.
There may also be messages that the server could not obtain Kerberos credentials for the host principal:
set_krb5_creds - Could not get initial credentials for principal [ldap/ replica1.example.com] in keytab [WRFILE:/etc/dirsrv/ds.keytab]: -1765328324 (Generic error)
These errors are both related to how and when the 389 Directory Server instance loads its Kerberos credentials cache.
While 389 Directory Server itself supports multiple different authentication mechanisms, Identity Management only uses GSS-API for Kerberos connections. The 389 Directory Server instance for Identity Management keeps its Kerberos credentials cache in memory. When the 389 Directory Server process ends — like when the IdM replica is stopped — the credentials cache is destroyed.
Also, the 389 Directory Server is used as the backend storage for the principal information for the KDC.
When the replica then restarts, the 389 Directory Server instance starts first, since it supplies information for the KDC, and then the KDC server starts. This start order is what causes the GSS-API and Kerberos connection errors.
The 389 Directory Server attempts to open a GSS-API connection, but since there is no credentials cache yet and the KDC is not started, the GSS connection fails. Likewise, any attempt to obtain the host credentials also fails.
These errors are transient. The 389 Directory Server re-attempts the GSS-API connection after the KDC starts and it has a credentials cache. The 389 Directory Server logs then record a
bind resumed message.
These startup GSS-API connection failures can be ignored as long as that connection is successfully established.
A.1.2.3. The DNS forward record does not match the reverse address
When configuring a new replica, installation can fail with a series of certificate errors and, ultimately an error that the DNS forward and reverse records do not match.
ipa: DEBUG: approved_usage = SSLServer intended_usage = SSLServer ipa: DEBUG: cert valid True for "CN=ipa-server2.example.com,O=EXAMPLE.COM" ipa: DEBUG: handshake complete, peer = 192.168.17.37:9444 Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) ... ipa: DEBUG: Created connection context.ldap2_21534032 ipa: DEBUG: Destroyed connection context.ldap2_21534032 The DNS forward record ipa-server2.example.com. does not match the reverse address ipa-server2.example.org
The hostname for every server and replica in the IdM domain must be fully resolvable for both DNS forward (A) and reverse (PTR) records. Both forward and reverse records are checked during authentication and certificate-related operations. If the hostnames in the records do not match, then both certificate errors and DNS errors are returned.
This problem can occur if multiple hostnames are used for a single PTR record. This is allowed in the DNS standard, but it creates problems during IdM replica creation when it attempts to configure services.
Ensure the primary hostname for the replica host is the only one returned for PTR lookups and remove any duplicate or additional hostnames.
Verifying the DNS A and PTR records is covered in Section 2.4.1, “DNS Records”.
A.1.3. Client Installations
For clients configured using
ipa-client-install, the client installation log is located in /var/log/ipaclient-install.log. The IdM logs, both for the server and client and for IdM-associated services, are covered in Section 28.1.4, “Checking IdM Server Logs”.
These are some issues and workarounds for client installation problems.
A.1.3.1. The client can't resolve reverse hostnames when using an external DNS.
While IdM can host its own DNS server as part of the domain services, it can also use external DNS name server. However, because of some of the limitations of reverse DNS, there can be problems with resolving reverse lookups if the external DNS is listed in the client's
/etc/resolv.conf file or if there are other resources on the network with SRV records, like Active Directory.
The problem is that the external DNS name server returns the wrong hostname for the IdM server.
One way this exhibits is errors with finding the IdM server in the Kerberos database:
Jun 30 11:11:48 server1 krb5kdc[1279](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.60.135: NEEDED_PREAUTH: admin EXAMPLE COM for krbtgt/EXAMPLE COM EXAMPLE COM, Additional pre-authentication required
Jun 30 11:11:48 server1 krb5kdc[1279](info): AS_REQ (4 etypes {18 17 16 23}) 192.168.60.135: ISSUE: authtime 1309425108, etypes {rep=18 tkt=18 ses=18}, admin EXAMPLE COM for krbtgt/EXAMPLE COM EXAMPLE COM
Jun 30 11:11:49 server1 krb5kdc[1279](info): TGS_REQ (4 etypes {18 17 16 23}) 192.168.60.135: UNKNOWN_SERVER: authtime 0, admin EXAMPLE COM for HTTP/server1.wrong.example.com@EXAMPLE.COM, Server not found in Kerberos database
There are several ways to work around this issue:
- Edit the
/etc/resolv.conffile to remove the external DNS name server references. - Add reverse lookup records for each IdM server.
- Give the IdM client or domain a subnet and forward all requests for that subnet.
A.1.3.2. The client is not added to the DNS zone.
If a client is in a subnet not controlled by an IdM DNS server, then the
nsupdate command may fail to add the client to the DNS zone when ipa-client-install runs.
If IdM is managing the DNS domain, then add a zone entry for the client manually, as described in Section 17.7, “Managing DNS Record Entries”. For example:
[jsmith@ipaserver ~]$ kinit admin [jsmith@ipaserver ~]$ ipa dnsrecord-add ipaclient.example.com www --a-rec 1.2.3.4
If the DNS domain is managed outside of IdM, the resource record can be added manually to the zone configuration. For information on DNS in Red Hat Enterprise Linux, see the DNS chapter in the Deployment Guide.
A.1.4. Uninstalling an IdM Client
For Red Hat Enterprise Linux clients, the
ipa-client-install utility can be used to uninstall the client and remove it from the IdM domain. To remove the client, use the --uninstall option.
# ipa-client-install --uninstall
Note
There is an uninstall option with the
ipa-join command. This is called by ipa-client-install --uninstall as part of the uninstallation process. However, while the ipa-join option removes the client from the domain, it does not actually uninstall the client or properly remove all of the IdM-related configuration. Do not run ipa-join -u to attempt to uninstall the IdM client. The only way to uninstall a client completely is to use ipa-client-install --uninstall.
