This section discusses the following issues that occur during authentication:
If users have the same common name and exist in different containers under the same authentication search base, one or more attributes in addition to the common name must be configured for authentication to uniquely identify the user. You can set up an authentication class to handle duplicate common names.
Select either the name/password or secure name/password class.
Add two properties to the class:
Query: The value of the Query attribute needs to be a valid LDAP query string. Field names from the JSP login form can be used in the LDAP query string as variables for LDAP attribute values. The variables must be enclosed between two % characters. For example, (&(objectclass=person)(cn=%Ecom_User_ID%)(mail=%Ecom_Email%)) queries for an object of type person that contained a common name equal to the Ecom_User_ID field from the specified JSP form and mail equal to the Ecom_Email field from the same JSP form.
JSP: The JSP property value needs to be the name of a new .jsp file that includes all the needed fields for the Query property. The value of this attribute does not include the .jsp extension of the file. For example, if you create a new .jsp file named login2.jsp, the value of the JSP property is login2.
For more information on creating custom login pages that prompt for more than username and password, see Section 2.1, Customizing the Identity Server Login Page.
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.
If you have created an admin user for the user store, make sure the user has sufficient rights to find the users in the specified the search contexts. For more information about the required rights, see Section 3.1.3, Configuring an Admin User for the User Store.
Check the user store health and replica layout. See TID 3066352.
Ensure that the user exists in the user store and that the user’s context is defined as a search context.
Make sure the Liberty protocol is enabled if you have configured Access Manager devices to use the Identity Server for authentication (click > > ).
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 (click > > ).
Ensure that the authentication contract matches the base URL scheme. For example, check to see if SSL is 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 NetIQ Access Manager 3.1 SP5 Setup Guide.
If your LDAP user store is large, make sure that the search contexts are as specific as possible to avoid searching the entire tree for a user.
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. (Click > > > > > > .) 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 Identity 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 that 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.
The Access Manager releases previous to Access Manager 3.1 SP1 allowed a colon in the Set-Cookie header. Because the cookie specifications stipulate that a colon character cannot be used in a cookie, the Set-Cookie header in Access Manager 3.1 SP1 removes the colon and sets a value similar to the following:
UrnNovellNidpClusterMemberId=~03~0Bslo~0A~0B~14mop~0C~09; Path=/nidp
A second Set-Cookie header is included with the colon value to allow for backward compatibility with devices that have not been upgraded to Access Manager 3.1 SP1. The devices requiring this old style cookie include Identity Servers that haven’t been upgraded and any device with an Embedded Service Provider that hasn’t been upgraded. The old Set-Cookie header value looks similar to the following:
urn:novell:nidp:cluster:member:id=~03~0Bslo~0A~0B~14mop~0C~09; Path=/nidp
Both cookies contain the same information. Setting the two cookies does not impact functionality or performance.