This section provides information about the following topics:
Section 30.3.1, Useful Networking Tools for Linux Identity Server
Section 30.3.2, Troubleshooting 100101043 and 100101044 Liberty Metadata Load Errors
Section 30.3.4, After Setting Up the User Store to Use SecretStore, Users Report 500 Errors
Section 30.3.6, After Consuming a SAML Response, the Browser Is redirected to an Incorrect URL
Section 30.3.8, Attributes Are Not Available Through Form Fill When OIOSAML Is Enabled
Section 30.3.10, Metadata Mentions Triple Des As Encryption Method
Section 30.3.15, Attribute Query from OIOSAML.SP Java Service Provider Fails with Null Pointer
Section 30.3.16, Disabling the Certificate Revocation List Checking
Section 30.3.19, Requesting the Authentication to a Service Provider Fails
Section 30.3.20, SAML 2.0 POST Compression Failure Does not Throw a Specific Error Code
Section 30.3.21, SAML 1.1 Service Provider Re-requests for Authentication
Section 30.3.22, Identity Server Statistics Logs Do Not Get Written In Less Than One Minute
Section 30.3.24, Terminating an Existing Authenticated User from Identity Server
Section 30.3.25, X.509 Authentication Lists the Entire List of Certificates Imported to the Browser
Section 30.3.26, Clustered Nodes Looping Due to JGroup Issues
Section 30.3.28, nidp/app Does Not Redirect to nidp/portal after Authentication
Section 30.3.29, Login to Office 365 Fails when WS-Trust MEX Metadata Is Larger than 65 KB
Section 30.3.30, Unsafe Server Certificate Change in SSL/TLS Renegotiations Is Not Allowed
Section 30.3.31, Viewing Request and Response Headers of All Protocols in a Log File
For information about Identity Server logging, see Section 21.3.1, Configuring Logging for Identity Server and Section 21.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 Administration Console and Identity Server. For example, you can generate an LDAP search/bind matching what Identity Server sends, to confirm whether an issue is with 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.
Identity Server is the identity provider for other Access Manager components. Access Gatewayshas Embedded Service Providers. When a device is imported into Administration Console and an Identity Server configuration is selected for them, a trusted relationship is established with 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 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 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 does not’ have a trusted relationship with Identity Server, update the device, reconfigure the device for a trusted relationship, then update the device. The following steps explain how to force Access Gateway to re-import the metadata of Identity Server.
In Administration Console Dashboard, click Devices > Access Gateways > Edit > Reverse Proxies/Authentication.
Select None for the Identity Server Cluster option, click OK twice, then update Access Gateway.
Click Edit > Reverse Proxies/Authentication.
Select an Identity Server configuration for the Identity Server Cluster option, click OK twice, then update 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 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 Administration Console Dashboard, 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 Identity Server. The base URL in Identity Server configuration is used to build all the metadata end points.
To view the metadata of 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 Access Gateway must be able to resolve the idpcluster.lab.novell.com hostname of Identity Server. To test that it is resolvable, send a ping command with the hostname of Identity Server. For example, from Access Gateway:
ping idpcluster.lab.novell.com
The same is true for Identity Server. It must be able to resolve the hostname of Access Gateway. To discover the URL for Access Gateway metadata:
In Administration Console Dashboard, 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 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 Identity Server can resolve the hostname of Access Gateway, send a ping command with the hostname of Access Gateway. For example, from 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 Identity Server.
Ensure that the issuers of 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 Identity Server certificate must be imported into the ESP Trust Store.
For more information, see Section 13.5, Importing a Signed Certificate.
If you use certificates generated by Administration Console CA, the trusted root certificate is the same for 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 Administration Console Dashboard, click Security > Certificates.
Determine the issuer of Identity Server certificate and the Embedded Service Provider certificate:
Click the name of Identity Server certificate, note the name of the Issuer, then click Close.
Click the name of the Embedded Service Provider certificate of Access Gateway, note the name of the Issuer, then click Close.
To verify the trusted root for 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 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 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 Identity Servers page or 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 Identity Server and the Embedded Service Provider of Access Gateway.
In Administration Console Dashboard, click Devices > Identity Servers > Edit > Auditing and 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 Identity Server, then update Access Gateway.
After enabling and applying the changes, duplicate the issue 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 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 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 2012, 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 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 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 Identity Server, but the Embedded Service Provider does not trust Identity Server certificate because the trusted root of the issuer of 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 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 Identity Server and enter the following URL:
https://idpcluster.lab.novell.com:8443/nidp/idff/metadata
Open a browser on Access Gateway Service, then enter the same URL.
Because Access Gateway Appliance does not have a graphical interface, you need to use the curl command to test whether Access Gateway Appliance can access the metadata of Identity Server. If the DNS name of the identity provider is idpcluster.lab.novell.com, enter the following command from Access Gateway machine:
curl -k https://idpcluster.lab.novell.com:8443/nidp/idff/metadata
To test whether Identity Server can access the metadata URL of Access Gateway, open a browser on 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 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 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 > Auditing and 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 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 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 Appliance 4.3 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 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 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 Access Gateway.
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 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 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 need to configure it as /nidp/app/logout.
After consuming a SAML response, 302 redirect to RelayState URL is sent to an Incorrect URL. Check whether the relay state is URL encoded. To fix this issue, add the following entry in the web.xml file:
(/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, manually copy the metadata by selecting the metadata text option while configuring an identity provider or service provider. The metadata text can be obtained from the browser.
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 should be removed manually by 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 Access Manger SAML 2.0, you must disable the Certificate Revocation List (CRL) checking.
To disable the CRL checking:
Modify the tomcat7.conf file of Identity Server located at /opt/novell/nam/idp/conf/tomcat7.conf.
Add this parameterJAVA_OPTS="${JAVA_OPTS} -Dcom.novell.nidp.serverOCSPCRL=false".
Restart 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:
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.
SAML 1.1 service provider performs a strict check on the name space of the attributes received in assertion.
To disable this, perform the following steps:
Click Devices > Identity Servers > Edit > Options > New.
Select SAML1X ATTRIBUTE MATCH BY NAME in Property Type.
Select true in Property Value.
Click OK > Apply.
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 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 when authenticated to an Identity Server, and authorized by Access Gateway. Having parsed the user credentials, and credentials validated against a back end user store, Identity Server creates and maintains an active session for that user. Only when the user manually logs out of 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 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 Identity Server and used in policy evaluations by Access Manager to reflect his new position.
User B who currently has an active session on 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 Identity Server, any subsequent requests to Identity Server will require the user to login again.
The User Sessions page in 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 Administration Console Dashboard, click Troubleshooting > User Sessions.
Specify the user ID and click Search. If a match is found, it lists the IP address of 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 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.
To restrict the list to only certain certificates, use the following procedure:
Go to etc/opt/novell/apache2/conf/cacerts/custom and copy the required CA certificates manually to this folder using the following command:
cp <ca files in pem format> .
This command copies the CA certificates to the current folder.
Create a hash of the pem file using the following command:
openssl x509 -noout -hash -in <cafile.pem>
Create a soft link in the same directory using the following command:
ln -s <cafile.pem> <hash value of the file>.0
For example, ls -l should display the following:
/etc/opt/novell/apache2/conf/cacerts/custom # ls -ltotal 8lrwxrwxrwx 1 root root 22 2013-10-16 03:35 78038f2c.0 ->NAM-RP-Certificate.pem-rw-r--r-- 1 root root 5375 2013-10-16 03:31 NAM-RP-Certificate.pem
Restart Apache using the following command:
/etc/init.d/novell-apache2 restart
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 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 restarting Identity Server, accessing https://idp:port/nidp/app first time does not redirect to https://<idp-url>: port/nidp/portal.
Workaround: After restarting Identity Server, access User Portal first time by using https://idp:port/nidp/. Afterwards, the redirection works fine.
To workaround this issue, perform the following steps:
Modify /opt/novell/nam/idp/webapps/nidp/WEB-INF/web.xml and map mex.jsp to the servlet mapping URL /ndip/wstrust/sts/mex as follows:
<servlet> <servlet-name>NetIQSTS12MEX</servlet-name> <jsp-file>/jsp/mex.jsp</jsp-file> <load-on-startup>1</load-on-startup> </servlet><servlet-mapping> <servlet-name>NetIQSTS12MEX</servlet-name> <url-pattern>/wstrust/sts/mex</url-pattern> </servlet-mapping>
Restart Identity Server.
After upgrading Access Manager from a version earlier than 4.0 Service Pack 1, if you have configured Identity Server to point to the Load Balancer virtual IP address than the real IP addresses of the LDAP replica servers, Identity Server’s request to different LDAP server replicas fails.
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 Identity Server refers to each LDAP server directly and not through the load balancer. In this way, 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.
You can use one of the following options:
Perform the following steps:
Add the following filter to /opt/novell/nam/idp/conf/web.xml:
<filter>
<filter-name>requestdumper</filter-name>
<filter-class>
org.apache.catalina.filters.RequestDumperFilter
</filter-class>
</filter>
<filter-mapping>
<filter-name>requestdumper</filter-name>
<url-pattern>*</url-pattern>
</filter-mapping>Add the following to the /opt/novell/nam/idp/conf/logging.properties file:
# Dumper
1request-dumper.org.apache.juli.FileHandler.level = INFO
1request-dumper.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
1request-dumper.org.apache.juli.FileHandler.prefix = request-dumper.
1request-dumper.org.apache.juli.FileHandler.formatter = org.apache.juli.VerbatimFormatter org.apache.catalina.filters.RequestDumperFilter.level = INFO
org.apache.catalina.filters.RequestDumperFilter.handlers = 1request-dumper.org.apache.juli.FileHandlerUpdate the following handler in the /opt/novell/nam/idp/conf/logging.properties file:
handlers = 1catalina.org.apache.juli.FileHandler, 2localhost.org.apache.juli.FileHandler, 3manager.org.apache.juli.FileHandler, 4host-manager.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler, 1request-dumper.org.apache.juli.FileHandler
A log file is created at /var/opt/novell/nam/logs/idp/tomcat/ that contains a log of all the headers. A sample log file format: request-dumper.2016-05-09.log.
Add the following in /opt/novell/nam/idp/conf/tomcat.conf:
JAVA_OPTS="${JAVA_OPTS} -Dcom.sun.xml.wss.provider.wsit.SecurityTubeFactory.dump=false"
JAVA_OPTS="${JAVA_OPTS} -Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=true"
JAVA_OPTS="${JAVA_OPTS} -Dcom.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true"