3.1 Configuring Identity User Stores

User stores are LDAP directory servers to which end users authenticate. You must specify an initial user store when creating an Identity Server configuration. You use the same procedure for setting up the initial user store, adding a user store, or modifying an existing user store.

  1. In the Administration Console, click Devices > Identity Servers > Servers > Edit > Local.

  2. Select from the following actions:

    New: To add a user store, click New. For configuration information, see Section 3.1.2, Configuring the User Store.

    Delete: To delete a user store, select the user store, then click Delete.The user store list needs to contain at least one configured user store for the Identity Server to be functional.

    Modify: To modify the configuration of an existing user store, click the name of a user store. For configuration information, see Section 3.1.2, Configuring the User Store.

  3. Click OK, then update the Identity Server if you have modified the configuration.

See the following sections for specific configuration tasks:

3.1.1 Using More Than One LDAP User Store

You can configure the Identity Server to search more than one user store during authentication. Figure 3-2 illustrates this type of configuration.

Figure 3-2 Multiple LDAP Directories

It is assumed that each LDAP directory contains different users. You should make sure the users have unique names across all LDAP directories. If both directories contain a user with an identical name, the name and password information discovered in the search of the first directory is always used for authentication. You specify the search order when configuring the authentication method.

When users are added to the configuration store, objects are created for Access Manager profiles. If you delete a user from the LDAP directory, orphaned objects for that user remain in the configuration store. Ensure that you also delete those objects from the configuration store. See Orphaned Objects in the Trust/Configuration Storein the Novell Access Manager 3.1 SP2 Administration Console Guide.

If you add a secondary Administration Console and you have added replicas to the user store of the primary Administration Console, ensure that you also add the replicas to the secondary Administration Console.

All user stores that you add are included in health checks. If health problems are found, the system displays the user store on the Health page and in the trace log file.

