test

Deployment Example 1: Access Manager 7.1 Load Balancing, Distributed Authentication UI, and Session Failover

Chapter 7 Configuring an Access Manager Realm for User Authentication

This chapter contains instructions to create user entries to be used for testing and to import them into the replicated Directory Server user data instances. Additionally, we configure a sub-realm for the users and create an authentication chain for the sub-realm using Access Manager. It contains the following sections.

7.1 Importing Test Users into User Data Instance

You create user entries in the Directory Server user data instance for the following users:

They will be used to verify that the policy agent is configured and working properly. Additionally, the Groups container will be used for the same purpose. This user data is imported into one Directory Server as it will be replicated to the other instance.

Note –

If you are using an existing user data store, create the appropriate users in it and move on to 7.2 Creating and Configuring a Realm for Test Users.

ProcedureTo Import the Test Users Data into Directory Server 1

Create an LDIF file with user entries that is imported into Directory Server 1.

  1. As a root user, log in to the DirectoryServer–1 host machine.

  2. Create an LDIF file with the following entries.

    dn: ou=users,dc=company,dc=com
objectclass: top
objectclass: organizationalUnit
ou: users
description: Container for user entries

dn: ou=Groups,dc=company,dc=com
objectClass: top
objectClass: organizationalUnit
ou: Groups
description: Container for group entries

dn: uid=testuser1,ou=users,dc=company,dc=com
uid: testuser1
givenName: Test
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetadmin
objectClass: inetorgperson
objectClass: inetUser
sn: User1
cn: Test User1
userPassword: password
inetUserStatus: Active

dn: uid=testuser2,ou=users,dc=company,dc=com
uid: testuser2
givenName: Test
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: inetUser
sn: User2
cn: Test User2
userPassword: password
inetUserStatus: Active

  3. Save the file as am-users.ldif in the /tmp directory.

  4. Import the LDIF file into Directory Server 1 using ldapmodify.


    # ldapmodify -h DirectoryServer-1.example.com -p 1489 
  -D "cn=Directory Manager" -w d1rm4n4ger -a -f /tmp/am-users.ldif

adding new entry ou=users,dc=company,dc=com

adding new entry ou=Groups,dc=company,dc=com

adding new entry uid=testuser1,ou=users,dc=company,dc=com

adding new entry uid=testuser2,ou=users,dc=company,dc=com

  5. Verify that the new users were imported using ldapsearch.


    # ldapsearch -h DirectoryServer-1.example.com 
  -b "dc=company,dc=com" -p 1489 -D "cn=Directory Manager" 
  -w d1rm4n4ger "uid=test*"

version: 1
dn: uid=testuser1,ou=users,dc=company,dc=com
uid: testuser1
givenName: Test
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetadmin
objectClass: inetorgperson
objectClass: inetUser
sn: User1
cn: Test User1
userPassword: {SSHA}H5LpB+QLZMoL9SiXzY/DokHKXRclELVy7w25AA==
inetUserStatus: Active

dn: uid=testuser2,ou=users,dc=company,dc=com
uid: testuser2
givenName: Test
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: inetUser
sn: User2
cn: Test User2
userPassword: {SSHA}aLNFCQ1qw78KpJeloVZJAAa5QSAPf/9c2mxCQQ==
inetUserStatus: Active

  6. Log out of the DirectoryServer–1 host machine.

  7. (Optional) Verify that the entries were replicated to Directory Server 2 by logging in as a root user to the DirectoryServer–2 host machine and using ldapsearch.


    # ldapsearch -h DirectoryServer-2.example.com 
  -b "dc=company,dc=com" -p 1489 -D "cn=Directory Manager" 
  -w d1rm4n4ger ""

version: 1
dn: dc=company,dc=com
objectClass: top
objectClass: domain
dc: company

dn: ou=users,dc=company,dc=com
objectClass: top
objectClass: organizationalUnit
ou: users
description: Container for user entries

dn: ou=Groups,dc=company,dc=com
objectClass: top
objectClass: organizationalUnit
objectclass: iplanet-am-managed-group
ou: Groups
description: Container for group entries

dn: uid=testuser1,ou=users,dc=company,dc=com
uid: testuser1
givenName: Test
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetadmin
objectClass: inetorgperson
objectClass: inetUser
sn: User1
cn: Test User1
inetUserStatus: Active
userPassword: {SSHA}H5LpB+QLZMoL9SiXzY/DokHKXRclELVy7w25AA==

dn: uid=testuser2,ou=users,dc=company,dc=com
uid: testuser2
givenName: Test
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
objectClass: inetUser
sn: User2
cn: Test User2
inetUserStatus: Active
userPassword: {SSHA}aLNFCQ1qw78KpJeloVZJAAa5QSAPf/9c2mxCQQ==

  8. Log out of the DirectoryServer–2 host machine.

7.2 Creating and Configuring a Realm for Test Users

At this point, the root realm is configured to authenticate against the Directory Server configuration data instances. We use the root realm to authenticate special Access Manager accounts (like amadmin and agents) but, we now create a sub-realm to authenticate end users against the Directory Server user data instances. This creates a demarcation between Access Manager configuration and administrative account data, and the end-user profiles.

