2.2.2 Configuring the User Store

  1. 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.

  3. Specify the following details:

    Field

    Description

    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. For the LDAP extension to work, the proxy user requires write rights on the ACL. 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 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

    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 in the Access Manager 5.0 SDK Guide.

    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 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 using that SecretStore for Access Manager secrets. If you select this option, ensure that the admin configured for the user store has sufficient rights to extend the schema and add objects to the tree.

    For additional steps to use secrets, see 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 shares secrets with other applications and these applications use the security flag that locks secrets when a user’s password is reset, you need to select this option.

    • If Access Manager does not share secrets with other applications, the secrets are never locked, and you do not need to select this option.

  4. Under LDAP timeout settings, specify the following details:

    Field

    Description

    LDAP Operation

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

    Idle Connection

    Specify how long before connections begin closing in seconds. If a connection has been idle for the specified duration, the system creates another connection.

  5. To specify a server replica, click New, then specify the following details:

    For an eDirectory server, you must 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.

    Field

    Description

    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 Identity Server.

    This is the only configuration we recommend for the connection between 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 Configuring Credential Profile Security and Display Settings. If you have specified this user store as 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 50. 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. Select the replica, then click Validate to test the connection between Identity Server and replica.

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

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

    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.

  8. 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), Identity Server cannot find the user, and the user cannot log in.

    • If the search context is too broad, 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 about how to create such contracts, see 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.

  9. Click Finish.

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