Troubleshooting Kerberos authentication to LDAP servers
If you experience problems with Kerberos authentication to an LDAP server, refer to error messages from your Open Liberty server or HTTP error messages to debug the problem. The following information can help determine the causes of common problems and error messages that are associated with Kerberos authentication to LDAP servers.
If multiple user registries are configured for an Open Liberty server, all basic, custom, and LDAP user registries are combined into a single federated user registry. By default, the server must successfully search for the user in all participating user registries to verify that the user is unique within the federated user registry. If a Kerberos-enabled LDAP server in a federated registry uses a Kerberos ticket cache to hold user credentials and the credentials expire, a search of the LDAP registry fails. To resolve the problem, renew the Kerberos ticket cache. For example, you can renew the Kerberos ticket cache by using the Java kinit tool.
To avoid failures if a user registry is unavailable, configure the
allowOpIfRepoDown attribute in your
server.xml file. Set the
allowOpIfRepoDown attribute to
true on the
primaryRealm subelement of the
federatedRepository element, as shown in the following example:
<federatedRepository> <primaryRealm name="FederatedRealm" allowOpIfRepoDown="true"> <participatingBaseEntry name="o=SampleBasicRealm"/> <participatingBaseEntry name="o=ibm,c=us"/> </primaryRealm> </federatedRepository>
For more information, see the Federated User Registry feature.
allowOpIfRepoDown attribute on the
federatedRepository element can help avoid failures if one or more user registries in a federated user registry are unavailable. However, this configuration might result in slower overall performance if Kerberos credentials are specified in a
ccache file with the
krb5TicketCache attribute. When Kerberos credentials are in a
ccache file, Open Liberty attempts to auto-renew expiring credentials, which can result in slower performance.
To avoid this problem, you can specify Kerberos credentials in a
keytab file with the
kerberos element. Credentials in a
keytab file do not expire so auto-renewal is not necessary. For more information, see Kerberos authentication for Open Liberty.
If the Kerberos principal name is not found in the Kerberos ticket cache file, Open Liberty logs the
CWIML message type. A missing Kerberos principal name can occur for the following reasons:
No credential was generated for the Kerberos principal name, which results in an incorrect Kerberos configuration.
The Kerberos ticket cache contains an expired credential.
In either case, renew the Kerberos ticket cache to resolve the problem. For example, you can renew the Kerberos ticket cache by using the Java kinit tool.
Depending on the type of Java SDK, the message that you can receive is similar to one of the following examples:
CWIML4507E: Kerberos login failed with the [email protected] Kerberos principal and the C:\krb5\krb5-user1.cc Kerberos credential cache (ccache). javax.security.auth.login.LoginException: Unable to obtain password from user CWIML4520E: The LDAP operation could not be completed. The LDAP naming exception javax.naming.AuthenticationException: GSSAPI [Root exception is javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Ticket expired (32))]] occurred during processing. CWIML4520E: The LDAP operation could not be completed. The LDAP naming exception javax.naming.NamingException: CWIML4507E: Kerberos login failed with the [email protected] Kerberos principal and the C:\krb5\krb5-user1.cc Kerberos credential cache (ccache). javax.security.auth.login.LoginException: Unable to obtain password from user
To review the expiration time of the Kerberos principal user, run the Java klist tool.