3.1.2 Configuring the User Store

  1. In the Administration Console, click Devices > Identity Servers > Servers > Edit > Local.

  2. In the User Stores list, click New or the name of an existing user store.

    If you are creating an Identity Server configuration, this is Step 3 of the wizard.

    Configuring a user store

  3. Fill in the following fields:

    Name: The name of the user store for reference.

    Admin Name: The distinguished name of the admin user of the LDAP directory, or a proxy user with specific LDAP rights to perform searches. Administrator-level rights are required for setting up a user store. This ensures read/write access to all objects used by Access Manager. For more information about this user, see Section 3.1.3, Configuring an Admin User for the User Store.

    Each directory type uses a slightly different format for the DN:

    • eDirectory: cn=admin,ou=users,o=novell

    • Active Directory: cn=Administrator,cn=users,dc=domeh,dc=test,dc=com

      or cn=john smith,cn=users,dc=domeh,dc=test,dc=com

    • Sun ONE: cn=admin,cn=users,dc=novell,dc=com

    Admin Password and Confirm Password: Specify the password for the admin user and confirm it.

    Directory Type: The type of LDAP directory. You can select eDirectory, Active Directory, or Sun ONE. If you have installed an LDAP server plug-in, you can select the custom type that you have configured it to use. For more information, see LDAP Server Plug-In.

    If eDirectory has been configured to use Domain Services for Windows, eDirectory behaves like Active Directory. When you configure such a directory to be a user store, its Directory Type must be set to Active Directory for proper operation.

    Install NMAS SAML method: (eDirectory only) Extends the schema on the eDirectory server and installs an NMAS method. This method converts the Identity Server credentials to a form understood by eDirectory. This method is required if you have installed Novell SecretStore on the eDirectory server and you are going to use that SecretStore for Access Manager secrets. If you select this option, make sure the admin you have configured for the user store has sufficient rights to extend the schema and add objects to the tree.

    For additional configuration steps required to use secrets, see Section 3.1.4, Configuring a User Store for Secrets.

    Enable Secret Store lock checking: (eDirectory only) Enables Access Manager to prompt users for a passphrase when secrets are locked.

    • If Access Manager is sharing secrets with other applications and these applications are using the security flag that locks secrets when a user’s password is reset, you need to enable this option.

    • If Access Manager is not sharing secrets with other applications, the secrets it is using are never locked, and you do not need enable this option.

  4. Under LDAP timeout settings, specify the following:

    LDAP Operation: Specify how long in seconds a transaction can take before timing out.

    Idle Connection: Specify how long in seconds before connections begin closing. If a connection has been idle for this amount of time, the system creates another connection.

  5. To specify a server replica, click New, then fill in the following fields:

    For an eDirectory server, you should use a replica of the partition where the users reside. Ensure that each LDAP server in the cluster has a valid read/write replica. One option is to create a users partition (a partition that points to the OU containing the user accounts) and reference this server replica.

    Name: The display name for the LDAP directory server. If your LDAP directory is replicated on multiple servers, use this name to identify a specific replica.

    IP Address: The IP address of the LDAP directory server.

    Port: The port of the LDAP directory server. Specify 389 for the clear text port, and 636 for the encrypted port.

    Use secure LDAP connections: Specifies that the LDAP directory server requires secure (SSL) connections with the Identity Server.

    This is the only configuration we recommend for the connection between the Identity Server and the LDAP server in a production environment. If you use port 389, usernames and passwords are sent in clear text on the wire.

    This option must be enabled if you use this user store as a Novell SecretStore User Store Reference in the Credential Profile details. (See Section 13.3, Configuring Credential Profile Security and Display Settings.) If you have specified that this user store is a SecretStore User Store Reference, this option is enabled but not editable.

    Connection limit: The maximum number of pooled simultaneous connections allowed to the replica. Valid values are between 5 and 100. How many you need depends upon the speed of your LDAP servers. If you modify the default value, monitor the change in performance. Larger numbers do not necessarily increase performance.

  6. Click Auto import trusted root.

  7. Click OK to confirm the import.

  8. Select one of the certificates in the list.

    You are prompted to choose either a server certificate or a root CA certificate. To trust one certificate, choose Server Certificate. Choose Root CA Certificate to trust any certificate signed by that certificate authority.

  9. Specify an alias, then click OK.

  10. Click OK in the Specify server replica information dialog box.

  11. Select the replica, then click Validate to test the connection between the Identity Server and the replica.

    The system displays the result under Validation Status. The system displays a green check mark if the connection is valid.

  12. (Optional) To add additional replicas for the same user store, repeat Step 5 through Step 11.

    Adding multiple replicas adds load balancing and failover to the user store. Replicas must be exact copies of each other.

    For load balancing, a hash algorithm is used to map a user to a replica. All requests on behalf of that user are sent to that replica. Users are moved from their replica to another replica only when their replica is no longer available.

  13. Add a search context.

    The search context is used to locate users in the directory when a contract is executed.

    • If a user exists outside of the specified search context (object, subtree, one level), the Identity Server cannot find the user, and the user cannot log in.

    • If the search context is too broad, the Identity Server might find more than one match, in which case the contract fails, and the user cannot log in.

    For example, if you allow users to have the same username and these users exist in the specified search context, these users cannot log in if you are using a simple username and password contract. The search for users matching this contract would return more than one match. In this case, you need to create a contract that specifies additional attributes so that the search returns only one match. For more information on how to create such contracts, see Section 15.3.1, Authentication Classes and Duplicate Common Names.

    IMPORTANT:For Active Directory, do not set the search context at the root level and set the scope to Subtree. This setting can cause serious performance problems. It is recommended that you set multiple search contexts, one for each top-level organizational unit.

  14. Click Finish.

  15. If prompted to restart Tomcat, click OK. Otherwise, update the Identity Server.

3.1.3 Configuring an Admin User for the User Store

The Identity Server must log in to each configured user store. It searches for users, and when a user is found, it reads the user’s attributes values. When you configure a user store, you must supply the distinguished name of the user you want the Identity Server to use for logging in. You can use the admin user of your user store, or you can create a specialized admin user for the this purpose. When creating this admin user, you need to grant the following rights:

  • The admin user needs rights to browse the tree, so the Identity Server can find the user who is trying to authenticate. The admin user needs browse rights to the object class that defines the users and read and compare rights to the attributes of that class. When looking for the user, the Identity Server uses the GUID and naming attributes of the user class.

    Directory

    Object Class

    GUID Attribute

    Naming Attribute

    eDirectory

    User

    guid

    cn

    Active Directory

    User

    objectGUID

    sAMAccountName

    Sun ONE

    inetOrgPerson

    nsuniqueid

    uid

  • The admin user needs read rights to any attributes used in policies (Role, Form Fill, Identity Injection, Authorization).

  • If a secret store is used in Form Fill policies, the admin user needs write rights to the attributes storing the secrets.

  • If a password management servlet is enabled, the admin user needs read rights to the attributes controlling grace login limits and remaining grace logins.

  • If you enable provisioning with the SAML or Liberty protocols, the admin user needs write rights to create users in the user store.

  • If you use X.509 authentication, the admin user needs write rights to update the user’s login status attributes.

