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.
You create user entries in the Directory Server user data instance for the following users:
testuser1
testuser2
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.
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.
Create an LDIF file with user entries that is imported into Directory Server 1.
As a root user, log in to the DirectoryServer–1 host machine.
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
Save the file as am-users.ldif in the /tmp directory.
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 |
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 |
Log out of the DirectoryServer–1 host machine.
(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== |
Log out of the DirectoryServer–2 host machine.
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.
To Change the Default User Data Store and Configure an Authentication Module for the Realm
To Verify That Access Manager Recognizes the External User Data Store
To Verify That a Realm Subject Can Successfully Authenticate
Access http://LoadBalancer-3.example.com:7070/ from a web browser.
This is the Access Manager load balancer.
Log in to the Access Manager console as the administrator.
amadmin
4m4dmin1
Click the Access Control tab.
Click New to create a new realm.
On the New Realm page, enter users in the Name field.
Enter users in the New Value field of the Realm/DNS Aliases list and click Add.
Click OK.
The users realm is listed as a sub-realm of the top-level realm, example.
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.
This procedure assumes you have just completed To Create a Realm and are still logged in to the Access Manager console.
Under the Access Control tab, click the users realm.
Click the Authentication tab.
Click Advanced Properties in the General section.
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.
Click Save.
The profile is updated.
Click Back to Authentication.
You will return to the users realm Authentication page.
Under Module Instances section, click New.
These next steps instantiate the Data Store authentication module in the users sub-realm.
Under Authentication Chaining, click on the default ldapService chain.
These next steps reconfigure the default ldapService chain to use the new authentication module.
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.
Click Delete
The modules are deleted and the users realm Authentication page is displayed.
Click Save.
Click the Data Stores tab.
Mark the checkbox for amConfigDS.
This is the data store inherited from the parent realm.
Click Delete.
Click New.
On the resulting page, set the following attributes:
usersLDAP
Choose Generic LDAPv3
Click Next.
On the resulting page, set the following attributes:
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.
Enter cn=Directory Manager
Enter d1rm4n4ger
Enter d1rm4n4ger
Replace dc=example,dc=com with dc=company,dc=com
Add inetorgperson as a new value.
Replace people with users.
If this field is empty, the search for user entries will start from the root suffix.
Replace dc=example,dc=com with dc=company,dc=com
Click Finish.
Log out of the Access Manager console.
Access http://AccessManager-1.example.com:1080/amserver/console from a web browser.
Log in to the Access Manager console as the administrator.
amadmin
4m4dmin1
Click on the Access Control tab
Click on the users sub-realm.
Click on the Subjects tab.
You should see Test User1 and Test User2.
Log out of the Access Manager console.
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.
Log in to Access Manager with a user name and password from the am-users directory.
testuser1
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.
Log out of the Access Manager console.