With the following procedures, we create a sub-realm to which we add our text subjects, and then configure the realm properties to suit the needs of this deployment example.

ProcedureTo Create a Realm

  1. Access http://LoadBalancer-3.example.com:7070/ from a web browser.

    This is the Access Manager load balancer.

  2. Log in to the Access Manager console as the administrator.

    User Name:

    amadmin

    Password:

    4m4dmin1

  3. Click the Access Control tab.

  4. Click New to create a new realm.

  5. On the New Realm page, enter users in the Name field.

  6. Enter users in the New Value field of the Realm/DNS Aliases list and click Add.

  7. Click OK.

    The users realm is listed as a sub-realm of the top-level realm, example.

ProcedureTo Change the Default User Data Store and Configure an Authentication Module for the Realm

Now we instantiate an authentication module and reconfigure the default ldapService authentication chain to use the new authentication module. Additionally, we will change the realm's User Profile attribute and delete the default authentication module instances. During this procedure, we also change the default user data store to the user data instance previously created.

Before You Begin

This procedure assumes you have just completed To Create a Realm and are still logged in to the Access Manager console.

  1. Under the Access Control tab, click the users realm.

  2. Click the Authentication tab.

  3. Click Advanced Properties in the General section.

  4. On the resulting page, change the value of the User Profile attribute to Ignored.

    This new value specifies that a user profile is not required by the Authentication Service to issue a token after successful authentication.

  5. Click Save.

    The profile is updated.

  6. Click Back to Authentication.

    You will return to the users realm Authentication page.

  7. Under Module Instances section, click New.

    These next steps instantiate the Data Store authentication module in the users sub-realm.

    1. On the New Module Instance page, set the following attribute values:

      Name:

      usersDataStore

      Type:

      Choose Data Store

    2. Click OK.

      You will return to the users realm Authentication page and the usersDataStore module is displayed in the list of Module Instances.

  8. Under Authentication Chaining, click on the default ldapService chain.

    These next steps reconfigure the default ldapService chain to use the new authentication module.

    1. On the resulting page, select usersDataStore in the Instance column.

    2. Set the Criteria attribute to Required.

    3. Click Save.

      The ldapService chain is updated.

    4. Click Back to Authentication.

      You will return to the users realm Authentication page.

  9. Under Module Instances, mark the checkbox for LDAP and Data Store.

    These modules are inherited from the default top-level realm and used to authenticate to the Access Manager configuration data instance of Directory Server. They are no longer needed now that the usersDataStore authentication module instance will be used.

  10. Click Delete

    The modules are deleted and the users realm Authentication page is displayed.

  11. Click Save.

  12. Click the Data Stores tab.

    1. Mark the checkbox for amConfigDS.

      This is the data store inherited from the parent realm.

    2. Click Delete.

    3. Click New.

    4. On the resulting page, set the following attributes:

      Name:

      usersLDAP

      Type:

      Choose Generic LDAPv3

    5. Click Next.

    6. On the resulting page, set the following attributes:

      LDAP Server

      • Enter the hostname and port number for the existing directory in the form LoadBalancer-2.example.com:489 and click Add.

      • Select the default LoadBalancer-1.example.com:389 and click Remove.

      LDAP Bind DN

      Enter cn=Directory Manager

      LDAP Bind Password

      Enter d1rm4n4ger

      LDAP Bind Password (confirm)

      Enter d1rm4n4ger

      LDAP Organization DN

      Replace dc=example,dc=com with dc=company,dc=com

      LDAP User Object Classes

      Add inetorgperson as a new value.

      LDAP People Container Value

      Replace people with users.

      Note –

      If this field is empty, the search for user entries will start from the root suffix.

      Persistent Search Base DN

      Replace dc=example,dc=com with dc=company,dc=com

    7. Click Finish.

  13. Log out of the Access Manager console.

ProcedureTo Verify That Access Manager Recognizes the External User Data Store

  1. Access http://AccessManager-1.example.com:1080/amserver/console from a web browser.

  2. Log in to the Access Manager console as the administrator.

    User Name:

    amadmin

    Password:

    4m4dmin1

  3. Click on the Access Control tab

  4. Click on the users sub-realm.

  5. Click on the Subjects tab.

    You should see Test User1 and Test User2.

  6. Log out of the Access Manager console.

ProcedureTo Verify That a Realm Subject Can Successfully Authenticate

  1. Access http://AccessManager-1.example.com:1080/amserver/UI/Login?realm=users from a web browser.

    The parameter realm=users specifies the realm to use for authentication. At this point, a user can log in against Directory Server only if the realm parameter is defined in the URL.

  2. Log in to Access Manager with a user name and password from the am-users directory.

    User Name

    testuser1

    Password

    password

    You should be able to log in successfully and see a page with a message that reads You're logged in. Since the User Profile attribute was set to Ignored, the user's profile is not displayed after a successful login. If the login is not successful, watch the Directory Server access log to troubleshoot the problem.

  3. Log out of the Access Manager console.