This section provides information about the following topics:
Section 26.5.1, Useful Networking Tools for Linux Identity Server
Section 26.5.2, Troubleshooting 100101043 and 100101044 Liberty Metadata Load Errors
Section 26.5.4, Problems Reading Keystores after Identity Server Re-installation
Section 26.5.5, After Setting Up the User Store to Use SecretStore, Users Report 500 Errors
Section 26.5.9, Attributes are Not Available Through Form Fill When OIOSAML Is Enabled
Section 26.5.11, Enabling Secure or HTTPOnly Flags for Cluster Cookies
Section 26.5.12, Apache Portable Runtime Native Library Does Not Get Loaded in Tomcat
Section 26.5.13, Metadata Mentions Triple Des As Encryption Method
Section 26.5.18, Attribute Query from OIOSAML.SP Java Service Provider Fails with Null Pointer
Section 26.5.19, Disabling the Certificate Revocation List Checking
Section 26.5.22, Requesting the Authentication to a Service Provider Fails
Section 26.5.23, SAML 2.0 POST Compression Failure Does not Throw a Specific Error Code
Section 26.5.24, SAML 1.1 Service Provider Re-requests for Authentication
Section 26.5.25, Issue in Generating WS-Federation Claim for SharePoint 2010 On Windows
Section 26.5.26, The Identity Server Statistics Logs Do Not Get Written In Less Than One Minute
Section 26.5.28, Terminating an Existing Authenticated User from the Identity Server
Section 26.5.29, Clustered Nodes Looping Due to JGroup Issues
Section 26.5.31, Unsafe Server Certificate Change in SSL/TLS Renegotiations Is Not Allowed
For information about Identity Server logging, see Section 17.3.1, Configuring Logging for Identity Server and Section 17.3.2, Configuring Session-Based Logging.
You can use the following tools (Linux and open source) to troubleshoot network problems:
netstat: Displays information related to open ports on your server. Lets you view listeners and various IP addresses, such as the TCP output state.
iptables: Allows you to change the default ports (8080 and 8443) to the standard ports (80 and 443) for HTTP traffic.
netcat: A networking utility that reads and writes data across network connections, using the TCP/IP protocol. Netcat is useful for checking connectivity with the user store.
ldapsearch: An LDAP search tool useful for the Administration Console and Identity Server. For example, you can generate an LDAP search/bind matching what the Identity Server sends, to confirm whether an issue is with the Identity Server JAR files.
tcpdump: A command line tool for monitoring network traffic. Captures and displays packet headers and matches them against a set of criteria.
LDAP Browser/Editor: Lets you export configuration information to a file, and to confirm that Access Manager objects and attribute values are valid in an AccessManagerContainer. A number of open source versions are available from the Internet.
The Identity Server is the identity provider for other Access Manager components. Access Gateways has Embedded Service Providers. When a device is imported into the Administration Console and an Identity Server configuration is selected for them, a trusted relationship is established with the Identity Server by using test certificates. When you change these certificates or change from using HTTP to HTTPS, you need to ensure that the trusted relationship is reestablished. Metadata is used for establishing trusted relationships.
The metadata exchanged between service providers and identity providers contains public key certificates, key descriptors for message signing, a URL for the SSO service, a URL for the SLO (single logout) service, and so on. With Access Manager, this metadata is accessible on both the Identity Server and the Embedded Service Provider of the device. Errors are generated when either the identity provider could not load the service provider’s metadata (100101043), or the service provider could not load the metadata of the identity provider (100101044).
If users are receiving either of these errors when they attempt to log in, verify the following:
If these steps do not solve your problem, try the following:
For information about metadata validation process and the flow of events that occur when accessing a protected resource on the Access Gateway, see “Troubleshooting 100101043 and 100101044 Errors in Access Manager”.
If you change the base URL of the Identity Provider, all service providers, including Embedded Service Providers, need to be updated so that they use the new metadata:
If you change the base URL of the Identity Provider, all Access Manager devices that have an Embedded Service Provider need to be updated so that new metadata is imported. To force a re-import of the metadata, you need to configure the device so it doesn’t have a trusted relationship with the Identity Server, update the device, reconfigure the device for a trusted relationship, then update the device. The following steps explain how to force the Access Gateway to re-import the metadata of the Identity Server.
In the Administration Console, click Devices > Access Gateways > Edit > Reverse Proxies/Authentication.
Select None for the Identity Server Cluster option, click OK twice, then update the Access Gateway.
Click Edit > Reverse Proxies/Authentication.
Select an Identity Server configuration for the Identity Server Cluster option, click OK twice, then update the Access Gateway.
If you have set up federation with another provider over the Liberty, SAML 1.1, SAML 2.0, or WS Federation protocol and you change the base URL of the Identity Server, you need to update the provider with the new metadata to reestablish the trusted relationship. If the provider is another Identity Server, follow the procedure below to update the metadata; otherwise, follow the provider’s procedures.
In the Administration Console of the provider, click Devices > Identity Servers > Edit > [Protocol] > [Provider] > Metadata.
Click Reimport.
Follow the steps in the wizard.
For more information, see Section 3.9.7, Managing Metadata.
When the service provider tries to access the metadata on the identity provider, it sends the request to the hostname defined in the base URL configuration of the Identity Server. The base URL in the Identity Server configuration is used to build all the metadata end points.
To view the metadata of the Identity Server with a DNS name of idpcluster.lab.novell.com, enter the following URL:
https://idpcluster.lab.novell.com:8443/nidp/idff/metadata
Scan through the document and notice the multiple references to https://idpcluster.lab.novell.com/... You should see lines similar to the following:
<md:SoapEndpoint> https://idpcluster.lab.novell.com:8443/nidp/idff/soap </md:SoapEndpoint> <md:SingleLogoutServiceURL> https://idpcluster.lab.novell.com:8443/nidp/idff/slo </md:SingleLogoutServiceURL> <md:SingleLogoutServiceReturnURL> https://idpcluster.lab.novell.com:8443/nidp/idff/slo_return </md:SingleLogoutServiceReturnURL>
The Embedded Service Provider of the Access Gateway must be able to resolve the idpcluster.lab.novell.com hostname of the Identity Server. To test that it is resolvable, send a ping command with the hostname of the Identity Server. For example, from the Access Gateway:
ping idpcluster.lab.novell.com
The same is true for the Identity Server. It must be able to resolve the hostname of the Access Gateway. To discover the URL for the Access Gateway metadata:
In the Administration Console, click Devices > Access Gateways > Edit > Reverse Proxy/Authentication.
View the Embedded Service Provider section.
The URL of the metadata is displayed in this section.
To view the metadata, enter the displayed URL. Scan through the document and notice the multiple references to the hostname of the Access Gateway. You should see lines similar to the following. In these lines, the hostname is ag1.provo.novell.com.
<md:SoapEndpoint> http://ag1.provo.novell.com:80/nesp/idff/spsoap </md:SoapEndpoint> <md:SingleLogoutServiceURL> http://ag1.provo.novell.com:80/nesp/idff/spslo </md:SingleLogoutServiceURL> <md:SingleLogoutServiceReturnURL> http://ag1.provo.novell.com:80/nesp/idff/spslo_return </md:SingleLogoutServiceReturnURL>
To test that the Identity Server can resolve the hostname of the Access Gateway, send a ping command with the hostname of the Access Gateway. For example, from the Identity Server:
ping ag1.provo.novell.com
To view sample log entries that are logged when a DNS name cannot be resolved, see The Embedded Service Provider Cannot Resolve the Base URL of the Identity Server.
Ensure that the certificates for the Identity Server and the Embedded Service Provider match the hostnames defined in the metadata URL (see DNS Name Resolution).
When the Identity Server and the Access Gateway are enabled for HTTPS, all communication to these devices requires that the devices send back a server certificate. Not only must the certificate be assigned to the appropriate device, but the subject name of the device certificate must match the hostname of the device it is assigned to.
To verify the certificate name of the Identity Server certificate:
In the Administration Console, click Devices > Identity Servers > Edit.
Click the SSL Certificate icon.
The SSL Connector keystore is displayed
Verify that the subject name of the certificate matches the DNS name of the Identity Server.
If the names match, a certificate name mismatch is not causing your problem.
If the names do not match, you need to either create a certificate that matches or import one that matches. For information about how to create a certificate for the Identity Server, see Section 14.0, Enabling SSL Communication.
To verify the certificate name of the Access Gateway certificate:
In the Administration Console, click Devices > Access Gateways > Edit > [Name of Reverse Proxy].
Read the alias name of the server certificate, then click the Server Certificate icon.
Verify that the Subject name of the server certificate matches the published DNS name of the proxy service of the Access Gateway.
If the names match, a certificate name mismatch is not causing your problem.
If the names do not match, you need to either create a certificate that matches or import one that matches. For information about how to create an Access Gateways certificate, see Configuring the Access Gateway for SSL.
To view sample log entries that are logged to the catalina.out file when the certificate has an invalid name, see The Server Certificate Has an Invalid Subject Name.
Ensure that the issuers of the Identity Server and Embedded Service Provider certificates are added to the appropriate trusted root containers.
When the server certificates are sent from the identity provider to the service provider client, and from the service provider to the identity provider client, the client needs to be able to validate the certificates. Part of the validation process is to confirm that the server certificate has been signed by a trusted source. By default, well known external trusted certificates are bundled with Access Manager. You can view this list here: Administration Console > Security > Certificates > External Trusted Roots. If the issuer of server certificate is not present in the External Trusted Root list, the import the issuers of the server certificate (intermediate and trusted roots) into the correct trusted root stores:
The intermediate and trusted roots of the Embedded Service Provider certificate must be imported into the NIDP Trust Store.
The intermediate and trusted roots of the Identity Server certificate must be imported into the ESP Trust Store.
For more information, see Section 10.5, Importing a Signed Certificate.
If you use certificates generated by the Administration Console CA, the trusted root certificate is the same for the Identity Server and the Embedded Service Provider. If you are using external certificates, the trusted root certificate might not be the same, and there might be intermediate certificates that need to be imported.
To verify the trusted root certificates:
In the Administration Console, click Security > Certificates.
Determine the issuer of the Identity Server certificate and the Embedded Service Provider certificate:
Click the name of the Identity Server certificate, note the name of the Issuer, then click Close.
Click the name of the Embedded Service Provider certificate of the Access Gateway, note the name of the Issuer, then click Close.
(Conditional) If you do not know the names of these certificates, see Certificate Names.
To verify the trusted root for the Identity Server, click Devices> Identity Servers > Edit > Security > NIDP Trust Store.
In the Trusted Roots section, scan for a certificate subject that matches the issuer of the Embedded Service Provider certificate, then click its name.
If the Issuer has the same name as the Subject name, then this certificate is the root certificate.
If the Issuer has a different name than the Subject name, the certificate is an intermediate certificate in the chain. Click Close, and ensure that another certificate in the trust store is the root certificate. If it isn’t there, you need to import it and any other intermediate certificates between the one you have and the root certificate.
To verify the trusted root for the Embedded Service Provider, click Devices > Access Gateways > Edit >Service Provider Certificates> Trusted Roots.
In the Trusted Roots section, scan for a certificate subject that matches the issuer of the Identity Server certificate, then click its name.
If the Issuer has the same name as the Subject name, then this certificate is the root certificate.
If the Issuer has a different name than the Subject name, the certificate is an intermediate certificate in the chain. Click Close, and ensure that another certificate in the trust store is the root certificate. If it isn’t there, you need to import it and any other intermediate certificates between the one you have and the root certificate.
(Optional) If you have clustered your Identity Servers and Access Gateways and you are concerned that not all members of the cluster are using the correct trusted root certificates, you can re-push the certificates to the cluster members.
Click Auditing > Troubleshooting > Certificates.
Select the Trust Store of your Identity Servers and Access Gateways, then click Re-push certificates.
Update the Identity Severs and Access Gateways.
Check the command status of each device to ensure that the certificate was pushed to the device. From the Identity Servers page or the Access Gateways page, click the Commands link.
To view sample log entries that are logged to the catalina.out file when a trusted root certificate is missing, see Trusted Roots Are Not Imported into the Appropriate Trusted Root Containers.
You can enable Identity Server logging to dump more verbose Liberty information to the catalina.out file on both the Identity Server and the Embedded Service Provider of the Access Gateway.
In the Administration Console, click Devices > Identity Servers > Edit > Logging.
Select Enabled for File Logging and Echo to Console.
In the Component File Logger Levels section, set Application and Liberty to a debug level.
Click OK, update the Identity Server, then update the Access Gateway.
After enabling and applying the changes, duplicate the issue once more to add specific details to the log file for the issue.
If the error is the 100101044 error, look at the log file on the Embedded Service Provider for the error code
If the error is the 100101043 error, look at the log file on the Identity Server for the error code.
On Linux, look at the catalina.out file, and on Windows, look at the stdout.log file.
(Conditional) To view the log files from the Administration Console, click Auditing > General Logging, then select the file and download it.
(Conditional) To view the log files on the device, change to the log directory.
On Linux, change to the /var/opt/novell/nam/logs/idp directory.
On Windows Server 2008, change to the /Program Files (x86)/Novell/Tomcat/logs directory.
Below are a few typical entries illustrating the most common problems. They are from the catalina.out file of the Embedded Service Provider:
When the Embedded Service Provider cannot resolve the DNS name of the Identity Server, the metadata cannot be loaded and a hostname error is logged. In the following entries, the Embedded Service Provider cannot resolve the idpcluster.lab.novell.com name of the Identity Server.
<amLogEntry> 2009-08-06T16:24:56Z INFO NIDS Application: AM#500105024: AMDEVICEID#esp-09C720981EEE4EB4: AMAUTHID#2CA1168DF7343A42C7879 E707C51A03C: ESP is requesting metadata from IDP https:// idpcluster.lab.novell.com/nidp/idff/metadata </amLogEntry> <amLogEntry> 2009-08-06T16:24:56Z SEVERE NIDS IDFF: AM#100106001: AMDEVICEID#esp-09C720981EEE4EB4: Unable to load metadata for Embedded Service Provider: https://idpcluster.lab.novell.com/nidp/idff/ metadata, error: AM#300101046: AMDEVICEID#esp-09C720981EEE4EB4:: Attempted to connect to a url with an unresolvable host name </amLogEntry> <amLogEntry> 2009-08-06T16:24:56Z INFO NIDS Application: AM#500105039: AMDEVICEID#esp-09C720981EEE4EB4: AMAUTHID#2CA1168DF7343A42C7879 E707C51A03C: Error on session id 2CA1168DF7343A42C7879E707C51A03C, error 100101044-esp-09C720981EEE4EB4, Unable to authenticate. AM#100101044: AMDEVICEID#esp-09C720981EEE4EB4:: Embedded Provider failed to load Identity Provider metadata </amLogEntry>
When the trusted roots are not imported into the appropriate trusted root containers, a certificate exception is thrown and an untrusted certificate message is logged. In the following log entries, the Embedded Service Provider is requesting metadata from the Identity Server, but the Embedded Service Provider does not trust the Identity Server certificate because the trusted root of the issuer of the Identity Server certificate is not in the Embedded Service Provider’s trusted root container.
<amLogEntry> 2009-08-05T16:07:53Z INFO NIDS Application: AM#500105024: AMDEVICEID#esp-09C720981EEE4EB4: AMAUTHID#D983B08C28D35221D13 9D33E5324F98F: ESP is requesting metadata from IDP https://idpcluster.lab.novell.com/nidp/idff/metadata </amLogEntry> <amLogEntry> 2009-08-05T16:07:53Z SEVERE NIDS IDFF: AM#100106001: AMDEVICEID#esp-09C720981EEE4EB4: Unable to load metadata for Embedded ServiceProvider: https://idpcluster.lab.novell.com/nidp/idff/metadata, error: java.security.cert.CertificateException: Untrusted Certificate- chain </amLogEntry> <amLogEntry> 2009-08-05T16:07:53Z INFO NIDS Application: AM#500105039: AMDEVICEID#esp-09C720981EEE4EB4: AMAUTHID#D983 B08C28D35221D139 D33E5324F98F: Error on session id D983B08C28D35221D139D33E5324F98F, error 100101044-esp-09C720981EEE4EB4, Unable to authenticate. AM#100101044: AMDEVICEID#esp-09C720981EEE4EB4:: Embedded Provider failed to load Identity Provider metadata </amLogEntry>
When the certificate has an invalid subject name, the handshake fails. In the log entries below, the Embedded Service Provider is requesting metadata from the Identity Server. The server certificate name does not match, so the Embedded Service Provider is unable to authenticate and get the metadata necessary to establish the trusted relationship.
<amLogEntry> 2009-07-05T16:07:53Z INFO NIDS Application: AM#500105024: AMDEVICEID#esp-09C720981EEE4EB4: AMAUTHID#D983B08C28D35221D139D33 E5324F98F: ESP is requesting metadata from IDP https://idpcluster.lab.novell.com/nidp/idff/metadata </amLogEntry> <amLogEntry> 2009-07-05T16:07:53Z SEVERE NIDS IDFF: AM#100106001: AMDEVICEID#esp-09C720981EEE4EB4: Unable to load metadata for Embedded Service Provider: https://idpcluster.lab.novell.com/nidp/idff/metadata, error: Received fatal alert: handshake_failure </amLogEntry> <amLogEntry> 2009-07-05T16:07:53Z INFO NIDS Application: AM#500105039: AMDEVICEID#esp-09C720981EEE4EB4: AMAUTHID#D983B08C28D35221D139D33 E5324F98F: Error on session id D983B08C28D35221D139D33E5324F98F, error 100101044-esp-09C720981EEE 4EB4, Unable to authenticate. AM#100101044: AMDEVICEID#esp-09C720981EEE4EB4: : Embedded Provider failed to load Identity Provider metadata </amLogEntry>
To test whether the metadata is available for download, enter the metadata URL of the identity provider and service provider. If the DNS name of the identity provider is idpcluster.lab.novell.com, open a browser at the Identity Server and enter the following URL:
https://idpcluster.lab.novell.com:8443/nidp/idff/metadata
Open a browser on the Access Gateway Service, then enter the same URL.
Because the Access Gateway Appliance does not have a graphical interface, you need to use the curl command to test whether the Access Gateway Appliance can access the metadata of the Identity Server. If the DNS name of the identity provider is idpcluster.lab.novell.com, enter the following command from the Access Gateway machine:
curl -k https://idpcluster.lab.novell.com:8443/nidp/idff/metadata
To test whether the Identity Server can access the metadata URL of the Access Gateway, open a browser on the Identity Server machine. If the published DNS name of service provider is www.aleris.net, enter the following URL:
https://www.aleris.net/nesp/idff/metadata
Occasionally, there are issues where the subject name was auto-generated and the entire configuration appears to be correct, but the 100101044/100101043 error is still reported. Delete the auto-generated certificate and manually re-create the server certificate, making sure that it is added to the relevant devices and stores.
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 about creating custom login pages that prompt for more than username and password, see 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, ensure that the user has sufficient rights to find the users in the specified the search contexts. For more information about the required rights, see 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.
Ensure that the Liberty protocol is enabled if you have configured Access Manager devices to use the Identity Server for authentication (click Identity Servers > Edit > General Configuration).
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 Identity Servers > Edit > Logging).
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 4.1 Installation and Upgrade Guide.
If your LDAP user store is large, ensure 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 Show Certificate Errors option on the Attributes page for the X.509 authentication class. (Click Identity Servers > Servers > Edit > Local > Classes > [x.509] > Properties.) 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 Overview tab for the protected resource and specify Any again in the Contract drop-down menu. Then click OK, 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.
This can occur if you replace a hard drive and incorrectly reinstall the Identity Server. See Uninstalling Components in the NetIQ Access Manager 4.1 Installation and Upgrade Guide for the correct procedure.
If your eDirectory user store is running on SLES 11 SP1 64-bit (or a higher version) on x86-64 hardware, you can install the NMAS SAML method for SecretStore from the Administration Console, but the eDirectory server is missing the required support libraries.
When users try to enter values for SecretStore entries in a form, they receive the following message:
Status: 500 Internal Server Error, Description: Datastore Error
To correct the problem, you need to install the missing libraries on your eDirectory server. For instructions, see TID 7006437.
Allow multiple browser session logout option in the Identity Server cluster specifies whether a user with more than one session to the server is presented with an option to log out of all sessions. If you do not select this option, only the current session can be logged out. If you deselect this option in instances where multiple users log in as guests, then when one user logs out, none of the other guests are logged out. When you enable this option, you must also restart any Embedded Service Providers that use this Identity Server configuration and for logout URL you have to configure it as /nidp/app/logout.
After consuming a SAML response, the browser is redirected to an incorrect URL, check whether the relay state is URL encoded. To fix this issue, have the following entries in the web.xml file as indicated below:
(/opt/novell/nids/lib/webapp/WEB-INF/web.xml)<context-param> <param-name>decodeRelayStateParam</param-name> <param-value>true</param-value></context-param>
While adding the identity provider, do not specify the login URL and clear the show card option. Use the login URL to access the service provider:
https://idp.sitea.novell.com/nidp/saml/idpsend?
PID = https://idp.siteb.novell.com/nidp/saml/metadata&
TARGET = https://idp.siteb.novell.com/nidp/app
In the identity provider, while adding the service provider, configure ID in the intersite transfer page. Configure the login URL with port number -2443 instead of the provider ID URL:
https://idp.sitea.novell.com:2443/nidp/saml/idpsend?
id = <idname>&TARGET=https://idp.siteb.novell.com:2443/nidp/app
To workaround this issue, create a new attribute set with the OIOSAML mandatory attributes having remote attribute mapping as its OID equivalent and associate the attribute set to the identity provider configured at the SP.
To work around this issue, the administrator has to manually copy the metadata by selecting the metadata text option while configuring identity provider or service provider. The metadata text can be obtained from the browser.
By default the Identity Server and ESP cluster cookies do not have any secure or HTTPOnly flags.
To set the cluster cookies in the Identity Server you must add the following parameter at the NIDP web.xml and restart Tomcat:
Add the following parameters in web.xml below the ldapLoadThreshold context parameter:
<context-param> <param-name>secureClusterCookie</param-name> <param-value>true</param-value> </context-param>
<context-param> <param-name>httponlyClusterCookie</param-name> <param-value>true</param-value> </context-param>
To set the cluster cookies in ESP, you must add the following parameter at the NESP web.xml and restart Tomcat:
Add the following parameters in the web.xml below the ldapLoadThreshold context parameter:
<context-param> <param-name>httponlyClusterCookie</param-name> <param-value>true</param-value> </context-param>
NOTE:The secure cookies cannot be configured for ESP cluster as the communication between the Access Gateway and NESP is over HTTP on the loopback interface.
The Apache Portable Runtime (APR) native library is not enabled by default. To workaround this issue, enable the APR native library.
Steps to enable the APR native library:
Download OpenSSl.
Extract the source (tar -zxvf openssl-version).
Compile and install (cd openssl-version) using the ./config, ./config shared, make, and sudo make install commands.
For example:
idp:~/openssl-0.9.8q #./config
idp:~/openssl-0.9.8q #./config sharedapr-1.4.5
idp:~/openssl-0.9.8q #make
idp:~/openssl-0.9.8q #sudo make install
Download APR.
Extract the source (tar -zxvf apr-version).
Compile and install (cd apr-version) using the ./configure, make, and sudo make install commands.
For example:
idp:~/apr-apr-1.4.5 #./configure
idp:~/apr-apr-1.4.5 #make
idp:~/apr-apr-1.4.5 #sudo make install
Create a lib folder under Openssl-version. For example, idp:~/openssl-0.9.8q/lib #
Copy *.so files from openssl-version to lib using idp:~/openssl-0.9.8q/lib #cp ../*.so.
Extract the wrapper library sources located in the Tomcat binary bundle $CATALINA_HOME/bin/tomcat-native.tar.gz or download the latest version.
Extract the source, compile, and install $CATALINA_HOME/bin/tomcat-native-1.1.20-src using this command:
$CATALINA_HOME/bin/tomcat-native-1.1.20-src/jni/native# ./configure --with-apr=/apr-version folder location from root --with-java-home=/jdk location from -- libdir=/usr/lib/lib64 --prefix=/usr/lib/lib64 --with-ssl=/openssl folder verion from root.
Example: Idp1:/var/opt/novell/tomcat7/bin/tomcat-native-1.1.20-src/jni/native#./configure --with-apr=/root/apr-1.4.5 --with-java-home=/opt/novell/jdk1.6.0_26/
If the message says "checking OpenSSL library version... ok", installation is successful. If it shows "checking OpenSSL library version... is not compatible", installation is not successful.
Tomcat-Native-library compilation and installation:
idp1:/$CATALINA_HOME/bin/tomcat-native-1.1.20-src/jni/native # make
idp1:/$CATALINA_HOME/bin/tomcat-native-1.1.20-src/jni/native # sudo make install
Go to idp:/usr/lib/lib64 #. Crate link of these two files using the following command:
Idp:/usr/lib/lib64 # sudo ln -s libtcnative-1.dylib libtcnative-1.jnilib
Copy all files from Idp:$CATALINA_HOME/bin/tomcat-native-1.1.20-src/jni/native/.libs to your #Native library path (JAVA_LIB_PATH).
Idp:/var/opt/novell/tomcat7/bin/tomcat-native-1.1.20-src/jni/native/.libs # cp * /opt/novell/lib64
If you are running the application through the APR connectors, it needs the SSL certificate file in the .pem format.
To Create SSL Certificate File :
Log in to Admin Console.
Under the Security tab, click Certificates.
Select the certificate, which is configured in your IDP Cluster and click that certificate name.
Example: Configure a certificate with the name [new_idp] and click new_idp.
Click Export Private/Public KeyPair.
Enter the encryption and decryption password.
Save the file. File is saved as .pfx.
Convert the .pfx format to .pem using https://www.sslshopper.com/ssl-converter.html.
Certificate file to Convert: Enter the location where you have saved the .pfx file.
Type of Current Certificate: Select PFX/PKCS#12.
Type To Convert To: select Standard PEM.
Click ConvertCerficate.
PFX Password: Enter the same password as given in step e and save the file.
If you need to run your Admin Console using the APR connector, configure the following details into server.xml of your Admin Console. (vi /opt/novell/nam/adminconsole/conf/server.xml)
If you need to run your Identity Provider Server using the APR connector you can configure these details into server.xml of your Identity Provider Server. (vi /opt/novell/nam/idp/conf/server.xml)
APR Lifecycle Listener <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
APR Connector configuration:
Example: <Connector port="8443" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" UploadTimeout="true" acceptCount="100" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" SSLEngine="on" SSLCertificateFile="${catalina.home}/tomcatcert.pem" SSLCertificateKeyFile="${catalina.home}/tomcatkey.pem" SSLPassword="tomcat" /> Give the SSL Certificate File the same name as you entered for the .pem file.
NOTE:SSLCertificateFile and sslProtocol are required to run when you are using the APR connectors.
Restart tomcat.
The OIO SAML metadata has tripledes-cbc and AES128-cbc mentioned as encryption methods. If triple des is not required, edit the following related tag in metadata and import the metadata manually.
Node:<md:EncryptionMethodAlgorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
To workaround this issue, set 'agm.lagmode=false' in /opt/novell/singlebox/mag/webapps/agm/agm.properties.
To workaround this issue:
Create a brokering group that has local IDP as Identity Provider and SP1 and SP2 as Trusted Providers.
Create brokering rules for the Intersite Transfer URL requests to SP2. All requests to SP1 will be allowed.
When a persistent federation is configured or a transient federation with user mapping is configured by using Liberty, SAML 1 and SAML 2.0, the federation objects are created in the configuration store.When you delete or disable a user object, the objects in the configuration datastore related to this specific user become orphaned. These orphaned user profile objects affect the user lookup operations and system performances. These objects have to be removed manually using the Defed Tool: Federation Entry Management.
This tool clears all the orphaned federation objects related to Liberty, SAML 1, and SAML 2 from the trust and configuration datastore, except for Shared Secret entries.
NOTE:When the Access Manger setup includes Access Gateway and no persistent or transient federations have been configured, these objects are not created.
Linux:
Change the current working directory to /opt/novell/devman/nam_tools/ from a terminal.
Run this command:
/opt/novell/java/bin/java -classpath .:./lib/nam_tool.jar:./lib/nidp.jar:./lib/NAMCommon.jar:./lib/bcprov-jdk15-140.jar -Djava.util.logging.config.file=./conf/logging.properties com.novell.nam.tools.defed.DefedTool
The Defed tool will ask either to delete the orphan objects orexit from the tool. Select the option to delete the orphan objects. The tool will ask you to provide the IP address, port, user DN, and password.
The Defed tool deletes the orphaned federation objects and gives the summary of total number of federation entries encountered and number of the federation objects deleted.
This tool can be used to perform the operation on remote server too.
Windows:
Go to the C:\Program Files (x86)\Novell\nam_tools folder.
Run this command:
C:\Program Files (x86)\Novell\nam_tools>java -cp lib/nam_tool.jar;lib/nidp.jar;lib/NAMCommon.jar;lib/bcprov-jdk15-140.jar -Djava.util.logging.config.file=conf\logging.properties com.novell.nam.tools.defed.DefedTool
Provide IP address, port, user DN, and password.
The Defed tool deletes the orphaned federation objects and gives the summary of total number of federation entries encountered and number of the federation objects deleted.
This tool can be used to perform the operation on remote server too.
To workaround this issue, ensure that the Show Card option is enabled on the default contract.
To workaround this issue:
Enable the OIOSAML compliance with service provider. The OIOSAML attribute set will be populated.
By default, the mandatory attributes are listed in the Available list.
Ensure that these mandatory attributes are moved from the Available list to the Send with authentication list to avoid the Null Pointer exception with OIOSAML compliance service providers.
For ADFS 2.0 to work with NetIQ Access Manger SAML 2.0, it is required to disable the Certificate Revocation List (CRL) checking.
To disable the CRL checking:
Modify the tomcat7.conf file of the Identity Server located at /opt/novell/nam/idp/conf/tomcat7.conf
Add this parameterJAVA_OPTS="${JAVA_OPTS} -Dcom.novell.nidp.serverOCSPCRL=false"
Restart the Identity Server by using this command: /etc/init.d/novell-idp restart.
For example, if a service provider is configured for a satisfiable contract that is only satisfiable by an external provider, then Intersite transfer service does not work.
To workaround this issue, ensure that any local contract is associated with the service provider. If not, then associate the same. External provider without any local contract is not supported
To workaround this issue, verify the network card configuration for the proper DNS.
To workaround this issue:
In the Administration Console, click Devices > Identity Servers > Edit > SAML 2.0 > [Service Provider] > Authentication Response.
Change Artifact to Post in the Binding field.
The POST Compression feature is supported when both the identity provider and service provider understand SAML 2 POST deflate and inflate. If the service provider sends a compressed message, the identity provider needs to decompress the message and vice-versa. For the Access Manager identity server and service provider, the nidpconfig.properties file located in /opt/novell/nam/idp/webapps/nidp/WEBINF/classes needs to be modified to enable the SAML 2.0 POST deflate and inflate.
The behavior of SAML 1.1 service provider has been changed in 3.1 Access Manger to perform a strict check on the name space of the attributes received in assertion.
To disable this, configure the following parameter in web.xml:
<context-param> <param-name>saml1xAttributeMatchByName</param-name> <param-value>true</param-value></context-param>
When Access Manager is installed on Windows 2008 and uses a SharePoint 2010 WS-federation service provider to build trust relationship with the Identity Server, users get a 500 internal error while trying to log in to SharePoint 2010.
This error occurs because Access Manager does not find the method to generate the SharePoint claim after authenticating the user at the Identity Server.
To resolve this issue, perform the following steps:
Navigate to C:\Program Files (x86)\Novell\Tomcat\bin.
Open the tomcat7w file.
Navigate to the Java tab.
Search for the following Java Options placeholder:
-Djava.endorsed.dirs=C:\PROGRA~2\Novell\Tomcat\common\endorsed
Modify this option as follows:
-Djava.endorsed.dirs=C:\PROGRA~2\Novell\Tomcat\endorsed
NOTE:Check for the endorsed folder in Tomcat (Catalina Home). This folder should contain stax-api-1.0.1.jar, serializer.jar, xalan.jar, xercesImpl.jar, and xml-apis.jar.
The Identity Server statistics logs do not get written before one minute even though the time specified is less than one minute, for example, 10 seconds. This issue happens only when the time is specified to less than one minute.
Do not specify the time less than one minute. As a best practice, you should not set small period because it increases the load on the server and also increases the log file size exponentially.
When a user tries to authenticate with an expired client certificate, the authentication fails. The log file does not have any information about the expiration of the certificate. Browsers also do not display any error message about it.
To see the logs related to expired certificates, perform the following steps:
Enable the following Java option in tomcat7.conf under /opt/novell/nam/idp/conf/:
JAVA_OPTS="${JAVA_OPTS} -Djavax.net.debug=ssl,handshake"
This option enables SSL logs.
Restart the Identity Server.
Access Manager provides the ability for users to single sign on to back end web servers. These back end web servers provide a series of protected resources that users can only access once authenticated to an Identity Server, and authorised by the Access Gateway. Having parsed the user credentials, and credentials validated against a back end user store, the Identity Server creates and maintains an active session for that user. Only when the user manually logs out of the Identity Server, or if the user’s session timeout expires, then the user’s active session will be removed. If the user continuously accesses protected resources before the session timeout expires, the session can remain active forever.
Use case: You may want to terminate an authenticated user sometimes. Some of the cases are listed below.
User A who currently has an active session on the Identity Server and access to many protected resources, has had a designation change within the organization causing a change to resources that may be available. By forcing user A to logout and login again, his new roles or attributes may be retrieved by the Identity Server and used in policy evaluations by Access Manager to reflect his new position.
User B who currently has an active session on the Identity Server and access to many protected resources, has been asked to leave an organization and all access to protected resources must be removed. By terminating user B’s session on the Identity Server, any subsequent requests to the Identity Server will require the user to login again.
The User Sessions page in the Administration Console helps you to find users logged into your system and also helps to terminate their sessions if required. It displays the active user details for each Identity Server. You can search for a user with the user ID and terminate the sessions.
In the Administration Console, click Auditing > Troubleshooting > User Sessions.
Specify the user ID and click Search. If a match is found, it lists the IP address of the Identity Server and its sessions.
Click Terminate Sessions to terminate the sessions of the specific user.
After you have performed the above procedure, the user sessions are terminated from the Identity Server, and any other trusted service providers it has provided an identity to during this session, for example, an Access Gateway or SAML 2.0 service provider.
NOTE:User details are fetched once per administration session. The last updated date is displayed. To refresh the data, click on Refresh.
In a cluster when multiple nodes are down, failover does not occur and user experiences looping due to jgroups issues.
Workaround:Modify the /opt/novell/nids/lib/webapp/WEB-INF/web.xml file on the Identity Server as follows to increase the jgroup timeouts.
<context-param> <param-name>JGroupsConfiguration</param-name> <param value>TCP(start_port=[nidp:ClusterPort];end_port=[nidp:ClusterPort][nidp:IfExternalAddress];external_addr=[nidp:ExternalAddress][nidp:EndIf]):TCPPING(initial_hosts=[nidp:ClusterMembers];port_range=1;timeout=3500;num_initial_members=2;up_thread=true;down_thread=true):MERGE2(min_interval=10000;max_interval=30000):FD_SOCK([nidp:IfExternalAddress]bind_addr=[nidp:ExternalAddress][nidp:EndIf]):FD(shun=true;timeout=5000;max_tries=5;up_thread=true;down_thread=true):VERIFY_SUSPECT(timeout=2000;down_thread=false;up_thread=false):pbcast.NAKACK(down_thread=true;up_thread=true;gc_lag=100;retransmit_timeout=3000):pbcast.STABLE(desired_avg_gossip=20000;down_thread=false;up_thread=false):pbcast.STATE_TRANSFER():pbcast.GMS(merge_timeout=10000;join_timeout=5000;join_retry_timeout=2000;shun=true;print_local_addr=[nidp:DebugOn];down_thread=true;up_thread=true)</param-value> </context-param>
For more information about the timeout options, see the following links:
If your userstore contains alias users and if you have configured alias class for authentication, the authentication fails. For the workaround, see TID 7015163.
After upgrading Access Manager from a version earlier than 4.0 Service Pack 1, if you have configured the Identity Server to point to the Load Balancer virtual IP address than the real IP addresses of the LDAP replica servers, the Identity Server’s request to different LDAP server replicas fails.
The Identity Server health becomes yellow from green and displays the following warning:
Ensure that the following replicas are operating correctly XXXX
After validating the LDAP server replica, the following message is displayed:
Server certificate change is restricted during renegotiation
This happens because Access Manager uses JDK version 7u71 or later from the version 4.0 Service Pack 1 onwards. In JDK 7u71, unsafe server certificate change in SSL/TLS renegotiations is not allowed by default.
To workaround this issue, perform any one of the following actions:
Add the following line in the /opt/novell/nam/idp/conf/tomcat7.conf file:
JAVA_OPTS="${JAVA_OPTS} -Djdk.tls.allowUnsafeServerCertChange=true"
Instead of specifying the load balancer virtual IP address as the LDAP replica server, ensure that the Identity Server refers to each LDAP server directly and not through the load balancer. In this way, the Identity Server maintains all communications with the LDAP servers directly, maintains states and connection information.
Create a wildcard certificate and assign this server certificate to all the LDAP servers in the replica ring.