If your user store is an eDirectory user store, Access Manager verifies that the admin user has sufficient rights to browse for users in the specified search contexts.

IMPORTANT:This check is not performed for Active Directory or Sun ONE. If your users cannot log in, you need to verify that you have given the admin for the user store sufficient rights to the specified search contexts.

3.1.4 Configuring a User Store for Secrets

Access Manager allows you to securely store user secrets. These secrets can then be used in Form Fill and Identity Injection policies. Where and how the secrets are stored depends upon your user store and your configuration:

For some troubleshooting tips, see Troubleshooting the Storing of Secrets.

Configuring the Configuration Datastore to Store the Secrets

When you use the configuration datastore of the Administration Console as the secret store, the nidswsfss attribute of the nidsLibertyUserProfile object is used to store the secrets.

  1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty > Web Service Provider.

  2. Click Credential Profile.

    Credential profile details

  3. Scroll to the Local Storage of Secrets section and configure the following security options:

    Encryption Password Hash Key: (Required) Specify the password that you want to use as a seed to create the encryption algorithm. To increase the security of the secrets, we recommend that you change the default password to a unique alphanumeric value.

    Preferred Encryption Method: Specify the preferred encryption method. Select the method that complies with your security model:

    • Password Based Encryption With MD5 and DES: MD5 is an algorithm that is used to verify data integrity. Data Encryption Standard (DES) is a widely used method of data encryption that uses a private key.

    • DES: Data Encryption Standard (DES) is a widely used method of data encryption that uses a private key. Like other private key cryptographic methods, both the sender and the receiver must know and use the same private key.

    • Triple DES: A variant of DES in which data is encrypted three times with standard DES, using two different keys.

    Extended Schema User Store References: Do not specify a user store reference. When this option contains no values, the configuration datastore is used to store the secrets.

  4. Click OK.

  5. On the Identity Servers page, update the Identity Server.

  6. To use the secret store to store policy secrets, see Creating and Managing Shared Secrets in the Novell Access Manager 3.1 SP2 Policy Guide.

Configuring an LDAP Directory to Store the Secrets

When you use an LDAP directory to store the secrets, you need to enable the user store for the secrets. You select the LDAP directory, then specify an attribute. The attribute you specify is used to store an XML document that contains encrypted secret values. This attribute should be a single-valued case ignore string that you have defined and assigned to the user object in the schema.

