This chapter contains detailed instructions for the following tasks:
Use the following as your checklist for installing the Access Manager servers:
Configure the Access Manager infrastructure to work with multiple instances.
Back up the Access Manager configuration in Directory Server.
You must have a CD image of the Sun Java Enterprise System product mounted on the host computer system where you are installing Access Manger. For information on obtaining and mounting the Sun Java Enterprise System, see 3.2 Downloading and Mounting the Java Enterprise System 2005Q4 Installer in this document.
As a root user, log into host AccessManager-1.
Unzip the two zip files that comprise the Java Enterprise System installer binaries.
Start the installer with the -nodisplay option.
# cd /mnt/Solaris_sparc # ./installer -nodisplay |
When prompted, provide the following information:
|
Press Enter. |
|
|
Press Enter. |
|
|
Enter n. |
|
|
Enter y. |
|
|
Enter 8 for “English only.” |
|
|
Press ENTER to continue. |
|
|
Enter 3,9,12 to select Web Server, Access Manager, and Message Queue. The Message Queue packages you install now will be used when you implement session failover later in the deployment. |
|
|
Enter -20 to deselect Directory Server. |
|
|
Press Enter. |
|
|
Enter D. |
|
|
Press Enter. |
|
|
Enter 2. |
|
|
Enter 1. |
|
|
Enter 1. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Enter 1 to configure now. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
For this example, enter web4dmin. |
|
|
Enter the same password again. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
For this example, enter web4dmin. |
|
|
Enter the same password again. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Enter root. |
|
|
Enter root. |
|
|
Enter 1080. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
For this example, enter 4m4dmin1. |
|
|
Enter the same password again. |
|
|
Accept the default value. |
|
|
For this example, enter 4mld4puser. Much later in the deployment, in a subsequent task, you use this password as the Web Policy Agent “shared secret.” |
|
|
Enter the same password again. |
|
|
Accept the default value and make note of this key string. You will need it when you install Access Manager 2. |
|
|
Enter Realm. |
|
|
Enter 2. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Enter DirectoryServer-1.example.com. |
|
|
Enter 1389. This is the port number you entered for the data instance of Directory Server. |
|
|
Enter o=example.com |
|
|
Accept the default value. |
|
|
For this example, enter d1rm4n4ger. |
|
|
Accept the default value No. |
|
|
First, see the next numbered (Optional) step. When you're ready to install, enter 1 to start the installation. |
(Optional) During installation, you can monitor the log to watch for installation errors. Example:
# cd /var/sadm/install/logs
# tail —f Java_Enterprise_System_install.B xxxxxx
Upon successful installation, enter ! to exit.
Start the Access Manager Web Server.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com
# ./stop; # ./start
Verify that Access Manager has been installed successfully.
Go to the Access Manager login URL:
http://AccessManager-1.example.com:1080/amserver/console
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
You should be able to log in successfully and to navigate to various areas of the console with no error messages.
If you have configured everything so far according to these instructions, and the following error message is displayed “No such Organization found,” it is probably due to the mixed— case Access Manager host names used in this deployment example. For example, the host name AccessManager-1.example.com includes both upper and lower case letters. For more detailed information, see Appendix H, Known Issues and Limitations.
You must have a CD image of the Sun Java Enterprise System product mounted on the host computer system where you are installing Access Manger. For information on obtaining and mounting the Sun Java Enterprise System, see 3.2 Downloading and Mounting the Java Enterprise System 2005Q4 Installer in this document.
As a root user, log in to host AccessManager-2.
Unzip the two zip files that comprise the Java Enterprise System installer binaries.
Start the installer with the -nodisplay option.
# cd /mnt/Solaris_sparc # ./installer -nodisplay |
When prompted, provide the following information:
|
Press Enter. |
||
|
Press Enter. |
||
|
Enter n. |
||
|
Enter yes. |
||
|
Enter 8 for “English only.” |
||
|
Press ENTER to continue. |
||
|
Enter 3,9, 12 to select Web Server, and Access Manager, and Message Queue. The Message Queue packages you install now will be used when you implement session failover later in the deployment. |
||
|
Enter -20 to deselect Directory Server. |
||
|
Press Enter. |
||
|
Enter D. |
||
|
Press Enter. |
||
|
Enter 2. |
||
|
Enter 1. |
||
|
Enter 1. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Enter 1 to configure now. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
For this example, enter web4dmin. |
||
|
Enter the same password again. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
For this example, enter web4dmin. |
||
|
Enter the same password again. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Enter root. |
||
|
Enter root. |
||
|
Enter 1080. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
For this example, enter 4m4dmin1. |
||
|
Enter the same password again. |
||
|
Accept the default value. |
||
|
For this example, enter 4mld4puser. Much later in the deployment, in a subsequent task, you use this password as the Web Policy Agent “shared secret.” |
||
|
Enter the same password again. |
||
|
This password encryption key must be identical to the key that was generated and entered when you installed Access Manager 1. In this deployment example, the string is
|
||
|
Enter Realm. |
||
|
Enter 2. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Enter DirectoryServer-2.example.com. |
||
|
Enter 1389. This is the port number you entered for the data instance of Directory Server. |
||
|
Enter o=example.com |
||
|
Accept the default value. |
||
|
For this example, enter d1rm4n4ger. |
||
|
Accept the default value No. |
||
|
First, see the next numbered (Optional) step. When you're ready to install, enter 1 to start the installation. |
(Optional) During installation, you can monitor the log to watch for installation errors. Example:
# cd /var/sadm/install/logs
# tail —f Java_Enterprise_System_install.Bxxxxxx
Upon successful installation, enter ! to exit.
Start the Access Manager Web Server.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com
# ./stop
# ./start
Add the lowercase host name accessmanager-2.example.com to the Realm alias list.
This eliminates the need to enter the full path to the user's organization each time you want to log in to Access Manager.
Go to the following URL:
http://AccessManager-1.example.com:1080/amserver/UI/Login?org=example.com
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
On the Access Control tab, under Realms, click the example.com realm name.
On the General tab, under Realm Attributes, in the Add field enter the name accessmanager-2.example.com (all lowercase).
Click Add, and then click Save.
Click “Log Out.”
Verify that Access Manager has been installed successfully.
Go to the Access Manager login URL:
http://AccessManager-2.example.com:1080/amserver/console
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
You should be able to log in successfully and to navigate to various areas of the console with no error messages.
Do not try to log in to the second Access Manager server because the instance is not fully configured to be used yet. Access Manager 2 is enabled in the following procedure.
In this procedure, you configure both Access Manager 1 and Access Manager 2 to operate as two instances of a single server. All configuration takes place on the Access Manager 1 host. There is no need to repeat the steps on the Access Manager 2 host.
On AccessManager-1, start a new browser, and go to the URL for the Access Manager console.
Example: http://AccessManager-1.example.com:1080/amserver/console
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
On the Access Control tab, under Realm Name, click the top-level realm.
In this example, the top-level realm is example.
On the General tab, under Realm Attributes, add AccessManager—2.example.com to the Realms/DNS Aliases list.
Go to Realms > Configuration.
On the Configuration tab, click System Properties > Platform.
On the Platform page, add a new instance name.
Click the Log Out button to log out of the console.
Verify that both Access Manager servers are configured properly.
As a root user, log in to host AccessManager-1.
Restart the Access Manager server by restarting the Web Server.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com # ./stop; ./start |
Check for errors on the start-up screen and in the Web Server error log as the server restarts.
As a root user, log in to host AccessManager-2.
Restart the Access Manager server by restarting the Web Server.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com # ./stop; ./start |
Check for errors on the start-up screen and in the Web Server error log as the server restarts.
Start a new browser and to go the URL for the other Access Manager server.
Example: http://AccessManager-2.example.com:1080/amserver/console
Log in as to the Access Manager console using the following information:
amadmin
4m4dmin1
If you can log in successfully, close the browser.
If you cannot log in successfully, restart Access Manager 2. Be sure that the Access Manager 2 host can access the Directory Server 1 host.
Log out of the Access Manager console.
When you cannot log in successfully, one way to troubleshoot is to log in using 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 log in. In the file /etc/opt/SUNWam/config/AMConfig.properties, look for the following entry:
com.sun.identity.authentication.super.user=uid=amAdmin,ou=People,o=example.com
Use the fully qualified User Name uid=amAdmin,ou=People,o=example.com to log in.
Backing up your Access Manager configuration ensures that if you run into problems later in the deployment, you can revert to this configuration without having to re-install Access Manager.
On Directory Server 1, in the slapd-am-config directory, run the db2ldif script.
# cd /var/opt/mps/serverroot/slapd-am-config/ # ./stop # ./db2ldif -n userroot ldiffile: /var/opt/mps/serverroot/slapd-am-config/ldif/2006_03_14_111537.ldif [14/Mar/2006:11:15:40 -0800] - export userRoot: Processed 112 entries (31%). [14/Mar/2006:11:15:41 -0800] - export userRoot: Processed 224 entries (62%). [14/Mar/2006:11:15:42 -0800] - export userRoot: Processed 338 entries (94%). [14/Mar/2006:11:15:42 -0800] - export userRoot: Processed 360 entries (100%). |
(Optional) You can create a readme file that describes the contents of the new ldif file.
# cd /var/opt/mps/serverroot/slapd-am-config/ldif # ls 2006_03_14_111537.ldif Example-Plugin.ldif Example.ldif European.ldif Example-roles.ldif # cat > README 2006_03_14_111537.ldif: backup after post-am install, pre-patch application ^D # ls -l 2006_03_14_111537.ldif Example-Plugin.ldif Example.ldif European.ldif Example-roles.ldif README |
The Access Manager 7 2005Q4 SP5 patch must be copied to the Access Manager host computer system. Patches are available for systems that use the SolarisTM Operating System (Solaris OS) or Linux operation system. You can download the following patches for from SunSolve Online (http://sunsolve.sun.com/).
Solaris OS on SPARC® based systems |
http://sunsolve.sun.com/search/document.do?assetkey=1-21-120954-03 |
Solaris OS on x86 platforms |
http://sunsolve.sun.com/search/document.do?assetkey=1-21-120955-03 |
Linux systems |
http://sunsolve.sun.com/search/document.do?assetkey=1-21-120956-03 Note – No Linux systems were used in this deployment. For Linux detailed patch instructions, see the Readme file that comes with the patch. |
Use the following as your checklist for applying Service Patch 5:
As a root user, log in to host AccessManager-1.
Unzip the patch file. Example:
# cd /temp # ls 120954-05.zip # unzip 120954-03.zip |
Run the patchadd command.
(On Solaris 10) # patchadd -G /temp/120954-05
For other platforms, see the Readme file that comes with the patch.
After successful installation ,a draft amsilent file is created in /opt/SUNWamdirectory. This amsilent is based on /opt/SUNWam/bin/amsamplesilent , but with some required parameters set according to the AM config files on this system.
Redeploy the Access Manager applications.
For detailed information about the following substeps, see the Release Notes (120954-05/rel_notes.html) that come with the patch.
In the amsilent file, use a text editor to uncomment and modify the value of each password parameter, and verify the accuracy of other parameters in this file.
In the following example, the entries in bold have been uncommented and modified.
# cd opt/SUNWam
# vi amsilent
... # The following entries contain sample values! # These should be modified for your specific installation # and then uncommented (remove the # from the line) # SERVER_NAME=AccessManager-1 SEVER_HOST=AccessManager-1.example.com SERVER_PORT=1080 ADMIN_PORT=8888 DS_HOST=DirectoryServer-1.example.com DS_DIRMGRPASSWD=d1rm4n4ger ROOT_SUFFIX="o=example.com" ADMINPASSWD=4m4dmin1 AMLDAPUSERPASSWD=4mld4puser COOKIE_DOMAIN=example.com AM_ENC_PWD=13MRBS4UH1fXNnfp3i/44elABip5CTnk NEW_OWNER=rootNEW_GROUP=otherPAM_SERVICE_NAME=other WEB_CONTAINER=WS6 ... DIRECTORY_MODE=5 DS_PORT=1389 ...
Run the following amconfig command:
# cd /opt/SUNWam/bin
# ./amconfig -s /opt/SUNWam/amsilent
Update the Access Manager schema.
In the directory where you unzipped the patch files, run the updateschema.sh command.
Provide information when prompted. See the following example:
# cd /tmp/120954-05 # ./udpateschema.sh Executing updateschema.sh, the lof file is /var/opt/SUNWam/logs/AM70Patch.upgrade.schema.03080833 Directory Server fully-qualified hostname (LoadBalancer-1.example.com): DirectoryServer-1.example.com Directory manager dn (cn=Directory Manager): Directory manager password: Top-Level Administrator DN (uid=amAdmin,ou=People,o=example.com): Top-Level Adminsitrator password: loading /etc/opt/SUNWam/accountLockout.ldif..... modifying entry cn=schema updateschema.sh done! |
Restart Directory Server 1.
# cd /var/opt/mps/serverroot/slapd-am-config # ./stop; start |
Check the error log to be sure there are no startup errors.
Restart Directory Server 2.
# cd /var/opt/mps/serverroot/slapd-am-config # ./stop; start |
Check the error log to be sure there are no startup errors.
Change the Server Name to Load Balancer 1 in the serverconfig.xml file.
This step is necessary because a load balancer is used between the two Access Manager servers.
# cd /etc/opt/SUNWam/config # vi serverconfig.xml <iPlanetDataAccessLayer> <ServerGroup name="default" minConnPool="1" maxConnPool="10"> <Server name="Server1" host="LoadBalancer-1.example.com" port="389" type="SIMPLE" /> <User name="User1" type="proxy"> <DirDN> cn=puser,ou=DSAME Users,o=example.com </DirDN> <DirPassword> AQICMvvJ0xQN1lpFwZ9IjTPISL2TOx1yX2N8 </DirPassword> </User> <User name="User2" type="admin"> <DirDN> cn=dsameuser,ou=DSAME Users,o=example.com </DirDN> <DirPassword> AQICMvvJ0xQN1lpFwZ9IjTPISL2TOx1yX2N8 </DirPassword> </User> <BaseDN> o=example.com </BaseDN> </ServerGroup> </iPlanetDataAccessLayer> |
Save the file.
Verify that the patch was successfully installed.
Restart the Access Manager 1 Web Server.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com # ./stop; ./start
Use the version command to display installed patches.
# cd /opt/SUNWam/bin # ./amadmin --version Sun Java System Access Manager 7 2005Q4 patch 120954-05 |
On AccessManager-1, start a new browser and go to the URL of Access Manager 1.
http://AccessManager-1:1080/amserver/console
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
If you can log in successfully, close the browser.
As a root user, log in to host AccessManager-2.
Unzip the patch file. Example:
# cd /temp # ls 120954-05.zip # unzip 120954-03.zip |
Run the patchadd command.
(On Solaris 10) # patchadd -G /temp/120954-05
For other platforms, see the Readme file that comes with the patch.
After successful installation ,a draft amsilent file is created in /opt/SUNWamdirectory. This amsilent is based on /opt/SUNWam/bin/amsamplesilent , but with some required parameters set according to the AM config files on this system.
Redploy the Access Manager applications.
For detailed information about the following substeps, see the Release Notes (120954-05/rel_notes.html) that come with the patch.
In the amsilent file, use a text editor to uncomment and modify the value of each password parameter, and verify the accuracy of other parameters in this file.
In the following example, the entries in bold have been uncommented and modified.
# cd opt/SUNWam
# vi amsilent
... # The following entries contain sample values! # These should be modified for your specific installation # and then uncommented (remove the # from the line) # SERVER_NAME=AccessManager-2 SEVER_HOST=AccessManager-2.example.com SERVER_PORT=1080 ADMIN_PORT=8888 DS_HOST=DirectoryServer-2.example.com DS_DIRMGRPASSWD=d1rm4n4ger ROOT_SUFFIX="o=example.com" ADMINPASSWD=4m4dmin1 AMLDAPUSERPASSWD=4mld4puser COOKIE_DOMAIN=example.com AM_ENC_PWD=13MRBS4UH1fXNnfp3i/44elABip5CTnk NEW_OWNER=rootNEW_GROUP=otherPAM_SERVICE_NAME=other WEB_CONTAINER=WS6 ... DIRECTORY_MODE=5 DS_PORT=1389 ...
Run the amconfig command:
# cd /opt/SUNWam/bin
# ./amconfig -s /opt/SUNWam/amsilent
Update the Access Manager schema.
In the directory where you unzipped the patch files, run the updateschema.sh command.
Provide information when prompted. See the following example:
# cd /tmp/120954-05 # ./udpateschema.sh Executing updateschema.sh, the lof file is /var/opt/SUNWam/logs/AM70Patch.upgrade.schema.03080833 Directory Server fully-qualified hostname (LoadBalancer-1.example.com): DirectoryServer-2.example.com Directory manager dn (cn=Directory Manager): Directory manager password: Top-Level Administrator DN (uid=amAdmin,ou=People,o=example.com): Top-Level Adminsitrator password: loading /etc/opt/SUNWam/accountLockout.ldif..... modifying entry cn=schema updateschema.sh done! |
Restart Directory Server 1.
# cd /var/opt/mps/serverroot/slapd-am-config # ./stop; start |
Check the error log to be sure there are no startup errors.
Restart Directory Server 2.
# cd /var/opt/mps/serverroot/slapd-am-config # ./stop; start |
Check the error log to be sure there are no startup errors.
Change the Server Name to Load Balancer 1 in the serverconfig.xml file.
This step is necessary because a load balancer is used between the two Access Manager servers.
# cd /etc/opt/SUNWam/config # vi serverconfig.xml <iPlanetDataAccessLayer> <ServerGroup name="default" minConnPool="1" maxConnPool="10"> <Server name="Server1" host="LoadBalancer-1.example.com" port="389" type="SIMPLE" /> <User name="User1" type="proxy"> <DirDN> cn=puser,ou=DSAME Users,o=example.com </DirDN> <DirPassword> AQICMvvJ0xQN1lpFwZ9IjTPISL2TOx1yX2N8 </DirPassword> </User> <User name="User2" type="admin"> <DirDN> cn=dsameuser,ou=DSAME Users,o=example.com </DirDN> <DirPassword> AQICMvvJ0xQN1lpFwZ9IjTPISL2TOx1yX2N8 </DirPassword> </User> <BaseDN> o=example.com </BaseDN> </ServerGroup> </iPlanetDataAccessLayer> |
Save the file.
Verify that the patch was successfully installed.
Restart the Access Manager 2 Web Server.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com # ./stop; ./start
Use the version command to display installed patches.
# cd /opt/SUNWam/bin # ./amadmin --version Sun Java System Access Manager 7 2005Q4 patch 120954-05 |
On AccessManager-2, start a new browser and go to the URL of Access Manager 2.
http://AccessManager-1:1080/amserver/console
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
If you can log in successfully, close the browser.
During the Access Manager installation, the installer requires that Access Manager run as a root user. If you want administrators who don't have root permissions to perform any administration tasks on Access Manager, you must reconfigure Access Manager to run as a non-root user.
You must use a port number higher than 1024. If the Web Server port is below 1024, then even after configuring the Access Manager server to run as a non-root user, you still must start Access Manager Web Server in a root shell.
As a root user, log into host AccessManager-1.
Stop Access Manager 1.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com/ # ./stop |
Stop the Web Server administration server.
# cd /opt/SUNWwbsvr/https-admserv/ # ./stop |
Change the “runs as” user ID from root to nobody.
# cd /opt/SUNWwbsvr/ # chown -R nobody:nobody https-AccessManager-1.example.com/* httpacl alias \ /var/opt/SUNWam /etc/opt/SUNWam # rm -rf /tmp/https-* |
Edit the magnus.conf file.
It is a good practice to make a backup of this or any other configuration file before making changes to the file.
# vi https-AccessManager-1.example.com/config/magnus.conf |
Change the User property value from root to nobody.
Verify that Access Manager successfully runs as a non-root user.
Log in as a root user to the Access Manager host.
Start the Access Manager server.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com/ # ./start |
Confirm that the Web Server start process actually runs as nobody.
# ps -ef | grep SUNWwbsvr |
Start a new browser and go to the Access Manager URL.
Example: http://AccessManager-1.example.com:1080/amserver/console
Close the browser if successful.
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
If you can log in successfully, close the browser.
As a root user, log into host AccessManager-2.
Stop Access Manager 2.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com/ # ./stop |
Stop the Web Server administration server.
# cd /opt/SUNWwbsvr/https-admserv/ # ./stop |
Change the “runs as” user ID from root to nobody.
# cd /opt/SUNWwbsvr/ # chown -R nobody:nobody https-AccessManager-2.example.cm/* httpacl alias /var/opt/SUNWam /etc/opt/SUNWam # rm -rf /tmp/https-* |
Edit the magnus.conf file.
# vi https-AccessManager-2.example.com/config/magnus.conf |
Change the User property value from root to nobody.
Verify that Access Manager 2 successfully runs as a non-root user.
As a root user, log into host AccessManager-2.
Start the Access Manager server.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com/ # ./start |
Confirm that the Web Server start process actually runs as nobody.
ps -ef | grep SUNWwbsvr |
Start a new browser and go to the Access Manager URL.
Example: http://AccessManager-2.example.com:1080/amserver/console Close the browser if successful.
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
If you can log in successfully, close the browser.
In this procedure, you reconfigure the administration server for each of the Web Servers that contain Access Manager. Although this is not required, it's a good practice to run the Access Manager Web Servers and their administration servers as the same non-root user ID. This eliminates permissions problems. For example, if the Access Manager Web Server runs as a non-root user, and its administration server runs as a root user, then files created by the administration server may not be readable by the Access Manager Web Server.
As a root user, log into host AccessManager-1.
Stop the Web Server administration server by issuing the commands:
# cd /opt/SUNWwbsvr/https-admserv # ./stop |
Change the “runs as” user ID from root to nobody.
# cd /opt/SUNWwbsvr/ # chown -R nobody:nobody https-admserv/* httpacl/ alias # rm -rf /tmp/https-admserv |
Edit the magnus.conf file.
Make a backup of this file before making changes to the file.
# vi https-admserv/config/magnus.conf |
Change the User property value from root to nobody.
Verify that the Web Server administration server successfully runs as a non–root user.
As a root user, log into host AccessManager-2.
Stop the Web Server administration server by issuing the commands:
# cd /opt/SUNWwbsvr/https-admserv # ./stop |
Change the “runs as” user ID from root to nobody.
# cd /opt/SUNWwbsvr/ # chown -R nobody:nobody https-admserv/* httpacl/ alias # rm -rf /tmp/https-admserv |
Edit the magnus.conf file.
# vi https-admserv/config/magnus.conf |
Change the User property value from root to nobody.
Verify that the Web Server administration server successfully runs as a non–root user.
In this procedure, you configure the Access Manager servers to access the Directory Server through the load balancer. All configuration changes you implement through the Access Manager 1 console will be replicated to Access Manager 2, so there is no need to repeat these steps on the Access Manager 2 console. However, you must also edit XML files in this task. You must manually edit the XML files on Access Manager 1 and on Access Manager 2.
The load balancer hardware and software used in the lab facility 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.
Use the following as your checklist for configuring the Access Manager load balancer:
Configure the Access Manager servers to access the Directory Server load balancer.
Verify successful Directory Server load balancing and system failover.
Verify that the Access Manager load balancer is configured properly.
Request an SSL certificate for the Access Manager load balancer.
Install a root CA certificate on the Access Manager load balancer.
Install an SSL certificate on the Access Manager load balancer.
Configure SSL termination on the Access Manager load balancer.
Go to the Access Manager URL.
http://AccessManager-1.example.com:1080/amserver/console
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
Click the Configuration tab.
Under Authentication, edit the following service configurations. Edit the service configurations to reflect the LDAP server name and port number LoadBalancer-1.example.com:1389
Under Authentication, for the following services, change the Primary LDAP server name and port to the load-balancer name and port. In this example, the new name is LoadBalancer-1.example.com:389 .
Under Authentication, click LDAP.
In the Primary LDAP Server list, Add LoadBalancer-1.example.com:389 and delete the default server from the list. Click Save, and the return to the Configuration tab.
Under Authentication, click Membership.
In the Primary LDAP Server list, Add LoadBalancer-1.example.com:389 and delete the default server from the list. Click Save, and the return to the Configuration tab.
Under Authentication, click MSISDN.
In the Primary LDAP Server list, Add LoadBalancer-1.example.com:389 and delete the default server from the list. Click Save, and the return to the Configuration tab.
Under Global Properties, click Policy Configuration.
In the Primary LDAP Server, add LoadBalancer-1.example.com:389 and delete the default server from the list. Click Save, and the return to the Configuration tab.
Edit the following property files on AccessManager–1.
Still logged in to the Access Manager server as a root user, use an editor to modify the file /etc/opt/SUNWam/config/serverconfig.xml.
Change LDAP serer host name and port number to the fully-qualified name and port number for Load Balancer 1 Example:
<iPlanetDataAccessLayer> <ServerGroup name="default" miConnPool="1" maxConnPool="10"> <Server name="Server1" host="LoadBalancer-1.example.com" port="389" type="SIMPLE"/> ... |
Use an editor to modify the file /etc/opt/SUNWam/config/AMConfig.properties.
Set the following properties:
com.iplanet.am.directory.port=389
com.iplanet.am.directory.host=LoadBalancer-1.example.com
com.sun.am.event.connection.idle.timeout=3
The connection idle time out value is set to 3 minutes. This value is less than the value for the Firewall 3–to-Load Balancer 1 connection timeout which is 5 minutes in this example. By setting this value to be 3 minutes, the Access Manager server will assume its persistent search connections may be silently dropped by Firewall 3–to-Load Balancer 1. The Access Manager server will re-establish the persistent search connections every 3 minutes. Otherwise, the Access Manager server may forever block on the persistent search because it is not made aware that the TCP connection is dropped silently.
Edit the following property files on AccessManager–2.
Still logged in to the Access Manager server as a root user, use an editor to modify the file /etc/opt/SUNWam/config/serverconfig.xml.
Change LDAP serer host name and port number to the fully-qualified name and port number for Load Balancer 1. Example:
<iPlanetDataAccessLayer> <ServerGroup name="default" miConnPool="1" maxConnPool="10"> <Server name="Server1" host="LoadBalancer-1.example.com" port="389" type="SIMPLE"/> ... |
Use an editor to modify the file /etc/opt/SUNWam/config/AMConfig.properties.
Set the following properties:
com.iplanet.am.directory.port=389
com.iplanet.am.directory.host=LoadBalancer-1.example.com
com.sun.am.event.connection.idle.timeout=3
Restart both Access Manager servers in order for the changes to take place.
For each of the Access Manager servers, perform the following steps to confirm its directory accesses are all directed to one and only one Directory Server instance, and that system failover and recover work properly. The following section describes how to perform the sanity check for the first Access Manager instance. Substitute the console URL with that of the second Access Manager instance when you perform the task for the second Access Manager instance.
Confirm that the load balancer is properly configured for simple persistence.
As a root user, log into host DirectoryServer-1 and host DirectoryServer-2.
For each server, use the tail command to watch the Directory Server access log.
# tail-f logs/access
Start a new browser and go to the Access Manager 1 URL.
Example: http://AccessManager-1.example.com:1080/amserver/console
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
Navigate inside the Access Manager console while paying attention to the Directory Server access log.
In the access log, 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. Logout and close the browser if successful.
Confirm that Directory Server failover works properly.
Shut down Directory Server 1.
Start a new browser and go to the Access Manager URL.
Example: http://AccessManager-1.example.com:1080/amserver/console
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
Navigate inside the Access Manager console while paying attention to the Directory Server access logs.
# cd /var/opt/mps/serverroot/slapd-data/logs
In the access logs, you should see all directory accesses are directed only to Directory Server 2. The navigation should not have any errors. Log out and close the browser if successful.
Restart Directory Server 1, and stop Directory Server 2.
Start a new browser go to the Access Manager URL.
Example: http://AccessManager-1.example.com:1080/amserver/console
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
Navigate inside the Access Manager console,
Watch the access logs of both Directory Server instances. You should see all directory accesses (excluding health checks by load balancer) are directed to only Directory Server 1. The navigation should not have any errors.
Log out and close the browser if successful.
Restart Directory Server 2.
Confirm that both Directory Servers are restarted and running.
Users internal to your company will access the Access Manager servers through the internal-facing load balancer. The internal-facing load balancer is optional, and enables you to customize an internal-facing login page that is different from the external-facing login page. Users external to your company will first access the Distributed Authentication UI servers, which in turn route requests to the external-facing load balancer. Internal users will access port 90 while External users will access port 9443.
Load Balancer 3 sends the user and agent requests to the server where the session originated. SSL is terminated at Load Balancer 3 before a request is forwarded to the Access Manager Servers. Otherwise the load balancer cannot 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 requests from a specific client to the same server. So a request from the client will always be processed by the server that last processed the request from that client. |
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. |
Contact your network administrator to obtain two available virtual IP addresses.
The load balancer hardware and software used in the lab facility 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.
Create a Pool.
A pool contains all the backend server instances.
Go to URL for the Big IP load balancer log in.
Open the Configuration Utility.
Click “Configure your BIG-IP (R) using the Configuration Utility.”
In the left pane, click Pools.
On the Pools tab, click the Add button.
In the Add Pool dialog, provide the following information:
Example: AccessManager-Pool
Round Robin
Add all the Access Manager servers IP addresses. In this example, add the IP address and port number for AccessManager-1:1080 and for AccessManager-2:1080.
Click the Done button.
Configure the load balancer for persistence.
Add a Virtual Server.
If you encounter Javascript errors or otherwise cannot proceed to create a virtual server, try using Microsoft Internet Explorer for this step.
In the left frame, Click Virtual Servers.
On the Virtual Servers tab, click the Add button.
In the Add a Virtual Server dialog box, provide the following information:
xxx.xx.69.13 (for LoadBalancer-3.example.com )
90
AccessManager-Pool
Continue to click Next until you reach the Pool Selection dialog box.
In the Pool Selection dialog box, assign the Pool (AccessManager-Pool) that you have just created.
Click the Done button.
Add Monitors.
The load balancer has a built-in HTTP monitor that probes the Access Manager TCP port periodically. Successive probing failure indicates the server is down. However, this probing does not address the case where the Access Manager server responds to a TCP connection request, but fails to process any further Access Manager requests because of internal errors such as deadlocks. Access Manager comes with a JSP file /amserver/isAlive.jsp to address this challenge. 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, and then the click Add button.
In the Add Monitor dialog, provide the following information:
AccessManager-http
Choose http.
Click Next.
In the Configure Basic Properties page, click Next.
In the “Configure ECV HTTP Monitor” dialog, in the Send String field, enter the following:
GET /amserver/isAlive.jsp
In the Destination Address and Service (Alias) page, click Done.
On the Monitors tab, the monitor you just added is now contained in the list of monitors.
Click the Basic Associations tab.
Look for 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.
Log in as root to the host AccessManager–1.
Run the tail command to view the access log.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com/logs # tail -f access |
If you see frequent entries similar to this one:
xxx.xx.69.18--[12/Oct/2006:13:10:20-0700] "GET/amserver/isAlive.jsp" 200 118 |
then the custom monitor is configured properly. If you do not see “GET /amserver/isAlive.jsp” then you must troubleshoot the load balancer configuration.
Log in as root to the host AccessManager-2.
Run the tail command to view the access log.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com/logs # tail -f access |
If you see frequent entries similar to this one:
xxx.xx.69.18--[12/Oct/2006:13:10:20-0700] "GET /amserver/isAlive.jsp" 200 118 |
then the custom monitor is configured properly. If you do not see “GET /amserver/isAlive.jsp” then you must troubleshoot the load balancer configuration.
Start a new browser and go to the internal-facing load balancer URL.
Example: http://LoadBalancer-2.example.com:90/ . Do not supply the amserver prefix.
If the browser successfully renders the default Sun Web Server default document root page, close the browser.
Open a browser, go to the BIG-IP URL:
https://is-F5.example.com
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 the button named “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 the button “Generate Key Pair/Certificate Request.”
On the SSL Certificate Request page, the request is generated in the Certificate Request field.
Copy all the text contained in the Certificate Request field.
Save the text in a text file to keep it handy for later use.
Send the text of the certificate request to a Certificate Authority of your choice.
A Certificate Authority is an entity that issues certified digital certificates. VersiSign, Thawte , Entrust, and GoDaddy are just a few examples of Certificate Authority companies. In this deployment example, CA certificates were obtained from OpenSSL. Follow the instructions provided by the Certificate Authority for submitting a certificate request.
The root Certificate Authority certificate proves that a Certificate Authority such as VeriSign or Entrus actually issued the digital server certificate you received. You install the root certificate on Load Balancer 3 to ensure that the link between the Load Balancer 3 SSL certificate can be maintained with the issuing company.
In the BIG-IP load balancer console, click Proxies.
Click the Cert-Admin tab.
Click the Import link.
In the Import Type field, choose Certificate, and then click Continue.
In the Install SSL Certificate page, in the Certificate File field, click Browse.
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.
In the Certificate OpenSSL_CA_Cert page, click Return to Certificate Administration.
The new certificate OpenSSL_CA_Cert is now included in the Certificate ID list.
Once you've received the SSL certificate from a Certificate Authority, 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 a previous step when you generated a key pair and a certificate request.
In the Certificate ID column, click the Install button for LoadBalancer-3.example.com.
In the Certificate File field, click Browse.
In the Choose File dialog, navigate to the text file in which you saved the certificate text sent to you by the certificate issuer, and then click Open.
Click Install Certificate.
In the Certificate LoadBalancer-3.example.com page, click Return to Certificate Administration Information link.
In the SSL Certificate Administration page, verify that the Certificate ID indicates LoadBalancer-3.example.com.
In this deployment example, Secure Socket Layer (SSL) termination at Load Balancer 3 increases the performance at the server level, and simplifies SSL certificate management. Clients will access Load Balancer 3 using SSL-encrypted data. Load Balancer 3 decrypts the data and then sends the unencrypted data on to the Access Manager server. The Access Manager server or Authentication UI server does not have to perform decryption, and the burden on its processor is relieved. Load Balancer 3 then load-balances the decrypted traffic to the appropriate Access Manager server. Finally, Load Balancer 3 encrypts the responses from server, and sends encrypted responses to the client.
Load Balancer 3 sends the user and agent requests to the server where the session originated. SSL is terminated at Load Balancer 3 before a request is forwarded to the Access Manager Servers. Otherwise the load balancer cannot inspect the traffic for proper routing.
In this deployment example, you set up a proxy server using BIG-IPTM hardware and software.
Configure the new proxy service.
Log in to the BIG-IP load balancer using the following information:
username
password
Click the link “Configure your BIG-IP using the Configuration Utility.”
In the load balancer console, in the left pane, click Proxies.
On the Proxies tab, click Add.
In the Add Proxy dialog, provide the following information:
Check the SSL checkbox.
xxx.xx.69.14 (The IP address of Load Balancer 3, the Access Manager server load balancer.)
9443 (The port number of the new proxy you are setting up.)
xxx.xx.69.14
90
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 now added to the Proxy Server list.
Verify that you can access the Access Manager server using the new proxy server port number.
Open a browser, and go to the following URL:
https://LoadBalancer-3.example.com:9443/index.html
A message may be displayed indicating that the Access Manager server doesn't recognize the certificate issuer. When this happens, install the root Certificate Authority 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.
Log out of Access Manager, and close the browser.
Use the following as your checklist for importing the root CA certificate into the Access Manager Web Servers:
Import the root CA certificate into the Access Manager 1 Web Server.
Import the root CA certificate into the Access Manager 2 Web Server.
To to the Web Server administration URL:
http://AccessManager-1.example.com:8888/https-admserv/bin/index |
Log in to the Web Server console using the following information:
admin
web4d4min
On the Servers tab, select the server AccessManager-1.example.com, and then click Manage.
Click on the Security tab, and then initialize the Trust Database by providing the following information:
password
password
Click OK.
In the left frame, click Install Certificate. In the Install a Server Certificate page, provide the following information:
Choose Trusted Certificate Authority (CA)
Choose this option, and then paste into the text box the root certificate you received from the CA. To Request an SSL Certificate for the Distributed Authentication UI Load Balancer. The root certificate will look similar to this:
-----BEGIN CERTIFICATE----- UbM77e50M63v1Z2A/5O5MA0GCSqGSIb3DQEOBAU AMF8xCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0 EgRGF0YSBTZWN1cml0eSwgSW5jLjEuMCwGA1UEC xMlU2VjdXJlIFNlcnZlciBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTAeFw0wMTA4MDIwMDAwMDBaFw0 wMzA4MDIyMzU5NTlaMIGQMQswCQYDVQQGEwJVUz ERMA8GA1UECBMIVmlyZ2luaWExETAPBgNVBAcUC FJpY2htb25kMSAwHgYDVQQKFBdDYXZhbGllciBU ZWxlcGhvYm9uZGluZy5jYXZ0ZWwuY29tMIGfMA0 GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8x/1dxo 2YnblilQLmpiEziOqb7ArVfI1ymXo/MKcbKjnY2 -----END CERTIFICATE REQUEST----- |
Click OK.
On the “Add Trusted CA Certificate page,” click “Add Server Certificate.”
In the left frame, click Manage Certificates.
In the list of certificates, you will see the certificate you just added. In this deployment example, the certificate name OpenSSLTestCA-Sun is displayed in the list.
Close the browser.
As a root user, log into the Access Manager 1 host.
To verify that the certificate was imported properly, go to the following directory:
/opt/SUNWwbsvr/alias |
In a directory listing, notice that certificate filename is formed by joining the prefix https-AccessManager-1.example.com and database file name cert8.db.
#ls https-AccessManager-1.example.com-AccessManager-1-cert8.db https-AccessManager-1.example.com-AccessManager-1-key3.db https-AccessManager-1.example.com-cert8.db https-AccessManager-1.example.com-key3.db secmod.db |
Run the certutil list command, specifying the prefix from certificate filename:
# cd /opt/SUNWwbsvr/bin/https/admin/bin # ./certutil -L -d /opt/SUNWwbsvr/alias/ -P "https-AccessManager-1.example.com-" OpenSSLTestCA - Sun |
The OpenSSLTestCA — Sun certificate you imported is displayed.
As a root user, log in to the Access Manager 1 host.
Go to the following directory:
/etc/opt/SUNWam/config |
Make a backup of the AMConfig.properties file before making any changes to the file.
In the AMConfig.properties file, verify that the certificate database directory is specified correctly as in this example:
com.iplanet.am.admin.cli.certdb.dir=/opt/SUNWWwbsvr/alias |
For the value of the following property, add the prefix from the certificate filename as in this example:
com.iplanet.am.admin.cli.certdb.prefix=https-AccessManager-1.example.com- |
Notice that the following property points to a file wtpass which doesn't exist yet:
com.iplanet.am.admin.cli.certdb. |
You will create this file in the next step.
Save the file.
Create the wtpass file.
In the file, enter the name of the password you used to create the certificate database. Example:
# cd /etc/opt/SUNWam/config # vi .wtpass password |
Save the file.
Verify that the file was created properly.
# cat .wtpass password |
Restart the Web Server.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com # ./stop; ./start |
To to the Web Server administration URL:
http://AccessManager-2.example.com:8888/https-admserv/bin/index |
Log in to the Web Server console using the following information:
admin
web4d4min
On the Servers tab, select the server AccessManager-2.example.com, and then click Manage.
Click on the Security tab, and then initialize the Trust Database by providing the following information:
password
password
Click OK.
In the left frame, click Install Certificate. In the Install a Server Certificate page, provide the following information:
Choose Trusted Certificate Authority (CA)
Choose this option, and then paste into the text box the root certificate you received from the CA. To Request an SSL Certificate for the Distributed Authentication UI Load Balancer. The root certificate will look similar to this:
-----BEGIN CERTIFICATE----- UbM77e50M63v1Z2A/5O5MA0GCSqGSIb3DQEOBAU AMF8xCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0 EgRGF0YSBTZWN1cml0eSwgSW5jLjEuMCwGA1UEC xMlU2VjdXJlIFNlcnZlciBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTAeFw0wMTA4MDIwMDAwMDBaFw0 wMzA4MDIyMzU5NTlaMIGQMQswCQYDVQQGEwJVUz ERMA8GA1UECBMIVmlyZ2luaWExETAPBgNVBAcUC FJpY2htb25kMSAwHgYDVQQKFBdDYXZhbGllciBU ZWxlcGhvYm9uZGluZy5jYXZ0ZWwuY29tMIGfMA0 GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8x/1dxo 2YnblilQLmpiEziOqb7ArVfI1ymXo/MKcbKjnY2 -----END CERTIFICATE REQUEST----- |
Click OK.
On the “Add Trusted CA Certificate page,” click “Add Server Certificate.”
In the left frame, click Manage Certificates.
In the list of certificates, you will see the certificate you just added. In this deployment example, the certificate name OpenSSLTestCA-Sun is displayed in the list.
Close the browser.
As a root user, log into the Access Manager 2 host.
To verify that the certificate was imported properly, go to the following directory:
/opt/SUNWwbsvr/alias |
In a directory listing, notice that certificate filename is formed by joining the prefix https-AccessManager-1.example.com and database file name cert8.db.
#ls https-AccessManager-1.example.com-AccessManager-2-cert8.db https-AccessManager-1.example.com-AccessManager-2-key3.db https-AccessManager-2.example.com-cert8.db https-AccessManager-1.example.com-key3.db secmod.db |
Run the certutil list command, specifying the prefix from certificate filename:
# cd /opt/SUNWwbsvr/bin/https/admin/bin # ./certutil -L -d /opt/SUNWwbsvr/alias/ -P "https-AccessManager-2.example.com-" OpenSSLTestCA - Sun |
The OpenSSLTestCA — Sun certificate you imported is displayed.
As a root user, log in to the Access Manager 2 host.
Go to the following directory:
/etc/opt/SUNWam/config |
Make a backup of the AMConfig.properties file before making any changes to the file.
In the AMConfig.properties file, verify that the certificate database directory is specified correctly as in this example:
com.iplanet.am.admin.cli.certdb.dir=/opt/SUNWWwbsvr/alias |
For the value of the following property, add the prefix from the certificate filename as in this example:
com.iplanet.am.admin.cli.certdb.prefix=https-AccessManager-2.example.com- |
Notice that the following property points to a file wtpass which doesn't exist yet:
com.iplanet.am.admin.cli.certdb. |
You will create this file in the next step.
Save the file.
Create the wtpass file.
In the file, enter the name of the password you used to create the certificate database. Example:
# cd /etc/opt/SUNWam/config # vi .wtpass password |
Save the file.
Verify that the file was created properly.
# cat .wtpass password |
Restart the Web Server.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com # ./stop; ./start |
Access Manager 7 2005Q4 introduces the site concept which provides centralized configuration management for an Access Manager deployment. In this example, you configure two Access Manager servers to work as a single site. Once configured as a site, all client requests always go through a load balancer. In this example, requests go through either the internal or external load balancer. This flow simplifies the deployment by resolving firewall issues between the client and the back-end Access Manager servers.
Use the following as your checklist for creating an Access Manager site:
Complete the following steps on the Access Manager 1 host. It is not necessary to repeat the steps on the Access Manager 2 host.
Start a browser, and access the Access Manager 1 server.
http://AccessManager-1:1080/amserver/console
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
In the Access Manager console, click the Access Control tab, and then click the top-level Realm Name example.
In the Realm/DNS Aliases field, add the name of the internal load balancer.
For this example, enter LoadBalancer-3.example.com:90, and then 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.
For this deployment example, add an entry for the same host name using all lowercase.
Example: loadbalancer-3.example.com:90
Click Save.
In the Access Manager console, click the Realms link, and then navigate through the following:
Configuration > System Properties > 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, and then click Save.
Under Site Name, click New. Enter the following values for the internal load balancer:
http://loadbalanacer-3.example.com:90
12
Click OK, and then click Save.
On the same Platform page, under Instance Name, click AccessManager-1.
Change the site ID from 01 to 01|11|12.
http://AccessManager-1.example.com:1080:01|11|12
Click OK, and then click Save.
On the Platform page, under Instance Name, click AccessManager-2.
Change the site ID from 02 to 02|11|12.
http://AccessManager-2.example.com:1080:02|11|12
Click OK, and then click Save.
Restart AccessManager-1 and AccessManager-2 for the changes to take effect.
Go to the Access Manager Site URL:
http://LoadBalancer-3.example.com:90/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, then the site configuration is not correct. If the site configuration is correct, all browser interactions will always occur with the Site URL.
If the Access Manager login page is displayed, verify that the browser URL still contains the Site URL.
If it does not contain the Site URL, then the site configuration is incorrect. If the site configuration is correct, all browser interactions will always occur with the Site URL
If the Access Manager login page is displayed, and the browser URL contains the Site URL, log in to the Access Manager console using the following information:
amadmin
4m4dmin1
Verify that you can successfully login to the Access Manager console.
Log out of the Access Manager console.