Variable Value

<provider_class> <provider_name> <keystore_type> <keystore_name> <keystore_pwd>
The name of the providerClass. For nCipher, this must be set to
com.ncipher.provider.km.nCipherKM.
The name of the provider. For nCipher, this must be set to

nCipherKM.

The type of keystore. For nCipher, this must be set to nCipher.sworld. The name you specified when you created the keystore. In this sample configuration, the name is AMstore.jks. When you use module-protected keys, the keystore password must be null. For example:
com.novell.nidp.extern.signing.keystorePwd= <key_alias> <key_pwd>
The alias you created for the key when you created the key. In this sample configuration, the name is od93. When you use module-protected keys, the key password must be null. For example:
com.novell.nidp.extern.signing.keyPwd=
6 To restart Tomcat, enter the following command:
7 Continue with Verifying the Use of the nCipher Key Pair on page 55. Configuring a Windows Identity Server for the Certificate 1 At the Identity Server, log in as the Windows administrator. 2 Add the nfast JAR files to the classpath. Because the Identity Server runs as a Tomcat service, the following steps explain how to modify the classpath for Tomcat. 2a Run the tomcat5w.exe utility located in the following directory: Windows Server 2003: \Program Files\Novell\Tomcat\bin Windows Server 2008: \Program Files (x86)\Novell\Tomcat\bin 2b Click the Java tab. 2c In the Java Classpath text box add the following to the end of the path:
";C:\nfast\java\classes\jcetools.jar;C:\nfast\java\classes\jutils.jar ;C:\nfast\java\classes\keysafe.jar;C:\nfast\java\classes\kmcsp.jar;C: \nfast\java\classes\kmjava.jar;C:\nfast\java\classes\nfjava.jar;C:\nf ast\java\classes\rsaprivenc.jar;C:\nfast\java\classes\spp.jar"
2d Save your changes. 3 Add the netHSM certificate configuration lines to the tomcat5.conf file: 3a Run the tomcat5w.exe utility located in the following directory: Windows Server 2003: \Program Files\Novell\Tomcat\bin
Windows Server 2008: \Program Files (x86)\Novell\Tomcat\bin 3b Click the Java tab. 3c In the Java Options text box, add the following as three separate lines:
Dcom.novell.nidp.extern.config.file=C:\PROGRA~1\Novell\Tomcat\webapps \nidp\WEB-INF\classes\externKeystore.properties -Dprotect=module -DignorePassphrase=true
The first line specifies the location of the properties file. For readability, it has been wrapped and indented. Remove the extra white space when creating the entry in the file. You can specify another location. The second line is required only if you want the keystore to be module protected rather than card protected. 4 Configure the externKeystore.properties file to use the nCipher key and keystore: 4a In a text editor, create an externKeystore.properties file in the following directory: Windows Server 2003: \Program Files\Novell\Tomcat\webapps\nidp\WEBINF\classes

<label><%=handler.getResource(JSPResDesc.USERNAME)%></label>
6b Replace it with the string you want, for example:
<label>Email Address:</label>
6c Copy the modified file to each Identity Server in the cluster. 6d Back up your customized file. 7 (Conditional) If you need to localize the prompt for multiple languages, create a custom message properties file for the login prompt. (For more information on how to create a custom message properties file, see Section 2.3.1, Customizing Messages, on page 80.)
The following steps assume you want to change the username prompt to an e-mail address prompt. 7a Find the following definition in the com/novell/nidp/resource/jsp directory of the unzipped nidp.jar file.

JSP.50=Username:

7b Add this definition to your custom properties file and modify it so that it prompts the user for an e-mail address.

JSP.50=Email Address:

7c Translate the value and add this entry to your localized custom properties files. 7d Copy the customized properties files to the WEB-INF/classes directory of each Identity Server in the cluster. 7e Restart Tomcat on each Identity Server. Linux Identity Server: Enter the following command:
Windows Identity Server: Enter the following commands:
8 To view a sample custom page with these modifications, see Section 2.4.1, Modified login.jsp File for Credential Prompts, on page 85.
Customizing the nidp.jsp File Figure 2-2 displays the default login page provided by Access Manager. Multiple JSPs are used to create the page.
Figure 2-2 The JSPs That Create the Login Page

nidp.jsp

menus.jsp

content.jsp

You can use the nidp.jsp file to customize the header with the Novell Access Manager product name and the Novell logo. The menus.jsp file controls the Authentication and User Login tabs. The login.jsp file controls the credential frame with username and password. The content.jsp file controls what is displayed on the page, including the available authentication cards. The following sections explain how to modify the login page that these JSPs create:

