4.1.1 Configuring Identity User Stores

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

  1. Click Devices > Identity Servers > Servers > Edit > Local.

  2. Select from the following actions:

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

    Delete: Select the user store, then click Delete.The user store list needs to contain at least one configured user store for 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 Configuring the User Store.

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

See the following sections for specific configuration tasks:

Using More Than One LDAP User Store

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

Figure 4-2 Multiple LDAP Directories

It is assumed that each LDAP directory contains different users. Ensure that 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 can 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.

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

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

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

    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 NetIQ Access Manager 4.5 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 more information, 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 recommended configuration 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.

    Enable this option 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 specify 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 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 and 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.

Configuring an Admin User for the User Store

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 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 Identity Server can find the user who is trying to authenticate. The admin user needs browse rights to object class that defines the users and read and compare rights to the attributes of that class. When looking for the user, 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).

  • 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 use an LDAP extension, the user must have write rights on ACL allowing the user to check for account locks, password expiration, grace logins used, and so on.

    To perform these operations, the user must have additional rights. Access Manager uses NMAS that requires the user to have write rights on ACL.

  • 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, verify that the user store admin has appropriate rights to the specified search contexts.

Configuring a User Store for Secrets

Access Manager allows you to securely store user secrets. Secrets are a way to capture user input, such as Login ID and password credentials. These input data can later be reused or injected using Form Fill and Identity Injection policies. This feature is helpful when your Access Manager Credential Profile does not contain credentials for an application protected by Access Manager yet a single sign-on experience is required. Where and how the secrets can be stored is configurable and depends upon your user store:

For troubleshooting tips, see Troubleshooting Secrets Storage.

Configuring the Configuration Datastore to Store Secrets

If you want to do minimal configuration, use the configuration datastore on Administration Console to store the secrets. You can use this option without changes, but is recommended only for use in small Access Manager environments. To increase the security of the secrets, NetIQ recommends that you change the default security options. When you use the configuration datastore of Administration Console as the secret store, the nidswsfss attribute of the nidsLibertyUserProfile object is used to store the secrets.

IMPORTANT:Using this option adds additional load on Administration Console and introduces login delays compared to other options. Therefore, it is recommended that this option is used wisely.

  1. Click Devices > Identity Servers > Edit > Liberty > Web Service Provider.

  2. Click Credential Profile.

  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.

    IMPORTANT:Before using Access Manager to store and encrypt secrets, ensure that you choose your Preferred Encryption Method and change the default Encryption Password Hash Key value. If any of these options is changed after secrets are stored, Access Manager cannot retrieve the secrets.

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

  6. To use the secret store to store policy secrets, see Creating and Managing Shared Secrets.

Configuring an LDAP Directory to Store the Secrets

This is the recommended option. You can use it with any LDAP directory. To use this option, extend the schema to add an attribute to your user object on the LDAP directory that will encrypt and 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 must 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 not, click the name of the replica and reconfigure it.

To configure the LDAP directory, perform the following steps:

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

  2. Click Credential Profile.

  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.

    IMPORTANT:Before using Access Manager to store and encrypt secrets, ensure that you choose your Preferred Encryption Method and change the default Encryption Password Hash Key value. If either of these options are changed after any secrets are stored, Access Manager will not be able to retrieve the secrets.

  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 Identity Servers page, update Identity Server.

  7. To create policies that use the stored secrets, see Creating and Managing Shared Secrets.

For troubleshooting information, see Troubleshooting Secrets Storage.

Configuring an eDirectory User Store to Use SecretStore

If your user store is eDirectory and you have installed Novell SecretStore, you can choose to use the SecretStore on your eDirectory server to store the secrets. This differs from the schema extension method as Novell SecretStore can also be accessed and managed by NetIQ SecureLogin. This allows secrets to be shared with SecureLogin to provide a thick client single sign-on while Access Manager can provide a web single sign-on experience without credential collisions.

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 Identity Server to authenticate as that user and access the user’s secrets. Without this NMAS method, 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 about the rights required, see 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.

    NOTE:While configuring new replicas for the same user store, by default the Use secure LDAP connections option will be selected and the default port will be 636. The Use secure LDAP connections option will be non-editable.

  • If you have enabled a firewall between Administration Console and the user store, and between Identity Server and the user store, ensure 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 SecretStore.

To configure the user store:

  1. 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 SP1 64-bit operating system (or a later version), the eDirectory server is missing some support libraries that this SAML method requires. For information about installing these libraries, see TID 7006437.

  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 Identity Servers page, update Identity Server.

  11. Continue with one of the following:

Determining a Strategy for Unlocking SecretStore

When an administrator resets a user's password, secrets written to SecretStore with an enhanced security flag become locked. 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, perform the following 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 SecretStore is locked, this feature of Access Manager cannot unlock SecretStore. If it is necessary to unlock SecretStore by using the user’s prior password, another tool must be used. See the SecretStore documentation.

  2. Configure Identity Server to perform the check:

    1. Click Devices > Identity Servers > Edit > Local > [User Store Name].

    2. Select the Enable Secret Store lock checking option.

    3. Click OK > OK, then update Identity Server.

  3. Ensure that Web Services Framework is enabled:

    1. Click Devices > Identity Servers > Edit > Liberty > Web Services Framework.

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

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

  4. Continue with Section 10.5.4, Creating and Managing Shared Secrets.

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

Troubleshooting Secrets Storage

Secrets Are Not 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 LDAP 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:

    • If these objects do not exist, verify the following, then continue with Step 5:

      • The admin user for the user store has sufficient rights to extend the schema and add these objects to the Security container.

      • Any configured firewalls must allow NCP and LDAP traffic for Administration Console, Identity Server, and the LDAP user store.

    • If the objects exist, check for time synchronization problems. For more information, see Users Are Receiving Invalid Credential Messages.

  5. In 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. Update 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.

Ensure 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 Are Not 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