This section discusses the following issues that occur during authentication:
Use LAN traces to check requests, responses, and interpacket delay times.
In the user store logs, confirm that the request arrived. Check for internal errors.
Check the user store health and replica layout. See TID 3066352.
Ensure that the user exists in the user store and that the context is defined.
Check the properties of the class and method. For example, the search format on the properties must match what you’ve defined on a custom login page. You might be asking for a name/password login, but the method specifies e-mail login criteria.
Enable authentication logging options. ( > > > .)
Ensure that the authentication contract matches the base URL scheme. For example, is SSL used across all components?
The following configuration problems can cause slow authentication:
If authentication is taking up to a minute per user, verify that your DNS server has been enabled for reverse lookups. The JNDI module in the Identity Server sends out a request to resolve the IP address of the LDAP server to a DNS name. If your DNS server is not enabled for reverse lookups, it takes 10 seconds for this request to fail before the Identity Server can continue with the authentication request.
If your user store resides on SUSE® Linux Enterprise Server 10, which installs with a firewall, you must open TCP 524. For more information about the ports that must be open when a firewall separates the user store from other Access Manager components, see Setting Up Firewalls
in the Novell Access Manager 3.0 SP4 Setup Guide.
You are not required to specify a search context with eDirectory™. However, when a search context is not specified, the entire directory tree is searched for the specified username. If the username is present in more than one context, authentication fails.
When using eDirectory as the user store, you should ensure that all usernames in the directory are unique, and you should also specify a search context. Otherwise, every authentication request generates a request to search the entire directory. For a small directory, this might not be significant, but for a large directory, it could take a significant amount of time.
Most errors that occur during federation occur because of time synchronization problems between servers. Ensure that all of your servers involved with federation have their time synchronized within one minute.
When the user denies consent to federate after clicking a Liberty link and logging in at the identity provider, the system displays an error page. The user should acknowledge that federation consent was denied and return to the service provider login page. This is the expected behavior when a user denies consent.
LAN traces:
Check the SSL handshake and look at trusted root list that was returned.
The client certificate issuer must be in the identity provider certificate store and be applied to all the devices in a cluster.
Ensure that the user exists and meets the authentication criteria. As the user store administrator, you can search for a subject name (or certificate mapping attributes defined) to locate a matching user.
Enable the option on the Attributes page for the X.509 authentication class. ( > > > > > > .) Enabling this option provides detailed error messages on the login browser, rather than generic messages.
Ensure that the certificate subject name matches the user you log in with, if you are chaining methods.
Use NTRadPing to test installations.
Verify that the correct UDP port 1812 is specified.
Verify that the RADIUS server can accept requests from the IDP server. This might require the NAS-IP-Address attribute along with credentials.
Verify that the user exists in the user store if multiple methods are added to a contract.
Verify if user authentication works independent of Access Manager.
Verify that the NMAS™ server is local and no tree walks are occurring across the directory.
Ensure that the NMAS_LOGIN_SEQUENCE property is defined correctly.
If the browser hangs when the user attempts to authenticate at an identity provider, determine whether a new authentication contract was created and set as the default contract on the Identity Server. If this is the case and you have an Access Gateway resource set to accept any contract from the identity provider, you should navigate to the tab for the protected resource and specify again in the drop-down menu. Then click , then update the Access Gateway.