configured for the user store must have sufficient rights to extend the schema on the eDirectory server, to install the SAML NMAS method, and set up the required certificates and objects. For more information on the rights required, see Section 3.1.3, Configuring an Admin User for the User Store, on page 109.
The user store must be configured to use secure connections (click Access Manager > Identity
Servers > Edit > Local > User Stores > [User Store Name]. In the Server replicas section, ensure that the Port is 636 and that Use SSL is enabled. If they arent, click the name of the replica and reconfigure it.
If you have enabled a firewall between the Administration Console and the user store, and
between the Identity Server and the user store, make sure that both LDAP ports (389 and 636) and the NCP port (524) are opened.
If you are going to configure Access Manager to use secrets that are used by other applications,
you need to plan a configuration that allows the user to unlock a locked SecretStore. See Determining a Strategy for Unlocking the SecretStore on page 116. To configure the user store: 1 In the Administration Console, click Devices > Identity Servers > Edit > Local. 2 Click the name of your user store.
114 Novell Access Manager 3.1 SP2 Identity Server Guide
3 Select Install NMAS SAML method, then click OK. This installs a required NMAS method in the eDirectory schema and adds required objects to the tree. IMPORTANT: If your eDirectory user store is running on SLES 11 64-bit operating system on x86-64 hardware, the eDirectory server is missing some support libraries that this SAML method requires. For information on installing these libraries, see TID 7006437 (http:// www.novell.com/support/viewContent.do?externalId=7006437&sliceId=1). 4 Click Liberty > Web Service Providers. 5 Click Credential Profile.
6 Scroll to the Remote Storage of Secrets section. 7 Click New under Novell Secret Store User Store References. This adds a reference to a user store where SecretStore has been installed.
8 Click the user store that you configured for SecretStore. 9 Click OK twice. 10 On the Identity Servers page, update the Identity Server. 11 Continue with one of the following:
If other applications are using the secret store, you need to determine whether Access
Manager users need the option to unlock the secret store. See Determining a Strategy for Unlocking the SecretStore on page 116.

144 Novell Access Manager 3.1 SP2 Identity Server Guide
4.2.1 Configuring Attribute Mappings
The attribute mapping options allow you to specify how the Identity Server maps the certificate to a user in the user store. Subject name is the default map. 1 Step 3 of the wizard or click Devices > Identity Servers > Edit > Local > Classes > [Name of X.509 class] > Properties > Attributes. 2 Configure attribute mappings.
Show certificate errors: Displays an error page when a certificate error occurs. This option is disabled by default. Auto Provision X509: Enables using X.509 authentication for automatic provisioning of users. This option allows you to activate X.509 for increased security, while using a less secure way of authentication, such as username/password. Extra security measures can even include manual intervention to activate X.509 authentication by adding an extra attribute that is checked during authentication. An example of using this option is when a user authenticates with an X.509 certificate, a lookup is performed for a matching SASallowableSubjectNames with the name of the user certificate. When no match is found, and Auto Provision X509 is enabled, the user is presented with a custom error page specifying to click a button to provide additional credentials, such as a username and password, or to start an optional Identity Manager workflow. If the authentication is successful, then the users SASallowableSubjectNames attribute is filled in with the certificate name of the user certificate. When Auto Provision X509 is enabled, and the attribute that is used for subject name mapping is changed from the default sasAllowableSubjectNames, you need to ensure that the LDAP attribute that is used can store string values with a length as long as the longest client certificate subject name. For example, if you use the LDAP attribute title (which has an upper bound of 64 characters) the Auto Provision X509 fails the provisioning part of the authentication if the client certificate subject name is longer 64 characters. The authentication works if a valid name and password is given. However, provisioning fails.
Configuring Advanced Local Authentication Procedures 145
Attributes: The list of attributes currently used for matching. If multiple attributes are specified, the evaluation of these attributes should resolve to only one user in the user store. The evaluation first does a DN lookup for subject name or directory name mapping. If this fails, the rest of the mappings are looked up in a single LDAP query. Available attributes: The available X.509 attributes. To use an attribute, select it and move it to the Attributes list. When the attribute is moved to the Attributes list, you can modify the mapping name in the Attribute Mappings section. The mapped name must match an attribute in your LDAP user store. Directory name: Searches for the directory address in the client certificate and tries to match it to the DN of a user in the user store. If that fails, it searches the sasAllowableSubjectNames attribute of all users for a value that matches. The sasAllowableSubjectNames attribute must contain values that are comma-delimited, with a space after the comma. (For example, O=CURLY, OU=Organization CA or OU=Organization CA, O=CURLY.) Email: Searches for the email attribute in the client certificate and tries to match it with a value in the LDAP mail attribute. Serial number and issuer name: Lets you match a users certificate by using the serial number and issuer name. The issuer name and the serial number must be put into the same LDAP attribute of the user, and the name of this attribute must be listed in the Attribute Mappings section. When using a Case Ignore String attribute, both the issuer name and the serial number must be in the same attribute separated by a dollar sign ($) character. The issuer name must precede the $ character, with the serial number following the $ character. Do not use any spaces preceding or following the $ character. For example: O=CURLY, OU=Organization CA$21C0562C5C4 The issuer name can be from root to leaf or from leaf to root. The issuer name must be commadelimited with a space after the comma. (For example, O=CURLY, OU=Organization CA or OU=Organization CA, O=CURLY.) The serial number cannot begin with a zero (0) or with a hexadecimal notation (0x). If the serial number is 0x0BAC05, the value of the serial number in the attribute must be BAC05. The certificate number is displayed in Internet Explorer with a space after every fourth digit. However, you should enter the certificate number without using spaces. The LDAP attribute can be any Case Ignore List or Case Ignore String attribute of the user. If you are configuring your own attribute, ensure that the attribute is added to the Person class. When using a Case Ignore List attribute, both the issuer name and the serial number must be in the same list. The issuer name needs to be the first item in the list, with the serial number being the second and last item in the list. Subject name: Searches for the Subject name of the client certificate and tries to match it to the DN of a user in the user store. If that fails, it searches the sasAllowableSubjectNames attribute of all users for a value that matches the Subject name of the client certificate. The sasAllowableSubjectNames attribute must contain values that are comma-delimited, with a space after the comma. (For example, O=CURLY, OU=Organization CA or OU=Organization CA, O=CURLY.) 3 Click Finish. 4 Create a method for this class. For instructions, see Section 3.3, Configuring Authentication Methods, on page 123. 5 Create a contract for the method: For instructions, see Section 3.4, Configuring Authentication Contracts, on page 125.

myopenid.com.myopenid.com
To specify multiple URLs, separate them with a semicolon (;)
Configuring Advanced Local Authentication Procedures 149
Identity the OpenID user locally: After the user authenticates at the OpenID provider, Access Manager can associate a username from the user store with the OpenID user. With this association, Access Manager can use the policies defined for the username to enforce access to protected resources.
When this option is not selected, the OpenID user is not mapped to a local user. The
username of the authenticated user remains as the OpenID URL. For example, if the user enters http://user123.myopenid.com for the URL, http://user123.myopenid.com becomes the username.
When this option is selected, an attempt is made to map the OpenID user with a username
in the user store. You can do this manually by storing the users OpenID in the attribute specified in the LDAP Attribute Name option. You can also have the Identity Server add the OpenID value to the attribute by selecting the Auto Provision LDAP Attribute option. LDAP Attribute Name: Specify the name of the attribute that contains the identification information for the users. For OpenID authentication, this attribute should contain the OpenID for the user. Auto Provision LDAP Attribute: Select this option when you want the user to provide additional information for identification for the first authentication, such as a username and password. The Identity Server uses this information to identify the user, then writes the users OpenID value to the attribute specified in the LDAP Attribute Name option. On subsequent logins, the Identity Server can identify the user by using the specified attribute and the user is not prompted for additional information. 4 Click Finish. 5 Create a method for this class. For instructions, see Section 3.3, Configuring Authentication Methods, on page 123. 6 Create a contract for the method: For instructions, see Section 3.4, Configuring Authentication Contracts, on page 125. If you want the users credentials available for Identity Injection policies, add the password fetch method as a second method to the contract. For more information about this class and method, see Section 4.5, Configuring Password Retrieval, on page 150. 7 Update the Identity Server.

The Identity Server can communicate with only one KDC identified by IP address in the
configuration. This limitation is caused by the underlying Sun JGSS and limits the Identity Server so that it can support only one Kerberos class with one Kerberos method.
5.2 Configuring Active Directory
You must create a new user in Active Directory for the Identity Server, set up this user account to be a service principal, create a keytab file, and add the Identity Server to the Forward Lookup Zone. These tasks are described in the following sections:
Installing the spn and the ktpass Utilities for Windows Server 2003 on page 165 Creating and Configuring the User Account for the Identity Server on page 166 Configuring the Keytab File on page 167 Adding the Identity Server to the Forward Lookup Zone on page 167
5.2.1 Installing the spn and the ktpass Utilities for Windows Server 2003
When you install Windows Server 2003 and Active Directory, the spn and ktpass utilities are not installed in a default installation. These utilities are installed in a default Windows Server 2008 installation. You need the spn and ktpass utilities to configure the Identity Server for Kerberos authentication. 1 Insert the Windows 2003 CD into the CD drive. 2 To install the utilities, run \SUPPORT\TOOLS\SUPTOOLS.MSI on the CD. The utilities are installed in C:\Program Files\Support Tools.
Configuring for Kerberos Authentication 165
5.2.2 Creating and Configuring the User Account for the Identity Server
1 In Manage Your Server on your Windows server, select the Manage users and computers in Active Directory option. 2 Select to create a new user. 3 Fill in the following fields: First name: Specify the hostname of the Identity Server. This is the username. For the example configuration, this is amser. User logon name: Specify HTTP/<Identity_Server_Base_URL>. For this example configuration, your Identity Server has a base URL of amser.provo.novell.com, and you would specify the following for the User Logon Name:
HTTP/amser.provo.novell.com
The realm is displayed next to the User logon name. User logon name (pre Windows 2000): Specify the hostname of the Identity Server. The default value must be modified. For the example configuration, this is amser. 4 Click Next, and configure the password and its options: Password: Specify a password for this user Confirm password: Enter the same password. User must change password at next logon: Deselect this option. Password never expires: Select this option. 5 Click Next, then click Finish. This creates the Identity Server user. You need to remember the values you assigned to this user for First name and User logon name. 6 To set the servicePrincipalName (spn) attribute on this user, open a command window and enter the following command:

Configuring SAML and Liberty Trusted Providers 201
2 Click the name of an identity provider.
3 On the Trust page, fill in the following fields: Name: Specify the display name for this trusted provider. The default name is the name you entered when creating the trusted provider. The Security section specifies how to validate messages received from trusted providers over the SOAP back channel. Both the identity provider and the service provider in the trusted relationship must be configured to use the same security method. Encrypt name identifiers: Specifies whether you want the name identifiers encrypted on the wire. Select one of the following security methods:
Message Signing: Relies upon message signing using a digital signature. Mutual SSL: Specifies that this trusted provider provides a digital certificate (mutual
SSL) when it sends a SOAP message. SSL communication requires only the client to trust the server. For mutual SSL, the server must also trust the client. For the client to trust the server, the servers certificate authority (CA) certificate must be imported into the client trust store. For the server to trust the client, the clients CA certificate must be imported into the server trust store.
Basic Authentication: Specifies standard header-based authentication. This method
assumes that a name and password for authentication are sent and received over the SOAP back channel. Send: The name and password to be sent for authentication to the trusted partner. The partner expects this password for all SOAP back-channel requests, which means that the name and password must be agreed upon. Verify: The name and password used to verify data that the trusted provider sends.
202 Novell Access Manager 3.1 SP2 Identity Server Guide
4 Click OK twice. 5 Update the Identity Server.
7.5.3 Configuring Communication Security for a SAML 2.0 Service Provider
The security settings control the direct communication between the Identity Server and the service provider across the SOAP back channel. 1 In the Administration Console, click Devices > Identity Servers > Edit > SAML 2.0. 2 Click the name of a service provider. 3 On the Trust page, fill in the following fields: Name: Specify the display name for this trusted provider. The default name is the name you entered when creating the trusted provider. The Security section specifies how to validate messages received from trusted providers over the SOAP back channel. Both the identity provider and the service provider in the trusted relationship must be configured to use the same security method. Encrypt assertions: Specifies whether you want the assertions encrypted on the wire. Encrypt name identifiers: Specifies whether you want the name identifiers encrypted on the wire. Select one of the following security methods:

Configuring CardSpace 241
The authentication profile allows you to select an option to trust any provider, including untrusted providers. For a secure system, you need to identify the providers you want to trust and create a configuration for them. To create a trusted provider, you need to obtain the issuer ID of the provider and the public key certificate for signing certificate from the providers administrator. For an Identity Server cluster, the issuer ID is the base URL of the Identity Server plus the following path:
This section explains the following:
Creating a Trusted Provider Configuration on page 242 Managing the Trusted Provider Configuration on page 242
Creating a Trusted Provider Configuration 1 In the Administration Console, click Devices > Identity Servers > Edit > CardSpace. 2 On the Trusted Providers page, click New, then fill in the following fields: Name: Specify a display name for the provider. This name appears in the list of trusted providers that you can select for an authentication card profile. Source: This line specifies that the Provider ID is entered manually. Provider ID: Specify the issuer ID of the trusted provider. For an Identity Server cluster when the base URL is https://test.lab.novell.com:8443/nidp, the Provider ID is the following value
For a third-party identity provider, you need to obtain the issuer ID from the provider. Signing Certificate: Import the certificate by clicking Browse. Find the signing certificate file, click Open to import it, then click Next. 3 To confirm the signing certificate, click Finish. Managing the Trusted Provider Configuration You can modify the name of the configuration, view and edit the metadata, view and reimport the signing certificate. 1 In the Administration Console, click Devices > Identity Servers > Edit > CardSpace. 2 On the Trusted Providers page, click the name of a trusted provider. 3 To change the name of the trusted provider, specify a new name on the Configuration page, then click Apply. 4 To view or edit the metadata, click Metadata.
242 Novell Access Manager 3.1 SP2 Identity Server Guide
5 To modify the Provider ID or to import a new signing certificate, click Edit. 5a (Optional) To change the Provider ID, enter a new value or modify the current value. 5b (Optional) To import a new signing certificate, click Browse, find the certificate file, click Open to import it, then click Apply. 6 To view the signing certificate, click Certificates. 7 (Conditional) If you made any modifications, update the Identity Server.
8.4.3 Cleaning Up Identities

You do not have an account partner policy file. For the display name, specify the DNS name of the Identity Server. For the Federation Services URI, specify the following:
https://<DNS_Name>:8443/nidp/wsfed/
Replace <DNS_Name> with the DNS name of the Identity Server. This URI is the base URL of your Identity Server with the addition of /wsfed/ on the end.
For the Federation Services endpoint URL, specify the following:
https://<DNS_Name>:8443/nidp/wsfed/ep
Replace <DNS_Name> with the DNS name of the Identity Server. This URL is the base URL of your Identify Server with the addition of /wsfed/ep at the end.
For the verification certificate, import the trusted root of the signing certificate on your
Identity Server. If you have not changed it, you need the Organizational CA certificate from your Administration Console. This is the trusted root for the test-signing certificate.
Select Federated Web SSO.
The Identity Server is outside of any forest, so do not select Forest Trust.

Select the E-mail claim.

262 Novell Access Manager 3.1 SP2 Identity Server Guide
Add the suffix that you will be using for your e-mail address.
You need to have the e-mail end in a suffix that the ADFS server is expecting, such as @novell.com, which grants access to any user with that e-mail suffix. 4 Enable this account partner. 5 Finish the wizard. 6 Continue with Enabling ClaimApp and TokenApp Claims on page 263. Enabling ClaimApp and TokenApp Claims The Active Directory step-by-step guide sets up these roles to be used by the resources. You set them up to be sent in the All Roles attribute from the Identity Server. You must map these roles into the Adatum ClaimApp Claim and the Adatum TokenApp Claim. 1 In the Active Directory Federation Services console, click the account partner that you created for the Identity Server (see Creating an Account Partners Configuration on page 262). 2 Right click the account partner, then create a new Incoming Group Claim Mapping with the following values: Incoming group claim name: Specify ClaimApp. Organization group claim: Specify Adatum ClaimApp Claim. 3 Right-click the account partner, and create another Incoming Group Claim Mapping with the following values: Incoming group claim name: Specify TokenApp. Organization group claim: Specify Adatum TokenApp Claim. 4 Continue with Disabling CRL Checking on page 263. Disabling CRL Checking If you are using the Access Manager certificate authority as your trusted root for the signing certificate (test-signing certificate), there is no CRL information in that certificate. However, the ADFS has a mandatory requirement to do CRL checking on any certificate that they receive. For instructions on how to disable this checking, see Turn CRL checking on or off (http:// go.microsoft.com/fwlink/?LinkId=68608). Use the following tips as you follow these instructions.

Default Value: https://adfsaccount.adatum.com/adfs/ls/ The service provider uses this value to redirect the user for login. This URL is listed in the Properties of the Trust Policy on the ADFS server. The label is Federation Services endpoint URL.
Default Value: https://adfsresource.treyresearch.net/adfs/ls/ The ADFS server makes no distinction between the login and logout URL. Access Manager has separate URLs for login and logout, but from a Novell Identity Server to an ADFS server, they are the same.
This is the certificate that the ADFS server uses for signing. You need to export it from the ADFS server. It can be retrieved from the properties of the Trust Policy on the ADFS Server on the Verification Certificates tab. This certificate is a self-signed certificate that you generated when following the step-by-step guide.
To create an identity provider: 1 In the Administration Console, click Devices > Identity Servers > Edit > WS Federation. 2 On the WS Federation page, click New, select Identity Provider, then fill in the following fields: Name: Specify a name that identifies the identity provider, such as Adatum. Provider ID: Specify the federation service URI of the identity provider, for example urn:federation:adatum. Sign-on URL: Specify the URL for logging in, such as https://
adfsaccount.adatum.com/adfs/ls/.
Logout URL: Specify the URL for logging out, such as https://
adfsresource.treyresearch.net/adfs/ls/
Identity Provider: Specify the path to the signing certificate of the ADFS server. 3 Confirm the certificate, then click Next. 4 For the authentication card, specify the following values: ID: Leave this field blank. Text: Specify a description that is available to the user when the user mouses over the card. Image: Select an image, such as Customizable, or any other image. Show Card: Enable this option so that the card can be presented to the user as a login option. 5 Click Finish. 6 Continue with Modifying the User Identification Specification on page 268. Modifying the User Identification Specification The default settings for user identification are set to do nothing. The user can authenticated but the user is not identified as a local user on the system. This is not the scenario we are configuring. We want the user to be identified on the local system. Additionally, we want to specify which contract

a delimited LDAP attribute. See Section 13.6.4, Configuring Postal Address Attribute Maps, on page 315.
Contact Method: Maps the Contact Method attribute to multiple LDAP attributes. See
Section 13.6.5, Configuring Contact Method Attribute Maps, on page 316.
308 Novell Access Manager 3.1 SP2 Identity Server Guide
Gender: Maps the Gender attribute to an LDAP attribute, then maps the possible Liberty
values to LDAP values. See Section 13.6.6, Configuring Gender Attribute Maps, on page 318.
Marital Status: Maps the Marital Status attribute to an LDAP attribute, then maps the
possible Liberty values to LDAP values. See Section 13.6.7, Configuring Marital Status Attribute Maps, on page 319. Delete: Deletes the selected mapping. Enable: Enables the selected mapping. Disable: Disables the selected mapping. When the mapping is disabled, the server does not load the definition. However, the definition is not deleted. 3 Click OK, then update the Identity Server.
13.6.1 Configuring One-to-One Attribute Maps
A one-to-one map enables you to map single-value and multiple-value LDAP attribute names to standard Liberty attributes. A default one-to-one attribute map is provided with Access Manager, but you can also define your own. An example of a one-to-one attribute map might be the single-valued Liberty attribute Common Name (CommonName) used by the Personal Profile that is mapped to the LDAP attribute givenName. You can further configure the various Liberty values to map to any LDAP attribute names that you use. 1 In the Administration Console, click Devices > Identity Servers > Edit > Liberty > LDAP Attribute Mapping > New > One to One. 2 Configure the following fields: Type: Displays the type of mapping you are modifying or creating: Name: The name you want to give the map. Description: A description of the map. Access Rights: A drop-down menu that provides the broadest control for the page. If you set this to Read/Write, you can specify rights for individual data items. In order for user provisioning to succeed, you must select Read/Write from the Access Rights drop-down menu for any maps that use an attribute during user provisioning. User Stores: The user store that a map applies to. If a user logs into a user store that is not in the maps user store list, that map is not used to read or write attributes for that user. 3 Use the following guidelines to configure the map:
Mapping Personal Profile Single-Value Data Items to LDAP Attributes Mapping Personal Profile Multiple-Value Data Items to LDAP Attributes Mapping Employee Profile Single-Value Data Items to LDAP Attributes Mapping Employee Profile Multiple-Value Data Items to LDAP Attributes Mapping Custom Profile Single-Value Data Items to LDAP Attributes Mapping Custom Profile Multiple-Value Data Items to LDAP Attributes
4 After you create the mapping, click Finish.
Configuring Liberty Web Services 309

Maintaining an Identity Server 341
Discovery Service Queries Discovery Service Modifies Redirected Interaction Service Requests Trusted Interaction Service Requests Client of Redirected Interaction Service Requests Client of Trusted Interaction Service Requests Data Location LDAP Data Location LDAP Aggregation Data Location User Profile
The number of Liberty Discovery Web Service queries performed since the Identity Server was started. The number of Liberty Discovery Web Service changes performed since the Identity Server was started. The number of Liberty User Interaction Redirection Profile requests performed since the Identity Server was started. The number of Liberty User Interaction Trusted Service Profile requests performed since the Identity Server was started. The number of Liberty User Interaction Redirection Profile requests initiated as a client since the Identity Server was started. The number of Liberty User Interaction Trusted Service Profile requests initiated as a client since the Identity Server was started. The number of attempts to use LDAP as a data location for a query or a modify of any Web Service since the Identity Server was started. The number of attempts to use LDAP as a data location for aggregation of a query or a modify of any Web Service since the Identity Server was started. The number of attempts to use the User Profile object as a data location for a query or a modify of any Web Service since the Identity Server was started. A User Profile object is a directory object stored in the Identity Server's configuration datastore. The number of attempts to use the User Profile object as a data location for aggregation of a query or a modify of any Web Service since the Identity Server was started. A User Profile object is a directory object stored on the Identity Server's configuration datastore. The number of attempts to use the Remote location as a data location for a query or a modify of any Web Service since the Identity Server was started. A Remote location includes Pushed Attributes and External Services. The number of attempts to use the Pushed Attributes as a remote data location for a query or a modify of any Web Service since the Identity Server was started. The number of attempts to use the Pushed Attributes as an remote data location for aggregation of a query or a modify of any Web Service since the Identity Server was started. The number of attempts to use an External Service as a remote data location for a query or a modify of any Web Service since the Identity Server was started. An External Service is where the same Web Service exists on an external Service Provider and a call can be made to request data from the service.

Maintaining an Identity Server 349
14.10.2 Disabling User Profile Objects
If you are not using the default configuration for storing Form Fill secrets and you have not enabled persistent federation between identity and service providers, you can disable the creation of objects under the LibertyUserProfile container in the configuration datastore. The default behavior is to create an object in this container for every user accessing the system, and the login process checks for a matching user in this container. If you have hundreds of thousands of users, the following symptoms might indicate that the user profile objects are slowing down the login process:
On the Administration Console, the ndsd process (Linux) or the NDS Server (Windows) is

running at 100%.

Running the backup utility is very slow. Logging in to the Administration Console is very slow.
To discover whether profile objects might be causing a slowdown, open an LDAP browser (or in the Administration Console, select the View Objects task in the menu bar). Expand the following objects: novell > accessManagerContainer > nids > cluster. Expand the SCC objects, and look for objects stored in LibertyUserProfile objects.
If you have only a few hundred of these objects, user profile objects are not slowing the

authentication process.

If you have thousands of these objects, user profile objects are probably causing a slowdown.
You can speed up authentication by disabling the use of these objects. When you do this, the Identity Server no longer creates objects in the LibertyUserProfile container, and it does not try to match an authenticating user with a profile object. To prevent the creation and use of user profile objects, make the following modifications to your Identity Server configuration: 1 In the Administration Console, click Devices > Identity Servers > Edit > Liberty > Web Service Provider. 2 Disable the following profiles:
Personal Profile Employee Profile Custom Profile
3 Either disable the Credential Profile (which also disables using Form Fill or Identity Injection with credentials) or enable the Credential Profile and modify its default configuration: 3a Click Credential Profile. 3b Select to store secrets either with the Extended Schema User References option or with the Novell Secret Store User Store References option. When the Credential Profile is enabled, the default behavior is to create user profile objects and store the secrets there. You must configure one of these other options to store the secrets. For more information about these options, see Section 3.1.4, Configuring a User Store for Secrets, on page 109. 4 Click OK twice, then update the Identity Server.

5 Changing the IP Address of Access Manager Devices

5.1 5.2

Changing the IP Address of the Administration Console. 95 Changing the IP Address of an Identity Server. 95

5.3 5.4 5.5

Changing the IP Address of the Access Gateway Appliance. 97 Changing the IP Address of the Access Gateway Service. 98 Changing the IP Address of the Audit Server. 99
6 Troubleshooting the Administration Console
6.1 Global Troubleshooting Options. 6.1.1 Checking for Potential Configuration Problems. 6.1.2 Checking for Version Conflicts. 6.1.3 Checking for Invalid Policies. 6.1.4 Viewing Device Health. 6.1.5 Viewing Health by Using the Hardware IP Address. 6.1.6 Using the Dashboard. 6.1.7 Viewing System Alerts. Stopping Tomcat on Windows. Logging. Event Codes. Restoring a Failed Secondary Console. Moving the Primary Administration Console to New Hardware. Converting a Secondary Console into a Primary Console. 6.7.1 Shutting Down the Administration Console. 6.7.2 Changing the Master Replica. 6.7.3 Restoring CA Certificates. 6.7.4 Editing the vcdn.conf File. 6.7.5 Deleting Objects from the eDirectory Configuration Store. 6.7.6 Performing Component-Specific Procedures. 6.7.7 Enabling Backup on the New Primary Administration Console. Orphaned Objects in the Trust/Configuration Store. Repairing the Configuration Datastore. Session Conflicts. Unable to Log In to the Administration Console. (Linux) Exception Processing IdentityService_ServerPage.JSP. Backup/Restore Failure Because of Special Characters in Passwords. Unable to Install NMAS SAML Method.

124 125

6.2 6.3 6.4 6.5 6.6 6.7
6.8 6.9 6.10 6.11 6.12 6.13 6.14
7 Troubleshooting Certificate Issues

7.2 7.3 7.4 7.5 7.6

Resolving Certificate Import Issues. 127 7.1.1 Importing an External Certificate Key Pair. 127 7.1.2 Resolving a -1226 PKI Error. 128 7.1.3 When the Full Certificate Chain Is Not Returned During an Automatic Import of the Trusted Root. 128 7.1.4 Using Internet Explorer to Add a Trusted Root Chain. 129 Mutual SSL with X.509 Produces Untrusted Chain Messages. 129 Troubleshooting Options for Certificate Problems. 129 Cant Log In with Certificate Error Messages. 131 When a User Accesses a Resource, the Browser Displays Certificate Errors. 131 Access Gateway Canceled Certificate Modifications. 131

objects are being created or deleted.
In the Attributes section, you probably want to monitor when attribute values are added or

deleted. 8 Click Apply.

9 (Linux) Restart eDirectory and the Audit Server. Enter the following commands:
/etc/init.d/ndsd restart /etc/init.d/novell-naudit restart
10 (Windows) Restart eDirectory and the Audit Server: 10a Click Control Panel > Administrative Tools > Services. 10b Right click NDS Server, then select Stop. 10c Answer Yes to the prompt to stop the Novell Audit Log Server. 10d Right click NDS Server, then select Start. 10e Right click Novell Audit Log Server, then select Start.

1.5 Enabling Auditing

Access Manager includes a licensed version of Novell Audit to provide compliance assurance logging and to maintain audit log entries that can be subsequently included in reports. In addition to selectable events, device-generated alerts are automatically sent to the audit server. Access Manager comes preconfigured to use the Novell Audit server, but you can configure Access Manager to use an already existing Novell Audit server, a Sentinel server, or a Sentinel Log Manager server. The audit logs record events that have occurred in the identity and access management system and are primarily intended for auditing and compliance purposes. You can configure the following types of events for logging:
Starting, stopping, and configuring a component Success or failure of user authentication Role assignment Allowed or denied access to a protected resource Error events Denial of service attacks Security violations and other events necessary for verifying the correct and expected operation
of the identity and access management system. Audit logging does not track the operational processing of the Access Manager components; that is, the processing and interactions between the Access Manager components required to fulfill a user request. (For this type of logging, see Configuring Component Logging in the Novell Access Manager 3.1 SP2 Identity Server Guide.) Audit logs record the results of user and administrator requests and other system events. Although the primary purpose for audit logging is for auditing and compliance, the types of events logged can also be useful for detecting abnormal and error conditions and can be used as a first alert mechanism for system support. You can configure the audit log entries to generate alerts by leveraging the Novell Audit Notification feature. You can select to generate e-mail, syslog, and SNMP notifications.

3.3.4 Exporting a Private/Public Key Pair
When you create a certificate, you can specify whether it is exportable. If a key is exportable, it can be extracted and put in a file along with the associated certificate. The file is written in an industry standard format, PKCS#12, which allows it to be transported to other platforms. It is encrypted with a user-specified password to protect the private key.You can export private certificates to obtain a backup copy of the key, to move the key to a different server, or to share the key between servers. You cannot export a certificate if you enabled the Do not allow private key to be exportable option while creating the certificate. 1 In the Administration Console, click Security > Certificates. 2 On the Certificates page, click the certificate.
3 On the Certificate Details page, click Export Private/Public Keypair.
4 Select the format for the key: PFX/PKCS12: Public Key Cryptography Standards #12 (PKCS#12) format, which is also called PFX format. This format can be used to create JKS or PEM files. JKS: Java keystore format. 5 Specify the password in the Encryption/decryption password field, then click OK. IMPORTANT: Remember this password because you need it to re-import the key. 6 Click OK.
3.3.5 Exporting a Public Certificate
You can export a trusted root or a public key certificate to a file so that a client can use it to verify the certificate chain sent by a cryptography-enabled application, or to have a backup copy of the file. You can export the certificate in the following formats:
DER-encoded (.der) to a file. PEM-encoded to a file. This is a Base64-encoded DER certificate that is enclosed between the
BEGIN CERTIFICATE and END CERTIFICATE tags.
PEM CUT/Paste Buffer. This displays the certificate data so you can copy it to the system
Clipboard. You can then pasted it directly into a cryptography-enabled application. To export the public certificate: 1 In the Administration Console, click Security > Certificates. 2 Click the certificate name. 3 On the Certificate Details page, click Export Public Certificate, then click the file type. 4 Save the output file to the location of your choosing.
3.3.6 Importing a Private/Public Key Pair
If you created a key pair that was exported from another certificate management system, you can import the key pair and then assign it to an Access Manager device. The file needs to be in PFX/ PKCS12 (*.pfx or *.p12) format. 1 In the Administration Console, click Security > Certificates. 2 Choose Actions > Import Private/Public Keypair. 3 Fill in the following fields: Certificate name: The name of the certificate. This is a system-wide, unique name used by Access Manager. The name must contain only alphanumeric characters and no spaces. If the name starts with a number, an underline (_) prefix is added to the name so that the name conforms to XML requirements. If the name contains invalid characters, it is automatically renamed. Keystore password: Type the encryption/decryption password established when exporting the certificate. Certificate data file (PFX/PKCS12): The certificate file to import. You can browse to locate the *.pfx or *.p12 file. Certificate data file (JKS): To locate a JKS file, select this option, then click the Browse button. 4 Click OK. If you receive an error when importing the certificate, the error comes from either NICI or PKI. For a description of these error codes, see Novell Certificate Server Error Codes and Novell International Cryptographic Infrastructure (http://www.novell.com/documentation/nwec/ index.html). For general certificate import issues, see Section 7.1.1, Importing an External Certificate Key Pair, on page 127. 5 Continue with Adding a Certificate to a Keystore on page 61.

Contains the final results of the login, with the URL that the request is redirected to.
Protected Resource Authentication Trace When a protected resource is configured to require authentication, both the Identity Server and the Embedded Service Provider of the Access Gateway (or J2EE Agent) generate log entries for the process. The following sections explain how to correlate the entries from the logs.
Entries from an Identity Server Log on page 93 Entries from an Access Gateway Log on page 94 Correlating the Log Entries between the Identity Server and the Access Gateway on page 94
Entries from an Identity Server Log
<amLogEntry> 2009-07-31T17:36:39Z INFO NIDS Application: AM#500105016: AMDEVICEID#AA257DA77ED48DB0: AMAUTHID#83778AE09DCA5A35B57842D754A60D67: Processing login resulting from Service Provider authentication request. </ amLogEntry> <amLogEntry> 2009-07-31T17:36:39Z INFO NIDS Application: AM#500105009: AMDEVICEID#AA257DA77ED48DB0: AMAUTHID#83778AE09DCA5A35B57842D754A60D67: Executing contract Name/Password - Form. </amLogEntry> <amLogEntry> 2009-07-31T17:36:39Z INFO NIDS Application: AM#500105010: AMDEVICEID#AA257DA77ED48DB0: AMAUTHID#83778AE09DCA5A35B57842D754A60D67: Contract Name/Password - Form requires additional interaction. </amLogEntry> <amLogEntry> 2009-07-31T17:36:49Z INFO NIDS Application: AM#500105016: AMDEVICEID#AA257DA77ED48DB0: AMAUTHID#83778AE09DCA5A35B57842D754A60D67: Processing login resulting from Service Provider authentication request. </ amLogEntry> <amLogEntry> 2009-07-31T17:36:49Z INFO NIDS Application: AM#500105009: AMDEVICEID#AA257DA77ED48DB0: AMAUTHID#83778AE09DCA5A35B57842D754A60D67: Executing contract Name/Password - Form. </amLogEntry> <amLogEntry> 2009-07-31T17:36:49Z INFO NIDS Application: AM#500105014: AMDEVICEID#AA257DA77ED48DB0: AMAUTHID#83778AE09DCA5A35B57842D754A60D67: Attempting to authenticate user cn=admin,o=novell with provided credentials. </amLogEntry> <amLogEntry> 2009-07-31T17:36:49Z INFO NIDS Application: AM#500105012: AMDEVICEID#AA257DA77ED48DB0: AMAUTHID#83778AE09DCA5A35B57842D754A60D67: Authenticated user cn=admin,o=novell in User Store Internal with no roles. </ amLogEntry> <amLogEntry> 2009-07-31T17:36:49Z INFO NIDS Application: AM#500105018: AMDEVICEID#AA257DA77ED48DB0: AMAUTHID#83778AE09DCA5A35B57842D754A60D67: Responding to AuthnRequest with artifact AAMoz+rm2jQjDSHjea8U9zm3Td/U2ax0YZCo/ qBNool8WkZiTCt7N7Jx </amLogEntry> <amLogEntry> 2009-07-31T17:36:49Z INFO NIDS Application: AM#500105019: AMDEVICEID#AA257DA77ED48DB0: AMAUTHID#C2D8D52704918AF2D5D62F6EDC2FFAC6: Sending AuthnResponse in response to artifact AAMoz+rm2jQjDSHjea8U9zm3Td/ U2ax0YZCo/qBNool8WkZiTCt7N7Jx </amLogEntry>
Entries from an Access Gateway Log

You can create XML validation errors on your Access Gateway Appliance if you start to create an alert profile (click Access Gateways > Edit > Alerts > New), but you do not finish the process. The incomplete alert profile does not appear in the configuration for the Access Gateway, so you cannot delete it. If such a profile exists, it appears in the Access Gateways with Invalid Alert Profile References list. Click the Remove button by the invalid profile. You should then be able to modify its configuration, and when you update the Access Gateway, the changes should be applied and saved. If an empty value is written to an XML attribute, the device with this invalid configuration appears in this list. Click the Repair button to rewrite the invalid attribute values.
Devices with Corrupt Data Store Entries
3 When you have finished repairing or deleting invalid Access Gateway configurations, click the Access Gateways link, then click Update > OK. 4 (Optional) Verify that all members of an Access Gateway cluster have the same configuration in cache: 4a Click Auditing > Troubleshooting > Configuration. 4b Scroll to the Cached Access Gateway Configuration option. 4c Click View next to the cluster configuration or next to an individual Access Gateway. This option allows you to view the Access Gateway configuration that is currently residing in browser cache. If the Access Gateway belongs to a cluster, you can view the cached configuration for the cluster as well as the cached configuration for each member. The + and - buttons allow you to expand and collapse individual configurations. The configuration is displayed in XML format To search for particular configuration parameters, you need to copy and paste the text into a text editor. 5 (Conditional) After viewing the Access Gateway configuration (see Step 4) and discovering that an Access Gateway does not have the current configuration, select the Access Gateway in the Current Access Gateway Configurations section, then click Re-push Current Configuration.
6.1.2 Checking for Version Conflicts
The Version page displays all the installed components along with their currently running version. Use this page to verify that you have updated all components to the latest compatible versions. There are two steps to ensuring that your Access Manager components are running compatible versions:

To return to the Device Health page, click Close. To edit the details of a device, click the server name.
104 Novell Access Manager 3.1 SP2 Administration Console Guide
To view health details, click the Health icon. To view the alerts, click the alerts link. To view device statistics, click the statistics link. To view or configure audit events for the device, click the Edit Events link.
6.1.6 Using the Dashboard
The Dashboard page is the starting point and central place to monitor and manage all product components and policies. The status of each device is available, with colored warnings or alert conditions. 1 In the Administration Console, click Access Manager > Dashboard. 2 Click a box to view a component or click the link to view the alerts:
Identity Servers Access Gateways SSL VPNs J2EE Agents Policies Alerts
For conventions that apply to all pages in the interface, see Section 1.2.4, Understanding Administration Console Conventions, on page 20. Identity Servers The Identity Server is the central authentication and identity access point for all Access Manager devices. The Identity Server is responsible for authenticating users and distributing role information to facilitate authorization decisions. It also provides the Liberty Alliance Web Service Framework to distribute identity information. An Identity Server always operates as an identity provider and can optionally be configured to run as an identity consumer (also known as a service provider), using either Liberty, SAML 1.1, or SAML 2.0 protocols. As an identity provider, the Identity Server is the central store for a users identity information and is the heart of the users identity federations or account linkage information. As an authentication authority, the identity provider is viewed by internal and external service providers as a trusted identity store. In an Access Manager configuration, the Identity Server is responsible for managing the following:
Authentication: Verifies user identities through various forms of authentication, both local
(user supplied) and indirect (supplied by external providers). The identity information can be some characteristic attribute of the user, such as a role, e-mail address, name, or job description.
Identity Stores: Stores user identities in eDirectory, Microsoft Active Directory, and Sun ONE

Directory Server.

Identity Federation: Enables user identity federation and provides access to Liberty-enabled

services.

Troubleshooting the Administration Console 105
Account Provisioning: Enables service provider account provisioning when federating, which
automatically creates user accounts.
Custom Attribute Mapping: Allows you to define custom attributes by mapping Liberty
Alliance keywords to LDAP-accessible data, in addition to the available Liberty Alliance Employee and Person profiles.

/etc/init.d/novell-jcc stop /etc/init.d/novell-tomcat5 stop
3 Edit the settings.properties file: 3a Enter:
3b Change the IP address in the remotemgmtip list from the IP address of the failed Administration Console to the address of the new primary Administration Console. 3c Enter :wq! to save and exit. 4 Start the services by entering the following commands:
/etc/init.d/novell-jcc start /etc/init.d/novell-tomcat5 start
Windows Identity Server For each Windows Identity Server imported into the Administration Console, perform the following steps: 1 Open a terminal window and shut down all services by entering the following commands:
net stop JCCServer net stop Tomcat5
2 Edit the settings.properties file: 2a Change to the following directory: Windows Server 2003: \Program Files\Novell\devman\jcc\conf
118 Novell Access Manager 3.1 SP2 Administration Console Guide
Windows Server 2008: \Program Files (x86)\Novell\devman\jcc\conf 2b Open the settings.properties file. 2c Change the IP address in the remotemgmtip list from the IP address of the failed Administration Console to the address of the new primary Administration Console. 2d Save your changes. 3 Start the services by entering the following commands:
net start JCCServer net start Tomcat5
Linux J2EE Agents For each Linux J2EE agent imported into the Administration Console, perform the following steps: 1 Log in as the root user. 2 Open a terminal window and shut down all services by entering
/etc/init.d/novell-jcc stop
3b Change the IP address in the remotemgmtip list from the IP address of the failed Administration Console to the address of the new primary Administration Console. 3c Enter :wq! to save and exit. 4 Start the services by entering
/etc/init.d/novell-jcc start
Windows J2EE Agents For each Windows J2EE agent imported into the Administration Console, you must perform the following steps: 1 Log in as a user with administration rights. 2 In the Control Panel, click Administrative Tools > Services. 3 Select the JCCServer, then click Stop. 4 In a text editor, open the settings.properties file in the JCC configuration directory: Windows Server 2003: \Program Files\Novell\devman\jcc\conf Windows Server 2008: \Program Files (x86)\Novell\devman\jcc\conf 5 Change the IP address in the remotemgmtip list from the IP address of the failed Administration Console to the address of the new primary Administration Console. 6 Save your changes and exit. 7 In the Control Panel, click Administrative Tools > Services. 8 Select the JCCServer, then click Start.

/etc/init.d/novell-jcc start /etc/init.d/novell-tomcat5 start /etc/init.d/novell-sslvpn start
8 (Conditional) If the SSL VPN server is still not functioning, restart the Linux server by entering reboot. 9 (Conditional) Repeat this process for each SSL VPN server that has been imported into the Administration Console. Old Primary Administration Console After the secondary console has been promoted to be the primary console, uninstall the Administration Console software of the old primary Administration Console. Before uninstalling, make sure the machine is disconnected from the network. For instructions, see Uninstalling the Administration Console in the Novell Access Manager 3.1 SP2 Installation Guide. If you want to use the old primary console as a secondary console, you need to first uninstall the Administration Console software. Connect the machine to the network, then reinstall the software, designating this console as a secondary console.
6.7.7 Enabling Backup on the New Primary Administration Console
If you installed your Administration Consoles using the 3.1 version of Access Manager, the backup utility is properly configured. If you have upgraded the Linux Administration Consoles from 3.0 SP4 to 3.1, you need to modify the defbkparm.sh file before performing a backup. 1 On the new primary Administration Console, change to the /opt/novell/devman/bin directory. 2 Open the defbkparm.sh file and find the following lines:
Troubleshooting the Administration Console 121
EDIR TREE=<tree_name> EDIR CA=<CA name>
These lines contain values using the hostname of the Administration Console you are on. 3 Modify these lines to use the hostname of the failed Administration Console. When you install the primary Administration Console, the EDIR TREE parameter is set to the hostname of the server with _tree appended to it. The EDIR CA parameter is set to the hostname of the server with _tree CA appended to it. If the failed Administration Console had amlab as its hostname, you would change these lines to have the following values:
EDIR TREE="amlab_tree" EDIR CA="amlab_tree CA"
4 Save your changes. 5 Make a backup from your new primary Administration Console. WARNING: After configuring the secondary console to be the new primary console and performing all the cleanup steps, you cannot restore an old backup from the primary console. Make a new backup as soon as your new primary console is functional.

6.8 Orphaned Objects in the Trust/Configuration Store
If you delete a User object in LDAP, the objects in the trust/configuration datastore related to that user can become orphaned. The system uses these objects for federated identity and user profiles. Currently, there are no known issues related to orphaned identity objects, but they might affect system performance. Orphaned user profile objects might also affect user lookup operations, and therefore you should remove them. To do so, you first delete the users profile before you delete a User object, as described in the following steps: 1 In iManager or an LDAP browser, edit the attributes of the User object that you are going to delete. 2 Note the value of the User objects GUID attribute (for eDirectory), objectGUID attribute (for Active Directory), or the nsuniqueid attribute (for Sun One). 3 In the Access Manager trust/configuration datastore, locate any containers that use the following naming patterns:
cn=LUP*,cn=SCC*,cn=cluster,cn=nids,ou=accessManagerContainer,o=novell,cn= LibertyUserProfiles*,cn=SCC*,cn=cluster,cn=nids,ou=accessManagerContainer ,o=novell.
4 Look for a child profile object inside of these containers that is named by using the GUID noted in Step 2. There should only be one profile object for each GUID. 5 Delete that child profile object. 6 Repeat these steps for each User object that you want to delete. 7 Delete the User objects.
122 Novell Access Manager 3.1 SP2 Administration Console Guide
6.9 Repairing the Configuration Datastore
The configuration datastore is an embedded version of eDirectory 8.8. If it becomes corrupted, you can run DSRepair to fix it. Or, you can restore a recent backup. To restore a backup, see Section 2.3, Restoring an Administration Console Configuration, on page 35. To run DSRepair: 1 In a browser, enter the following URL.
http://<ip_address>:8028/nds
Replace <ip_address> with the IP address of your Administration Console. 2 At the login prompt, enter the username and password of the admin user for the Administration Console. The NDS iMonitor application is launched. For more information, see Accessing iMonitor (http://www.novell.com/documentation/edir88/edir88/data/a6l60f7.html). 3 In the View bar, select the Repair icon. For more information about DSRepair, see the following:

Signing Encryption SSL Connector Provider Introductions SSL Connector Consumer Introductions SSL Connector
2b Click Validate trusted root. 2c If an error is reported, add the missing trusted root to a trust store. To identify the trust store, check the ESP Trust Store of the devices that are using the Identity Server for authentication. For instructions, see the following sections: Section 3.4.5, Viewing Trust Store Details, on page 69 Section 3.4.2, Adding Trusted Roots to Trust Stores, on page 68 2d Repeat Step 2a and Step 2c for each keystore that you want to validate. 3 Validate the trusted root certificates of the Access Gateway cluster or the SSL VPN cluster: 3a Select one of the following keystores that belong to the cluster:

Signing

130 Novell Access Manager 3.1 SP2 Administration Console Guide
Encryption ESP Mutual SSL
3b Click Validate trusted root. 3c If an error is reported, add the missing trusted root to the Trust Store of the Identity Server. For instructions, see Section 3.4.2, Adding Trusted Roots to Trust Stores, on page 68. 3d Repeat Step 3a and Step 3c for each keystore that you want to validate.
7.4 Cant Log In with Certificate Error Messages
After an upgrade if your users cant log in to access protected resources, and the failure messages contain certificate error messages, you might need to manually push the certificates from the Administration Console to the Access Gateway. To re-push a certificate:
For a reverse proxy certificate, go to the Reverse Proxy page, select a different certificate, click
OK, return to the Reverse Proxy page, select the correct certificate, then click OK.
For a Web server certificate, go to the Web Server page, select a different SSL mutual
certificate, click OK, return to the Web Server page, select the correct certificate, click OK, then apply the changes.
7.5 When a User Accesses a Resource, the Browser Displays Certificate Errors
When you configure the Identity Server to use SSL (the HTTPS protocol), the browser must be configured to trust the CA that created the certificate for the Identity Server. If you use a well-known CA, the browser is usually already configured to trust certificates from the CA. If you use a lessknown CA or the Access Manager CA to create the certificate, you need to import the public key of the trusted root certificate into the browsers to establish the trust. For the Access Manager CA, this certificate is called configCA. For instructions on how to export the public key of a trusted root certificate, see Viewing Trusted Root Details on page 70. To import a public key into the browser, access the certificate options, then follow the prompts:

Access Manager Audit Events and Data 141
Section C.19, NIDS: Connection to User Store Replica Reestablished (002e0013), on

page 154

Section C.20, NIDS: Server Started (002e0014), on page 154 Section C.21, NIDS: Server Stopped (002e0015), on page 155 Section C.22, NIDS: Server Refreshed (002e0016), on page 155 Section C.23, NIDS: Intruder Lockout (002e0017), on page 156 Section C.24, NIDS: Severe Component Log Entry (002e0018), on page 156 Section C.25, NIDS: Warning Component Log Entry (002e0019), on page 157 Section C.26, NIDS: Roles PEP Configured (002e0300), on page 157 Section C.27, Access Gateway: PEP Configured (002e0301), on page 158 Section C.28, J2EE Agent: Web Service Authorization PEP Configured (002e0305), on

page 158

Section C.29, J2EE Agent: JACC Authorization PEP Configured (002e0306), on page 159 Section C.30, Roles Assignment Policy Evaluation (002e0320), on page 160 Section C.31, Access Gateway: Authorization Policy Evaluation (002e0321), on page 160 Section C.32, Access Gateway: Form Fill Policy Evaluation (002e0322), on page 161 Section C.33, Access Gateway: Identity Injection Policy Evaluation (002e0323), on

page 161

Section C.34, J2EE Agent: Web Service Authorization Policy Evaluation (002e0324), on

page 162

Section C.35, J2EE Agent: Web Service SSL Required Policy Evaluation (002e0325), on
Section C.36, J2EE Agent: Startup (002e0401), on page 163 Section C.37, J2EE Agent: Shutdown (002e0402), on page 163 Section C.38, J2EE Agent: Reconfigure (002e0403), on page 164 Section C.39, J2EE Agent: Authentication Successful (002e0404), on page 164 Section C.40, J2EE Agent: Authentication Failed (002e0405), on page 165 Section C.41, J2EE Agent: Web Resource Access Allowed (002e0406), on page 166 Section C.42, J2EE Agent: Clear Text Access Allowed (002e0407), on page 166 Section C.43, J2EE Agent: Clear Text Access Denied (002e0408), on page 167 Section C.44, J2EE Agent: Web Resource Access Denied (002e0409), on page 167 Section C.45, J2EE Agent: EJB Access Allowed (002e040a), on page 168 Section C.46, J2EE Agent: EJB Access Denied (002e040b), on page 169 Section C.47, Access Gateway: Access Denied (0x002e0505), on page 169 Section C.48, Access Gateway: URL Not Found (0x002e0508), on page 170 Section C.49, Access Gateway: System Started (0x002e0509), on page 171 Section C.50, Access Gateway: System Shutdown (0x002e050a), on page 171 Section C.51, Access Gateway: Identity Injection Parameters (0x002e050c), on page 172 Section C.52, Access Gateway: Identity Injection Failed (0x002e050d), on page 173

166 Novell Access Manager 3.1 SP2 Administration Console Guide
Text3 (F): Schema Title: Event Identifier Data Description: Event Tracking Identifier Value1 (1): 0 Group (G): 0 Data Length (X): 0 Data (D): null
C.43 J2EE Agent: Clear Text Access Denied (002e0408)
This event is generated when you select the Denied clear text access option in the Audit Configuration section of the Server Configuration page for the J2EE Agents. Description: J2EE Agent: Clear text access denied Originator (B): Schema Title: Originator Data Description: JCC Device ID (AMDEVICEID#device_id:) Target (U): Schema Title: User Identifier Data Description: User DN SubTarget (Y): Schema Title: Source IP Address Data Description: User IP Address Text1 (S): Schema Title: Authentication Identifier Data Description: IDP Session ID (AMAUTHID#auth_id:) Text2 (T): Schema Title: Permission Requested Data Description: Web User Data Permission Text3 (F): Schema Title: Event Identifier Data Description: Event Tracking Identifier Value1 (1): 0 Group (G): 0 Data Length (X): 0 Data (D): null
C.44 J2EE Agent: Web Resource Access Denied (002e0409)
This event is generated when you select the Denied web resource access option in the Audit Configuration section of the Server Configuration page for the J2EE Agents. Description: J2EE Agent: Web resource access denied Originator (B): Schema Title: Originator Data Description: JCC Device ID (AMDEVICEID#device_id:)
Access Manager Audit Events and Data 167
Target (U): Schema Title: User Identifier Data Description: User DN SubTarget (Y): Schema Title: Source IP Address Data Description: User IP Address Text1 (S): Schema Title: Authentication Identifier Data Description: IDP Session ID (AMAUTHID#auth_id:) Text2 (T): Schema Title: Permission Requested Data Description: Web User Data Permission Text3 (F): Schema Title: Event Identifier Data Description: Event Tracking Identifier Value1 (1): 0 Group (G): 0 Data Length (X): 0 Data (D): null
C.45 J2EE Agent: EJB Access Allowed (002e040a)
This event is generated when you select the Allowed EJB access option in the Audit Configuration section of the Server Configuration page for the J2EE Agents. Description: J2EE Agent: EJB access allowed Originator (B): Schema Title: Originator Data Description: JCC Device ID (AMDEVICEID#device_id:) Target (U): Schema Title: User Identifier Data Description: User DN SubTarget (Y): null Text1 (S): Schema Title: Authentication Identifier Data Description: IDP Session ID (AMAUTHID#auth_id:) Text2 (T): Schema Title: Permission Requested Data Description: EJB Method Permission Text3 (F): Schema Title: Event Identifier Data Description: Event Tracking Identifier Value1 (1): 0 Group (G): 0 Data Length (X): 0 Data (D): null

178 Novell Access Manager 3.1 SP2 Administration Console Guide
Target (U): null SubTarget (Y): null Text1 (S): Schema Title: Device Data Description: IP address and device type of the changed device Text2 (T): blank string Text3 (F): blank string Value1 (1): 0 Group (G): 0 Data Length (X): 0 Data (D): null
C.61 Management Communication Channel: Device Deleted (0x002e0603)
This event is generated when you select the Server Deletes option on the Access Manager Auditing page. Description: Management Communication Channel: Device Deleted In the Event list (Auditing and Logging > Logging Server Options > [Name of Novell Audit Secure Logging Server] > Novell Access Manager > Events), this column is called Event Name. In a query, this column is called EventID. Event ID: 0x002e0603 Originator (B): Schema Title: Originator Data Description: devmanagement (AMDEVICEID#devmanagement:) Target (U): null SubTarget (Y): null Text1 (S): Schema Title: Device Data Description: IP address and device type of the changed device Text2 (T): Schema Title: Administrator Data Description: DN of the administrator deleting the device Text3 (F): blank string Value1 (1): 0 Group (G): 0 Data Length (X): 0 Data (D): null
Access Manager Audit Events and Data 179
C.62 Management Communication Channel: Device Configuration Changed (0x002e0604)
This event is generated when you select the Configuration Changes option on the Access Manager Auditing page. Description: Management Communication Channel: Device Configuration Changed In the Event list (Auditing and Logging > Logging Server Options > [Name of Novell Audit Secure Logging Server] > Novell Access Manager > Events), this column is called Event Name. In a query, this column is called EventID. Event ID: 0x002e0604 Originator (B): Schema Title: Originator Data Description: devmanagement (AMDEVICEID#devmanagement:) Target (U): null SubTarget (Y): null Text1 (S): Schema Title: Device Data Description: IP address and device type of the changed device Text2 (T): Schema Title: Administrator Data Description: DN of the administrator invoking the configuration change Text3 (F): blank string Value1 (1): 0 Group (G): 0 Data Length (X): 0 Data (D): null
C.63 Management Communication Channel: Device Alert (0x002e0605)
This event is generated when you enable auditing. Description: Management Communication Channel: Device Alert In the Event list (Auditing and Logging > Logging Server Options > [Name of Novell Audit Secure Logging Server] > Novell Access Manager > Events), this column is called Event Name. In a query, this column is called EventID. Event ID: 0x002e0605 Originator (B): Schema Title: Originator Data Description: devmanagement (AMDEVICEID#devmanagement:) Target (U): null