To use an LDAP directory to store secrets, your network environment must conform to the following requirements:

  • The user class object must contain an attribute that can be used to store the secrets. This attribute must be a string attribute that is single valued and case ignore.

  • The user store must be configured to use secure connections (click Devices > 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 aren’t, click the name of the replica and reconfigure it.

To configure the LDAP directory:

  1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty > Web Service Providers.

  2. Click Credential Profile.

    Credential profile details

  3. Scroll to the Local Storage of Secrets section and configure the following options:

    Encryption Password Hash Key: (Required) Specifies the password that you want to use as a seed to create the encryption algorithm. To increase the security of the secrets, we recommend that you change the default password to a unique alphanumeric value.

    Preferred Encryption Method: Specifies the preferred encryption method. Select the method that complies with your security model:

    • Password Based Encryption With MD5 and DES: MD5 is an algorithm that is used to verify data integrity. Data Encryption Standard (DES) is a widely used method of data encryption that uses a private key.

    • DES: Data Encryption Standard (DES) is a widely used method of data encryption that uses a private key. Like other private key cryptographic methods, both the sender and the receiver must know and use the same private key.

    • Triple DES: A variant of DES in which data is encrypted three times with standard DES, using two different keys.

  4. To specify where to store secret data, click New under Extended Schema User Store References and fill in the following:

    User Store: Select the user store where you want secret store enabled.

    Attribute Name: Specify the LDAP attribute that you have created to store the secrets on the selected user store.

  5. Click OK twice.

  6. On the Identity Servers page, update the Identity Server.

  7. To create policies that use the stored secrets, see Creating and Managing Shared Secrets in the Novell Access Manager 3.1 SP2 Policy Guide.

For troubleshooting information, see Troubleshooting the Storing of Secrets.

Configuring an eDirectory User Store to Use SecretStore

For Access Manager to use Novell SecretStore, the user store must be eDirectory and Novell SecretStore must be installed there. When configuring this user store for secrets, Access Manager extends the eDirectory schema for an NMAS method. This method converts authentication credentials to a form understood by eDirectory. For example, Access Manager supports smart card and token authentications, and these authentication credentials must be converted into the username and password credentials that eDirectory requires. This allows the Identity Server to authenticate as that user and access the user’s secrets. Without this NMAS method, the Identity Server is denied access to the user’s secrets.

To use a remote SecretStore, your network environment must conform to the following requirements:

  • The eDirectory server must have Novell SecretStore installed.

  • When you configure a user store to use Novell SecretStore, the admin user that you have 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.

  • 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 aren’t, 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.

To configure the user store:

  1. In the Administration Console, click Devices > Identity Servers > Edit > Local.

  2. Click the name of your user store.

  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.

  4. Click Liberty > Web Service Providers.

  5. Click Credential Profile.

    Credential profile details

  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:

Determining a Strategy for Unlocking the SecretStore

When an administrator resets a user's password, secrets written to the Novell SecretStore with an enhanced security flag become locked. The Identity Server does not write the secrets that it creates with this flag, but other applications might:

  • If Access Manager is not sharing secrets with other applications, the secrets it is using are never locked, and you do not need to configure Access Manager to unlock secrets.

  • If Access Manager is sharing secrets with other applications and these application are using the security flag that locks secrets when a user’s password is reset, you need to configure Access Manager so that users can unlock their secrets.

If you want users to receive a prompt for a passphrase when secrets are locked, complete the following configuration steps:

  1. Require all users to set up a passphrase (also called the Master Password).

    Access Manager uses the SecretStore Master Password as the passphrase to unlock the secrets. If the user has not set a passphrase before the SecretStore is locked, this feature of Access Manager cannot unlock the SecretStore. If it is necessary to unlock the SecretStore by using the user’s prior password, another tool must be used. See your SecretStore documentation.

  2. Configure the Identity Server to perform the check:

    1. In the Administration Console, click Devices > Identity Servers > Edit > Local > [User Store Name].

    2. Select the Enable Secret Store lock checking option.

    3. Click OK twice, then update the Identity Server.

  3. Make sure Web Services Framework is enabled:

    1. In the Administration Console, click Devices > Identity Servers > Edit > Liberty > Web Services Framework.

    2. In the Framework General Settings section, make sure that Enable Framework is selected.

    3. Click OK. If you made any changes, update the Identity Server.

  4. Continue with Creating and Managing Shared Secrets in the Novell Access Manager 3.1 SP2 Policy Guide.

When the SecretStore is locked and the users log in, the users are first prompted for their login credentials, then prompted for the passphrase that is used to unlock the SecretStore.

Troubleshooting the Storing of Secrets

Secrets Aren’t Stored in Novell SecretStore

When you use Novell SecretStore to store the secrets, the schema on the eDirectory server must be extended, and specific SAML objects and certificates must be created.

To verify that the schema was extended and the objects were created on the eDirectory server:

  1. Open an LDAP browser and connect to the eDirectory server.

  2. Browse to the Security container.

  3. Look for objects similar to the following:

    If the schema has been extended correctly, you can find a SAML Assertion object in the Authorized Login Methods container. The SAML_Assertion object contains an alphanumeric generated name for a SAML affiliate object. This object has four attributes.

    The SAML affiliate object name is used to generate another container in the Security container. This new container is the <AffiliateObjectName> Trusted Root container that contains public key signing certificate.

  4. Complete one of the following:

  5. In the Administration Console, modify the secret store configuration so that it is resent to the user store:

    1. Click Devices > Identity Servers > Edit > Liberty > Web Service Providers > Credential Profile.

    2. In the Remote Storage of Secrets section, remove the user store, then add it again.

    3. Click OK.

  6. On the Identity Servers page, update the Identity Server.

Users Are Receiving Invalid Credential Messages

The <SAML_Affiliate_Object>.SAML-Assertion.AuthorizedLoginMethods.Security object contains two attributes that determine how long credentials are valid. If your Identity Server and eDirectory server are not time synchronized, the credentials can become invalid before a user has time to use them.

Either make sure that the time of your Identity Server and eDirectory server are synchronized, or increase the value of the authsamlValidAfter and authsamlValidBefore attributes of the SAML affiliate object.

Secrets Aren’t Stored in the LDAP Directory

  1. Open an LDAP browser and connect to the eDirectory server.

  2. Browse to the user object.

  3. Verify that the user object contains the LDAP attribute that you have specified as the attribute to store the secrets.

  4. If the attribute exists, browse to the schema and verify that the attribute has the following characteristics:

    • Single valued

    • Case ignore

    • String