This chapter contains instructions on how to install and configure Sun Java™ System Access Manager. It begins with installation of the two web containers into which the Access Manager WAR will be deployed. It also contains instructions for other post-installation procedures, including the configuration of the Access Manager load balancer. It contains the following sections:
6.2 Deploying and Configuring Access Manager 1 and Access Manager 2
6.5 Reconfiguring Access Manager to Communicate with Directory Server
In this section, we will create a non-root user with the roleadd command in the Solaris Operating Environment, and install Sun Java System Web Server using the non-root user on each Access Manager host machine. Use the following as your checklist for completing these tasks.
To Create a Non-Root User on the Access Manager 1 Host Machine
To Create a Non-Root User on the Access Manager 2 Host Machine
Web Server can also be installed with a root user.
As a root user, log in to the AccessManager–1 host machine.
Use roleadd to create a new user.
# roleadd -s /sbin/sh -m -g staff -d /export/am71adm am71adm |
We chose to use roleadd rather than useradd for security reasons as roleadd disables the ability of the user to log in.
(Optional) Verify that the user was created.
# cat /etc/passwd root:x:0:0:Super-User:/:/sbin/sh daemon:x:1:1::/: ... nobody4:x:65534:SunOS 4.x NFS Anonymous Access User:/: am71adm:x:215933:10::/export/am71adm:/sbin/sh |
(Optional) Verify that the user's directory was created.
# cd /export/am71adm # ls local.cshrc local.profile local.login |
Create a password for the non-root user.
# passwd am71adm New Password: 4m71a6m Re-ener new Pasword: 4m71a6m passwd: password successfully changed for am71adm |
If you do not perform this step, you will not be able to switch user (su) when logged in as the non-root user.
This procedure assumes you have just completed To Create a Non-Root User on the Access Manager 1 Host Machine.
On the AccessManager-1 host machine, install required patches if necessary.
# patchadd -p | grep 117461-08 |
A list of patch numbers is displayed. On our lab machine, the required patch 117461-08 is present so there is no need to install patches at this time.
Results for your machines might be different. Read the latest version of the Web Server 7.0 Release Notes to determine if you need to install patches and, if so, what they might be. You can search for patches directly at http://sunsolve.sun.com by navigating to the PatchFinder page, entering the patch number and clicking Find Patch.
Create a directory into which the Web Server bits can be downloaded and change into it.
# mkdir /export/WS7 # cd /export/WS7 |
Download the Sun Java System Web Server 7.0 software from http://www.sun.com/download/products.xml?id=45ad781d.
Follow the instructions on the Sun Microsystems Product Downloads web site for downloading the software.
Unpack the software package.
# gunzip sjsws-7_0-solaris-sparc.tar.gz # tar xvf sjsws-7_0-solaris-sparc.tar |
Run setup.
# ./setup --console |
When prompted, provide the following information.
|
Press Enter. Continue to press Enter when prompted. |
|
|
Enter yes. |
|
|
Enter /opt/SUNWwbsvr |
|
|
Enter yes. |
|
|
Enter 2. |
|
|
Enter 1,3,5. |
|
|
Enter 1. |
|
|
Enter 1. |
|
|
Enter no. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Enter no. |
|
|
Enter am71adm. |
|
|
Accept the default value. |
|
|
Enter web4dmin. |
|
|
Enter web4dmin. |
|
|
Accept the default value. |
|
|
Enter 1080. |
|
|
Accept the default value. |
|
|
Enter 1. |
When installation is complete, the following message is displayed:
Installation Successful. |
To verify that Web Server was installed with the non-root user, examine the permissions.
# cd /opt/SUNWwbsvr/admin-server/ # ls -al total 16 drwxr-xr-x 8 root root 512 Jul 19 10:36 . drwxr-xr-x 11 am71adm staff 512 Jul 19 10:36 .. drwxr-xr-x 2 root root 512 Jul 19 10:36 bin drwx------ 2 am71adm staff 512 Jul 19 10:36 config drwx------ 3 am71adm staff 512 Jul 19 11:09 config-store drwx------ 3 am71adm staff 512 Jul 19 10:40 generated drwxr-xr-x 2 am71adm staff 512 Jul 19 10:40 logs drwx------ 2 am71adm staff 512 Jul 19 10:36 sessions |
The appropriate files and directories are owned by am71adm.
Start the Web Server 1 administration server.
# su am71adm # cd /opt/SUNWwbsvr/admin-server/bin # ./startserv |
Verify that the non-root user was able to start Web Server with the following sub-procedure.
Log out of the AccessManager–1 host machine.
As a root user, log in to the AccessManager–2 host machine.
Use roleadd to create a new user.
# roleadd -s /sbin/sh -m -g staff -d /export/am71adm am71adm |
(Optional) Verify that the user was created.
# cat /etc/passwd root:x:0:0:Super-User:/:/sbin/sh daemon:x:1:1::/: ... nobody4:x:65534:SunOS 4.x NFS Anonymous Access User:/: am71adm:x:215933:10::/export/am71adm:/sbin/sh |
(Optional) Verify that the user's directory was created.
# cd /export/am71adm # ls local.cshrc local.profile local.login |
Create a password for the non-root user.
# passwd am71adm New Password: 4m71a6m Re-ener new Pasword: 4m71a6m passwd: password successfully changed for am71adm |
If you do not perform this step, you will not be able to switch user (su) when logged in as the non-root user.
This procedure assumes that you just completed To Create a Non-Root User on the Access Manager 2 Host Machine.
On the AccessManager-2 host machine, install required patches if necessary.
# patchadd -p | grep 117461-08 |
A list of patch numbers is displayed. On our lab machine, the required patch 117461-08 is present so there is no need to install patches at this time.
Results for your machines might be different. Read the latest version of the Web Server 7.0 Release Notes to determine if you need to install patches and, if so, what they might be. You can search for patches directly at http://sunsolve.sun.com by navigating to the PatchFinder page, entering the patch number and clicking Find Patch.
Create a directory into which the Web Server bits can be downloaded and change into it.
# mkdir /export/WS7 # cd /export/WS7 |
Download the Sun Java System Web Server 7.0 software from http://www.sun.com/download/products.xml?id=45ad781d.
Follow the instructions on the Sun Microsystems Product Downloads web site for downloading the software.
Unpack the software package.
# gunzip sjsws-7_0-solaris-sparc.tar.gz # tar xvf sjsws-7_0-solaris-sparc.tar |
Run setup.
# ./setup --console |
When prompted, provide the following information.
|
Press Enter. Continue to press Enter when prompted. |
|
|
Enter yes. |
|
|
Enter /opt/SUNWwbsvr |
|
|
Enter yes. |
|
|
Enter 2. |
|
|
Enter 1,3,5. |
|
|
Enter 1. |
|
|
Enter 1. |
|
|
Enter no. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Enter no. |
|
|
Enter am71adm. |
|
|
Accept the default value. |
|
|
Enter web4dmin. |
|
|
Enter web4dmin. |
|
|
Accept the default value. |
|
|
Enter 1080. |
|
|
Accept the default value. |
|
|
Enter 1. |
When installation is complete, the following message is displayed:
Installation Successful. |
To verify that Web Server was installed with the non-root user, examine the permissions.
# cd /opt/SUNWwbsvr/admin-server/ # ls -al total 16 drwxr-xr-x 8 root root 512 Jul 19 10:36 . drwxr-xr-x 11 am71adm staff 512 Jul 19 10:36 .. drwxr-xr-x 2 root root 512 Jul 19 10:36 bin drwx------ 2 am71adm staff 512 Jul 19 10:36 config drwx------ 3 am71adm staff 512 Jul 19 11:09 config-store drwx------ 3 am71adm staff 512 Jul 19 10:40 generated drwxr-xr-x 2 am71adm staff 512 Jul 19 10:40 logs drwx------ 2 am71adm staff 512 Jul 19 10:36 sessions |
The appropriate files and directories are owned by am71adm.
Start the Web Server 2 administration server.
# su am71adm # cd /opt/SUNWwbsvr/admin-server/bin # ./startserv |
Verify that the non-root user was able to start Web Server with the following sub-procedure.
Log out of the AccessManager–2 host machine.
An Access Manager WAR will be deployed in the installed Web Server containers on both the Access Manager host machines. Additionally, you will configure the installations and back up the Access Manager configuration data. Use the following list of procedures as a checklist for completing the tasks.
To Generate an Access Manager WAR File on the Access Manager 1 Host Machine
To Back Up the Access Manager Configuration Data from Directory Server 1
As a root user, log in to the AccessManager–1 host machine.
Create a directory into which the Access Manager WAR file can be downloaded and change into it.
# mkdir /export/AM71 # cd /export/AM71 |
Download the Access Manager 7.1 WAR file from http://www.sun.com/download/products.xml?id=460d5c8e.
Unzip the Access Manager download.
# unzip AccessManager7_1RTM.zip # ls -al total 228716 drwxr-xr-x 6 root root 512 Jul 11 20:00 . drwxr-xr-x 5 root sys 512 Jul 19 10:30 .. -rw-r--r-- 1 root root 117008919 Jul 10 15:00 AccessManager7_1RTM.zip drwxr-xr-x 4 root root 512 Jun 25 20:16 applications drwxr-xr-x 2 root root 1536 Jun 25 20:16 legal -rw-r--r-- 1 root root 3018 Jun 25 20:16 README drwxr-xr-x 2 root root 512 Jun 25 20:16 samples -r--r--r-- 1 root root 11934 Jun 25 20:16 Software_License_Agt_SLA.txt drwxr-xr-x 2 root root 512 Jun 25 20:16 tools |
Switch to the non-root user.
# su am71adm |
Create a staging area in which the WAR will be exploded.
# cd /export/am71adm # mkdir am-staging |
In the staging area, after exploding the WAR, you can modify the WAR contents to suit your needs, generate a new WAR, and deploy it on any number of remote host computers. Whenever you need to make changes to the WAR, you maintain the changes in this one staging area, and redeploy the modified WAR as many times as you want, on as many host machines as you need.
Explode the WAR file.
# cd am-staging # jar xvf /export/AM71/applications/jdk15/amserver.war |
Add the following context parameter to the web.xml file.
By default, during the WAR deployment, Access Manager creates a bootstrap file in the user's home directory. The bootstrap file points to the directory where all the Access Manager configurations will be created. By specifying this new context parameter, Access Manager will create the bootstrap file in the directory you specify; in this case, /export/am71adm/bootstrap. web.xml is located in /export/am71adm/am-staging/WEB-INF/.
<context-param> <param-name>com.sun.identity.bootClassPath</param-name> <param-value>/export/am71adm/bootstrap</param-value> </context-param> |
Regenerate the Access Manager WAR file.
# cd /export/am71adm/am-staging # jar cvf ../amserver.war * |
A new WAR file is created, including the modified web.xml.
Verify that the new WAR file was created in the proper location and with the appropriate permissions.
# cd /export/am71adm # ls -al total 62262 drwxr-xr-x 6 am71adm staff 512 Jul 19 11:46 . drwxr-xr-x 5 root sys 512 Jul 19 10:30 .. -rw-r--r-- 1 am71adm staff 144 Jul 19 10:30 .profile drwx------ 3 am71adm staff 512 Jul 19 10:40 .sunw -rw-r--r-- 1 am71adm staff 566 Jul 19 11:06 .wadmtruststore drwxr-xr-x 16 am71adm staff 512 Jul 19 10:47 am-staging -rw-r--r-- 1 am71adm staff 31834862 Jul 19 10:56 amserver.war -rw-r--r-- 1 am71adm staff 136 Jul 19 10:30 local.cshrc -rw-r--r-- 1 am71adm staff 157 Jul 19 10:30 local.login -rw-r--r-- 1 am71adm staff 174 Jul 19 10:30 local.profile |
The amserver.war file is owned by am71adm.
This procedure assumes you have just completed To Generate an Access Manager WAR File on the Access Manager 1 Host Machine.
On the AccessManager-1 host machine, start the Web Server administration server.
# cd /opt/SUNWwbsvr/admin-server/bin # ./startserv |
Change to the non-root user am71adm.
# cd /opt/SUNWwbsvr/bin # su am71adm |
Start the Web Server AccessManager-1 instance.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com/bin # ./startserv |
Run wadm add-webapp to add the Access Manager WAR file to the Web Server.
# ./wadm add-webapp --user=admin --host=AccessManager-1.example.com --port=8989 --config=AccessManager-1.example.com --vs=AccessManager-1.example.com --uri=/amserver /export/am71adm/amserver.war Please enter admin-user-password> web4dmin ... Do you trust the above certificate? [yes/no] yes CLI201 Command 'add-webapp' ran successfully. |
Run wadm deploy-config to deploy the Access Manager WAR file.
# ./wadm deploy-config --user=admin --host=AccessManager-1.example.com --port=8989 AccessManager-1.example.com Please enter admin-user-password> web4dmin CLI201 Command 'deploy-config' ran successfully. |
To verify that the Access Manager WAR file was successfully deployed, list the contents of the Web Server instance directory.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com/ web-app/AccessManager-1.example.com # ls -al total 6 drwxr-xr-x 3 am71adm staff 512 Jul 19 11:08 . drwxr-xr-x 3 am71adm staff 512 Jul 19 11:08 .. drwxr-xr-x 16 am71adm staff 512 Jul 19 11:09 amserver |
amserver exists in the directory and is owned by the non-root user am71adm.
Restart the Web Server instance.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com/bin # ./stopserv; ./startserv |
Log out of the AccessManager–1 host machine.
This procedure assumes you have completed To Generate an Access Manager WAR File on the Access Manager 1 Host Machine.
As a root user, log in to the AccessManager–2 host machine.
Change to the non-root user am71adm.
# su am71adm |
Change into the am71adm directory.
# cd /export/am71adm |
Copy amserver.war from the AccessManager–1 host machine to the am71adm directory.
Verify that the WAR file was copied into the proper location and with the appropriate permissions.
# ls -al total 62260 drwxr-xr-x 5 am71adm staff 512 Jul 19 12:10 . drwxr-xr-x 6 root sys 512 Jul 19 11:53 .. -rw-r--r-- 1 am71adm staff 144 Jul 19 11:53 .profile drwx------ 3 am71adm staff 512 Jul 19 11:57 .sunw -rw-r--r-- 1 am71adm staff 566 Jul 19 12:05 .wadmtruststore -rw-r--r-- 1 am71adm staff 31834862 Jul 19 12:01 amserver.war -rw-r--r-- 1 am71adm staff 136 Jul 19 11:53 local.cshrc -rw-r--r-- 1 am71adm staff 157 Jul 19 11:53 local.login -rw-r--r-- 1 am71adm staff 174 Jul 19 11:53 local.profile |
The amserver.war files are owned by am71adm.
This procedure assumes you have just completed To Copy the Access Manager WAR File to Access Manager 2.
On the AccessManager-2 host machine, start the Web Server administration server.
# cd /opt/SUNWwbsvr/admin-server/bin # ./startserv |
Change to the non-root user am71adm.
# cd /opt/SUNWwbsvr/bin # su am71adm |
Start the Web Server AccessManager-2 instance.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com/bin # ./startserv |
Run wadm add-webapp to add the Access Manager WAR file to the Web Server container.
# ./wadm add-webapp --user=admin --host=AccessManager-2.example.com --port=8989 --config=AccessManager-2.example.com --vs=AccessManager-2.example.com --uri=/amserver /export/am71adm/amserver.war Please enter admin-user-password> web4dmin ... Do you trust the above certificate? [yes/no] yes CLI201 Command 'add-webapp' ran successfully. |
Run wadm deploy-config to deploy the Access Manager WAR file.
# ./wadm deploy-config --user=admin --host=AccessManager-2.example.com --port=8989 AccessManager-2.example.com Please enter admin-user-password> web4dmin CLI201 Command 'deploy-config' ran successfully. |
To verify that the Access Manager WAR file was successfully deployed, list the contents of the Web Server instance directory.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com/ web-app/AccessManager-2.example.com # ls -al total 6 drwxr-xr-x 3 am71adm staff 512 Jul 19 12:07 . drwxr-xr-x 3 am71adm staff 512 Jul 19 12:07 .. drwxr-xr-x 16 am71adm staff 512 Jul 19 12:07 amserver |
amserver exists in the directory and is owned by the non-root user am71adm.
Restart the Web Server instance.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com/bin # ./stopserv; ./startserv |
Log out of the AccessManager–2 host machine.
The encryption key used in this procedure must be identical to the encryption key used in the procedure To Configure Access Manager 2. You should therefore save the encryption key from this procedure for easy access when you are configuring Access Manager 2.
This constraint is particular to this deployment example only.
Access http://AccessManager-1.example.com:1080/amserver from a web browser.
The Access Manager Configurator page is displayed for first time access.
Provide the following information on the Configurator page.
4m4dmin1
4m4dmin1
/export/am71adm/config
The value is PXXdT8Sf+ubQwxUhB+/R37LVBrJFYNnhR.
Copy the value from this field, and save it for use in To Configure Access Manager 2.
Choose Directory Server.
It is a common mistake to accept the default value here. Be sure to choose Directory Server.
LoadBalancer-1.example.com
389
dc=example,dc=com
cn=Directory Manager
d1rm4n4ger
d1rm4n4ger
Click the box to mark it.
Click Configure.
When configuration is complete, you are redirected to the Access Manager login page.
Log in to the Access Manager console as the administrator.
amadmin
4m4dmin1
If authentication succeeds, Access Manager has successfully accessed the Directory Server load balancer. You should see the example realm in the Realm page.
Log out of the Access Manager console.
(Optional) To verify that the Access Manager schema was successfully loaded into the configuration data instance on the DirectoryServer–1 host machine do the following.
As a root user, log in to the DirectoryServer–1 host machine.
Run ldapsearch.
# ldapsearch -p 1389 -b "dc=example,dc=com" -D "cn=Directory Manager" -w d1rm4n4ger "(objectclass=*)" |
You should see a number of entries for Access Manager administrators and special users.
Log out of the DirectoryServer–1 host machine.
(Optional) To verify that the config directory and the supporting bootstrap directory have been created with the proper permissions, do the following.
As a root user, log in to the AccessManager–1 host machine.
Examine the file system.
# cd /export/am71adm # ls -al total 62262 drwxr-xr-x 6 am71adm staff 512 Jul 19 11:46 . drwxr-xr-x 5 root sys 512 Jul 19 10:30 .. -rw-r--r-- 1 am71adm staff 144 Jul 19 10:30 .profile drwx------ 3 am71adm staff 512 Jul 19 10:40 .sunw -rw-r--r-- 1 am71adm staff 566 Jul 19 11:06 .wadmtruststore drwxr-xr-x 16 am71adm staff 512 Jul 19 10:47 am-staging -rw-r--r-- 1 am71adm staff 31834862 Jul 19 10:56 amserver.war drwxr-xr-x 3 am71adm staff 512 Jul 19 11:46 bootstrap drwxr-xr-x 3 am71adm staff 512 Jul 19 11:46 config -rw-r--r-- 1 am71adm staff 136 Jul 19 10:30 local.cshrc -rw-r--r-- 1 am71adm staff 157 Jul 19 10:30 local.login -rw-r--r-- 1 am71adm staff 174 Jul 19 10:30 local.profile |
The config directory and the bootstrap directory were created, and are owned by non-root user am71adm.
Log out of the AccessManager–1 host machine.
If you cannot login successfully, try the fully qualified name for the user amadmin. If you can authenticate using the fully qualified name, you can focus on issues other than authentication and login. In the /export/am71adm/config/AMConfig.properties file, the value of com.sun.identity.authentication.super.user is the fully qualified name for amadmin; in this example, uid=amAdmin,ou=People,dc=example,dc=com.
The encryption key used in this procedure must be identical to the encryption key used in the procedure To Configure Access Manager 1. If you did not save the encryption key, it can be found as the value of the am.encryption.pwd property in the /export/am71adm/config/AMConfig.properties file on the Access Manager 1 host machine.
This constraint is particular to this deployment example only.
Access http://AccessManager-2.example.com:1080/amserver from a web browser.
The Access Manager Configurator page is displayed for first time access.
Provide the following information on the Configurator page.
4m4dmin1
4m4dmin1
/export/am71adm/config
PXXdT8Sf+ubQwxUhB+/R37LVBrJFYNnhR
Be sure this value is copied from Access Manager 1. See To Configure Access Manager 1.
Choose Directory Server.
It is a common mistake to accept the default value here. Be sure to choose Directory Server.
LoadBalancer-1.example.com
389
dc=example,dc=com
cn=Directory Manager
d1rm4n4ger
d1rm4n4ger
Do not mark the box with a check. The user management schema was loaded into Directory Server when you configured Access Manager 1.
Click Configure.
When configuration is complete, you are redirected to the Access Manager login page.
Log in to the Access Manager console as the administrator.
amadmin
4m4dmin1
If authentication succeeds, Access Manager has successfully accessed the Directory Server load balancer. You should see the example realm in the Realm page.
Click the example realm name.
You should see three values in the Realms/DNS Aliases List.
accessmanager-1.example.com
accessmanager-2.example.com
example
Log out of the Access Manager console.
(Optional) To verify that the config directory and the supporting bootstrap directory have been created with the proper permissions, do the following.
As a root user, log in to the AccessManager–2 host machine.
Examine the file system.
# cd /export/am71adm # ls -al total 62262 drwxr-xr-x 6 am71adm staff 512 Jul 19 11:46 . drwxr-xr-x 5 root sys 512 Jul 19 10:30 .. -rw-r--r-- 1 am71adm staff 144 Jul 19 10:30 .profile drwx------ 3 am71adm staff 512 Jul 19 10:40 .sunw -rw-r--r-- 1 am71adm staff 566 Jul 19 11:06 .wadmtruststore -rw-r--r-- 1 am71adm staff 31834862 Jul 19 10:56 amserver.war drwxr-xr-x 3 am71adm staff 512 Jul 19 11:46 bootstrap drwxr-xr-x 3 am71adm staff 512 Jul 19 11:46 config -rw-r--r-- 1 am71adm staff 136 Jul 19 10:30 local.cshrc -rw-r--r-- 1 am71adm staff 157 Jul 19 10:30 local.login -rw-r--r-- 1 am71adm staff 174 Jul 19 10:30 local.profile |
amserver.war and the bootstrap and config files are all in this directory, and owned by non-root user am71adm.
Log out of the AccessManager–2 host machine.
If you cannot login successfully, try the fully qualified name for the user amadmin. If you can authenticate using the fully qualified name, you can focus on issues other than authentication and login. In the /export/am71adm/config/AMConfig.properties file, the value of com.sun.identity.authentication.super.user is the fully qualified name for amadmin; in this example, uid=amAdmin,ou=People,dc=example,dc=com.
Backing up your Access Manager configuration data ensures that if you run into problems later, you can revert to this configuration without having to reinstall Access Manager. In this procedure, we will back up the configuration data from Directory Server 1.
As a root user, log in to the DirectoryServer–1 host machine.
Stop the configuration data instance on Directory Server 1.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsadm stop /var/opt/mps/am-config Server stopped |
The backup utility db2ldif can only be used if the slapd process has been shutdown.
Change to the am-config directory.
# cd /var/opt/mps/am-config |
Run db2ldif from within the am-config directory.
# ./db2ldif -n dbExample ldiffile: /var/opt/mps/am-config/ldif/2007_06_27_132405.ldif [27/Jun/2007:13:24:06 -0700] - export dbExample: Processed n entries (100%). |
(Optional) Create a README that describes the contents of the new LDIF file.
# cd /var/opt/mps/am-config/ldif # ls 2007_06_27_132405.ldif # cat > README Hit ENTER and type the following: 2007_06_27_132405.ldif: backup after post-am install, pre-patch application Hit Control D to terminate the cat command ^D # ls 2007_06_27_132405.ldif README |
Start the configuration data instance on Directory Server 1.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsadm start /var/opt/mps/am-config |
Log out of the DirectoryServer–1 host machine.
The Access Manager servers are fronted by one load balancer (Load Balancer 3). Users internal to the company will access the servers through the non-secure port 7070. Users external to the company will access the servers through the secure port 9443. Additionally, configuring two load balancer instances enables you to customize internal-facing and external-facing login pages. Users external to your company first access the Distributed Authentication User Interface which, in turn, routes the request to the secure port 9443. The following figure illustrates this architecture.
Load Balancer 3 sends the user and agent requests to the server where the session originated. Secure Sockets Layer (SSL) is terminated before a request is forwarded to the Access Manager servers to allow the load balancer to inspect the traffic for proper routing. Load Balancer 3 is capable of the following types of load balancing:
Cookie-based |
The load balancer makes decisions based on client's cookies. The load balancer looks at the request and detects the presence of a cookie by a specific name. If the cookie is detected in the request, the load balancer routes the request to the specific server to which the cookie has been assigned. If the cookie is not detected in the request, the load balancer balances client requests among the available servers. |
IP-based |
This is similar to cookie-based load balancing, but the decision is based on the IP address of the client. The load balancer sends all requests from a specific IP address to the same server. |
TCP |
The load balancer mainstreams session affinity. This means that all requests related to a TCP session, are forwarded to the same server. In this deployment example, Load Balancer 3 forwards all requests from a single client to exactly the same server. When the session is started and maintained by one client, session affinity is guaranteed. This type of load-balancing is applicable to the TCP-based protocols. |
Use the following list of procedures as a checklist for configuring the Access Manager load balancer. The first procedure tests the Directory Server load balancing and system failover configurations.
To Request an Secure Sockets Layer Certificate for the Access Manager Load Balancer
To Import a Certificate Authority Root Certificate on the Access Manager Load Balancer
To Install an SSL Certificate on the Access Manager Load Balancer
To Create an SSL Proxy for SSL Termination on the Access Manager Load Balancer
Perform the following steps to confirm that Access Manager directory requests are directed to only one instance of Directory Server, and that system failover and recovery work properly. The steps in this procedure are specific to Access Manager 1. Substitute http://AccessManager-2.example.com:1080/amserver/console where appropriate to perform this procedure for Access Manager 2.
Confirm that the load balancer is properly configured for simple persistence.
As a root user, log in to the DirectoryServer–1 and the DirectoryServer–2 host machines.
On each server, use the tail command to watch the Directory Server access log.
# cd /var/opt/mps/am-config/logs # tail-f logs/access |
Access http://AccessManager-1.example.com:1080/amserver/console from a web browser and log in to the Access Manager 1 console as the default administrator.
amadmin
4m4dmin1
Navigate inside the Access Manager 1 console while paying attention to the Directory Server access logs.
You should see all directory accesses are directed to one Directory Server instance only, excluding the health check probing from the load balancer device. The navigation should not have any errors.
Log out of the Access Manager 1 console and close the browser when successful.
Confirm that Directory Server failover is working properly.
Stop Directory Server 1 instance.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsadm stop /var/opt/mps/am-config Server stopped |
Access http://AccessManager-1.example.com:1080/amserver/console from a web browser and log in to the Access Manager 1 console as the default administrator.
amadmin
4m4dmin1
Navigate inside the Access Manager 1 console while paying attention to the Directory Server access logs.
You should see all directory accesses are directed to Directory Server 2. The navigation should not have any errors.
Log out and close the browser when successful.
Start the Directory Server 1 instance.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsadm start /var/opt/mps/am-config Server started |
Stop Directory Server 2 instance.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsadm stop /var/opt/mps/am-config Server stopped |
Access http://AccessManager-1.example.com:1080/amserver/console from a web browser and log in as the administrator, if necessary.
amadmin
4m4dmin1
Navigate inside the Access Manager 1 console while paying attention to the Directory Server access logs.
You should see all directory accesses are directed to Directory Server 1. The navigation should not have any errors.
Log out and close the browser when successful.
Start the Directory Server 2 instance.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsadm start /var/opt/mps/am-config Server started |
Confirm that both Directory Servers are running and log out of both host machines.
Repeat this procedure for Access Manager 2.
Substitute http://AccessManager-2.example.com:1080/amserver/console where applicable and perform these steps again.
This procedure assumes that you have already installed a load balancer.
The load balancer hardware and software used for this deployment is BIG-IP® manufactured by F5 Networks. If you are using different load balancer software, see the documentation that comes with that product for detailed settings information.
Contact your network administrator to obtain two available virtual IP addresses.
Know the IP address of the load balancer hardware, the URL for the load balancer login page, and a username and password for logging in to the load balancer application.
Get the IP addresses for Access Manager 1 and Access Manager 2 by running the following command on each host machine:
# ifconfig -a |
Access https://is-f5.example.com, the BIG-IP load balancer login page, in a web browser.
Log in using the following information:
username
password
Click Configure your BIG-IP (R) using the Configuration Utility.
Create a Pool.
A pool contains all the backend server instances.
In the left pane, click Pools.
On the Pools tab, click Add.
In the Add Pool dialog, provide the following information.
AccessManager-Pool
Round Robin
Add the IP addresses and port numbers for the Access Manager servers: AccessManager-1:1080 and AccessManager-2:1080.
Click Done.
Add a Virtual Server for the non-secure port 7070 on the Access Manager Load Balancer 3.
This step defines instances of the load balancer.
If you encounter JavaScriptTM errors or otherwise cannot proceed to create a virtual server, try using Internet Explorer.
In the left frame, click Virtual Servers.
On the Virtual Servers tab, click Add.
In the Add a Virtual Server dialog box, provide the following information:
Enter the IP address for LoadBalancer-3.example.com
7070
AccessManager-Pool
Continue to click Next until you reach the Pool Selection dialog box.
In the Pool Selection dialog box, assign the AccessManager-Pool Pool.
Click Done.
Add Monitors.
Access Manager comes with a JSP file named isAlive.jsp that can be contacted to determine if the server is down. In the following steps, you create a custom monitor that periodically accesses the JSP. If a success response can be obtained, it means not only that Access Manager is responding to TCP connection request, but also that free threads exist to process the request.
Click the Monitors tab
Click Add and provide the following information.
AccessManager-http
Choose http.
Click Next on the Configure Basic Properties page.
Enter the following value in the Send String field of the Configure ECV HTTP Monitor dialog.
GET /amserver/isAlive.jsp
On the Destination Address and Service (Alias) page, click Done.
The monitor you entered is now added to the list of monitors.
Click the Basic Associations tab.
Find the IP address for AccessManager-1:1080 and AccessManager-2:1080.
Mark the Add checkbox for AccessManager-1 and AccessManager-2.
At the top of the Node column, choose the monitor that you just added, AccessManager-http.
Click Apply.
Configure the load balancer for persistence.
In the left pane, click Pools.
Click the name of the pool you want to configure.
Click the Persistence tab.
Under Persistence Type, select Cookie Hash and set the following values.
In this type of persistence, the load balancer uses a portion of the cookie as a hash ID.
amlbcookie
1
1
Click Apply.
Log out of the load balancer console.
Verify that the Access Manager load balancer is configured properly.
As a root user, log in to the AccessManager–1 host machine.
Run tail to view the access log.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com/logs # tail -f access |
If you see frequent entries similar to the one below, the custom monitor is configured properly.
IP_address--[12/Oct/2006:13:10:20-0700] "GET /amserver/isAlive.jsp" 200 118 |
If you do not see “GET /amserver/isAlive.jsp”, you must troubleshoot the load balancer configuration.
As a root user, log in to the AccessManager–2 host machine.
Run tail to view the access log.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com/logs # tail -f access |
If you see frequent entries similar to the one below, the custom monitor is configured properly.
IP_address--[12/Oct/2006:13:10:20-0700] "GET /amserver/isAlive.jsp" 200 118 |
If you do not see “GET /amserver/isAlive.jsp”, you must troubleshoot the load balancer configuration.
Access http://LoadBalancer-3.example.com:7070/, the internal-facing load balancer, in a web browser.
Do not supply the amserver prefix.
If the browser displays the default Sun Java System Web Server document root page, it is configured properly.
Log out of both Access Manager host machines.
Generate a request for a Secure Sockets Layer (SSL) certificate to send to a certificate authority.
Access https://is-f5.example.com, the BIG-IP load balancer login page, in a web browser.
Log in to the BIG-IP console using the following information.
username
password
Click Configure your BIG-IP (R) using the Configuration Utility.
In the left pane, click Proxies.
Click the Cert-Admin tab.
On the SSL Certificate Administration page, click Generate New Key Pair/Certificate Request.
In the Create Certificate Request page, provide the following information.
LoadBalancer-3.example.com
Deployment
LoadBalancer-3.example.com
password
password
Click Generate Key Pair/Certificate Request.
On the SSL Certificate Request page, the request is generated in the Certificate Request field.
Save the text contained in the Certificate Request field to a text file.
Log out of the console and close the browser.
Send the certificate request text you saved to the Certificate Authority of your choice.
A Certificate Authority (CA) is an entity that issues certified digital certificates; VeriSign, Thawte, Entrust, and GoDaddy are just a few. In this deployment, CA certificates were obtained from OpenSSL. Follow the instructions provided by your Certificate Authority to submit a certificate request.
The CA root certificate proves that the particular CA (such as VeriSign or Entrust) did, in fact, issue a particular SSL certificate. You install the root certificate on Load Balancer 3 to ensure that a link between the Load Balancer 3 SSL certificate can be maintained with the issuing company. CA root certificates are publicly available.
You should have a CA root certificate.
Access https://is-f5.example.com, the BIG-IP load balancer login page, in a web browser.
Log in with the following information.
username
password
In the BIG-IP load balancer console, click Proxies.
Click the Cert-Admin tab.
Click Import.
In the Import Type field, choose Certificate, and click Continue.
Click Browse in the Certificate File field on the Install SSL Certificate page.
In the Choose File dialog, choose Browser.
Navigate to the file that includes the root CA certificate and click Open.
In the Certificate Identifier field, enter OpenSSL_CA_cert.
Click Install Certificate.
On the Certificate OpenSSL_CA_Cert page, click Return to Certificate Administration.
The root certificate OpenSSL_CA_Cert is now included in the Certificate ID list.
This procedure assumes you have received an SSL certificate from a CA and just completed To Import a Certificate Authority Root Certificate on the Access Manager Load Balancer.
In the BIG-IP load balancer console, click Proxies.
Click the Cert-Admin tab.
The key LoadBalancer-3.example.com is in the Key List. This was generated in To Request an Secure Sockets Layer Certificate for the Access Manager Load Balancer.
In the Certificate ID column, click Install for LoadBalancer-3.example.com.
In the Certificate File field, click Browse.
In the Choose File dialog, navigate to the file that contains the certificate text sent to you by the CA and click Open.
Click Install Certificate.
On the Certificate LoadBalancer-3.example.com page, click Return to Certificate Administration Information.
Verify that the Certificate ID indicates LoadBalancer-3.example.com on the SSL Certificate Administration page.
Log out of the load balancer console.
Secure Socket Layer (SSL) termination at Load Balancer 3 increases performance on the Access Manager level, and simplifies SSL certificate management. Because Load Balancer 3 sends unencrypted data to the Access Manager server, it does not have to perform decryption, and the burden on its processor is relieved. Clients send SSL-encrypted data to Load Balancer 3 which, in turn, decrypts the data and sends the unencrypted data to the appropriate Access Manager server. Load Balancer 3 also encrypts responses from the Access Manager server, and sends these encrypted responses back to the client. Towards this end, you create an SSL proxy, the gateway for decrypting HTTP requests and encrypting the reply.
SSL communication is terminated at Load Balancer 3 before a request is forwarded to the Access Manager servers.
Before creating the SSL proxy, you should have a certificate issued by a recognized CA.
Access https://is-f5.example.com, the BIG-IP load balancer login page, in a web browser.
Log in with the following information.
username
password
Click Configure your BIG-IP (R) using the Configuration Utility.
In the left pane, click Proxies.
Under the Proxies tab, click Add.
In the Add Proxy dialog, provide the following information.
Check the SSL checkbox.
The IP address of Load Balancer 3.
9443
The secure port number
The IP address of Load Balancer 3.
7070
The non-secure port number
Choose Local Virtual Server.
Choose LoadBalancer-3.example.com.
Choose LoadBalancer-3.example.com.
Check this checkbox.
Click Next.
In the Rewrite Redirects field, choose Matching.
Click Done.
The new proxy server is added to the Proxy Server list.
Log out of the load balancer console.
Access https://LoadBalancer-3.example.com:9443/index.html from a web browser.
If the Web Server index page is displayed, you can access the Web Server using the new proxy server port number and the load balancer is configured properly.
A message may be displayed indicating that the browser doesn't recognize the certificate issuer. If this happens, install the CA root certificate in the browser so that the browser recognizes the certificate issuer. See your browser's online help system for information on installing a root CA certificate.
Close the browser.
Access Manager 7.1 features the Platform Service which provides centralized configuration management for an Access Manager deployment. In this procedure, you configure the two Access Manager servers to work as a single unit. Once configured as a site, all client requests go through either the internal or external load balancer. Use the following list of procedures as a checklist for completing this task.
It is not necessary to repeat this procedure on Access Manager 2.
Access http://AccessManager-1.example.com:1080/amserver/console in a web browser.
Log in to the Access Manager console as the administrator.
amadmin
4m4dmin1
Under the Access Control tab, click example, the top-level Realm Name.
Enter LoadBalancer-3.example.com, the name of the internal load balancer, in the Realm/DNS Aliases field and click Add.
Do not remove the host names AccessManager-1 and AccessManager-2 from the alias list. These allow administrators to log in to the console directly in the event of a load balancer failure.
Enter loadbalancer-3.example.com, a second entry for the same host name in all lowercase, and click Add.
The Access Manager site will not be configured properly unless you use all lowercase when entering this second host name. This is a known issue.
Click Save.
Click Back to Realms.
Click the Configuration tab.
Under System Properties, click Platform.
Under Site Name, click New, and enter the following values for the external load balancer.
https://loadbalancer-3.example.com:9443
11
Click OK.
Click Save
Under Site Name, click New again, and enter the following values for the internal load balancer.
http://loadbalancer-3.example.com:7070
12
Click OK.
Click Save
On the same Platform page, under Instance Name, click AccessManager-1.example.com:1080.
Change the site ID to 01|11|12
Click OK.
Click Save
On the Platform page again, under Instance Name, click AccessManager-2.example.com:1080.
Change the site ID to 02|11|12
Click OK.
Click Save
Log out of the Access Manager console.
Log in to the AccessManager–1 host machine and restart Access Manager for the changes to take effect.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com/bin # ./stopserv; ./startserv |
Log in to the AccessManager–2 host machine and restart Access Manager for the changes to take effect.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com/bin # ./stopserv; ./startserv |
Log out of both Access Manager host machines.
Access the internal load balancer at http://LoadBalancer-3.example.com:7070/amserver/UI/Login.
If an error message is displayed indicating that the browser cannot connect to either AccessManager- 1.example.com or AccessManager-2.example.com, the site configuration is not correct. If the site configuration is correct, all browser interactions will occur as expected.
If you have an issue accessing the Access Manager load balancer, read about reference number 6472662 in Appendix G, Known Issues and Limitations.
When the Access Manager login page is displayed, verify that the browser URL still contains the Site URL for the internal load balancer.
If it does not contain the Site URL, the site configuration is incorrect. If the site configuration is correct, all browser interactions will occur through the Site URL.
Log in to the Access Manager console as the administrator.
amadmin
4m4dmin1
A successful login occurs when the site configuration is correct.
Log out of the Access Manager console.
After Access Manager is deployed, any agent profiles and users created are stored in a flat file, by default. In To Configure Access Manager 1 and To Configure Access Manager 2, we used a Directory Server instance previously created that we can now use to store these agent profiles and users for the root realm. In this procedure, we reconfigure the Access Manager root realm to communicate with this configuration directory instance, am-config, allowing the agent profiles to authenticate successfully through the load balancer against either Access Manager server.
In an environment with more than one Access Manager server configured behind a load balancer, this procedure is required to use a centralized data store rather than the default flat file.
Log in to the Access Manager console as the administrator.
amadmin
4m4dmin1
Under the Access Control tab, click example, the top-level Realm Name.
Click the Data Stores tab to configure the Directory Server installation as the Access Manager Repository.
Under the Data Stores tab, select the default Flat Files Repository and click Delete.
Click Back to Realms.
Log out of the Access Manager console.