This second part of the Deployment Example 1: Access Manager 7.1 Load Balancing, Distributed Authentication UI, and Session Failover provides the instructions for installing and configuring the deployment and its components. It contains the following chapters:
Chapter 5, Configuring Instances of Sun Java System Directory Server for User Data
Chapter 7, Configuring an Access Manager Realm for User Authentication
Chapter 8, Installing and Configuring the Distributed Authentication User Interface
This chapter contains information you need to know before beginning the documented installation and configuration procedures. It contains the following sections:
See Chapter 2, Technical Overview for a quick reference of host machines, port numbers, operating systems, naming conventions, and component names used in this deployment example. See Part III, Reference: Summaries of Server and Component Configurations for more detailed information.
The load balancer hardware and software used in this deployment environment 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. This document assumes that you have already installed the required load balancers.
The following sections require load-balancing hardware and software.
4.3 Configuring a Load Balancer for the Directory Server Configuration Data Instances
5.3 Configuring the Load Balancer for the User Data Instances
8.4 Configuring the Distributed Authentication User Interface Load Balancer
You will need to obtain certificate authority (CA) root certificates and server Secure Socket Layer (SSL) certificates to enable SSL in this deployment environment. The certificate issuer used in this deployment is a test CA certificate from OpenSSL. You can obtain a root CA certificate from a commercial certificate issuer such as Verisign. For more information, see the documentation provided by your certificate authority.
The following tasks are related to requesting, installing, and importing SSL certificates:
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 Import a CA Root Certificate on the Distributed Authentication User Interface Load Balancer
To Install an SSL Certificate on the Distributed Authentication User Interface Load Balancer
To Import the Certificate Authority Root Certificate into the Web Server 1 Keystore
To Import the Certificate Authority Root Certificate into the Application Server 1 Keystore
To Import the Certificate Authority Root Certificate into the Web Server 2 Keystore
To Import the CA Root Certificate into the Application Server 2 Keystore
There are many ways to resolve the host names used in this deployment example. You may use a DNS naming service, or you can map IP addresses to host names in the local host file on all UNIX® hosts. The same entries must also be added to equivalent files on Windows hosts, and on client machines where browsers are used. For example:
1xx.xx.xx.x1 DirectoryServer-1 DirectoryServer-1.example.com 1xx.xx.xx.x2 DirectoryServer-2 DirectoryServer-2.example.com 1xx.xx.xx.x3 AccessManager-1 AccessManager-1.example.com 1xx.xx.xx.x4 AccessManager-2 AccessManager-2.example.com |
See Appendix G, Known Issues and Limitations for descriptions of problems you may encounter when implementing the deployment example. This list will be updated as new information becomes available.
Although these instructions incorporate many recommended or best practices, and may be suitable in many different scenarios, this is not the only way to achieve the same results. If you plan to deviate from the task sequence or details described, you should refer to the relevant product documentation for information on differences in platforms, software versions or other requirement constraints.
This chapter contains instructions for installing Sun Java™ System Directory Server and creating the instances in which Sun Java System Access Manager configuration data will be stored. It also includes the procedure for enabling multi-master replication between the two instances and configuring the configuration data load balancer. It contains the following sections:
4.1 Installing and Configuring Directory Server 1 and Directory Server 2
4.2 Enabling Multi-Master Replication Between the Access Manager Configuration Data Instances
4.3 Configuring a Load Balancer for the Directory Server Configuration Data Instances
This section contains the instructions for installing Directory Server on two different host machines and creating the instances in which Access Manager configuration data will be stored. Use the following list of procedures as a checklist for completing the tasks.
To Download Sun Java System Directory Server Enterprise Edition 6.0 and Required Patches
To Create an Access Manager Configuration Data Instance for Directory Server 1
To Create a Base Suffix for the Directory Server 1 Access Manager Configuration Data Instance
To Create the Access Manager Configuration Data Instance for Directory Server 2
To Create a Base Suffix for the Directory Server 2 Access Manager Configuration Data Instance
Perform this procedure to download the Sun Java System Directory Server 6.0 bits and the required system patches to both the DirectoryServer–1 host machine and the DirectoryServer–2 host machine.
Go to http://www.sun.com/software/products/directory_srvr_ee/get.jsp.
Provide the following information in the Select product configuration section and click View Downloads.
Directory Server Enterprise Edition
6.0
Compress Archive (ZIP)
Choose the platform you are using.
The Selection Results page will be displayed with links to the download sites for the Directory Server and required patches.
The patch numbers generated for download on the Selection Results page are based on your input. Check the most recent Directory Server Enterprise Edition 6.0 Release Notes to determine if you need to install other patches based on your machine's architecture and operating system. In this deployment, the Release Notes indicate that based on the hardware and operating system being used, patch 118855–36, patch 119964–08, and patch 122033–05 are required.
Log into the DirectoryServer–1 host machine as a root user.
Run the patchadd command to see if the patches are already installed.
# patchadd -p | grep 118855–36 |
No results are returned which indicates that the patch is not yet installed on the system.
# patchadd -p | grep 119964–08 |
No results are returned which indicates that the patch is not yet installed on the system.
# patchadd -p | grep 122033–05 |
No results are returned which indicates that the patch is not yet installed on the system.
If these patches are already installed on your machine, proceed to step 7.
Make a directory for the patch downloads and change into it.
# mkdir /export/patches # cd /export/patches |
Download the patches.
You can click on the patch links from the Selection Results page or search for patches directly at http://sunsolve.sun.com. If searching directly, navigate to the PatchFinder page and enter the patch number. For each patch you are downloading, click the HTTP link beside the heading Download Signed Patch (xxx bytes).
Signed patches are downloaded as JAR files. Unsigned patches are downloaded as ZIP files. In this step, ZIP files are downloaded.
Make a directory for the Directory Server download and change into it.
# mkdir /export/DS6 # cd /export/DS6 |
Download the Directory Server EE 6.0 - Zip Distribution, Multi Language, (DS/DPS/DE/ISW/DSRK) - No Console) bits.
No Directory Server Administration Console is installed with these bits. This deployment example uses the command line to configure the software.
Log out of the DirectoryServer–1 host machine.
Repeat this same procedure on the DirectoryServer–2 host machine.
If necessary, perform this procedure to patch both the Directory Server 1 host machine and the Directory Server 2 host machine.
Log in to the DirectoryServer–1 host machine as a root user.
Change into the directory that contains the downloaded patch files.
# cd /export/patches |
Unzip the patch files.
# unzip 118855–36.zip # unzip 119964-08.zip # unzip 122033-05.zip |
Install the patches.
# patchadd /export/patches/118855-36 # patchadd /export/patches/119964-08 # patchadd /export/patches/122033-05 |
You can use the -M option to install all patches at once. See the patchadd man page for more information.
Reboot your machine, if requested.
After installation is complete, verify that each patch was added successfully.
# patchadd -p | grep 118855–36 |
A series of patch numbers are displayed, and the patch 118855–36 is present.
# patchadd -p | grep 119964-08 |
A series of patch numbers are displayed, and the patch 119964-08 is present.
# patchadd -p | grep 122033-05 |
A series of patch numbers are displayed, and the patch 122033-05 is present.
Log out of the DirectoryServer–1 host machine.
Repeat this same procedure on the DirectoryServer–2 host machine.
Patch your machine accordingly and download the Directory Server bits to the host machine.
As a root user, log in to the DirectoryServer–1 host machine.
Resolve the following issues, if necessary.
The LD_LIBRARY_PATH environment variable should not be set to the default setting. Change the value to empty as in the following example:
# setenv LD_LIBRARY_PATH |
The JAVA_HOME environment variable should be set appropriately for your system architecture. For example:
# setenv JAVA_HOME /usr/jdk/jdk1.5.0_07 |
Unzip the Directory Server ZIP file.
# cd /export/DS6 # ls DSEE.6.0Solaris10-X86_AMD64-full.tar.gz # gunzip DSEE.6.0Solaris10-X86_AMD64-full.tar.gz |
Untar the resulting Directory Server tar file.
# tar xvf DSEE.6.0Solaris10-X86_AMD64-full.tar |
From the resulting directory, run dsee_deploy install to install Directory Server.
# cd DSEE_ZIP_Distribution # ./dsee_deploy install -c DS -i /var/opt/mps/serverroot |
The Licensing Agreement is displayed. At each Type return to continue prompt, press Return to continue.
When Do you accept the license terms? is displayed, enter yes to continue.
Once you accept the license terms, the Directory Server binaries will be installed in the /var/opt/mps/serverroot/ds6 directory.
After installing the binaries, create an instance of Directory Server 1 named am-config on the DirectoryServer–1 host machine. The instance uses the default ports for non-root users: 1389 for LDAP and 1636 for LDAPS. It will be populated with Access Manager configuration data in To Configure Access Manager 1.
By default, Directory Server always creates a secure LDAP port when creating an instance. We do not use this port.
This procedure assumes you have just completed To Install Directory Server 1.
As a root user on the DirectoryServer–1 host machine, run dsadm create to create the instance.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsadm create -p 1389 -P 1636 /var/opt/mps/am-config Choose the Directory Manager password: d1rm4n4ger Confirm the Directory Manager password: d1rm4n4ger use 'dsadm start /var/opt/mps/am-config' to start the instance |
Run dsadm start to start the instance.
# ./dsadm start /var/opt/mps/am-config Server started: pid=10381 |
Run netstat to verify that the new instance is up and running.
# netstat -an | grep 1389 .1389 *.* 0 0 49152 0 LISTEN |
Run ldapsearch to verify that you can read the root Directory Server entry (DSE) of the new instance.
# ldapsearch -h DirectoryServer-1.example.com -p 1389 -b "" -s base "(objectclass=*)" version: 1 dn: objectClass: top ... supportedLDAPVersion: 3 vendorname: Sun Microsystems, Inc. vendorVersion: Sun-Java(tm)-System-Directory/6.0 ... |
After creating the configuration data instance of DirectoryServer–1, create a base suffix in which the entries will be stored.
This procedure assumes you have just completed To Create an Access Manager Configuration Data Instance for Directory Server 1.
As a root user on the Directory Server 1 host machine, run dsconf create-suffix to create a new base suffix.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsconf create-suffix -p 1389 -B dbExample -L /var/opt/mps/am-config/db/exampleDS dc=example,dc=com |
Provide the appropriate information when prompted.
Certificate "CN=DirectoryServer-1, CN=1636, CN=directory Server, O=Sun Microsystems" presented by the server is not trusted. Type "Y" to accept, "y" to accept just one, "n" to refuse, "d" for more details: Y Enter "cn=Directory Manager" password: d1rm4n4ger |
When you enter an uppercase Y, you are not asked for the certificate again in the next steps.
Run dsconf list-suffixes to verify that the base suffix was successfully created.
# ./dsconf list-suffixes -p 1389 Enter "cn=Directory Manager" password: d1rm4n4ger dc=example,dc=com |
Log out of the Directory Server 1 host machine.
Patch your machine accordingly and download the Directory Server bits to the host machine.
As a root user, log in to the Directory Server 2 host machine.
Resolve the following issues, if necessary.
The LD_LIBRARY_PATH environment variable should not be set to the default setting. Change the value to empty as in the following example:
# setenv LD_LIBRARY_PATH |
The JAVA_HOME environment variable should be set appropriately for your system architecture. For example:
# setenv JAVA_HOME /usr/jdk/jdk1.5.0_07 |
Unzip the Directory Server ZIP file.
# cd /export/DS6 # ls DSEE.6.0Solaris10-X86_AMD64-full.tar.gz # gunzip DSEE.6.0Solaris10-X86_AMD64-full.tar.gz |
Untar the resulting Directory Server tar file.
# tar xvf DSEE.6.0Solaris10-X86_AMD64-full.tar |
In the resulting directory, run dsee_deploy install to install Directory Server.
# cd DSEE_ZIP_Distribution # ./dsee_deploy install -c DS -i /var/opt/mps/serverroot |
The Licensing Agreement is displayed. At each Type return to continue prompt, press Return to continue.
When Do you accept the license terms? is displayed, enter yes to continue.
Once you accept the license terms, the Directory Server binaries will be installed in the /var/opt/mps/serverroot/ds6 directory.
After installing the binaries, create an instance of Directory Server 2 named am-config on the DirectoryServer–2 host machine. The instance uses the default ports for non-root users: 1389 for LDAP and 1636 for LDAPS. It will be populated with Access Manager configuration data in To Configure Access Manager 2.
By default, Directory Server always creates a secure LDAP port when creating an instance. We do not use this port.
This procedure assumes you have just completed To Install Directory Server 2.
As a root user on the DirectoryServer–2 host machine, run dsadm create to create the instance.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsadm create -p 1389 -P 1636 /var/opt/mps/am-config Choose the Directory Manager password: d1rm4n4ger Confirm the Directory Manager password: d1rm4n4ger use 'dsadm start /var/opt/mps/am-config' to start the instance |
Run dsadm start to start the instance.
# ./dsadm start /var/opt/mps/am-config Server started: pid=10381 |
Run netstat to verify that the new instance is up and running.
# netstat -an | grep 1389 .1389 *.* 0 0 49152 0 LISTEN |
Run ldapsearch to verify that you can read the root DSE of the new instance.
# ldapsearch -h DirectoryServer-2.example.com -p 1389 -b "" -s base "(objectclass=*)" version: 1 dn: objectClass: top ... supportedLDAPVersion: 3 vendorname: Sun Microsystems, Inc. vendorVersion: Sun-Java(tm)-System-Directory/6.0 ... |
After creating the configuration data instance of DirectoryServer–2, create a base suffix in which the entries will be stored.
This procedure assumes you have completed To Create the Access Manager Configuration Data Instance for Directory Server 2.
As a root user on the DirectoryServer–2 host machine, run dsconf create-suffix to create a new base suffix.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsconf create-suffix -p 1389 -B dbExample -L /var/opt/mps/am-config/db/exampleDS dc=example,dc=com |
Provide the appropriate information when prompted.
Certificate "CN=DirectoryServer-2, CN=1636, CN=directory Server, O=Sun Microsystems" presented by the server is not trusted. Type "Y" to accept, "y" to accept just one, "n" to refuese, "d" for more details: Y Enter "cn=Directory Manager" password: d1rm4n4ger |
When you enter an uppercase Y, you are not asked for the certificate again in the next steps.
Run dsconf list-suffixes to verify that the base suffix was successfully created.
# ./dsconf list-suffixes -p 1389 Enter "cn=Directory Manager" password: d1rm4n4ger dc=example,dc=com |
Log out of the DirectoryServer–2 host machine.
This section contains the instructions to enable multi-master replication (MMR) between two directory masters. This includes creating replication agreements between the masters and initializing the second directory master with the data and schema from the first directory master. The previously created am-config instances will serve as the two masters. An illustration of the architecture can be seen in Figure 4–1.
Use the following list of procedures as a checklist for completing the tasks.
To Enable Multi-Master Replication for the Directory Server 1 Configuration Data Instance
To Enable Multi-Master Replication for the Directory Server 2 Configuration Data Instance
To Change the Default Replication Manager Passwords for Each Configuration Data Instance
To Create Replication Agreements for Each Configuration Data Instance
To Initialize the Configuration Data Instance Replication Agreements
To Verify that Configuration Data Replication Works Properly
As a root user, log in to the DirectoryServer–1 host machine.
(Optional) Run dsconf list-suffixes to verify that the instance is not already enabled for replication.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsconf list-suffixes -p 1389 -v Enter "cn=Directory Manager" password: d1rm4n4ger ... dc=example,dc=com 1 not-replicated N/A N/A 29 The "list-suffixes" operation succeeded on "localhost:1389" |
The base suffix of the instance is not-replicated as displayed in the resulting list.
Run dsconf enable-repl to enable replication.
# ./dsconf enable-repl -h DirectoryServer-1.example.com -p 1389 -d 11 master dc=example,dc=com Enter "cn=Directory Manager" password: d1rm4n4ger Use "dsconf create-repl-agmt" to create replication agreements on "dc=example,dc=com". |
The -d option takes as input a randomly chosen identifier to represent the Directory Server 1 configuration data instance; in this case, 11. master indicates that the instance is a master and not a replica. The base suffix is specified as dc=example,dc=com.
Run dsconf list-suffixes again to verify that the instance is now enabled for replication.
# ./dsconf list-suffixes -p 1389 -v Enter "cn=Directory Manager" password: d1rm4n4ger ... dc=example,dc=com 1 master(11) N/A N/A 29 The "list-suffixes" operation succeeded on "localhost:1389" |
The base suffix of the instance is master(11) as displayed in the resulting list, indicating that the master was successfully enabled.
Log out of the DirectoryServer–1 host machine.
As a root user, log in to the DirectoryServer–2 host machine.
(Optional) Run the dsconf list-suffixes command to verify that the instance is not already enabled for replication.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsconf list-suffixes -p 1389 -v Enter "cn=Directory Manager" password: d1rm4n4ger ... dc=example,dc=com 1 not-replicated N/A N/A 29 The "list-suffixes" operation succeeded on "localhost:1389" |
The base suffix of the instance is not-replicated as displayed in the resulting list.
Run dsconf enable-repl to enable replication.
# ./dsconf enable-repl -h DirectoryServer-2.example.com -p 1389 -d 22 master dc=example,dc=com Enter "cn=Directory Manager" password: d1rm4n4ger Use "dsconf create-repl-agmt" to create replication agreements on "dc=example,dc=com". |
The -d option takes as input a randomly chosen identifier to represent the Directory Server 2 configuration data instance; in this case, 22. master indicates that the instance is a master and not a replica. The base suffix is specified as dc=example,dc=com.
Run dsconf list-suffixes again to verify that the instance is now enabled for replication.
# ./dsconf list-suffixes -p 1389 -v Enter "cn=Directory Manager" password: d1rm4n4ger ... dc=example,dc=com 1 master(22) N/A N/A 29 The "list-suffixes" operation succeeded on "localhost:1389" |
The base suffix of the instance is master(22) as displayed in the resulting list, indicating that the master was successfully enabled.
Log out of the DirectoryServer–2 host machine.
The replication manager is the user that suppliers use to bind to the consumer server when sending replication updates. (In MMR the consumer server refers to whichever master happens to be the consumer for that particular operation.) It is recommended by the Directory Server documentation to change the default password created during the process of enabling replication.
As a root user, log in to the DirectoryServer–1 host machine.
Create a temporary file that contains the new replication manager password.
This file will be read once, and the password stored for future use.
# cd /var/opt/mps/serverroot/ds6/bin # echo replm4n4ger > pwd.txt |
Verify that the file was successfully created.
# cat pwd.txt replm4n4ger |
Run dsconf set-server-prop to set the new replication manager password using pwd.txt as input.
# ./dsconf set-server-prop -h DirectoryServer-1.example.com -p 1389 def-repl-manager-pwd-file:pwd.txt Enter "cn=Directory Manager" password: d1rm4n4ger |
Remove the pwd.txt file.
Log out of the DirectoryServer–1 host machine.
As a root user, log in to the DirectoryServer–2 host machine.
Create a temporary file that contains the new replication manager password.
This file will be read once, and the password stored for future use.
# cd /var/opt/mps/serverroot/ds6/bin # echo replm4n4ger > pwd.txt |
Verify that the file was successfully created.
# cat pwd.txt replm4n4ger |
Run dsconf set-server-prop to set the new replication manager password using pwd.txt as input.
# ./dsconf set-server-prop -h DirectoryServer-2.example.com -p 1389 def-repl-manager-pwd-file:pwd.txt Enter "cn=Directory Manager" password: d1rm4n4ger |
Remove the pwd.txt file.
Log out of the DirectoryServer–2 host machine.
A replication agreement is a set of parameters on a supplier that controls how updates are sent to a given consumer. In this case, we are making the configuration data instances aware of each other.
As a root user, log in to the DirectoryServer–1 host machine.
Run dsconf create-repl-agmt to create the replication agreement.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsconf create-repl-agmt -h DirectoryServer-1.example.com -p 1389 dc=example,dc=com DirectoryServer-2.example.com:1389 Enter "cn=Directory Manager" password: d1rm4n4ger Use "dsconf init-repl-dest dc=example,dc=com DirectoryServer-2.example.com:1389" to start replication of "dc=example,dc=com" data. |
Run dsconf list-repl-agmts to verify that the replication agreement was successfully created.
# ./dsconf list-repl-agmts -p 1389 Enter "cn=Directory Manager" password: d1rm4n4ger dc=example,dc=com DirectoryServer-2.example.com:1389 |
The response indicates that the Directory Server 1 configuration data base suffix will be replicated to Directory Server 2.
Log out of the DirectoryServer–1 host machine.
As a root user, log in to the DirectoryServer–2 host machine.
Run dsconf create-repl-agmt to create the replication agreement.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsconf create-repl-agmt -h DirectoryServer-2.example.com -p 1389 dc=example,dc=com DirectoryServer-1.example.com:1389 Enter "cn=Directory Manager" password: d1rm4n4ger Use "dsconf init-repl-dest dc=example,dc=com DirectoryServer-1.example.com:1389" to start replication of "dc=example,dc=com" data. |
Run dsconf list-repl-agmts to verify that the replication agreement was successfully created.
# ./dsconf list-repl-agmts -p 1389 Enter "cn=Directory Manager" password: d1rm4n4ger dc=example,dc=com DirectoryServer-1.example.com:1389 |
The response indicates that the Directory Server 2 configuration data base suffix will be replicated to Directory Server 1.
Log out of the DirectoryServer–2 host machine.
In this procedure, initialize the configuration data instance on Directory Server 1. The previously created replication agreement will replicate the data to Directory Server 2.
Initialization is not required on both instances when configuring for MMR.
As a root user, log in to the DirectoryServer–1 host machine.
Run dsconf show-repl-agmt-status to verify that the replication agreements have not yet been initialized.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsconf show-repl-agmt-status -h DirectoryServer-1.example.com -p 1389 dc=example,dc=com DirectoryServer-2.example.com:1389 Enter "cn=Directory Manager" password: d1rm4n4ger Configuration Status : OK Authentication Status : OK Initialization Status : NOT OK Status: : Dest. Not Initialized |
Run dsconf init-repl-dest to initialize the replication agreements.
# ./dsconf init-repl-dest -h DirectoryServer-1.example.com -p 1389 dc=example,dc=com DirectoryServer-2.example.com:1389 Enter "cn=Directory Manager" password: d1rm4n4ger Sent 1 entries... Sent 2 entries... Completed initialization of "DirectoryServer-2.example.com:1389"; May 15, 2007 1:53:32 PM |
Run dsconf show-repl-agmt-status again to verify that the replication agreements are now initialized.
# ./dsconf show-repl-agmt-status -h DirectoryServer-1.example.com -p 1389 dc=example,dc=com DirectoryServer-2.example.com:1389 Enter "cn=Directory Manager" password: d1rm4n4ger Configuration Status : OK Authentication Status : OK Initialization Status : OK Status: : Enabled Last Update Date : Jul 12, 2007 8:47 PM |
Log out of the DirectoryServer–1 host machine.
As a root user, log in to the Directory Server 1 host machine.
Run ldapmodify to create a new directory entry.
# ldapmodify -a -h DirectoryServer-1.example.com -p 1389 -D cn=admin,cn=Administrators,cn=config -w d1rm4n4ger dn: ou=People,dc=example,dc=com objectclass: top objectclass: organizationalUnit ou: People description: Container for user entries Hit ENTER to indicate end of input. adding new entry ou=People,dc=example,dc=com Hit Control C to terminate the command. ^C |
This step creates a new organization unit on Directory Server 1.
As a root user, log in to the Director Server–2 host machine.
Run ldapsearch on Directory Server 2 to verify that the entry was successfully replicated.
# ldapsearch -b "dc=example,dc=com" -p 1389 -D "cn=Directory Manager" -w d1rm4n4ger "objectclass=organizationalUnit" version: 1 dn: ou=People,dc=example,dc=com objectClass: top objectClass: organizationalUnit ou: People description Container for user entries |
Run ldapdelete on Directory Server 2 to delete the entry.
# ldapdelete -h DirectoryServer-2.example.com -p 1389 -D "cn=Directory Manager" -w d1rm4n4ger "ou=People,dc=example,dc=com" |
Run ldapsearch on Directory Server 1 to verify that the entry was deleted.
# ldapsearch -b "dc=example,dc=com" -p 1389 -D "cn=Directory Manager" -w d1rm4n4ger "objectclass=organizationalUnit" |
If the delete was successfully replicated to Directory Server 1, the search will return no results.
Log out of the Directory Server host machines.
Two load balancers are configured for the Directory Server installations. Load Balancer 1 fronts the configuration data instances and Load Balancer 2 fronts the user data instances. In the following procedure, you configure a load balancer in front of the configuration data instances. The following figure illustrates this architecture.
This procedure assumes that you have already installed a load balancer.
The load balancer hardware and software used in 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 an available virtual IP address for the load balancer you want to configure.
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 Directory Server 1 and Directory Server 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:
DirectoryServer-ConfigData-Pool
Round Robin
Add the IP address and port number of both Directory Server hosts: DirectoryServer-1:1389 and DirectoryServer-2:1389.
Click Done.
Add a Virtual Server.
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 the LoadBalancer-1.example.com
389
DirectoryServer-ConfigData-Pool
Continue to click Next until you reach the Pool Selection dialog box.
In the Pool Selection dialog box, assign DirectoryServer-ConfigData-Pool to the virtual server.
Click Done.
Add Monitors
Monitors are required by the load balancer to detect backend server failures.
In the left frame, click Monitors.
Click the Basic Associations tab.
Add an LDAP monitor for the Directory Server 1 node.
In the Node column, locate the IP address and port number, DirectoryServer–1:1389, and select the Add checkbox.
Add an LDAP monitor for the Directory Server 2 node.
In the Node column, locate the IP address and port number, DirectoryServer–2:1389, and select the Add checkbox.
At the top of the Node column, in the drop-down list, choose ldap-tcp.
Click Apply.
Configure the load balancer for simple persistence.
The configuration data load balancer is configured for simple persistence. With simple persistence, all requests sent within a specified interval are processed by the same Directory Server instance, ensuring complete replication of entries. For example, when a request requires information to be written to Directory Server 1, that information must also be replicated to Directory Server 2. As the replication takes time to complete, if a related request is directed by the load balancer to Directory Server 2 during the replication process itself, the request may fail as the entry might only be partially created. When properly configured, simple persistence ensures that both requests are routed to Directory Server 1 and processed in consecutive order; the first request is finished before the second request begins processing. Simple persistence ensures that within the specified interval, no errors or delays occur due to replication time or redirects when retrieving data. Simple persistence tracks connections based only on the client IP address.
Verify the Directory Server load balancer configuration.
Log in as a root user to the host machine of each Directory Server instance.
On each Directory Server host machine, use the tail command to monitor the Directory Server access log.
# cd /var/opt/mps/am-config/logs # tail -f access |
You should see connections to the load balancer IP address opening and closing. For example:
[12/Oct/2006:13:10:20-0700] conn=54 op=-1 msgId=-1 — fd=22 slot=22 LDAP connection from IP_address to IP_address [12/Oct/2006:13:10:20-0700] conn=54 op=-1 msgId=-1 — closing — B1 [12/Oct/2006:13:10:20-0700] conn=54 op=-1 msgId=-1 — closed.
Execute the following LDAP search against the Directory Server load balancer.
# ldapsearch -h LoadBalancer-1.example.com -p 389 -b "dc=example,dc=com" -D "cn=directory manager" -w d1rm4n4ger "(objectclass=*)" |
The ldapsearch operation should return entries. Make sure they display in the access log on only one Directory Server.
Run dsadm stop to stop Directory Server 1.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsadm stop /var/opt/mps/am-config |
Again perform the LDAP search against the Directory Server load balancer to confirm that the request is forwarded to the running Directory Server 2.
# ldapsearch -h LoadBalancer-1.example.com -p 389 -b "dc=example,dc=com" -D "cn=directory manager" -w d1rm4n4ger "(objectclass=*)" |
The ldapsearch operation should return entries. Verify that the entries display in the access log only on Directory Server 2.
You may encounter the following error message:
ldap_simple_bind: Cant' connect to the LDAP server — Connection refused
This means that the load balancer may not fully detect that Directory Server 1 is stopped. In this case, you may have started the search too soon based on the polling interval setting. For example, if the polling interval is set to 10 seconds, you should wait ten seconds to start the search. You can reset the timeout properties to a lower value using the following procedure.
Click the Monitors tab.
Click the ldap-tcp monitor name.
In the Interval field, set the value to 5.
This tells the load balancer to poll the server every 5 seconds.
In the Timeout field, set the value to 16.
Click Apply and repeat the LDAP search.
See your load balancer documentation for more information on the timeout property.
Start Directory Server 1.
# ./dsadm start /var/opt/mps/am-config |
Stop Directory Server 2.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsadm stop /var/opt/mps/am-config |
Perform the following LDAP search against the Directory Server load balancer to confirm that the request is forwarded to the running Directory Server 1.
# ldapsearch -h LoadBalancer-1.example.com -p 389 -b "dc=example,dc=com" -D "cn=Directory Manager" -w d1rm4n4ger "(objectclass=*)" |
The ldapsearch operation should return entries. Verify that the entries display in the access log only on Directory Server 1.
Start Directory Server 2.
# ./dsadm start /var/opt/mps/am-config |
Log out of both Directory Server host machines and the load balancer console.
This chapter contains instructions for creating instances of Directory Server to hold user data called am-users. If you have an existing user data store, you can go directly to the instructions in 7.2 Creating and Configuring a Realm for Test Users to configure Access Manager to recognize your data store and users. This chapter contains the following sections:
5.2 Enabling Multi-Master Replication of the User Data Instances
5.3 Configuring the Load Balancer for the User Data Instances
This section contains information on creating user data instances on the Directory Server 1 and Directory Server 2 host machines. Use the following list of procedures as a checklist for these tasks.
To Create a Base Suffix for the User Data Instance on Directory Server 1
To Create a Base Suffix for the User Data Instance on Directory Server 2
In this procedure, you create a Directory Server instance named am-users for storing user data on Directory Server 1. The new instance uses the ports for non-root users: 1489 for LDAP and 1736 for LDAPS. This instance will be populated with user information in Chapter 7, Configuring an Access Manager Realm for User Authentication.
By default, Directory Server always creates a secure LDAP port when creating an instance. We do not use this port.
As a root user, log in to the DirectoryServer–1 host machine.
Run dsadm create to create a user data instance called am-users.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsadm create -p 1489 -P 1736 /var/opt/mps/am-users Choose the Directory Manager password: d1rm4n4ger Confirm the Directory Manager password: d1rm4n4ger Use 'dsadm start /var/opt/mps/am-users' to start the instance |
Run dsadm start to start the instance.
# ./dsadm start /var/opt/mps/am-users Server started: pid=10381 |
Run netstat to verify that the new instance is up and running.
# netstat -an | grep 1489 .1489 *.* 0 0 49152 0 LISTEN |
Run ldapsearch to verify that you can read the root Directory Server entry (DSE) of the new instance.
# ldapsearch -h DirectoryServer-1.example.com -p 1489 -b "" -s base "(objectclass=*)" version: 1 dn: objectClass: top ... supportedLDAPVersion: 3 vendorname: Sun Microsystems, Inc. vendorVersion: Sun-Java(tm)-System-Directory/6.0 ... |
After creating the user data instance, you create a base suffix in which the entries will be stored.
This procedure assumes you have just completed To Create a User Data Instance for Directory Server 1.
As a root user on the DirectoryServer–1 host machine, run dsconf create-suffix to create a base suffix.
# ./dsconf create-suffix -p 1489 -B dbExample -L /var/opt/mps/am-users/db/exampleDS dc=company,dc=com |
Provide information when prompted.
Certificate "CN=DirectoryServer-1, CN=1736, CN=directory Server, O=Sun Microsystems" presented by the server is not trusted. Type "Y" to accept, "y" to accept just one, "n" to refuese, "d" for more details: Y Enter "cn=Directory Manager" password: d1rm4n4ger |
When you enter an uppercase Y, you are not asked for the certificate again in the next steps.
Run dsconf list-suffixes to verify that the base suffix was successfully created.
# ./dsconf list-suffixes -p 1489 Enter "cn=Directory Manager" password: d1rm4n4ger dc=company,dc=com |
If the base suffix was successfully created, dc=company, dc=com is returned. You can also see am-users in the list of directory instances:
# cd /var/opt/mps # ls am-config am-users serverroot |
Log out of the DirectoryServer–1 host machine.
In this procedure, you create a Directory Server instance named am-users for storing user data on Directory Server 2. The new instance uses the ports for non-root users: 1489 for LDAP and 1736 for LDAPS. This instance will be populated with user information in Chapter 7, Configuring an Access Manager Realm for User Authentication.
By default, Directory Server always creates a secure LDAP port when creating an instance. We do not use this port.
As a root user, log in to the DirectoryServer–2 host machine.
Run dsadm create to create a user data instance called am-users.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsadm create -p 1489 -P 1736 /var/opt/mps/am-users Choose the Directory Manager password: d1rm4n4ger Confirm the Directory Manager password: d1rm4n4ger Use 'dsadm start /var/opt/mps/am-users' to start the instance |
Run dsadm start to start the instance.
# ./dsadm start /var/opt/mps/am-users Server started: pid=10381 |
Run netstat to verify that the new instance is up and running.
# netstat -an | grep 1489 .1489 *.* 0 0 49152 0 LISTEN |
Run ldapsearch to verify that you can read the root DSE of the new instance.
# ldapsearch -h DirectoryServer-2.example.com -p 1489 -b "" -s base "(objectclass=*)" version: 1 dn: objectClass: top ... supportedLDAPVersion: 3 vendorname: Sun Microsystems, Inc. vendorVersion: Sun-Java(tm)-System-Directory/6.0 ... |
After creating an instance, you must create a base suffix in which the entries will be stored.
This procedure assumes you have just completed To Create a User Data Instance for Directory Server 2.
As a root user on the DirectoryServer–2 host machine, run dsconf create-suffix to create a base suffix.
# ./dsconf create-suffix -p 1489 -B dbExample -L /var/opt/mps/am-users/db/exampleDS dc=company,dc=com |
Provide information when prompted.
Certificate "CN=DirectoryServer-2, CN=1736, CN=directory Server, O=Sun Microsystems" presented by the server is not trusted. Type "Y" to accept, "y" to accept just one, "n" to refuese, "d" for more details: Y Enter "cn=Directory Manager" password: d1rm4n4ger |
When you enter an uppercase Y, you are not asked for the certificate again in the next steps.
Run dsconf list-suffixes to verify that the base suffix was successfully created.
# ./dsconf list-suffixes -p 1489 Enter "cn=Directory Manager" password: d1rm4n4ger dc=company,dc=com |
If the base suffix was successfully created, dc=company, dc=com is returned. You can also see am-users in the list of directory instances as follows:
# cd /var/opt/mps # ls am-config am-users serverroot |
Log out of the DirectoryServer–2 host machine.
This section contains the instructions to enable multi-master replication (MMR) between two directory masters. This includes creating replication agreements between the masters and initializing the second directory master with the data and schema from the first directory master. The previously created am-users instances will serve as the two masters. An illustration of the architecture can be seen in Figure 4–1.
Use the following list of procedures as a checklist for completing the tasks.
To Enable Multi-Master Replication for User Data Instance on Directory Server 1
To Enable Multi-Master Replication for User Data Instance on Directory Server 2
To Change the Default Replication Manager Passwords for Each User Data Instance
To Create Replication Agreements for Each User Data Instance
As a root user, log in to the DirectoryServer–1 host machine.
(Optional) Run dsconf list-suffixes to verify that the instance is not already enabled for replication.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsconf list-suffixes -p 1489 -v Enter "cn=Directory Manager" password: d1rm4n4ger ... dc=company,dc=com 1 not-replicated N/A N/A 29 The "list-suffixes" operation succeeded on "DirectoryServer-1.example.com:1489" |
The base suffix of the instance is not-replicated as displayed in the resulting list.
Run dsconf enable-repl to enable replication.
# ./dsconf enable-repl -h DirectoryServer-1.example.com -p 1489 -d 11 master dc=company,dc=com Enter "cn=Directory Manager" password: d1rm4n4ger Use "dsconf create-repl-agmt" to create replication agreements on "dc=company,dc=com". |
The -d option takes as input a randomly chosen identifier to represent the Directory Server 1 configuration data instance; in this case, 11. master indicates that the instance is a master and not a replica. The base suffix is specified as dc=company,dc=com.
Run dsconf list-suffixes again to verify that the instance is now enabled for replication.
# ./dsconf list-suffixes -p 1489 -v Enter "cn=Directory Manager" password: d1rm4n4ger ... dc=company,dc=com 1 master(11) N/A N/A 29 The "list-suffixes" operation succeeded on "DirectoryServer-1.example.com:1489" |
The base suffix of the instance is master(11) as displayed in the resulting list, indicating that the master was successfully enabled.
Log out of the DirectoryServer–1 host machine.
As a root user, log in to the DirectoryServer–2 host machine.
(Optional) Run dsconf list-suffixes to verify that the instance is not already enabled for replication.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsconf list-suffixes -p 1489 -v Enter "cn=Directory Manager" password: d1rm4n4ger ... dc=company,dc=com 1 not-replicated N/A N/A 29 The "list-suffixes" operation succeeded on "DirectoryServer-2.example.com:1489" |
The base suffix of the instance is not-replicated as displayed in the resulting list.
Run dsconf enable-repl to enable replication.
# ./dsconf enable-repl -h DirectoryServer-2.example.com -p 1489 -d 22 master dc=company,dc=com Enter "cn=Directory Manager" password: d1rm4n4ger Use "dsconf create-repl-agmt" to create replication agreements on "dc=company,dc=com". |
The -d option takes as input a randomly chosen identifier to represent the Directory Server 1 configuration data instance; in this case, 22. master indicates that the instance is a master and not a replica. The base suffix is specified as dc=company,dc=com.
Run dsconf list-suffixes again to verify that the instance is now enabled for replication.
# ./dsconf list-suffixes -p 1489 -v Enter "cn=Directory Manager" password: d1rm4n4ger ... dc=company,dc=com 1 master(22) N/A N/A 29 The "list-suffixes" operation succeeded on "DirectoryServer-2.example.com:1489" |
The base suffix of the instance is master(22) as displayed in the resulting list, indicating that the master was successfully enabled.
Log out of the DirectoryServer–2 host machine.
The replication manager is the user that suppliers use to bind to the consumer server when sending replication updates. (In MMR the consumer server refers to whichever master happens to be the consumer for that particular operation.) It is recommended by the Directory Server documentation to change the default password created during the process of enabling replication.
As a root user, log in to the DirectoryServer–1 host machine.
Create a temporary file that contains the new replication manager password.
This file is read once, and the password is stored for future use.
# cd /var/opt/mps/serverroot/ds6/bin # echo replm4n4ger > pwd.txt |
Verify that the file was successfully created.
# cat pwd.txt replm4n4ger |
Run dsconf set-server-prop to set the replication manager password using pwd.txt as input.
# ./dsconf set-server-prop -h DirectoryServer-1.example.com -p 1489 def-repl-manager-pwd-file:pwd.txt Enter "cn=Directory Manager" password: d1rm4n4ger |
Remove the pwd.txt file.
Log out of the DirectoryServer–1 host machine.
As a root user, log in to the DirectoryServer–2 host machine.
Create a temporary file that contains the new replication manager password.
This file is read once, and the password is stored for future use.
# cd /var/opt/mps/serverroot/ds6/bin # echo replm4n4ger > pwd.txt |
Verify that the file was successfully created.
# cat pwd.txt replm4n4ger |
Run dsconf set-server-prop to set the replication manager password using pwd.txt as input.
# ./dsconf set-server-prop -h DirectoryServer-2.example.com -p 1489 def-repl-manager-pwd-file:pwd.txt Enter "cn=Directory Manager" password: d1rm4n4ger |
Remove the pwd.txt file.
Log out of the DirectoryServer–2 host machine.
A replication agreement is a set of parameters on a supplier that controls how updates are sent to a given consumer. In this case, we are making the user data instances aware of each other.
As a root user, log in to the DirectoryServer–1 host machine.
Run dsconf create-repl-agmt to create the replication agreement.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsconf create-repl-agmt -h DirectoryServer-1.example.com -p 1489 dc=company,dc=com DirectoryServer-2.example.com:1489 Enter "cn=Directory Manager" password: d1rm4n4ger Use "dsconf init-repl-dest dc=company,dc=com DirectoryServer-2.example.com:1489" to start replication of "dc=company,dc=com" data. |
Run dsconf list-repl-agmts to verify that the replication agreement was successfully created.
# ./dsconf list-repl-agmts -p 1489 Enter "cn=Directory Manager" password: d1rm4n4ger dc=company,dc=com DirectoryServer-2.example.com:1489 |
This response indicates that the Directory Server 1 base suffix will be replicated to Directory Server 2.
Log out of the DirectoryServer–1 host machine.
As a root user, log in to the DirectoryServer–2 host machine.
Run dsconf create-repl-agmt to create the replication agreement.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsconf create-repl-agmt -h DirectoryServer-2.example.com -p 1489 dc=company,dc=com DirectoryServer-1.example.com:1489 Enter "cn=Directory Manager" password: d1rm4n4ger Use "dsconf init-repl-dest dc=company,dc=com DirectoryServer-1.example.com:1489" to start replication of "dc=company,dc=com" data. |
Run dsconf list-repl-agmts to verify that the replication agreement was successfully created.
# ./dsconf list-repl-agmts -p 1489 Enter "cn=Directory Manager" password: d1rm4n4ger dc=company,dc=com DirectoryServer-1.example.com:1489 |
This response indicates that the Directory Server 2 base suffix will be replicated to Directory Server 1.
Log out of the DirectoryServer–2 host machine.
In this procedure, initialize the user data instance on Directory Server 1. The previously created agreements will replicate the data to Directory Server 2.
Initialization is not required on both instances when configuring for MMR.
As a root user, log in to the DirectoryServer–1 host machine.
Run dsconf show-repl-agmt-status to verify that the replication agreements are not yet initialized.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsconf show-repl-agmt-status -h DirectoryServer-1.example.com -p 1489 dc=company,dc=com DirectoryServer-2.example.com:1489 Enter "cn=Directory Manager" password: d1rm4n4ger Configuration Status : OK Authentication Status : OK Initialization Status : NOT OK Status: : Dest. Not Initialized |
Run dsconf init-repl-dest to initialize the replication agreements.
# ./dsconf init-repl-dest -h DirectoryServer-1.example.com -p 1489 dc=company,dc=com DirectoryServer-2.example.com:1489 Enter "cn=Directory Manager" password: d1rm4n4ger Sent 1 entries... Sent 2 entries... Completed initialization of "DirectoryServer-2.example.com:1489"; May 15, 2007 1:53:32 PM |
Run dsconf show-repl-agmt-status again to verify that the replication agreements are now initialized.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsconf show-repl-agmt-status -h DirectoryServer-1.example.com -p 1489 dc=company,dc=com DirectoryServer-2.example.com:1489 Enter "cn=Directory Manager" password: d1rm4n4ger Configuration Status : OK Authentication Status : OK Initialization Status : OK Status: : Enabled Last Update Date : Jul 12, 2007 8:47:42 PM |
Log out of the DirectoryServer–1 host machine.
As a root user, log in to the DirectoryServer–1 host machine.
Run ldapmodify to create a new directory entry.
# ldapmodify -a -h DirectoryServer-1.example.com -p 1489 -D cn=admin,cn=Administrators,cn=config -w d1rm4n4ger dn: ou=People,dc=company,dc=com objectclass: top objectclass: organizationalUnit ou: People description: Container for user entries Hit ENTER to indicate end of input. adding new entry ou=People,dc=company,dc=com Hit Control C to terminate the command. ^C |
This step creates a new organizational unit on Directory Server 1.
After the entry is created, as a root user, log in to the DirectoryServer–2 host machine.
Run ldapsearch on Directory Server 2 to verify that the directory entry was successfully replicated.
# ldapsearch -b "dc=company,dc=com" -p 1489 -D "cn=Directory Manager" -w d1rm4n4ger "objectclass=organizationalUnit" version: 1 dn: ou=People,dc=company,dc=com objectClass: top objectClass: organizationalUnit ou: People description Container for user entries |
Now run ldapdelete on Directory Server 2 to delete the entry just created.
# ldapdelete -h DirectoryServer-2.example.com -p 1489 -D "cn=Directory Manager" -w d1rm4n4ger "ou=People,dc=company,dc=com" |
As a root user on Directory Server 1, run ldapsearch to verify that the entry was deleted.
# ldapsearch -b "dc=company,dc=com" -p 1489 -D "cn=Directory Manager" -w d1rm4n4ger "objectclass=organizationalUnit" |
If the delete was successfully replicated to Directory Server 1, the search will return no results.
Log out of the Directory Server host machines.
Two load balancers are configured for the Directory Server installations. Load Balancer 1 fronts the configuration data instances and Load Balancer 2 fronts the user data instances. In the following procedure, you configure a load balancer in front of the configuration data instances. Figure 4–1 illustrates this architecture.
This procedure assumes that you have already installed a load balancer.
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.
Contact your network administrator to obtain an available virtual IP address for the load balancer you want to configure.
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 Directory Server 1 and Directory Server 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:
DirectoryServer-UserData-Pool
Round Robin
Add the IP address and port number of both Directory Server hosts: DirectoryServer-1:1489 and DirectoryServer-2:1489.
Click Done.
Add a Virtual Server.
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-2.example.com
489
DirectoryServer-UserData-Pool
Continue to click Next until you reach the Pool Selection dialog box.
In the Pool Selection dialog box, assign DirectoryServer-UserData-Pool to the virtual server.
Click Done.
Add Monitors
Monitors are required for the load balancer to detect the backend server failures.
In the left frame, click Monitors.
Click the Basic Associations tab.
Add an LDAP monitor for the Directory Server 1 node.
In the Node column, locate the IP address and port number, DirectoryServer-1:1489, and select the Add checkbox.
Add an LDAP monitor for the Directory Server 2 node.
In the Node column, locate the IP address and port number, DirectoryServer–2:1489, and select the Add checkbox.
At the top of the Node column, in the drop-down list, choose ldap-tcp.
Click Apply.
Configure the load balancer for persistence.
The user data load balancer is configured for simple persistence. With simple persistence, all requests sent within a specified interval are processed by the same Directory Server instance, ensuring complete replication of entries. For example, when a request requires information to be written to Directory Server 1, that information must also be replicated to Directory Server 2. As the replication takes time to complete, if a related request is directed by the load balancer to Directory Server 2 during the replication process itself, the request may fail as the entry might only be partially created. When properly configured, simple persistence ensures that both requests are routed to Directory Server 1 and processed in consecutive order; the first request is finished before the second request begins processing. Simple persistence ensures that within the specified interval, no errors or delays occur due to replication time or redirects when retrieving data. Simple persistence tracks connections based only on the client IP address.
Verify the Directory Server load balancer configuration.
Log in as a root user to the host machine of each Directory Server instance.
On each Directory Server host machine, use the tail command to monitor the Directory Server access log.
# cd /var/opt/mps/am-users/logs # tail -f access |
You should see connections to the load balancer IP address opening and closing. For example:
[12/Oct/2006:13:10:20-0700] conn=54 op=-1 msgId=-1 — fd=22 slot=22 LDAP connection from IP_address to IP_address [12/Oct/2006:13:10:20-0700] conn=54 op=-1 msgId=-1 — closing — B1 [12/Oct/2006:13:10:20-0700] conn=54 op=-1 msgId=-1 — closed.
Execute the following LDAP search against the Directory Server load balancer.
# ldapsearch -h LoadBalancer-2.example.com -p 489 -b "dc=company,dc=com" -D "cn=directory manager" -w d1rm4n4ger "(objectclass=*)" |
The ldapsearch operation should return entries. Make sure they display in the access log on only one Directory Server.
Run dsadm stop to stop Directory Server 1.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsadm stop /var/opt/mps/am-users |
Again perform the following LDAP search against the Directory Server load balancer.
# ldapsearch -h LoadBalancer-2.example.com -p 489 -b "dc=company,dc=com" -D "cn=directory manager" -w d1rm4n4ger "(objectclass=*)" |
The ldapsearch operation should return entries. Verify that the entries display in the access log on only Directory Server 2.
You may encounter the following error message:
ldap_simple_bind: Cant' connect to the LDAP server — Connection refused
This means that the load balancer may not fully detect that Directory Server 1 is stopped. In this case, you may have started the search too soon based on the polling interval setting. For example, if the polling interval is set to 10 seconds, you should wait ten seconds to start the search. You can reset the timeout properties to a lower value using the following procedure.
Click the Monitors tab.
Click the ldap-tcp monitor name.
In the Interval field, set the value to 5.
This tells the load balancer to poll the server every 5 seconds.
In the Timeout field, set the value to 16.
Click Apply and repeat the LDAP search.
See your load balancer documentation for more information on the timeout property.
Start Directory Server 1.
# ./dsadm start /var/opt/mps/am-users |
Stop Directory Server 2.
# cd /var/opt/mps/serverroot/ds6/bin # ./dsadm stop /var/opt/mps/am-users |
Perform the following LDAP search against the Directory Server load balancer to confirm that the request is forwarded to the running Directory Server 1.
# ldapsearch -h LoadBalancer-2.example.com -p 489 -b "dc=company,dc=com" -D "cn=Directory Manager" - w d1rm4n4ger "(objectclass=*)" |
The ldapsearch operation should return entries. Make sure the entries display in the access log on only Directory Server 1.
Start Directory Server 2.
# ./dsadm start /var/opt/mps/am-users |
Log out of both Directory Server host machines and the load balancer console.
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.
This chapter contains instructions to create user entries to be used for testing and to import them into the replicated Directory Server user data instances. Additionally, we configure a sub-realm for the users and create an authentication chain for the sub-realm using Access Manager. It contains the following sections.
You create user entries in the Directory Server user data instance for the following users:
testuser1
testuser2
They will be used to verify that the policy agent is configured and working properly. Additionally, the Groups container will be used for the same purpose. This user data is imported into one Directory Server as it will be replicated to the other instance.
If you are using an existing user data store, create the appropriate users in it and move on to 7.2 Creating and Configuring a Realm for Test Users.
Create an LDIF file with user entries that is imported into Directory Server 1.
As a root user, log in to the DirectoryServer–1 host machine.
Create an LDIF file with the following entries.
dn: ou=users,dc=company,dc=com objectclass: top objectclass: organizationalUnit ou: users description: Container for user entries dn: ou=Groups,dc=company,dc=com objectClass: top objectClass: organizationalUnit ou: Groups description: Container for group entries dn: uid=testuser1,ou=users,dc=company,dc=com uid: testuser1 givenName: Test objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetadmin objectClass: inetorgperson objectClass: inetUser sn: User1 cn: Test User1 userPassword: password inetUserStatus: Active dn: uid=testuser2,ou=users,dc=company,dc=com uid: testuser2 givenName: Test objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson objectClass: inetUser sn: User2 cn: Test User2 userPassword: password inetUserStatus: Active
Save the file as am-users.ldif in the /tmp directory.
Import the LDIF file into Directory Server 1 using ldapmodify.
# ldapmodify -h DirectoryServer-1.example.com -p 1489 -D "cn=Directory Manager" -w d1rm4n4ger -a -f /tmp/am-users.ldif adding new entry ou=users,dc=company,dc=com adding new entry ou=Groups,dc=company,dc=com adding new entry uid=testuser1,ou=users,dc=company,dc=com adding new entry uid=testuser2,ou=users,dc=company,dc=com |
Verify that the new users were imported using ldapsearch.
# ldapsearch -h DirectoryServer-1.example.com -b "dc=company,dc=com" -p 1489 -D "cn=Directory Manager" -w d1rm4n4ger "uid=test*" version: 1 dn: uid=testuser1,ou=users,dc=company,dc=com uid: testuser1 givenName: Test objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetadmin objectClass: inetorgperson objectClass: inetUser sn: User1 cn: Test User1 userPassword: {SSHA}H5LpB+QLZMoL9SiXzY/DokHKXRclELVy7w25AA== inetUserStatus: Active dn: uid=testuser2,ou=users,dc=company,dc=com uid: testuser2 givenName: Test objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson objectClass: inetUser sn: User2 cn: Test User2 userPassword: {SSHA}aLNFCQ1qw78KpJeloVZJAAa5QSAPf/9c2mxCQQ== inetUserStatus: Active |
Log out of the DirectoryServer–1 host machine.
(Optional) Verify that the entries were replicated to Directory Server 2 by logging in as a root user to the DirectoryServer–2 host machine and using ldapsearch.
# ldapsearch -h DirectoryServer-2.example.com -b "dc=company,dc=com" -p 1489 -D "cn=Directory Manager" -w d1rm4n4ger "" version: 1 dn: dc=company,dc=com objectClass: top objectClass: domain dc: company dn: ou=users,dc=company,dc=com objectClass: top objectClass: organizationalUnit ou: users description: Container for user entries dn: ou=Groups,dc=company,dc=com objectClass: top objectClass: organizationalUnit objectclass: iplanet-am-managed-group ou: Groups description: Container for group entries dn: uid=testuser1,ou=users,dc=company,dc=com uid: testuser1 givenName: Test objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetadmin objectClass: inetorgperson objectClass: inetUser sn: User1 cn: Test User1 inetUserStatus: Active userPassword: {SSHA}H5LpB+QLZMoL9SiXzY/DokHKXRclELVy7w25AA== dn: uid=testuser2,ou=users,dc=company,dc=com uid: testuser2 givenName: Test objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson objectClass: inetUser sn: User2 cn: Test User2 inetUserStatus: Active userPassword: {SSHA}aLNFCQ1qw78KpJeloVZJAAa5QSAPf/9c2mxCQQ== |
Log out of the DirectoryServer–2 host machine.
At this point, the root realm is configured to authenticate against the Directory Server configuration data instances. We use the root realm to authenticate special Access Manager accounts (like amadmin and agents) but, we now create a sub-realm to authenticate end users against the Directory Server user data instances. This creates a demarcation between Access Manager configuration and administrative account data, and the end-user profiles.
With the following procedures, we create a sub-realm to which we add our text subjects, and then configure the realm properties to suit the needs of this deployment example.
To Change the Default User Data Store and Configure an Authentication Module for the Realm
To Verify That Access Manager Recognizes the External User Data Store
To Verify That a Realm Subject Can Successfully Authenticate
Access http://LoadBalancer-3.example.com:7070/ from a web browser.
This is the Access Manager load balancer.
Log in to the Access Manager console as the administrator.
amadmin
4m4dmin1
Click the Access Control tab.
Click New to create a new realm.
On the New Realm page, enter users in the Name field.
Enter users in the New Value field of the Realm/DNS Aliases list and click Add.
Click OK.
The users realm is listed as a sub-realm of the top-level realm, example.
Now we instantiate an authentication module and reconfigure the default ldapService authentication chain to use the new authentication module. Additionally, we will change the realm's User Profile attribute and delete the default authentication module instances. During this procedure, we also change the default user data store to the user data instance previously created.
This procedure assumes you have just completed To Create a Realm and are still logged in to the Access Manager console.
Under the Access Control tab, click the users realm.
Click the Authentication tab.
Click Advanced Properties in the General section.
On the resulting page, change the value of the User Profile attribute to Ignored.
This new value specifies that a user profile is not required by the Authentication Service to issue a token after successful authentication.
Click Save.
The profile is updated.
Click Back to Authentication.
You will return to the users realm Authentication page.
Under Module Instances section, click New.
These next steps instantiate the Data Store authentication module in the users sub-realm.
Under Authentication Chaining, click on the default ldapService chain.
These next steps reconfigure the default ldapService chain to use the new authentication module.
Under Module Instances, mark the checkbox for LDAP and Data Store.
These modules are inherited from the default top-level realm and used to authenticate to the Access Manager configuration data instance of Directory Server. They are no longer needed now that the usersDataStore authentication module instance will be used.
Click Delete
The modules are deleted and the users realm Authentication page is displayed.
Click Save.
Click the Data Stores tab.
Mark the checkbox for amConfigDS.
This is the data store inherited from the parent realm.
Click Delete.
Click New.
On the resulting page, set the following attributes:
usersLDAP
Choose Generic LDAPv3
Click Next.
On the resulting page, set the following attributes:
Enter the hostname and port number for the existing directory in the form LoadBalancer-2.example.com:489 and click Add.
Select the default LoadBalancer-1.example.com:389 and click Remove.
Enter cn=Directory Manager
Enter d1rm4n4ger
Enter d1rm4n4ger
Replace dc=example,dc=com with dc=company,dc=com
Add inetorgperson as a new value.
Replace people with users.
If this field is empty, the search for user entries will start from the root suffix.
Replace dc=example,dc=com with dc=company,dc=com
Click Finish.
Log out of the Access Manager console.
Access http://AccessManager-1.example.com:1080/amserver/console from a web browser.
Log in to the Access Manager console as the administrator.
amadmin
4m4dmin1
Click on the Access Control tab
Click on the users sub-realm.
Click on the Subjects tab.
You should see Test User1 and Test User2.
Log out of the Access Manager console.
Access http://AccessManager-1.example.com:1080/amserver/UI/Login?realm=users from a web browser.
The parameter realm=users specifies the realm to use for authentication. At this point, a user can log in against Directory Server only if the realm parameter is defined in the URL.
Log in to Access Manager with a user name and password from the am-users directory.
testuser1
password
You should be able to log in successfully and see a page with a message that reads You're logged in. Since the User Profile attribute was set to Ignored, the user's profile is not displayed after a successful login. If the login is not successful, watch the Directory Server access log to troubleshoot the problem.
Log out of the Access Manager console.
Access Manager provides a remote authentication interface component to enable secure authentication. Installing the Distributed Authentication User Interface on one or more web containers within a non-secure layer eliminates the exposure of service URLs to the end user. This chapter contains the following sections.
8.1 Creating an Agent Profile and Custom User for Distributed Authentication User Interface
8.2 Installing and Configuring the Distributed Authentication User Interface 1
8.3 Installing and Configuring the Distributed Authentication User Interface 2
8.4 Configuring the Distributed Authentication User Interface Load Balancer
Before installing and configuring the Distributed Authentication User Interface, you create an agent profile in Access Manager to be used by the Distributed Authentication User Interface to authenticate itself. An agent profile allows Access Manager to store authentication and configuration information regarding the Distributed Authentication User Interface. The agent profile created in this procedure will be stored in the Access Manager configuration data store.
Creating an agent profile also creates a custom user. This custom user will allow the Distributed Authentication User Interface to log into the Access Manager server and therefore must be defined as an Access Manager special user.
Although the Distributed Authentication User Interface is not an agent, it acts on behalf of Access Manager and therefore must have its own agent profile.
Use the following list of procedures as a checklist for these tasks.
To Create an Agent Profile for the Distributed Authentication User Interface
To Define Agent Profile User as an Access Manager Special User
This agent profile will be used by the Distributed Authentication User Interface to authenticate itself to Access Manager. The process includes creation of a special user that will be defined as an Access Manager special user in the next procedure, To Define Agent Profile User as an Access Manager Special User.
Access http://LoadBalancer-3.example.com:7070/ from 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.
Click the Subjects tab.
Click the Agent tab.
Click New to create a new agent profile.
Type authuiadmin in the ID field.
Type 4uthu14dmin in the Password and Password (confirm) fields, respectively.
Click OK.
From the list of Agent names, click authuiadmin.
Copy the value of the UniversalID and save it to a temporary text file.
You will need this value in To Define Agent Profile User as an Access Manager Special User.
Log out of the console.
(Optional) Verify that the agents organizational unit was created successfully by logging into a Directory Server host machine and running ldapsearch.
# ldapsearch -b "dc=example,dc=com" -h LoadBalancer-1.example.com -p 389 -D "cn=Directory Manager" -w d1rm4n4ger "ou=agents" version: 1 dn: ou=agents,dc=example,dc=com sunIdentityServerSupportedTypes: agent ou: agents objectClass: sunNameSpace objectClass: iplanet-am-managed-org-unit objectClass: top objectClass: organizationalUnit |
This organization unit will hold all agent profiles.
The agents organizational unit is created only after the first agent profile is configured.
This is an optional, verification step.
Log in to either of the Directory Server host machines.
Run ldapsearch to verify that the authuiadmin entry was successfully created.
# ldapsearch -b "dc=example,dc=com" -h LoadBalancer-1.example.com -p 389 -D "cn=Directory Manager" -w d1rm4n4ger "uid=authuiadmin" version: 1 dn: uid=authuiadmin,ou=agents,dc=example,dc=com sunIdentityServerDeviceStatus: Active uid: authuiadmin objectClass: sunIdentityServerDevice objectClass: iplanet-am-user-service objectClass: top objectClass: iPlanetPreferences sunIdentityServerDeviceType: Agent cn: default sunIdentityServerDeviceVersion: 2.2 userPassword: {SSHA}aeEi095TamPnJCOLinRNDzlLC8SDaOsdQ2Nqfw== |
Log out of the Directory Server host machine.
The agent profile just created includes a user that will now be defined as an Access Manager special administrative user for both Access Manager 1 and Access Manager 2.
You should have the UniversalID value saved in To Create an Agent Profile for the Distributed Authentication User Interface.
Define authuiadmin as a special user in Access Manager 1.
As a root user, log in to the AccessManager–1 host machine.
Locate AMConfig.properties in the /export/am71adm/config directory.
Backup AMConfig.properties before you modify it.
Add the UniversalID you saved to the end of the list of values for the com.sun.identity.authentication.special.users property in AMConfig.properties.
You saved id=authuiadmin,ou=agent,dc=example, dc=com in To Create an Agent Profile for the Distributed Authentication User Interface.
Change ou=agent to ou=agents and id to uid before adding it to AMConfig.properties.
Restart the Web Server 1 web container to apply the change.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com/bin # ./stopserv; ./startserv |
Log out of the AccessManager–1 host machine.
Define authuiadmin as a special user in Access Manager 2.
As a root user, log in to the AccessManager–2 host machine.
Locate AMConfig.properties in the /export/am71adm/config directory.
Backup AMConfig.properties before you modify it.
Add the UniversalID you saved to the end of the list of values for the com.sun.identity.authentication.special.users property in AMConfig.properties.
You saved id=authuiadmin,ou=agent,dc=example, dc=com in To Create an Agent Profile for the Distributed Authentication User Interface.
Change ou=agent to ou=agents and id to uid before adding it to AMConfig.properties.
Restart the Web Server 2 web container to apply the change.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com/bin # ./stopserv; ./startserv |
Log out of the AccessManager–2 host machine.
Use the following list of procedures as a checklist for installing and deploying the Distributed Authentication User Interface 1.
To Create a Non-Root User on the Distributed Authentication User Interface 1 Host Machine
To Install Sun Java System Web Server for Distributed Authentication User Interface 1
To Configure the WAR for Distributed Authentication User Interface 1
To Deploy the Distributed Authentication User Interface 1 WAR
To Verify that Authentication Through the Distributed Authentication User Interface 1 is Successful
Create a non-root user with the roleadd command in the Solaris Operating Environment on the Distributed Authentication User Interface 1 (AuthenticationUI-1) host machine
As a root user, log in to the AuthenticationUI-1 host machine.
Use roleadd to create a new user.
# roleadd -s /sbin/sh -m -g staff -d /export/da71adm da71adm |
(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:/: da71adm:x:215933:10::/export/da71adm:/sbin/sh |
(Optional) Verify that the user's directory was created.
# cd /export/da71adm # ls local.cshrc local.profile local.login |
(Optional) Create a password for the non-root user.
# passwd da71adm New Password: 6a714dm Re-ener new Pasword: 6a714dm passwd: password successfully changed for da71adm |
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 have just completed To Create a Non-Root User on the Distributed Authentication User Interface 1 Host Machine.
Before beginning the installation, read the Web Server 7.0 Release Notes to determine the latest patches you might need to install.
On the AuthenticationUI-1 host machine, install required patches if necessary.
In this case, the Release Notes indicate that based on the hardware and operating system being used, patch 118855-36 and patch 119964–08 are required.
Run patchadd to see if the patches are already installed.
# patchadd -p | grep 118855-36 |
No results are returned which indicates that the patch is not yet installed on the system.
# patchadd -p | grep 119964-08 |
No results are returned which indicates that the patch is not yet installed on the system.
Make a directory for downloading the patches you need and change into it.
# mkdir /export/patches # cd /export/patches |
Download the patches.
You can search for patches directly at http://sunsolve.sun.com. Navigate to the PatchFinder page, enter the patch number, click Find Patch, and download the appropriate patch.
Signed patches are downloaded as JAR files. Unsigned patches are downloaded as ZIP files.
Unzip the patch files.
# unzip 118855–36.zip # unzip 119964-08.zip |
Run patchadd to install the patches.
# patchadd /export/patches/118855-36 # patchadd /export/patches/119964-08 |
You can use the -M option to install all patches at once. See the patchadd man page for more information.
After installation is complete, run patchadd to verify that each patch was added successfully.
# patchadd -p | grep 118855–36 |
In this example, a series of patch numbers are displayed, and the patch 118855–36 is present.
# patchadd -p | grep 119964-08 |
In this example, a series of patch numbers are displayed, and the patch 119964-08 is present.
Create a directory into which you can download the Web Server bits 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-amd64.tar.gz # tar xvf sjsws-7_0-solaris-amd64.tar |
Run setup.
# cd /export/WS7 # ./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 da71adm. |
|
|
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. |
(Optional) 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 da71adm staff 512 Jul 19 10:36 .. drwxr-xr-x 2 root root 512 Jul 19 10:36 bin drwx------ 2 da71adm staff 512 Jul 19 10:36 config drwx------ 3 da71adm staff 512 Jul 19 11:09 config-store drwx------ 3 da71adm staff 512 Jul 19 10:40 generated drwxr-xr-x 2 da71adm staff 512 Jul 19 10:40 logs drwx------ 2 da71adm staff 512 Jul 19 10:36 sessions |
The appropriate files and directories are owned by da71adm.
Start the Web Server administration server.
# su da71adm # cd /opt/SUNWwbsvr/admin-server/bin # ./startserv |
To verify that the non-root user was able to start Web Server, access https://AuthenticationUI-1.example.com:8989 from a web browser.
Log out of the AuthenticationUI–1 host machine.
This procedure configures the amauthdistui.war that will be used for deployment in To Deploy the Distributed Authentication User Interface 1 WAR.
As a root user, log in to the AuthenticationUI–1 host machine.
Switch to the non-root user.
# su da71adm |
Change to the directory into which you will copy amDistAuth.zip.
# cd /export/da71adm |
amDistAuth.zip contains the files you need to install the Distributed Authentication User Interface. It is included in the Access Manager software downloaded in 6.2 Deploying and Configuring Access Manager 1 and Access Manager 2.
Copy amDistAuth.zip from the AccessManager–1 host machine.
# ftp AccessManager-1.example.com Connected to AccessManager-1.example.com 220 AccessManager-1.example.com FTP server ready. Name (AccessManager-1.example.com:username):username Password: ******** ... Using binary mode to transfer files ftp> cd /export/AM71/applications CWD command successful ftp> mget amDistAuth.zip? mget amDistAuth.zip? y 200 PORT command successful ftp> bye |
List the contents of /export/da71adm to verify that amDistAuth.zip was transferred and is owned by the non-root user.
# ls -al total 26496 drwxr-xr-x 5 da71adm staff 512 Jul 19 20:59 . drwxr-xr-x 7 root sys 512 Jul 20 10:13 .. -rw-r--r-- 1 da71adm staff 144 Jul 19 19:53 .profile drwx------ 3 da71adm staff 512 Jul 19 20:41 .sunw -rw-r--r-- 1 da71adm staff 6747654 Jul 19 20:43 amDistAuth.zip |
Unzip amDistAuth.zip.
# unzip amDistAuth.zip |
List the contents again to verify the unzip.
# ls -al total 26496 drwxr-xr-x 5 da71adm staff 512 Jul 19 20:59 . drwxr-xr-x 7 root sys 512 Jul 20 10:13 .. -rw-r--r-- 1 da71adm staff 144 Jul 19 19:53 .profile drwx------ 3 da71adm staff 512 Jul 19 20:41 .sunw -rw-r--r-- 1 da71adm staff 572 Jul 19 20:59 .wadmtruststore -rw-r--r-- 1 da71adm staff 6772566 Jul 19 20:56 amauthdistui.war -rw-r--r-- 1 da71adm staff 6747654 Jul 19 20:43 amDistAuth.zip drwxr-xr-x 2 da71adm staff 512 Jul 19 20:52 lib -rw-r--r-- 1 da71adm staff 136 Jul 19 19:53 local.cshrc -rw-r--r-- 1 da71adm staff 157 Jul 19 19:53 local.login -rw-r--r-- 1 da71adm staff 174 Jul 19 19:53 local.profile -rw-r--r-- 1 da71adm staff 10038 Mar 19 15:33 README.distAuthUI -rw-r--r-- 1 da71adm staff 1865 Mar 19 15:31 setup.bat -rw-r--r-- 1 da71adm staff 1865 Mar 19 15:31 setup.sh drwxr-xr-x 3 da71adm staff 512 Jun 25 20:13 WEB-INF |
Change permissions on setup.sh, the Distributed Authentication User Interface configuration script.
# chmod +x setup.sh |
This gives the non-root user permission to run the script that configures the Distributed Authentication User Interface WAR for its deployment.
Run setup.sh.
# ./setup.sh |
If using a shell other than sh, you must modify the setup script before running it.
Open setup.sh in a text editor.
Add #!/bin/sh as the first line of the file.
Save and close the file.
Run the script.
Provide the following information.
|
Enter /tmp/distAuth |
|
|
Enter authuiadmin |
|
|
Enter 4uthu14dmin |
|
|
Enter http |
|
|
Enter LoadBalancer-3.example.com |
|
|
Enter 7070 |
|
|
Enter amserver |
|
|
Press Enter to accept the default value. |
|
|
Enter http |
|
|
Enter AuthenticationUI-1.example.com |
|
|
Enter 1080 |
|
|
Enter distAuth |
|
|
Press Enter to accept the default value. |
After running the script, amauthdistui.war is updated with the above values. The next step is To Deploy the Distributed Authentication User Interface 1 WAR.
This procedure assumes you just completed To Configure the WAR for Distributed Authentication User Interface 1 and are still logged into the AuthenticationUI–1 host machine as the non-root user.
Start the Web Server administration server.
# cd /opt/SUNWwbsvr/admin-server/bin # ./startserv |
Add the Distributed Authentication User Interface WAR.
# cd /opt/SUNWwbsvr/bin # ./wadm add-webapp --user=admin --host=AuthenticationUI-1.example.com --port=8989 --config=AuthenticationUI-1.example.com --vs=AuthenticationUI-1.example.com --uri=/distAuth /export/da71adm/amauthdistui.war Please enter admin-user-password:web4dmin Do you trust the above certificate? [y|n] y CLI201 Command 'add-webapp' ran successfully |
Deploy the Distributed Authentication User Interface WAR.
# ./wadm deploy-config --user=admin --host=AuthenticationUI-1.example.com --port=8989 AuthenticationUI-1.example.com Please enter admin-user-password: web4dmin CLI201 Command 'deploy-config' ran successfully |
Restart the Web Server AuthenticationUI-1 instance.
# cd /opt/SUNWwbsvr/https-AuthenticationUI-1.example.com/bin # ./stopserv; ./startserv |
Verify that the distAuth web module is loaded.
# cd /opt/SUNWwbsvr/https-AuthenticationUI-1.example.com/ web-app/AuthenticationUI-1.example.com # ls -al total 6 drwxr-xr-x 3 da71adm staff 512 Jul 19 21:00 . drwxr-xr-x 3 da71adm staff 512 Jul 19 21:00 .. drwxr-xr-x 8 da71adm staff 512 Jul 19 21:00 distAuth |
Log out of the AuthenticationUI–1 host machine.
Import a Certificate Authority (CA) root certificate that enables the Distributed Authentication User Interface to trust the SSL certificate from the Access Manager Load Balancer 3, and establish trust with the certificate chain that is formed from the Certificate Authority to the certificate.
As a root user, log in to the AuthenticationUI–1 host machine.
Copy the CA root certificate into a directory.
Use the same root certificate installed in To Import a Certificate Authority Root Certificate on the Access Manager Load Balancer. In this example, the file is /export/software/ca.cer.
Import the CA root certificate into the Java keystore.
# /opt/SUNWwbsvr/jdk/jre/bin/keytool -import -trustcacerts -alias OpenSSLTestCA -file /export/software/ca.cer -keystore /opt/SUNWwbsvr/jdk/jre/lib/security/cacerts -storepass changeit Owner: EMAILADDRESS=nobody@nowhere.com, CN=OpenSSLTestCA, OU=Sun, O=Sun,L=Santa Clara, ST=California C=US Issuer: EMAILADDRESS=nobody@nowhere.com, CN=OpenSSLTestCA, OU=Sun, O=Sun,L=Santa Clara, ST=California C=US Serial number: 97dba0aa26db6386 Valid from: Tue Apr 18 07:66:19 PDT 2006 until: Tue Jan 13 06:55:19 PST 2009 Certificate fingerprints: MD5: 9f:57:ED:B2:F2:88:B6:E8:0F:1E:08:72:CF:70:32:06 SHA1: 31:26:46:15:C5:12:5D:29:46:2A:60:A1:E5:9E:26:64:36:80:E4:70 Trust this certificate: [no] yes Certificate was added to keystore. |
Verify that the CA root certificate was imported into the keystore.
# /opt/SUNWwbsvr/jdk/jre/bin/keytool -list -keystore /opt/SUNWwbsvr/jdk/jre/lib/security/cacerts -storepass changeit | grep -i open openssltestca, Nov 8, 2006, trustedCertEntry |
Restart the Web Server AuthenticationUI-1 instance.
# cd /opt/SUNWwbsvr/https-AuthenticationUI-1.example.com/bin # ./stopserv server has been shutdown # ./startserv Sun Java System Web Server 7.0 B12/04/2006 07:59 info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_09] from [Sun Microsystems Inc.] info: WEB0100: Loading web module in virtual server [AuthenticationUI-1.example.com] at [/distAuth] info: HTTP3072: http-listener-1: http://AuthenticationUI-1.example.com:1080 ready to accept requests info: CORE3274: successful server startup |
Log out of the AuthenticationUI–1 host machine.
Find a host that has direct network connectivity to Distributed Authentication User Interface 1 and the external facing load balancer of the Access Manager servers. One natural place is the AuthenticationUI–1 host machine itself.
As a root user, log into the AuthenticationUI—1 host machine.
Modify AMConfig.properties.
Change to the classes directory.
# cd /opt/SUNWwbsvr/https-AuthenticationUI-1.example.com/ web-app/AuthenticationUI-1.example.com/distAuth/WEB-INF/classes |
Backup AMConfig.properties before you modify it.
Set the values of the properties as follows.
com.iplanet.am.naming.url=https://LoadBalancer-3. example.com:9443/amserver/namingservice com.iplanet.am.server.protocol=https com.iplanet.am.server.port=9443
Save the file and close it.
Restart the AuthenticationUI-1 host machine.
# cd /opt/SUNWwbsvr/https-AuthenticationUI-1.example.com/bin # ./stopserv; ./startserv |
Access http://AuthenticationUI-1.example.com:1080/distAuth/UI/Login?goto= http://LoadBalancer-3.example.com:7070 from a web browser.
Log in to the Access Manager console as the administrator.
amadmin
4m4dmin1
After successful authentication, you should be redirected to the index page for the Web Server in which Access Manager is deployed.
Log out of the Access Manager console.
Use the following list of procedures as a checklist for installing and configuring the Distributed Authentication User Interface 2.
To Create a Non-Root User on the Distributed Authentication User Interface 2 Host
To Install Sun Java System Web Server for Distributed Authentication User Interface 2
To Configure the WAR for Distributed Authentication User Interface 2
To Deploy the Distributed Authentication User Interface 2 WAR
To Verify that Authentication Through the Distributed Authentication User Interface 2 is Successful
Create a non-root user with the roleadd command in the Solaris Operating Environment on the Distributed Authentication User Interface (AuthenticationUI–2) host machine
As a root user, log in to the AuthenticationUI–2 host machine.
Use roleadd to create a new user.
# roleadd -s /sbin/sh -m -g staff -d /export/da71adm da71adm |
(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:/: da71adm:x:215933:10::/export/da71adm:/sbin/sh |
(Optional) Verify that the user's directory was created.
# cd /export/da71adm # ls local.cshrc local.profile local.login |
(Optional) Create a password for the non-root user.
# passwd da71adm New Password: 6a714dm Re-ener new Pasword:6a714dm passwd: password successfully changed for da71adm |
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 have just completed To Create a Non-Root User on the Distributed Authentication User Interface 2 Host.
Before beginning the installation, read the Web Server 7.0 Release Notes to determine the latest patches you might need to install.
On the AuthenticationUI–2 host machine, install required patches if necessary.
In this case, the Release Notes indicate that based on the hardware and operating system being used, patch 118855-36 and patch 119964–08 are required.
Run patchadd to see if the patches are already installed.
# patchadd -p | grep 118855-36 |
No results are returned which indicates that the patch is not yet installed on the system.
# patchadd -p | grep 119964-08 |
No results are returned which indicates that the patch is not yet installed on the system.
Make a directory for downloading the patches you need and change into it.
# mkdir /export/patches # cd /export/patches |
Download the patches.
You can search for patches directly at http://sunsolve.sun.com. Navigate to the PatchFinder page, enter the patch number, click Find Patch, and download the appropriate patch.
Signed patches are downloaded as JAR files. Unsigned patches are downloaded as ZIP files.
Unzip the patch files.
# unzip 118855–36.zip # unzip 119964-08.zip |
Run patchadd to install the patches.
# patchadd /export/patches/118855-36 # patchadd /export/patches/119964-08 |
You can use the -M option to install all patches at once. See the patchadd man page for more information.
After installation is complete, run patchadd to verify that each patch was added successfully.
# patchadd -p | grep 118855–36 |
In this example, a series of patch numbers are displayed, and the patch 118855–36 is present.
# patchadd -p | grep 119964-08 |
In this example, a series of patch numbers are displayed, and the patch 119964-08 is present.
Create a directory into which you can download the Web Server bits 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-amd64.tar.gz # tar xvf sjsws-7_0-solaris-amd64.tar |
Run setup.
# cd /export/WS7 # ./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 da71adm. |
|
|
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 da71adm staff 512 Jul 19 10:36 .. drwxr-xr-x 2 root root 512 Jul 19 10:36 bin drwx------ 2 da71adm staff 512 Jul 19 10:36 config drwx------ 3 da71adm staff 512 Jul 19 11:09 config-store drwx------ 3 da71adm staff 512 Jul 19 10:40 generated drwxr-xr-x 2 da71adm staff 512 Jul 19 10:40 logs drwx------ 2 da71adm staff 512 Jul 19 10:36 sessions |
The appropriate files and directories are owned by da71adm.
Start the Web Server administration server.
# su da71adm # cd /opt/SUNWwbsvr/admin-server/bin # ./startserv |
To verify that the non-root user was able to start Web Server, access https://AuthenticationUI-2.example.com:8989 from a web browser.
Log out of the AuthenticationUI–2 host machine.
This procedure configures the amauthdistui.war that will be used for deployment in To Deploy the Distributed Authentication User Interface 2 WAR.
As a root user, log in to the AuthenticationUI–2 host machine.
Switch to the non-root user.
# su da71adm |
Change to the directory into which you will copy amDistAuth.zip.
# cd /export/da71adm |
amDistAuth.zip contains the files you need to install the Distributed Authentication User Interface. It is included in the Access Manager software downloaded in 6.2 Deploying and Configuring Access Manager 1 and Access Manager 2.
Copy amDistAuth.zip from the AccessManager–1 host machine.
# cd /export/da71adm # ftp AccessManager-1.example.com Connected to AccessManager-1.example.com 220 AccessManager-1.example.com FTP server ready. Name (AccessManager-1.example.com:username):username Password: ******** ... Using binary mode to transfer files ftp> cd /export/AM71/applications CWD command successful ftp> mget amDistAuth.zip? mget amDistAuth.zip? y 200 PORT command successful ftp> bye |
List the contents of /export/da71adm to verify that amDistAuth.zip was transferred and is owned by the non-root user.
# ls -al total 26496 drwxr-xr-x 5 da71adm staff 512 Jul 19 20:59 . drwxr-xr-x 7 root sys 512 Jul 20 10:13 .. -rw-r--r-- 1 da71adm staff 144 Jul 19 19:53 .profile drwx------ 3 da71adm staff 512 Jul 19 20:41 .sunw -rw-r--r-- 1 da71adm staff 6747654 Jul 19 20:43 amDistAuth.zip |
Unzip amDistAuth.zip.
# unzip amDistAuth.zip |
List the contents again to verify the unzip.
# ls -al total 26496 drwxr-xr-x 5 da71adm staff 512 Jul 19 20:59 . drwxr-xr-x 7 root sys 512 Jul 20 10:13 .. -rw-r--r-- 1 da71adm staff 144 Jul 19 19:53 .profile drwx------ 3 da71adm staff 512 Jul 19 20:41 .sunw -rw-r--r-- 1 da71adm staff 572 Jul 19 20:59 .wadmtruststore -rw-r--r-- 1 da71adm staff 6772566 Jul 19 20:56 amauthdistui.war -rw-r--r-- 1 da71adm staff 6747654 Jul 19 20:43 amDistAuth.zip drwxr-xr-x 2 da71adm staff 512 Jul 19 20:52 lib -rw-r--r-- 1 da71adm staff 136 Jul 19 19:53 local.cshrc -rw-r--r-- 1 da71adm staff 157 Jul 19 19:53 local.login -rw-r--r-- 1 da71adm staff 174 Jul 19 19:53 local.profile -rw-r--r-- 1 da71adm staff 10038 Mar 19 15:33 README.distAuthUI -rw-r--r-- 1 da71adm staff 1865 Mar 19 15:31 setup.bat -rw-r--r-- 1 da71adm staff 1865 Mar 19 15:31 setup.sh drwxr-xr-x 3 da71adm staff 512 Jun 25 20:13 WEB-INF |
Change permissions on setup.sh, the Distributed Authentication User Interface configuration script.
# chmod +x setup.sh |
This gives the non-root user permission to run the script that configures the Distributed Authentication User Interface WAR for its deployment.
Run setup.sh.
# ./setup.sh |
If using a shell other than sh, you must modify the setup script before running it.
Open setup.sh in a text editor.
Add #!/bin/sh as the first line of the file.
Save and close the file.
Run the script.
Provide the following information.
|
Enter /tmp/distAuth |
|
|
Enter authuiadmin |
|
|
Enter 4uthu14dmin |
|
|
Enter http |
|
|
Enter LoadBalancer-3.example.com |
|
|
Enter 7070 |
|
|
Enter amserver |
|
|
Press Enter to accept the default value. |
|
|
Enter http |
|
|
Enter AuthenticationUI-2.example.com |
|
|
Enter 1080 |
|
|
Enter distAuth |
|
|
Press Enter to accept the default value. |
After running the script, amauthdistui.war is updated with the above values. The next step is To Deploy the Distributed Authentication User Interface 2 WAR.
This procedure assumes you just completed To Configure the WAR for Distributed Authentication User Interface 2 and are still logged into the AuthenticationUI–2 host machine as the non-root user.
Start the Web Server administration server.
# cd /opt/SUNWwbsvr/admin-server/bin # ./startserv |
Add the Distributed Authentication User Interface WAR.
# cd /opt/SUNWwbsvr/bin # ./wadm add-webapp --user=admin --host=AuthenticationUI-2.example.com --port=8989 --config=AuthenticationUI-2.example.com --vs=AuthenticationUI-2.example.com --uri=/distAuth /export/da71adm/amauthdistui.war Please enter admin-user-password:web4dmin ... Do you trust the above certificate? [y|n] y CLI201 Command 'add-webapp' ran successfully |
Deploy the Distributed Authentication User Interface WAR.
# ./wadm deploy-config --user=admin --host=AuthenticationUI-2.example.com --port=8989 AuthenticationUI-2.example.com Please enter admin-user-password: web4dmin CLI201 Command 'deploy-config' ran successfully |
Restart the Web Server AuthenticationUI-2 instance.
# cd /opt/SUNWwbsvr/https-AuthenticationUI-2.example.com/bin # ./stopserv; ./startserv |
Verify that the distAuth web module is loaded.
# cd /opt/SUNWwbsvr/https-AuthenticationUI-2.example.com/ web-app/AuthenticationUI-2.example.com # ls -al total 6 drwxr-xr-x 3 da71adm staff 512 Jul 19 21:00 . drwxr-xr-x 3 da71adm staff 512 Jul 19 21:00 .. drwxr-xr-x 8 da71adm staff 512 Jul 19 21:00 distAuth |
Log out of the AuthenticationUI–2 host machine.
Import a Certificate Authority (CA) root certificate that enables the Distributed Authentication User Interface to trust the SSL certificate from the Access Manager Load Balancer 3, and establish trust with the certificate chain that is formed from the CA to the certificate.
As a root user, log in to the AuthenticationUI–2 host machine.
Copy the CA root certificate into a directory.
Use the same root certificate installed in To Import a Certificate Authority Root Certificate on the Access Manager Load Balancer. In this example, the file is /export/software/ca.cer.
Import the CA root certificate into the Java keystore.
# /opt/SUNWwbsvr/jdk/jre/bin/keytool -import -trustcacerts -alias OpenSSLTestCA -file /export/software/ca.cer -keystore /opt/SUNWwbsvr/jdk/jre/lib/security/cacerts -storepass password Owner: EMAILADDRESS=nobody@nowhere.com, CN=OpenSSLTestCA, OU=Sun, O=Sun,L=Santa Clara, ST=California C=US Issuer: EMAILADDRESS=nobody@nowhere.com, CN=OpenSSLTestCA, OU=Sun, O=Sun,L=Santa Clara, ST=California C=US Serial number: 97dba0aa26db6386 Valid from: Tue Apr 18 07:66:19 PDT 2006 until: Tue Jan 13 06:55:19 PST 2009 Certificate fingerprints: MD5: 9f:57:ED:B2:F2:88:B6:E8:0F:1E:08:72:CF:70:32:06 SHA1: 31:26:46:15:C5:12:5D:29:46:2A:60:A1:E5:9E:26:64:36:80:E4:70 Trust this certificate: [no] yes Certificate was added to keystore. |
Verify that the CA root certificate was imported into the keystore.
# /opt/SUNWwbsvr/jdk/jre/bin/keytool -list -keystore /opt/SUNWwbsvr/jdk/jre/lib/security/cacerts -storepass password | grep -i open openssltestca, Nov 8, 2006, trustedCertEntry |
Restart the Web Server AuthenticationUI-2 instance.
# cd /opt/SUNWwbsvr/https-AuthenticationUI-2.example.com/bin # ./stopserv server has been shutdown # ./startserv Sun Java System Web Server 7.0 B12/04/2006 07:59 info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_09] from [Sun Microsystems Inc.] info: WEB0100: Loading web module in virtual server [AuthenticationUI-2.example.com] at [/distAuth] info: HTTP3072: http-listener-1: http://AuthenticationUI-2. example.com:1080 ready to accept requests info: CORE3274: successful server startup |
Log out of the AuthenticationUI–2 host machine.
Find a host that has direct network connectivity to Distributed Authentication User Interface 2 and the external facing load balancer of the Access Manager servers. One natural place is the AuthenticationUI–2 host machine itself.
As a root user, log into the AuthenticationUI–2 host machine.
Modify AMConfig.properties.
Change to the classes directory.
# cd /opt/SUNWwbsvr/https-AuthenticationUI-2.example.com/ web-app/AuthenticationUI-2.example.com/distAuth/WEB-INF/classes |
Backup AMConfig.properties before you modify it.
Set the values of the properties as follows.
com.iplanet.am.naming.url=https://LoadBalancer-3. example.com:9443/amserver/namingservice com.iplanet.am.server.protocol=https com.iplanet.am.server.port=9443
Save the file and close it.
Restart the AuthenticationUI-2 host machine.
# cd /opt/SUNWwbsvr/https-AuthenticationUI-2.example.com/bin # ./stopserv; ./startserv |
Access http://AuthenticationUI-2.example.com:1080/distAuth/UI/Login?goto= http://LoadBalancer-3.example.com:7070 from a web browser.
Log in to the Access Manager console as the administrator.
amadmin
4m4dmin1
After successful authentication, you should be redirected to the index page for the Web Server in which Access Manager is deployed.
Log out of the Access Manager console.
The following figure illustrates how Load Balancer 4 is configured in front of the two instances of the Distributed Authentication User Interface.
Use the following list of procedures as a checklist for configuring the Distributed Authentication User Interface load balancer.
To Configure the Distributed Authentication User Interface Load Balancer
To Configure Load Balancer Cookies for the Distributed Authentication User Interface
To Import a CA Root Certificate on the Distributed Authentication User Interface Load Balancer
To Install an SSL Certificate on the Distributed Authentication User Interface Load Balancer
To Configure SSL Termination on the Distributed Authentication User Interface Load Balancer
This procedure assumes that you have already installed a load balancer.
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.
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 Distributed Authentication User Interface 1 and Distributed Authentication User Interface 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, from 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:
AuthenticationUI-Pool
Round Robin
Add the IP address and port number of both Distributed Authentication User Interface host machines: AuthenticationUI-1:1080 and AuthenticationUI-2:1080.
Click Done.
Add a Virtual Server.
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 Virtual Server wizard, enter the virtual server IP address and port number.
Enter the IP address for LoadBalancer-4.example.com
90
AuthenticationUI-Pool
Continue to click Next until you reach the Pool Selection dialog box.
In the Pool Selection dialog box, assign the AuthenticationUI-Pool Pool.
Click Done.
Add Monitors.
Monitors are required for the load balancer to detect the backend server failures.
Configure the load balancer for persistence.
To verify that the Distributed Authentication User Interface load balancer is configured properly, access http://LoadBalancer-4.example.com:90/ from a web browser.
If the browser successfully renders the default Web Server document root page, the load balancer has been configured properly.
Modify AMconfig.properties on both Distributed Authentication User Interface host machines.
Log in as a root user to the AuthenticationUI–1 host machine.
Change to the classes directory.
# cd /opt/SUNWwbsvr/https-AuthenticationUI-1.example.com/ web-app/AuthenticationUI-1.example.com/distAuth/WEB-INF/classes |
Make the following changes to AMconfig.properties.
Backup AMConfig.properties before you modify it.
Save the file and close it.
Restart the AuthenticationUI–1 host machine.
Log in as a root user to the AuthenticationUI–2 host machine.
Change to the classes directory.
# cd /opt/SUNWwbsvr/https-AuthenticationUI-2.example.com/ web-app/AuthenticationUI-2.example.com/distAuth/WEB-INF/classes |
Make the following changes to AMconfig.properties.
Backup AMConfig.properties before you modify it.
Save the file and close it.
Restart the AuthenticationUI–2 host machine.
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, from 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.
On the Create Certificate Request page, provide the following information:
LoadBalancer-4.example.com
Deployment
LoadBalancer-4.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 4 to ensure that a link between the Load Balancer 4 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, from a web browser.
Log in using 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 CA Root Certificate on the Distributed Authentication User Interface Load Balancer.
In the BIG-IP load balancer console, click Proxies.
Click the Cert-Admin tab.
The key LoadBalancer-4.example.com is in the Key List. This was generated in To Request a Secure Sockets Layer Certificate for the Distributed Authentication User Interface Load Balancer.
In the Certificate ID column, click the Install button for LoadBalancer-4.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-4.example.com page, click Return to Certificate Administration Information.
Verify that the Certificate ID indicates LoadBalancer-4.example.com on the SSL Certificate Administration page.
Log out of the load balancer console.
Secure Socket Layer (SSL) termination at Load Balancer 4 increases performance on the Access Manager level, and simplifies SSL certificate management. For example, because Load Balancer 4 sends unencrypted data internally neither the Access Manager server nor the Distributed Authentication User Interface has to perform decryption, and the burden on its processor is relieved. Clients send SSL-encrypted data to Load Balancer 4 which, in turn, decrypts the data and sends the unencrypted data to the appropriate Distributed Authentication User Interface. Load Balancer 4 also encrypts responses from the Distributed Authentication User Interface, 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.
Load Balancer 4 can intelligently load-balance a request based on unencrypted cookies. This would not be possible with SSL-encrypted cookies because Load Balancer 4 cannot read SSL-encrypted cookies.
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 using the following information:
username
password
Click Configure your BIG-IP using the Configuration Utility.
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.
The IP address of Load Balancer 4, the Distributed Authentication User Interface load balancer.
9443
The secure port number
The IP address of Load Balancer 4, the Distributed Authentication User Interface load balancer.
90
The non-secure port number
Choose Local Virtual Server.
Choose LoadBalancer-4.example.com.
Choose LoadBalancer-4.example.com.
Check this checkbox.
Click Next.
In the Rewrite Redirects field, choose All.
Click Done.
The new proxy server is now added to the Proxy Server list.
Log out of the load balancer console.
Access https://LoadBalancer-4.example.com:9443/distAuth/UI/Login?goto= https://LoadBalancer-3.example.com:9443 from a web browser.
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.
Log in to the Access Manager console as the administrator.
amadmin
4m4dmin1
If you can successfully log in to Access Manager, the SSL certificate is installed and the proxy service is configured properly.
Log out of Access Manager, and close the browser.
Each Protected Resource host machine will have two installed web containers (one Sun Java™ System Web Server and one BEA WebLogic Server application server) and an appropriate policy agent for each (a web policy agent and a J2EE policy agent, respectively). The policy agents are configured to access Load Balancer 3. This chapter contains the following tasks:
We will install Sun Java™ System Web Server, BEA WebLogic Server, a web policy agent, and a J2EE policy agent on the ProtectedResource–1 host machine. The policy agents are configured to access Load Balancer 3 as illustrated in the following figure.
Use the following list of procedures as a checklist for configuring the ProtectedResource–1 host machine.
9.1.1 Installing Web Container 1 and Web Policy Agent 1 on Protected Resource 1
9.1.4 Configuring the J2EE Policy Agent 1 to Communicate Over SSL
Install Sun Java System Web Server and a web policy agent on the ProtectedResource–1 host machine as well as supporting configurations. Use the following list of procedures as a checklist.
To Install Sun Java System Web Server as Web Container 1 on Protected Resource 1
To Install and Configure Web Policy Agent 1 on Protected Resource 1
To Import the Certificate Authority Root Certificate into the Web Server 1 Keystore
To Configure Policy for Web Policy Agent 1 on Protected Resource 1
Create an agent profile in Access Manager to store authentication and configuration information that will be used by the policy agent to authenticate itself to Access Manager. Creating an agent profile also creates a custom user. The policy agent will, by default, use the account with the user identifier UrlAccessAgent to authenticate to Access Manager.
Creating an agent profile is not a requirement for web policy agents. You can use the agent's default values and not change the user name; however, in certain cases, you might want to change these default values. For example, if you want to audit the interactions between multiple agents and Access Manager, you want be able to distinguish one agent from another. This would not be possible if all the agents used the same default agent user account. For more information, see the Sun Java System Access Manager Policy Agent 2.2 User’s Guide.
Access http://AccessManager-1.example.com:1080/amserver/UI/Login from 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.
Click the Subjects tab.
Click the Agents tab.
Click New to create a new agent profile.
On the resulting page, enter the following and click OK.
webagent-1
web4gent1
web4gent1
Choose Active.
The new agent webagent-1 is displayed in the list of agent users.
Log out of the console.
Download the Sun Java System Web Server bits and install the software on the ProtectedResource–1 host machine.
As a root user, log into the ProtectedResource–1 host machine.
Install required patches if necessary.
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. In this case, the Release Notes indicate that based on the hardware and operating system being used, patch 117461–08 is required.
Run patchadd to see if the patch is installed.
# patchadd -p | grep 117461–08 |
No results are returned which indicates that the patch is not yet installed on the system.
Make a directory for downloading the patch you need and change into it.
# mkdir /export/patches # cd /export/patches |
Download the patches.
You can search for patches directly at http://sunsolve.sun.com. Navigate to the PatchFinder page, enter the patch number, click Find Patch, and download the appropriate patch.
Signed patches are downloaded as JAR files. Unsigned patches are downloaded as ZIP files.
Unzip the patch file.
# unzip 117461–08.zip |
Run patchadd to install the patches.
# patchadd /export/patches/117461–08 |
After installation is complete, run patchadd to verify that the patch was added successfully.
# patchadd -p | grep 117461–08 |
In this example, a series of patch numbers are displayed, and the patch 117461–08 is present.
Create a directory into which you can download the Web Server bits 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. In this example, the software was downloaded to the /export/WS7 directory.
# ls -al total 294548 drwxr-xr-x 2 root root 512 Aug 7 13:23 . drwxr-xr-x 3 root sys 512 Aug 7 13:16 .. -rw-r--r-- 1 root root 150719523 Aug 7 13:24 sjsws-7_0-solaris-sparc.tar.gz |
Unpack the Web Server bits.
# 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 root. |
|
|
Accept the default value. |
|
|
Enter web4dmin. |
|
|
Enter web4dmin. |
|
|
Accept the default value. |
|
|
Enter 1080. |
|
|
Accept the default value. |
|
|
Enter1. |
When installation is complete, the following message is displayed:
Installation Successful. |
Start the Web Server administration server.
# cd /opt/SUNWwbsvr/admin-server/bin # ./startserv server not running Sun Java System Web Server 7.0 B12/04/2006 10:15 info: CORE3016: daemon is running as super-user info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_09] from [Sun Microsystems Inc.] info: WEB0100: Loading web module in virtual server [admin-server] at [/admingui ] info: WEB0100: Loading web module in virtual server [admin-server] at [/jmxconne ctor] info: HTTP3072: admin-ssl-port: https://protectedresource-1.example.com:8989 ready to accept requests info: CORE3274: successful server startup |
Run netstat to verify that the port is open and listening.
# netstat -an | grep 8989 *.8989 *.* 0 0 49152 0 LISTEN |
(Optional) Login to the Web Server administration console at https://protectedresource-1.example.com:8989.
admin
web4dmin
You should see the Web Server console.
Log out of the Web Server console.
Start the Protected Resource 1 Web Server instance.
# cd /opt/SUNWwbsvr/https-ProtectedResource-1.example.com/bin # ./startserv server not running Sun Java System Web Server 7.0 B12/04/2006 10:15 info: CORE3016: daemon is running as super-user info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_09] from [Sun Microsystems Inc.] info: HTTP3072: http-listener-1: http://ProtectedResource-1.example.com:1080 ready to accept requests info: CORE3274: successful server startup |
Run netstat to verify that the port is open and listening.
# netstat -an | grep 1080 *.1080 *.* 0 0 49152 0 LISTEN |
(Optional) Access the Protected Resource 1 instance at https://ProtectedResource-1.example.com:1080 using a web browser.
You should see the default Web Server index page.
Log out of the ProtectedResource–1 host machine.
Due to a known problem with this version of the Web Policy Agent, you must start an X-display session on the server host using a program such as Reflections X or VNC, even though you use the command-line installer. For more information about this known problem, see On UNIX-based machines, all web agents require that the X11 DISPLAY variable be set properly. in Sun Java System Access Manager Policy Agent 2.2 Release Notes.
As a root user, log into the ProtectedResource–1 host machine.
Create a directory into which you can download the Web Server agent bits and change into it.
# mkdir /export/WebPA1 # cd /export/WebPA1 |
Download the web policy agent for Web Server from http://www.sun.com/download/.
# ls -al total 294548 drwxr-xr-x 2 root root 512 Aug 7 13:23 . drwxr-xr-x 3 root sys 512 Aug 7 13:16 .. -rw-r--r-- 1 root root 150719523 Aug 7 13:24 sjsws_v70_SunOS_agent.zip |
Unzip the downloaded file.
# unzip sjsws_v70_SunOS_agent.zip |
Change the permissions for the resulting agentadmin binary.
# cd /export/WebPA1/web_agents/sjsws_agent/bin # chmod +x agentadmin |
Verify that crypt_util has execute permission before running the installer.
# cd /export/WebPA1/web_agents/sjsws_agent/bin # chmod +x crypt_util |
Create a temporary file for the password that will be required later during agent installation.
# echo web4gent1 > /export/WebPA1/pwd.txt # cat /export/WebPA1/pwd.txt |
Run the agent installer.
# ./agentadmin --install |
When prompted, do the following.
|
Type yes and press Enter. |
|
| ||
|
Type /opt/SUNWwbsvr/https-ProtectedResource-1.example.com/config and press Enter. |
|
|
Type LoadBalancer-3.example.com and press Enter. |
|
|
Type 9443 and press Enter. |
|
|
Type https and press Enter. |
|
|
Press Enter to accept the default /amserver. |
|
|
Type ProtectedResource-1.example.com and press Enter. |
|
|
Type 1080 and press Enter. |
|
|
Press Enter to accept the default http. |
|
|
Type webagent-1 and press Enter. |
|
|
Type /export/WebPA1/pwd.txt and press Enter. |
|
|
Type 1 and press Enter. |
|
|
Modify the AMAgent.properties file.
Backup AMAgent.properties before you modify it.
Change to the config directory.
# cd /export/WebPA1/web_agents/sjsws_agent/Agent_001/config |
Set the values of the following properties as shown.
com.sun.am.policy.am.login.url = https://LoadBalancer-3. example.com:9443/amserver/UI/Login?realm=users com.sun.am.load_balancer.enable = true
Save the file and close it.
Restart the Protected Resource 1 Web Server instance.
# cd /opt/SUNWwbsvr/https-ProtectedResource-1.example.com/bin # ./stopserv; ./startserv server has been shutdown Sun Java System Web Server 7.0 B12/04/2006 10:15 info: CORE3016: daemon is running as super-user info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_09] from [Sun Microsystems Inc.] info: HTTP3072: http-listener-1: http://ProtectedResource-1.example.com:1080 ready to accept requests |
Log out of the ProtectedResource–1 host machine.
The web policy agent on Protected Resource 1 connects to Access Manager through Load Balancer 3. The load balancer is SSL-enabled, so the agent must be able to trust the load balancer SSL certificate to establish the SSL connection. For this reason, import the root certificate of the Certificate Authority (CA) that issued the Load Balancer 3 SSL server certificate into the policy agent keystore.
Import the same CA root certificate used in To Import a Certificate Authority Root Certificate on the Access Manager Load Balancer.
As a root user, log into the ProtectedResource–1 host machine.
Copy the CA root certificate into a directory.
In this example, the file is /export/software/ca.cer.
Import the CA root certificate into the Java keystore.
# /opt/SUNWwbsvr/jdk/jre/bin/keytool -import -trustcacerts -alias OpenSSLTestCA -file /export/software/ca.cer -keystore /opt/SUNWwbsvr/jdk/jre/lib/security/cacerts -storepass changeit Owner: EMAILADDRESS=nobody@nowhere.com, CN=OpenSSLTestCA, OU=Sun, O=Sun,L=Santa Clara, ST=California C=US Issuer: EMAILADDRESS=nobody@nowhere.com, CN=OpenSSLTestCA, OU=Sun, O=Sun,L=Santa Clara, ST=California C=US Serial number: 97dba0aa26db6386 Valid from: Tue Apr 18 07:66:19 PDT 2006 until: Tue Jan 13 06:55:19 PST 2009 Certificate fingerprints: MD5: 9f:57:ED:B2:F2:88:B6:E8:0F:1E:08:72:CF:70:32:06 SHA1: 31:26:46:15:C5:12:5D:29:46:2A:60:A1:E5:9E:26:64:36:80:E4:70 Trust this certificate: [no] yes Certificate was added to keystore. |
Verify that the CA root certificate was imported.
# /opt/SUNWwbsvr/jdk/jre/bin/keytool -list -keystore /opt/SUNWwbsvr/jdk/jre/lib/security/cacerts -storepass changeit | grep -i open openssltestca, Sep 10, 2007, trustedCertEntry, |
Restart the Web Server 1 instance.
# cd /opt/SUNWwbsvr/https-ProtectedResource-1.example.com/bin # ./stopserv; ./startserv server has been shutdown Sun Java System Web Server 7.0 B12/04/2006 10:15 info: CORE3016: daemon is running as super-user info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_09] from [Sun Microsystems Inc.] info: HTTP3072: http-listener-1: http://ProtectedResource-1. example.com:1080 ready to accept requests info: CORE3274: successful server startup |
Log out of the ProtectedResource–1 host machine.
Use the Access Manager console to configure policy for Web Policy Agent 1. This policy will be used to verify that Web Policy Agent 1 is working properly.
You will modify this policy later when we add a load balancer in front of it.
Access http://AccessManager-1.example.com:1080/amserver/UI/Login from a web browser.
Log in to the Access Manager console as the administrator.
amadmin
4m4dmin1
Create a referral policy in the top-level realm.
Under the Access Control tab, click the top-level realm, example.
Click the Policies tab.
Click New Referral.
On the New Policy page, provide the following information.
Referral URL Policy for users realm
Mark the Yes checkbox.
On the same page, in the Rules section, click New.
On the resulting page, select URL Policy Agent (with resource name) as a Service Type and click Next.
Provide the following information on the resulting page:
URL Rule for ProtectedResource-1
http://ProtectedResource-1.example.com:1080/*
Click Finish.
Back on the New Policy page, under the Referrals section, click New.
Provide the following information on the New Referral — Sub Realm page.
Sub-Realm users
Type an asterisk (*), and click Search.
In the list, choose users.
Click Finish.
Back on the New Policy page, click OK.
Under the Policies tab for the example realm, you should see the policy named Referral URL Policy for users realm.
Create a policy in the users realm.
The users realm was previously created in 7.2 Creating and Configuring a Realm for Test Users.
Click the Access Control tab.
Under Realms, click users.
Click the Policies tab.
Click New Policy.
On the New Policy page, provide the following information:
URL Policy for ProtectedResource-1
Mark the Yes checkbox.
On the same page, in the Rules section, click New.
Select a Service Type for the rule and click Next.
URL Policy Agent (with resource name) is the only choice.
On the resulting page, provide the following information:
URL Rule for ProtectedResource-1
Click http://ProtectedResource-1.example.com:1080/*, listed in the Parent Resource Name list, to add it to the Resource Name field.
Mark this checkbox, and select Allow.
Mark this checkbox, and select Allow.
Click Finish.
Create a new subject in the users realm for testing.
On the New Policy page, in the Subjects section, click New.
Select Access Manager Identity Subject as the subject type and click Next.
Provide the following information on the resulting page.
Test Subject
Choose User and click Search. Two users are added to the Available list.
In the list, select Test User1 and click Add.
Click Finish.
Back on the New Policy page, click Create.
Under the Policies tab, you should see the policy named URL Policy for ProtectedResource-1.
Log out of the console.
Access http://ProtectedResource-1.example.com:1080 from a web browser.
Log in to Access Manager as testuser1.
testuser1
password
You should see the default index page for Web Server 1 as testuser1 was configured in the test policy to be allowed to access Protected Resource 1.
Log out and close the browser.
Once again, access http://ProtectedResource-1.example.com:1080 from a web browser.
If you are not redirected to the Access Manager login page for authentication, clear your browser's cache and cookies and try again.
Log in to Access Manager as testuser2.
testuser2
password
You should see the message, You're not authorized to view this page, (or Your client is not allowed to access the requested object) as testuser2 was not included in the test policy that allows access to Protected Resource 1.
You will download the BEA WebLogic Server bits and install this application server on the ProtectedResource–1 host machine. Additionally, you will download and install the appropriate J2EE policy agent, deploy the policy agent application, setup up an authentication provider, and modify the Bypass Principal List. All of these tasks must be completed before the agent can do its job. Use the following list of procedures as a checklist for installing Application Server 1 and the J2EE Policy Agent 1.
To Create Manager and Employee Groups Using Access Manager for J2EE Policy Agent Test
To Install BEA WebLogic Server as J2EE Container 1 on Protected Resource 1
To Configure BEA WebLogic Server as J2EE Container 1 on Protected Resource 1
This new agent profile will be used by J2EE Policy Agent 1 to authenticate to Access Manager.
Access http://LoadBalancer-3.example.com:7070/amserver/UI/Login, the Access Manage load balancer, from a web browser.
Log in to the Access Manager console as the administrator.
amadmin
4m4dmin1
On the Access Control tab, click the top-level realm, example.
Click the Subjects tab.
Click the Agents tab.
On the Agent page, click New.
On the New Agent page, provide the following information and click OK.
j2eeagent-1
j2ee4gent1
j2ee4gent1
Choose Active.
The new agent j2eeagent–1 is displayed in the list of Agent Users.
Log out of the Access Manager console.
As a root user, log into the ProtectedResource–1 host machine.
Create a directory into which you can download the J2EE policy agent bits and change into it.
# mkdir /export/J2EEPA1 # cd /export/J2EEPA1 |
Create a text file that contains the Agent Profile password.
The J2EE Policy Agent installer requires this file for installation.
# cat > agent.pwd j2ee4gent1 Hit Control D to terminate the command ^D |
Log out of the ProtectedResource–1 host machine.
A group represents a collection of users with a common function, feature, or interest. The groups created in this section will be used to test the policy agent after installation.
Access http://LoadBalancer-3.example.com:7070/amserver/UI/Login, the Access Manage load balancer, from a web browser.
Log in to the Access Manager console as the administrator.
amadmin
4m4dmin1
On the Access Control tab, click the users realm.
Click the Subjects tab.
Click the Groups tab.
Create a manager group for the Users realm.
On the Groups page, click New.
On the New Group page, enter Manager-Group as the ID and click OK.
The Manager-Group is displayed in the list of Groups.
Click Manager-Group in the list of Groups.
Copy the value of the Universal ID and save it to a text file.
You will need this value in To Configure Properties for the J2EE Policy Agent 1 Sample Application.
Click the Users tab.
You should see the users that were created in Chapter 7, Configuring an Access Manager Realm for User Authentication.
Select Test User1 from the list and click Add.
Click Save.
Click Back to Subjects.
Create an employee group for the Users realm.
On the Groups page, click New.
On the New Group page, enter Employee-Group as the ID and click OK.
The Employee-Group is displayed in the list of Groups.
Click Employee-Group in the list of Groups.
Copy the value of the Universal ID and save it to a text file.
You will need this value in To Configure Properties for the J2EE Policy Agent 1 Sample Application.
Click the Users tab.
You should see the users that were created in Chapter 7, Configuring an Access Manager Realm for User Authentication.
Select Test User2 from the list and click Add.
Click Save.
Click Back to Subjects.
Log out of the Access Manager console.
BEA WebLogic Server is the application server used as the J2EE container on Protected Resource 1. After installing the bits in this procedure, see To Configure BEA WebLogic Server as J2EE Container 1 on Protected Resource 1.
As a root user, log into the ProtectedResource–1 host machine.
Ensure that your system is properly patched.
Refer to the BEA web site to make sure that your system has the recommended patches.
Create a directory into which you can download the WebLogic Server bits and change into it.
# mkdir /export/BEAWL92 # cd /export/BEAWL92 |
Download the WebLogic Server bits from http://commerce.bea.com/.
For this deployment, we download the Solaris version.
# ls -al total 294548 drwxr-xr-x 2 root root 512 Aug 7 13:23 . drwxr-xr-x 3 root sys 512 Aug 7 13:16 .. -rw-r--r-- 1 root root 722048346 Aug 7 13:24 portal920_solaris32.bin |
Run the installer.
# ./portal920_solaris32.bin |
When prompted, do the following:
|
Select Yes and click Next. |
|
|
Type /usr/local/bea and click Next. |
|
|
Click Next. |
|
|
Click Next. |
|
|
Type /usr/local/bea/weblogic92 and click Next. |
|
|
Deselect Run Quickstart and click Done. |
Verify that the application was correctly installed.
# cd /usr/local/bea # ls -al total 34 drwxr-xr-x 6 root root 512 Sep 13 14:26 . drwxr-xr-x 3 root root 512 Sep 13 14:22 .. -rwxr-xr-x 1 root root 851 Sep 13 14:26 UpdateLicense.sh -rw-r--r-- 1 root root 14 Sep 13 14:26 beahomelist drwxr-xr-x 6 root root 512 Sep 13 14:26 jdk150_04 -rw-r--r-- 1 root root 7818 Sep 13 14:26 license.bea drwxr-xr-x 2 root root 512 Sep 13 14:26 logs -rw-r--r-- 1 root root 947 Sep 13 14:26 registry.xml drwxr-xr-x 3 root root 512 Sep 13 14:26 utils drwxr-xr-x 10 root root 512 Sep 13 14:26 weblogic92 |
After installing the bits, WebLogic Server must be configured.
This procedure assumes you have just completed To Install BEA WebLogic Server as J2EE Container 1 on Protected Resource 1.
Run the WebLogic Server configuration script.
# cd /usr/local/bea/weblogic92/common/bin # ./config.sh |
When prompted, do the following:
Start the WebLogic administration server.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-1 # ./startWebLogic.sh |
When prompted, type the following credentials.
weblogic
w3bl0g1c
Run the netstat command to verify that the port is open and listening.
# netstat -an | grep 7001 XXX.XX.XX.151.7001 *.* 0 0 49152 0 LISTEN XXX.X.X.1.7001 *.* 0 0 49152 0 LISTEN |
You can also access the administration console by pointing a web browser to http://protectedresource-1.example.com:7001/console.
Change to the AdminServer directory.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-1/servers/AdminServer |
Create a security directory and change into it.
# mkdir security # cd security |
Create a boot.properties file for the WebLogic Server administration server administrator credentials.
The administrative user and password are stored in boot.properties. Application Server 1 uses this information during startup. WebLogic Server encrypts the file, so there is no security risk even if you enter the user name and password in clear text.
# cat > boot.properties username=weblogic password=w3bl0g1c Hit Control D to terminate the command ^D |
Restart WebLogic to encrypt the username and password in boot.properties.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-1/bin # ./stopWebLogic.sh # ./startWebLogic.sh |
Start the managed servers.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-1/bin # ./startManagedWebLogic.sh ApplicationServer-1 t3://localhost:7001 |
You will be prompted for the administrative user credentials.
weblogic
w3bl0g1c
Change to the ApplicationServer-1 directory.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-1/ servers/ApplicationServer-1 |
Create a security directory and change into it.
# mkdir security # cd security |
Create a boot.properties file for the WebLogic Server managed server administrator credentials.
The administrative user and password are stored in boot.properties. The ApplicationServer–1 managed server uses this information during startup. WebLogic Server encrypts the file, so there is no security risk even if you enter the user name and password in clear text.
# cat > boot.properties username=weblogic password=w3bl0g1c Hit Control D to terminate the command ^D |
Restart the managed server.
# cd /usr/local/bea/user_projects/domains/ ProtectedResource-1/bin # ./stopManagedWebLogic.sh ApplicationServer-1 t3://localhost:7001 # ./startManagedWebLogic.sh ApplicationServer-1 t3://localhost:7001 |
Run the netstat command to verify that the port is open and listening.
# netstat -an | grep 1081 XXX.X.X.1.1081 *.* 0 0 49152 0 LISTEN XXX.XX.XX.151.1081 *.* 0 0 49152 0 LISTEN |
Access http://ProtectedResource-1.example.com:7001/console from a web browser.
Login to the BEA WebLogic Server as the administrator.
weblogic
w3bl0g1c
Click servers.
On the Summary of Servers page, verify that both AdminServer (admin) and ApplicationServer-1 are running and OK.
Log out of the console.
Log out of the ProtectedResource–1 host machine.
You must stop both the WebLogic Server 1 instance and the WebLogic Server 1 administration server before beginning the installation process.
As a root user, log into the ProtectedResource–1 host machine.
Stop the WebLogic Server 1 administration server and the WebLogic Server 1 instance.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-1/bin # ./stopManagedWebLogic.sh ApplicationServer-1 t3://localhost:7001 # ./stopWebLogic.sh |
Ensure that your system is properly patched.
Read the appropriate policy agent Release Notes for your web container to determine the latest patches you might need to install before beginning installation. In this case, no patch is required.
You can search for patches directly at http://sunsolve.sun.com. Navigate to the PatchFinder page, enter the patch number, click Find Patch, and download the appropriate patch.
Change into the J2EEPA1 directory.
# cd /export/J2EEPA1 |
Download the J2EE policy agent bits for WebLogic Server from http://www.sun.com/download/index.jsp.
# ls -al total 8692 drwxr-xr-x 2 root root 512 Sep 13 13:19 . drwxr-xr-x 5 root sys 512 Aug 13 17:08 .. -rw-r--r-- 1 root root 4433920 Sep 13 13:19 SJS_Weblogic_92_agent_2.2.tar |
Unpack the J2EE policy agent bits.
# /usr/sfw/bin/gtar -xvf /export/J2EEPA1/SJS_Weblogic_92_agent_2.2.tar |
Use the gtar command and not the tar command.
Run the J2EE policy agent installer.
# cd /export/J2EEPA1/j2ee_agents/am_wl92_agent/bin # ./agentadmin --install |
When prompted, provide the following information.
|
Press Enter to continue. Continue to press Enter until you reach the end of the License Agreement. |
|
|
Enter /usr/local/bea/user_projects/domains/ ProtectedResource-1/bin/ startwebLogic.sh |
|
|
Enter ApplicationServer-1 |
|
|
Enter LoadBalancer-3.example.com |
|
|
Enter 7070 |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Enter ProtectedResource-1.example.com |
|
|
Accept the default value. |
|
|
Accept false, the default value. |
|
|
Enter 1081 |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
j2eeagent-1 |
|
|
Enter /export/J2EEPA1/agent.pwd |
|
|
Accept the default value. |
|
|
Accept the default value. |
The installer runs and, when finished, creates a new file in the bin directory called setAgentEnv_ApplicationServer-1.sh.
Modify the startup script setDomainEnv.sh to reference setAgentEnv_ApplicationServer-1.sh.
Backup setDomainEnv.sh before you modify it.
Change permissions for setAgentEnv_ApplicationServer-1.sh.
# chmod 755 setAgentEnv_ApplicationServer-1.sh |
Start the WebLogic Server administration server.
# ./startWebLogic.sh & |
Watch for startup errors.
The agent application is a housekeeping application bundled with the agent binaries and used by the agent for notifications and other internal functionality. In order for the agent to function correctly, this application must be deployed on the agent-protected deployment container instance using the same URI that was supplied during the agent installation process. For example, during the installation process, if you entered /agentapp as the deployment URI for the agent application, use that same context path in the deployment container.
Access http://ProtectedResource-1.example.com:7001/console from a web browser.
Log in to the WebLogic Server console as the administrator.
weblogic
w3bl0g1c
Under Domain Structure, click Deployments.
On the Summary of Deployments page, in the Change Center, click Lock & Edit.
Under Deployments, click Install.
On the Install Application Assistant page, click the protectedresource-1.example.com link.
In the field named Location: protectedresource-1.example.com, click the root directory.
Navigate to /export/J2EEPA1/j2ee_agents/am_wl92_agent/etc, the application directory.
Select agentapp.war and click Next.
In the Install Application Assistant page, choose Install this deployment as an application and click Next.
In the list of Servers, mark the checkbox for ApplicationServer-1 and click Next.
In the Optional Settings page, click Next.
Click Finish.
On the Settings for agentapp page, click Save.
In the Change Center, click Activate Changes.
This procedure assumes that you have just completed To Deploy the J2EE Policy Agent 1 Application.
In the WebLogic Server console, on the Settings for agentapp page, click Deployments.
On the Summary of Deployments page, mark the agentapp checkbox and click Start > Servicing all requests.
On the Start Application Assistant page, click Yes.
You may encounter a JavaScriptTM error as the agent application will not start until you start the WebLogic Server instance. In this case start the ApplicationServer-1 and perform the steps again.
This procedure assumes that you have just completed To Start the J2EE Policy Agent 1 Application.
In the WebLogic Server console, on the Summary of Deployments page, under Domain Structure, click Security Realms.
On the Summary of Security Realms page, click Lock & Edit.
Click the myrealm link.
On the Settings for myrealm page, click the Providers tab.
Under Authentication Providers, click New.
On the Create a New Authentication Provider page, provide the following information and click OK.
Agent-1
Select AgentAuthenticator from the drop down list.
Agent-1 is now included in the list of Authentication Providers.
In the list of Authentication Providers, click Agent-1.
In the Settings for Authentication Providers page, verify that the Control Flag is set to OPTIONAL.
In the navigation tree near the top of the page, click Providers.
In the list of Authentication Providers, click DefaultAuthenticator.
In the Settings for DefaultAuthenticator page, set the Control Flag to OPTIONAL and click Save.
In the navigation tree near the top of the page, click Providers again.
In the Change Center, click Activate Changes.
If indicated by the console, restart the servers.
Log out of the WebLogic Server console.
As a root user, log into the ProtectedResource–1 host machine.
Restart the administration server and the managed instance.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-1/bin # ./stopManagedWebLogic.sh ApplicationServer-1 t3://localhost:7001 # ./stopWebLogic.sh # ./startWebLogic.sh # ./startManagedWebLogic.sh ApplicationServer-1 t3://localhost:7001 |
Log out of the ProtectedResource–1 host machine.
As a root user, log into the ProtectedResource–1 host machine.
Change to the directory that contains the AMAgent.properties file.
# cd /export/J2EEPA1/j2ee_agents/am_wl92_agent/agent_001/config |
Backup AMAgent.properties before you modify it.
Make the following modifications to AMAgent.properties.
Set the following property.
com.sun.identity.agents.config.bypass.principal[0] = weblogic
This ensures that the WebLogic administrator will be authenticated against WebLogic itself and not Access Manager.
At end of the file, insert the following new property.
com.sun.identity.session.resetLBCookie=true
You must add this property if session failover has been configured for Access Manager. If session failover is not configured and this property is added, it could negatively impact performance. If session failover is enabled for Access Manager and this property is not added, the session failover functionality will work properly but, the stickiness to the Access Manager server will not be maintained after failover occurs. This property is not required for web policy agents.
This property must be also be added to the Access Manager file, AMConfig.properties if added here.
Save and close the file.
Log out of the ProtectedResource–1 host machine.
The BEA Policy Agent comes with a sample application created to help you test policies. For more information, see the file readme.txt in the /export/J2EEPA1/j2ee_agents/am_wl92_agent/sampleapp directory.
Use the following list of procedures as a checklist for setting up a test for the J2EE Policy Agent 1.
To Create a Test Referral Policy in the Access Manager Root Realm
To Configure Properties for the J2EE Policy Agent 1 Sample Application
Access Application Server 1 at http://ProtectedResource-1.example.com:7001/console.
Log in to the WebLogic Server console as the administrator.
weblogic
w3bl0g1c
On the Summary of Deployments page, click Lock & Edit.
Under Domain Structure, click Deployments.
Under Deployments, click Install.
On the Install Application Assistant page, click the protectedresource-1.example.com link.
In the list for Location: protectedresource-1.example.com, click the root directory.
Navigate to the application directory (/export/J2EEPA1/j2ee_agents/am_wl9_agent/sampleapp/dist), select agentsample and click Next.
In the Install Application Assistant page, choose Install this deployment as an application and click Next.
In the list of Servers, mark the checkbox for ApplicationServer-1 and click Next.
On the Optional Settings page, click Next to accept the default settings.
On the Review Your Choices page, click Finish.
The Target Summary section indicates that the module agentsample will be installed on the target ApplicationServer-1.
On the Settings for agentsample page, click Save.
On the Settings for agentsample page, click Activate Changes.
Under Domain Structure, click Deployments.
In the Deployments list, mark the checkbox for agentsample and click Start > Servicing All Requests.
On the Start Application Assistant page, click Yes.
The state of the deployment changes from Prepared to Active.
Log out of the Application Server 1 console.
Access http://LoadBalancer-3.example.com:7070/amserver/UI/Login, the Access Manage load balancer, from a web browser.
Log in to the Access Manager console as the administrator.
amadmin
4m4dmin1
Under the Access Control tab, click the example realm link.
Click the Policies tab.
Under Policies, click the Referral URL Policy for users realm link.
On the Edit Policy page, under Rules, click New.
On the resulting page, select URL Policy Agent (with resource name) and click Next.
On the resulting page, provide the following information and click Finish.
URL Policy for ApplicationServer-1
http://protectedresource-1.example.com:1081/agentsample/*
Make sure the hostname is typed in lowercase.
On the resulting page, click Save.
This procedure assumes you have just completed To Create a Test Referral Policy in the Access Manager Root Realm.
In the Access Manager console, under the Access Control tab, click the users realm link.
Click the Policies tab.
Under Policies, click New Policy.
In the Name field, enter URL Policy for ApplicationServer-1.
Under Rules, click New.
On the resulting page, make sure the default URL Policy Agent (with resource name) is selected and click Next.
On the resulting page, provide the following information and click Finish.
agentsample
From the list, select http://protectedresource-1.example.com:1081/agentsample/*
The value of this property is populated when you select the Parent Resource Name. It should read http://protectedresource-1.example.com:1081/agentsample/*.
Mark this check box and verify that Allow is selected.
Mark this check box and verify that Allow is selected.
The rule agentsample is now added to the list of Rules.
Under Subjects, click New.
On the resulting page, select Access Manager Identity Subject and click Next.
On the resulting page, provide the following information and click Search.
agentsampleGroup
Select Group.
Manager-Group and Employee-Group are displayed in the Available list.
Select Manager-Group and Employee-Group and click Add.
The groups are now displayed in the Selected list.
Click Finish.
Click OK.
The new policy subject is included in the list of Policies.
Log out of the Access Manager console.
Modify AMAgent.properties.
Log in as a root user to the ProtectedResource–1 host machine.
Change to the config directory.
# cd /export/J2EEPA1/j2ee_agents/am_wl92_agent/agent_001/config |
Backup AMAgent.properties before you modify it.
Set the following properties in AMAgent.properties.
com.sun.identity.agents.config.notenforced.uri[0] = /agentsample/public/* com.sun.identity.agents.config.notenforced.uri[1] = /agentsample/images/* com.sun.identity.agents.config.notenforced.uri[2] = /agentsample/styles/* com.sun.identity.agents.config.notenforced.uri[3] = /agentsample/index.html com.sun.identity.agents.config.notenforced.uri[4] = /agentsample com.sun.identity.agents.config.access.denied.uri = /agentsample/authentication/accessdenied.html com.sun.identity.agents.config.login.form[0] = /agentsample/authentication/login.html com.sun.identity.agents.config.login.url[0] = http://LoadBalancer-3.example.com:7070/ amserver/UI/Login?realm=users com.sun.identity.agents.config.privileged.attribute. type[0] = group com.sun.identity.agents.config.privileged.attribute. tolowercase[group] = false |
Set these remaining properties as follows.
This is specific to this deployment example. For more information see The agentadmin -getUuid command fails for amadmin user on Access Manager 7 with various agents (6452713) in Sun Java System Access Manager Policy Agent 2.2 Release Notes.
Retrieve the Universal IDs.
They were saved in To Create Manager and Employee Groups Using Access Manager for J2EE Policy Agent Test.
Convert all uppercase to lowercase and append a back slash (\) in front of each equal sign (=).
Set the properties.
com.sun.identity.agents.config.privileged.attribute. mapping[id\=manager-group,ou\=group,o\=users,ou\=services, dc\=example,dc\=com] = am_manager_role com.sun.identity.agents.config.privileged.attribute. mapping[id\=employee-group,ou\=group,o\=users,ou\=services, dc\=example,dc\=com] = am_employee_role |
Save AMAgent.properties and close it.
Restart the Application Server 1 administration server and managed instance.
Change to the bin directory.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-1/bin |
Stop the managed instance.
# ./stopManagedWebLogic.sh ApplicationsServer-1 t3://localhost:7001 |
Stop the administration server.
# ./stopWebLogic.sh |
Start the administration server.
# ./startWebLogic.sh & |
Start the managed instance.
# ./startManagedWebLogic.sh ApplicationServer-1 t3://localhost:7001 & |
Log out of the ProtectedResource-1 host machine.
Use these steps to access the agent sample application and test policies against it.
Access http://protectedresource-1.example.com:1081/agentsample/index.html, the sample application URL, from a web browser.
The Sample Application welcome page is displayed.
Click the J2EE Declarative Security link.
On the resulting page, click Invoke the Protected Servlet.
You are redirected to the Access Manager login page.
Log in to the Access Manager console as testuser1.
testuser1
password
If you can successfully log in as testuser1 and the J2EE Policy Agent Sample Application page is displayed, the first part of the test has succeeded and authentication is working as expected.
Click the J2EE Declarative Security link again.
On the resulting page, click Invoke the Protected Servlet.
If the Success Invocation message is displayed, the second part of the test has succeeded as the sample policy for the manager role has been enforced as expected.
Click the J2EE Declarative Security link to return.
On the resulting page, click Invoke the Protected EJB via an Unprotected Servlet.
If the Failed Invocation message is displayed, the third part of the test has succeeded as the sample policy for the employee role has been enforced as expected.
Log out and close the browser.
In a new browser session, access http://protectedresource-1.example.com:1081/agentsample/index.html, the sample application URL, again.
The Sample Application welcome page is displayed.
Click the J2EE Declarative Security link.
On the resulting page, click Invoke the Protected EJB via an Unprotected Servlet.
You are redirected to the Access Manager login page.
Log in to the Access Manager console as testuser2.
testuser2
password
The Failed Invocation message is displayed. This is a known issue.
Click the J2EE Declarative Security link.
On the resulting page, click Invoke the Protected EJB via an Unprotected.
The Successful Invocation message is displayed as the sample policy for the employee role has been enforced as expected.
Click the J2EE Declarative Security link to return.
On the resulting page, click Invoke the Protected Servlet.
If the Access to Requested Resource Denied message is displayed, this part of the test has succeeded as the sample policy for the manager role has been enforced as expected.
Log out and close the browser.
Configure the J2EE policy agent to point to the secure port of the Access Manager Load Balancer 3. Use the following list of procedures as a checklist for your configurations.
To Import the Certificate Authority Root Certificate into the Application Server 1 Keystore
To Configure the J2EE Policy Agent 1 to Access the Distributed Authentication User Interface
Log in as a root user to the ProtectedResource–1 host machine.
Change to the directory that contains the AMAgent.properties file.
# cd /export/J2EEPA1/j2ee_agents/am_wl92_agent/agent_001/config |
Backup AMAgent.properties before you modify it.
Modify these properties in AMAgent.properties as follows.
com.sun.identity.agents.config.login.url[0] = https://LoadBalancer-3.example.com:9443/amserver/UI/Login?realm=users com.sun.identity.agents.config.cdsso.cdcservlet.url[0] = https://LoadBalancer-3.example.com:9443/amserver/cdcservlet com.sun.identity.agents.config.cdsso.trusted.id.provider[0] = https://LoadBalancer-3.example.com:9443/amserver/cdcservlet com.iplanet.am.naming.url= https://LoadBalancer-3.example.com:9443/amserver/namingservice com.iplanet.am.server.protocol=https com.iplanet.am.server.port=9443 |
Save AMAgent.properties and close the file.
The Certificate Authority (CA) root certificate enables the J2EE policy agent to trust the certificate from the Access Manager Load Balancer 3, and to establish trust with the certificate chain that is formed from the CA to the certificate. Import the same CA root certificate used in To Import a Certificate Authority Root Certificate on the Access Manager Load Balancer.
This procedure assumes you have just completed To Configure the J2EE Policy Agent 1 for SSL Communication. In this example, the file is /export/software/ca.cer.
Change to the directory where the cacerts keystore is located.
# cd /usr/local/bea/jdk150_04/jre/lib/security |
Backup cacerts before you modify it.
Import the root certificate.
# /usr/local/bea/jdk150_04/bin/keytool -import -trustcacerts -alias OpenSSLTestCA -file /export/software/ca.cer -keystore /usr/local/bea/jdk150_04/jre/lib/security/cacerts -storepass changeit Owner: EMAILADDRESS=nobody@nowhere.com, CN=OpenSSLTestCA, OU=Sun, O=Sun, L=Santa Clara, ST=California, C=US Issuer: EMAILADDRESS=nobody@nowhere.com, CN=OpenSSLTestCA, OU=Sun, O=Sun, L=Santa Clara, ST=California, C=US Serial number: 97dba0aa26db6386 Valid from: Tue Apr 18 07:55:19 PDT 2006 until: Tue Jan 13 06:55:19 PST 2009 Certificate fingerprints: MD5: 9F:57:ED:B2:F2:88:B6:E8:0F:1E:08:72:CF:70:32:06 SHA1: 31:26:46:15:C5:12:5D:29:46:2A:60:A1:E5:9E:28:64:36:80:E4:70 Trust this certificate? [no]: yes Certificate was added to keystore |
Verify that the certificate was successfully added to the keystore.
# /usr/local/bea/jdk150_04/bin/keytool -list -keystore /usr/local/bea/jdk150_04/jre/lib/security/cacerts -storepass changeit | grep -i openssl openssltestca, Sept 19, 2007, trustedCertEntry, |
Restart the Application Server 1 administration server and managed instance.
Change to the bin directory.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-1/bin |
Stop the managed instance.
# ./stopManagedWebLogic.sh ApplicationsServer-1 t3://localhost:7001 |
Stop the administration server.
# ./stopWebLogic.sh |
Start the administration server.
# ./startWebLogic.sh & |
Start the managed instance.
# ./startManagedWebLogic.sh ApplicationServer-1 t3://localhost:7001 & |
Log out of the ProtectedResource–1 host machine.
Use these steps to access the agent sample application and test the policies.
Access http://ProtectedResource-1.example.com:1081/agentsample/index.html, the sample application URL, from a web browser.
The Sample Application welcome page is displayed.
Click the J2EE Declarative Security link.
On the resulting page, click Invoke the Protected Servlet.
You are redirected to the Access Manager login page.
Log in to the Access Manager console as testuser1.
testuser1
password
If you can successfully log in as testuser1 and the J2EE Policy Agent Sample Application page is displayed, this first part of the test has succeeded and authentication is working as expected.
Click the J2EE Declarative Security link to go back.
On the resulting page, click Invoke the Protected Servlet.
If the Success Invocation message is displayed, this second part of the test has succeeded as the sample policy for the manager role has been enforced as expected.
Click the J2EE Declarative Security link to go back.
On the resulting page, click Invoke the Protected EJB via an Unprotected Servlet.
If the Failed Invocation message is displayed, this third part of the test succeeded as the sample policy for the employee role has been enforced as expected.
Log out and close the browser.
In a new browser session, go to http://ProtectedResource-1.example.com:1081/agentsample/index.html, the sample application URL.
You are redirected to the Access Manager login page.
Log in to the Access Manager console as testuser2.
testuser2
password
The Failed Invocation message is displayed. This is a known issue.
Click the J2EE Declarative Security link.
On the resulting page, click Invoke the Protected EJB via an Unprotected Servlet.
The Successful Invocation message is displayed. The sample policy for the employee role has been enforced as expected.
Click the J2EE Declarative Security link to go back.
On the resulting page, click Invoke the Protected Servlet.
If the Access to Requested Resource Denied message is displayed, this part of the test is successful as the sample policy for the manager role has been enforced as expected.
Log out and close the browser.
Log in as a root user to the ProtectedResource–1 host machine.
Change to the directory that contains the AMAgent.properties file.
# cd /export/J2EEPA1/j2ee_agents/am_wl92_agent/agent_001/config |
Backup AMAgent.properties before you modify it.
Set the following properties in AMAgent.properties.
com.sun.identity.agents.config.login.url[0] = https://LoadBalancer-4.example.com:9443/distAuth/UI/Login?realm=users |
Save AMAgent.properties and close it.
Restart the Application Server 1 managed instance.
Log out of the ProtectedResource–1 host machine.
Verify that the agent is configured properly.
Access http://protectedresource-1.example.com:1081/agentsample/index.html, the sample application URL, from a web browser.
The Sample Application Welcome page is displayed.
Click the J2EE Declarative Security link.
On the resulting page, click Invoke the Protected Servlet.
You are redirected to the Distributed Authentication User Interface at https://loadbalancer-4.example.com:9443/distAuth/UI/Login.
(Optional) Double-click the gold lock in the lower left corner of the browser.
In the Properties page, you see the certificate for LoadBalancer–4.example.com.
Log in to the Access Manager console as testuser1.
testuser1
password
If you can successfully log in as testuser1 and the J2EE Policy Agent Sample Application page is displayed, user authentication worked through the Distributed Authentication User Interface and the agent is configured properly.
Log out of the console.
We will install Sun Java™ System Web Server, BEA WebLogic Server, a web policy agent, and a J2EE policy agent on the ProtectedResource–2 host machine. The policy agents are configured to access Load Balancer 3 as illustrated in the following figure.
Use the following list of procedures as a checklist for configuring Protected Resource 2.
9.2.1 Installing Web Container 2 and Web Policy Agent 2 on Protected Resource 2
9.2.4 Configuring the J2EE Policy Agent 2 to Communicate Over SSL
In this section, you install Sun Java System Web Server and a web policy agent on the ProtectedResource–2 host machine. Use the following list of procedures as a checklist.
To Install Sun Java System Web Server as Web Container 2 on Protected Resource 2
To Install and Configure Web Policy Agent 2 on Protected Resource 2
To Import the Certificate Authority Root Certificate into the Web Server 2 Keystore
To Configure Policy for Web Policy Agent 2 on Protected Resource 2
You create an agent profile in Access Manager to store authentication and configuration information that will be used by the policy agent to authenticate itself to Access Manager. Creating an agent profile also creates a custom user. The policy agent will, by default, use the account with the user identifier UrlAccessAgent to authenticate to Access Manager.
Creating an agent profile is not a requirement for web policy agents. You can use the agent's default values and not change the user name; however, in certain cases, you might want to change these default values. For example, if you want to audit the interactions between multiple agents and the Access Manager server, you want be able to distinguish one agent from another. This would not be possible if all the agents used the same default agent user account. For more information, see the Sun Java System Access Manager Policy Agent 2.2 User’s Guide.
Access http://AccessManager-1.example.com:1080/amserver/UI/Login from 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.
Click the Subjects tab.
Click the Agents tab.
Click New to create a new agent profile.
On the resulting page, enter the following and click OK.
webagent-2
web4gent2
web4gent2
Choose Active.
The new agent webagent-2 is displayed in the list of agent users.
Log out of the console.
Download the Sun Java System Web Server bits and install the software on the ProtectedResource–2 host machine.
As a root user, log into the ProtectedResource–2 host machine.
Install required patches if necessary.
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. In this case, the Release Notes indicate that based on the hardware and operating system being used, patch 117461–08 is required.
Run patchadd to see if the patch is installed.
# patchadd -p | grep 117461–08 |
No results are returned which indicates that the patch is not yet installed on the system.
Make a directory for downloading the patch you need and change into it.
# mkdir /export/patches # cd /export/patches |
Download the patches.
You can search for patches directly at http://sunsolve.sun.com. Navigate to the PatchFinder page, enter the patch number, click Find Patch, and download the appropriate patch.
Signed patches are downloaded as JAR files. Unsigned patches are downloaded as ZIP files.
Unzip the patch file.
# unzip 117461–08.zip |
Run patchadd to install the patches.
# patchadd /export/patches/117461–08 |
After installation is complete, run patchadd to verify that the patch was added successfully.
# patchadd -p | grep 117461–08 |
In this example, a series of patch numbers are displayed, and the patch 117461–08 is present.
Create a directory into which you can download the Web Server bits 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. In this example, the software was downloaded to the /export/ws7 directory.
# ls -al total 294548 drwxr-xr-x 2 root root 512 Aug 7 13:23 . drwxr-xr-x 3 root sys 512 Aug 7 13:16 .. -rw-r--r-- 1 root root 150719523 Aug 7 13:24 sjsws-7_0-solaris-sparc.tar.gz |
Unpack the Web Server bits.
# 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 root. |
|
|
Accept the default value. |
|
|
Enter web4dmin. |
|
|
Enter web4dmin. |
|
|
Accept the default value. |
|
|
Enter 1080. |
|
|
Accept the default value. |
|
|
Enter1. |
When installation is complete, the following message is displayed:
Installation Successful. |
Start the Web Server administration server.
# cd /opt/SUNWwbsvr/admin-server/bin # ./startserv server not running Sun Java System Web Server 7.0 B12/04/2006 10:15 info: CORE3016: daemon is running as super-user info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_09] from [Sun M icrosystems Inc.] info: WEB0100: Loading web module in virtual server [admin-server] at [/admingui ] info: WEB0100: Loading web module in virtual server [admin-server] at [/jmxconne ctor] info: HTTP3072: admin-ssl-port: https://protectedresource-2.example.com:8989 ready to accept requests info: CORE3274: successful server startup |
Run netstat to verify that the port is open and listening.
# netstat -an | grep 8989 *.8989 *.* 0 0 49152 0 LISTEN |
(Optional) Login to the Web Server administration console at https://protectedresource-2.example.com:8989.
admin
web4dmin
You should see the Web Server console.
(Optional) Log out of the Web Server console.
Start the Protected Resource 2 Web Server instance.
# cd /opt/SUNWwbsvr/https-ProtectedResource-2.example.com/bin # ./startserv server not running Sun Java System Web Server 7.0 B12/04/2006 10:15 info: CORE3016: daemon is running as super-user info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_09] from [Sun Microsystems Inc.] info: HTTP3072: http-listener-1: http://ProtectedResource-2.example.com:1080 ready to accept requests info: CORE3274: successful server startup |
Run netstat to verify that the port is open and listening.
# netstat -an | grep 1080 *.1080 *.* 0 0 49152 0 LISTEN |
Access the Protected Resource 2 instance at https://ProtectedResource-2.example.com:1080 using a web browser.
You should see the default Web Server index page.
Log out of the ProtectedResource–2 host machine.
Due to a known problem with this version of the Web Policy Agent, you must start an X-display session on the server host using a program such as Reflections X or VNC, even though you use the command-line installer. For more information about this known problem, see On UNIX-based machines, all web agents require that the X11 DISPLAY variable be set properly. in Sun Java System Access Manager Policy Agent 2.2 Release Notes.
As a root user, log into the ProtectedResource–2 host machine.
Ensure that your system is properly patched.
This should have been done in To Install Sun Java System Web Server as Web Container 2 on Protected Resource 2.
Create a directory into which you can download the Web Server agent bits and change into it.
# mkdir /export/WebPA2 # cd /export/WebPA2 |
Download the web policy agent for Web Server from http://www.sun.com/download/.
# ls -al total 294548 drwxr-xr-x 2 root root 512 Aug 7 13:23 . drwxr-xr-x 3 root sys 512 Aug 7 13:16 .. -rw-r--r-- 1 root root 150719523 Aug 7 13:24 sjsws_v70_SunOS_agent.zip |
Unzip the downloaded file.
# unzip sjsws_v70_SunOS_agent.zip |
Change the permissions for the resulting agentadmin binary.
# cd /export/WebPA2/web_agents/sjsws_agent/bin # chmod +x agentadmin |
Verify that crypt_util has execute permission before running the installer.
# cd /export/WebPA2/web_agents/sjsws_agent/bin # chmod +x crypt_util |
Create a temporary file for the password that will be required during agent installation.
# echo web4gent2 > /export/WebPA2/pwd.txt # cat /export/WebPA2/pwd.txt |
Run the agent installer.
# ./agentadmin --install |
When prompted, do the following.
|
Type yes and press Enter. |
|
| ||
|
Type /opt/SUNWwbsvr/https-ProtectedResource-2.example.com/config and press Enter. |
|
|
Type LoadBalancer-3.example.com and press Enter. |
|
|
Type 9443 and press Enter. |
|
|
Type https and press Enter. |
|
|
Press Enter to accept the default /amserver. |
|
|
Type ProtectedResource-2.example.com and press Enter. |
|
|
Type 1080 and press Enter. |
|
|
Press Enter to accept the default http. |
|
|
Type webagent-2 and press Enter. |
|
|
Type /export/WebPA2/pwd.txt and press Enter. |
|
|
Type 1 and press Enter. |
|
|
Modify the AMAgent.properties file.
Backup AMAgent.properties before you modify it.
Change to the config directory.
# cd /export/WebPA2/web_agents/sjsws_agent/Agent_001/config |
Set the values of the following properties as shown.
com.sun.am.policy.am.login.url = https://LoadBalancer-3. example.com:9443/amserver/UI/Login?realm=users com.sun.am.load_balancer.enable = true
Save the file and close it.
Restart the Protected Resource 2 Web Server instance.
# cd /opt/SUNWwbsvr/https-ProtectedResource-2.example.com/bin # ./stopserv; ./startserv server has been shutdown Sun Java System Web Server 7.0 B12/04/2006 10:15 info: CORE3016: daemon is running as super-user info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_09] from [Sun Microsystems Inc.] info: HTTP3072: http-listener-1: http://ProtectedResource-2.example.com:1080 ready to accept requests |
Log out of the ProtectedResource–2 host machine.
The web policy agent on Protected Resource 2 connects to Access Manager through Load Balancer 3. The load balancer is SSL-enabled, so the agent must be able to trust the load balancer SSL certificate to establish the SSL connection. For this reason, import the root certificate of the Certificate Authority (CA) that issued the Load Balancer 3 SSL server certificate into the policy agent keystore.
Import the same CA root certificate used in To Import a Certificate Authority Root Certificate on the Access Manager Load Balancer.
As a root user, log into the ProtectedResource–2 host machine.
Copy the CA root certificate into a directory.
In this example, the file is /export/software/ca.cer.
Import the CA root certificate into the Java keystore.
# /opt/SUNWwbsvr/jdk/jre/bin/keytool -import -trustcacerts -alias OpenSSLTestCA -file /export/software/ca.cer -keystore /opt/SUNWwbsvr/jdk/jre/lib/security/cacerts -storepass changeit Owner: EMAILADDRESS=nobody@nowhere.com, CN=OpenSSLTestCA, OU=Sun, O=Sun,L=Santa Clara, ST=California C=US Issuer: EMAILADDRESS=nobody@nowhere.com, CN=OpenSSLTestCA, OU=Sun, O=Sun,L=Santa Clara, ST=California C=US Serial number: 97dba0aa26db6386 Valid from: Tue Apr 18 07:66:19 PDT 2006 until: Tue Jan 13 06:55:19 PST 2009 Certificate fingerprints: MD5: 9f:57:ED:B2:F2:88:B6:E8:0F:1E:08:72:CF:70:32:06 SHA1: 31:26:46:15:C5:12:5D:29:46:2A:60:A1:E5:9E:26:64:36:80:E4:70 Trust this certificate: [no] yes Certificate was added to keystore. |
Verify that the CA root certificate was imported into the keystore.
# /opt/SUNWwbsvr/jdk/jre/bin/keytool -list -keystore /opt/SUNWwbsvr/jdk/jre/lib/security/cacerts -storepass changeit | grep -i open openssltestca, Sep 10, 2007, trustedCertEntry, |
Restart the Protected Resource 2 Web Server instance.
# cd /opt/SUNWwbsvr/https-ProtectedResource-2.example.com/bin # ./stopserv # ./startserv server has been shutdown Sun Java System Web Server 7.0 B12/04/2006 10:15 info: CORE3016: daemon is running as super-user info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_09] from [Sun Microsystems Inc.] info: HTTP3072: http-listener-1: http://ProtectedResource-2. example.com:1080 ready to accept requests info: CORE3274: successful server startup |
Log out of the ProtectedResource–2 host machine.
Use the Access Manager console to configure policy for Web Policy Agent 2. This policy will be used to verify that Web Policy Agent 2 is working properly. You will modify this policy later when we add a load balancer in front of it.
Access http://AccessManager-1.example.com:1080/amserver/UI/Login from a web browser.
Log in to the Access Manager console as the administrator.
amadmin
4m4dmin1
Create a referral policy in the top-level realm.
Under the Access Control tab, click the top-level realm, example.
Click the Policies tab.
Click Referral URL Policy for users realm.
On the same page, in the Rules section, click New.
On the resulting page, select URL Policy Agent (with resource name) as a Service Type and click Next.
Provide the following information on the resulting page.
URL Rule for ProtectedResource-2
http://ProtectedResource-2.example.com:1080/*
Click Finish.
Click Save.
On the Edit Policy page, click Back to Policies.
Under the Policies tab for the example realm, you should see the policy named Referral URL Policy for users realm with http://ProtectedResource-2.example.com:1080/* added in the list of protected resources.
Create a policy in the users realm.
The users realm was previously created in 7.2 Creating and Configuring a Realm for Test Users.
Click the Access Control tab.
Under Realms, click users.
Click the Policies tab.
Click New Policy.
On the New Policy page, provide the following information:
URL Policy for ProtectedResource-2
Mark the Yes checkbox.
On the same page, in the Rules section, click New.
Select a Service Type for the rule and click Next.
URL Policy Agent (with resource name) is the only choice.
On the resulting page, provide the following information:
URL Rule for ProtectedResource-2
Click http://ProtectedResource-2.example.com:1080/*, listed in the Parent Resource Name list, to add it to the Resource Name field.
Mark this checkbox, and select Allow.
Mark this checkbox, and select Allow.
Click Finish.
Create a new subject in the users realm for testing.
On the New Policy page, in the Subjects section, click New.
Select Access Manager Identity Subject as the subject type and click Next.
Provide the following information on the resulting page.
Test Subject
Choose User and click Search. Two users are added to the Available list.
In the list, select Test User1 and click Add.
Click Finish.
Back on the New Policy page, click Create.
Under the Policies tab, you should see the policy named URL Policy for ProtectedResource-2.
Log out of the console.
Access http://ProtectedResource-2.example.com:1080 from a web browser.
Log in to Access Manager as testuser1.
testuser1
password
You should see the default index page for Web Server 2 as testuser1 was configured in the test policy to be allowed to access Protected Resource 2.
Log out and close the browser.
Once again, access http://ProtectedResource-2.example.com:1080 from a web browser.
If you are not redirected to the Access Manager login page for authentication, clear your browser's cache and cookies and try again.
Log in to Access Manager as testuser2.
testuser2
password
You should see the message, You're not authorized to view this page, (or Your client is not allowed to access the requested object) as testuser2 was not included in the test policy that allows access to Protected Resource 2.
In this section, you will download the BEA WebLogic Server bits and install this application server on the ProtectedResource–2 host machine. Additionally, you will download and install the appropriate J2EE policy agent, deploy the policy agent application, setup up an authentication provider, and modify the Bypass Principal List. Use the following list of procedures as a checklist for installing Application Server 2 and the J2EE Policy Agent 2.
To Install BEA WebLogic Server as J2EE Container 2 on Protected Resource 2
To Configure BEA WebLogic Server as J2EE Container 2 on Protected Resource 2
BEA WebLogic Server is the application server used as the J2EE container on Protected Resource 2. After installing the bits in this procedure, see To Configure BEA WebLogic Server as J2EE Container 2 on Protected Resource 2.
As a root user, log into the ProtectedResource–2 host machine.
Ensure that your system is properly patched.
Refer to the BEA web site to make sure that your system has the recommended patches.
Create a directory into which you can download the WebLogic Server bits and change into it.
# mkdir /export/BEAWL92 # cd /export/BEAWL92 |
Download the WebLogic Server bits from http://commerce.bea.com/.
For this deployment, we download the Solaris version.
# ls -al total 294548 drwxr-xr-x 2 root root 512 Aug 7 13:23 . drwxr-xr-x 3 root sys 512 Aug 7 13:16 .. -rw-r--r-- 1 root root 722048346 Aug 7 13:24 portal920_solaris32.bin |
Run the installer.
# ./portal920_solaris32.bin |
When prompted, do the following:
|
Select Yes and click Next. |
|
|
Type /usr/local/bea and click Next. |
|
|
Click Next. |
|
|
Click Next. |
|
|
Type /usr/local/bea/weblogic92 and click Next. |
|
|
Deselect Run Quickstart and click Done. |
Verify that the application was correctly installed.
# cd /usr/local/bea # ls -al total 34 drwxr-xr-x 6 root root 512 Sep 13 14:26 . drwxr-xr-x 3 root root 512 Sep 13 14:22 .. -rwxr-xr-x 1 root root 851 Sep 13 14:26 UpdateLicense.sh -rw-r--r-- 1 root root 14 Sep 13 14:26 beahomelist drwxr-xr-x 6 root root 512 Sep 13 14:26 jdk150_04 -rw-r--r-- 1 root root 7818 Sep 13 14:26 license.bea drwxr-xr-x 2 root root 512 Sep 13 14:26 logs -rw-r--r-- 1 root root 947 Sep 13 14:26 registry.xml drwxr-xr-x 3 root root 512 Sep 13 14:26 utils drwxr-xr-x 10 root root 512 Sep 13 14:26 weblogic92 |
After installing the bits, WebLogic Server must be configured for use as the J2EE container on Protected Resource 2.
This procedure assumes you have just completed To Install BEA WebLogic Server as J2EE Container 2 on Protected Resource 2.
Run the WebLogic Server configuration script.
# cd /usr/local/bea/weblogic92/common/bin # ./config.sh |
When prompted, do the following:
|
Click Next. |
|
|
Click Next. |
|
|
Enter the following and click Next.
|
|
|
Click Next. |
|
|
Select yes and click Next. |
|
|
Accept the default values and click Next. |
|
|
Select Add, enter the following values, and click Next.
|
|
|
Accept the default values and click Next. |
|
|
Select the Unix Machine tab, then select Add, type ProtectedResource-2, and click Next. |
|
|
From the left panel select AdminServer ApplicationServer-2. From the right panel select ProtectedResource-2. Click --> and then click Next. |
|
|
Click Next. |
|
|
Add the following and click Create.
|
|
|
Click Done. |
Start the WebLogic administration server.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-2 # ./startWebLogic.sh |
When prompted, type the following credentials.
weblogic
w3bl0g1c
Run the netstat command to verify that the port is open and listening.
# netstat -an | grep 7001 XXX.XX.XX.151.7001 *.* 0 0 49152 0 LISTEN XXX.X.X.1.7001 *.* 0 0 49152 0 LISTEN |
You can also access the administration console by pointing a browser to http://protectedresource-2.example.com:7001/console.
Change to the AdminServer directory.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-2/servers/AdminServer |
Create a security directory and change into it.
# mkdir security # cd security |
Create a boot.properties file for the WebLogic Server administration server.
The administrative user and password are stored in boot.properties. Application Server 2 uses this information during startup. WebLogic Server encrypts the file, so there is no security risk even if you enter the user name and password in clear text.
# cat > boot.properties username=weblogic password=w3bl0g1c Hit Control D to terminate the command ^D |
Restart the WebLogic administration server to encrypt the username and password in boot.properties.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-2/bin # ./stopWebLogic.sh # ./startWebLogic.sh |
Start the ApplicationServer-2 managed instance.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-2/bin # ./startManagedWebLogic.sh ApplicationServer-2 t3://localhost:7001 |
You will be prompted for the following credentials.
weblogic
w3bl0g1c
Change to the ApplicationServer-2 directory.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-2/ servers/ApplicationServer-2 |
Create a security directory and change into it.
# mkdir security # cd security |
Create a boot.properties file for the ApplicationServer-2 managed instance.
The administrative user and password are stored in boot.properties. The WebLogic Server managed instance uses this information during startup. WebLogic Server encrypts the file, so there is no security risk even if you enter the user name and password in clear text.
# cat > boot.properties username=weblogic password=w3bl0g1c Hit Control D to terminate the command ^D |
Restart the managed server.
# cd /usr/local/bea/user_projects/domains/ ProtectedResource-2/bin # ./stopManagedWebLogic.sh ApplicationServer-2 t3://localhost:7001 # ./startManagedWebLogic.sh ApplicationServer-2 t3://localhost:7001 |
Run the netstat command to verify that the port is open and listening.
# netstat -an | grep 1081 XXX.X.X.1.1081 *.* 0 0 49152 0 LISTEN XXX.XX.XX.151.1081 *.* 0 0 49152 0 LISTEN |
Access http://ProtectedResource-2.example.com:7001/console from a web browser.
Login to the BEA WebLogic Server as the administrator.
weblogic
w3bl0g1c
Click servers.
On the Summary of Servers page, verify that both AdminServer (admin) and ApplicationServer-2 are running and OK.
Log out of the console.
Log out of the ProtectedResource–2 host machine.
This new agent profile will be used by J2EE Policy Agent 2 to authenticate to Access Manager.
Access http://LoadBalancer-3.example.com:7070/amserver/UI/Login, the Access Manage load balancer, from a web browser.
Log in to the Access Manager console as the administrator.
amadmin
4m4dmin1
On the Access Control tab, click the top-level realm, example.
Click the Subjects tab.
Click the Agents tab.
On the Agent page, click New.
On the New Agent page, provide the following information and click OK.
j2eeagent-2
j2ee4gent2
j2ee4gent2
Choose Active.
The new agent j2eeagent–2 is displayed in the list of Agent Users.
Log out of the Access Manager console.
As a root user, log into the ProtectedResource–2 host machine.
Create a directory into which you can download the J2EE policy agent bits and change into it.
# mkdir /export/J2EEPA2 # cd /export/J2EEPA2 |
Create a text file that contains the Agent Profile password.
The J2EE Policy Agent installer requires this file for installation.
# cat > agent.pwd j2ee4gent2 Hit Control D to terminate the command ^D |
Log out of the ProtectedResource–2 host machine.
You must stop both the WebLogic Server 2 managed instance and the WebLogic Server 2 administration server before beginning the installation process.
As a root user, log into the ProtectedResource–2 host machine.
Stop the WebLogic Server 2 administration server and the WebLogic Server 2 managed instance.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-2/bin # ./stopManagedWebLogic.sh ApplicationServer-2 t3://localhost:7001 # ./stopWebLogic.sh |
Ensure that your system is properly patched.
Read the appropriate policy agent Release Notes for your web container to determine the latest patches you might need to install before beginning installation. In this case, no patch is required.
You can search for patches directly at http://sunsolve.sun.com. Navigate to the PatchFinder page, enter the patch number, click Find Patch, and download the appropriate patch.
Change into the J2EEPA2 directory.
# cd /export/J2EEPA2 |
Download the J2EE policy agent bits for WebLogic Server from http://www.sun.com/download/index.jsp.
# ls -al total 8692 drwxr-xr-x 2 root root 512 Sep 13 13:19 . drwxr-xr-x 5 root sys 512 Aug 13 17:08 .. -rw-r--r-- 1 root root 4433920 Sep 13 13:19 SJS_Weblogic_92_agent_2.2.tar |
Unpack the J2EE policy agent bits.
# /usr/sfw/bin/gtar -xvf /export/J2EEPA2/SJS_Weblogic_92_agent_2.2.tar |
Use the gtar command and not the tar command.
Run the J2EE policy agent installer.
# cd /export/J2EEPA2/j2ee_agents/am_wl92_agent/bin # ./agentadmin --install |
When prompted, provide the following information.
|
Press Enter to continue. Continue to press Enter until you reach the end of the License Agreement. |
||
|
Enter .
|
||
|
Enter ApplicationServer-2. |
||
|
Enter LoadBalancer-3.example.com. |
||
|
Enter 7070. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
ProtectedResource-2.example.com |
||
|
Accept the default value. |
||
|
Accept false, the default value. |
||
|
Enter 1081. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
j2eeagent-2 |
||
|
Enter /export/J2EEPA2/agent.pwd. |
||
|
Accept the default value. |
||
|
Accept the default value. |
The installer runs and, when finished, creates a new file in the bin directory called setAgentEnv_ApplicationServer-2.sh.
Modify the startup script setDomainEnv.sh to reference setAgentEnv_ApplicationServer-2.sh.
Backup setDomainEnv.sh before you modify it.
Change permissions for setAgentEnv_ApplicationServer-2.sh.
# chmod 755 setAgentEnv_ApplicationServer-2.sh |
Start the WebLogic Server administration server.
# ./startWebLogic.sh & |
Watch for startup errors.
Log out of the ProtectedResource–2 host machine.
The agent application is a housekeeping application bundled with the agent binaries and used by the agent for notifications and other internal functionality. In order for the agent to function correctly, this application must be deployed on the agent-protected deployment container instance using the same URI that was supplied during the agent installation process. For example, during the installation process, if you entered /agentapp as the deployment URI for the agent application, use that same context path in the deployment container.
Access http://ProtectedResource-2.example.com:7001/console from a web browser.
Log in to the WebLogic Server console as the administrator.
weblogic
w3bl0g1c
Under Domain Structure, click Deployments.
On the Summary of Deployments page, in the Change Center, click Lock & Edit.
Under Deployments, click Install.
On the Install Application Assistant page, click the protectedresource-2.example.com link.
In the field named Location: protectedresource-2.example.com, click the root directory.
Navigate to /export/J2EEPA2/j2ee_agents/am_wl92_agent/etc, the application directory.
Select agentapp.war and click Next.
In the Install Application Assistant page, choose Install this deployment as an application and click Next.
In the list of Servers, mark the checkbox for ApplicationServer-2 and click Next.
In the Optional Settings page, click Next.
Click Finish.
On the Settings for agentapp page, click Save.
In the Change Center, click Activate Changes.
This procedure assumes that you have just completed To Deploy the J2EE Policy Agent 2 Application.
In the WebLogic Server console, on the Settings for agentapp page, click Deployments.
On the Summary of Deployments page, mark the agentapp checkbox and click Start > Servicing all requests.
On the Start Application Assistant page, click Yes.
You may encounter a JavaScript error as the agent application will not start until you start the WebLogic Server. In this case start the ApplicationServer-2 managed instance and perform the steps again.
This procedure assumes that you have just completed To Start the J2EE Policy Agent 2 Application.
In the WebLogic Server console, on the Summary of Deployments page, under Domain Structure, click Security Realms.
On the Summary of Security Realms page, click Lock & Edit.
Click the myrealm link.
On the Settings for myrealm page, click the Providers tab.
Under Authentication Providers, click New.
On the Create a New Authentication Provider page, provide the following information and click OK.
Agent-2
Select AgentAuthenticator from the drop down list.
Agent-2 is now included in the list of Authentication Providers.
In the list of Authentication Providers, click Agent-2.
In the Settings for Authentication Providers page, verify that the Control Flag is set to OPTIONAL.
In the navigation tree near the top of the page, click Providers.
In the list of Authentication Providers, click DefaultAuthenticator.
In the Settings for DefaultAuthenticator page, set the Control Flag to OPTIONAL and click Save.
In the navigation tree near the top of the page, click Providers again.
In the Change Center, click Activate Changes.
(Optional) If indicated by the console, restart the servers.
Log out of the WebLogic Server console.
As a root user, log into the ProtectedResource–2 host machine.
Restart the administration server and the managed instance.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-2/bin # ./stopManagedWebLogic.sh ApplicationServer-2 t3://localhost:7001 # ./stopWebLogic.sh # ./startWebLogic.sh # ./startManagedWebLogic.sh ApplicationServer-2 t3://localhost:7001 |
Log out of the ProtectedResource–2 host machine.
As a root user, log into the ProtectedResource–2 host machine.
Change to the directory that contains the AMAgent.properties file.
# cd /export/J2EEPA2/j2ee_agents/am_wl92_agent/agent_001/config |
Backup AMAgent.properties before you modify it.
Make the following modifications to AMAgent.properties.
Set the following property.
com.sun.identity.agents.config.bypass.principal[0] = weblogic
This ensures that the WebLogic administrator will be authenticated against WebLogic itself and not Access Manager.
At end of the file, insert the following new property.
com.sun.identity.session.resetLBCookie=true
You must add this property if session failover has been configured for Access Manager. If session failover is not configured and this property is added, it could negatively impact performance. If session failover is enabled for Access Manager and this property is not added, the session failover functionality will work properly but, the stickiness to the Access Manager server will not be maintained after failover occurs. This property is not required for web policy agents.
This property must be also be added to the Access Manager file, AMConfig.properties if added here.
Save and close the file.
Log out of the ProtectedResource–2 host machine.
Use the following list of procedures as a checklist for setting up a test for the J2EE Policy Agent 2.
To Create a Test Referral Policy in the Access Manager Root Realm
To Configure Properties for the J2EE Policy Agent 2 Sample Application
The BEA Policy Agent comes with a sample application created to help test policies. For more information, see the file readme.txt in the /export/J2EEPA2/j2ee_agents/am_wl92_agent/sampleapp directory.
Access http://ProtectedResource-2.example.com:7001/console from a web browser.
Log in to the WebLogic Server console as the administrator.
weblogic
w3bl0g1c
On the Summary of Deployments page, click Lock & Edit.
Under Domain Structure, click Deployments.
Under Deployments, click Install.
On the Install Application Assistant page, click the protectedresource-2.example.com link.
In the list for Location: protectedresource-2.example.com, click the root directory.
Navigate to the application directory (/export/J2EEPA2/j2ee_agents/am_wl9_agent/sampleapp/dist), select agentsample and click Next.
In the Install Application Assistant page, choose Install this deployment as an application and click Next.
In the list of Servers, mark the checkbox for ApplicationServer-2 and click Next.
On the Optional Settings page, click Next to accept the default settings.
On the Review Your Choices page, click Finish.
The Target Summary section indicates that the module agentsample will be installed on the target ApplicationServer-2.
On the Settings for agentsample page, click Save.
On the Settings for agentsample page, click Activate Changes.
Under Domain Structure, click Deployments.
In the Deployments list, mark the checkbox for agentsample and click Start > Servicing All Requests.
On the Start Application Assistant page, click Yes.
The state of the deployment changes from Prepared to Active.
Log out of the console.
Access http://LoadBalancer-3.example.com:7070/amserver/UI/Login, the Access Manager load balancer, from a web browser.
Log in to the Access Manager console as the administrator.
amadmin
4m4dmin1
Under the Access Control tab, click the example realm link.
Click the Policies tab.
Under Policies, click the Referral URL Policy for users realm link.
On the Edit Policy page, under Rules, click New.
On the resulting page, select URL Policy Agent (with resource name) and click Next.
On the resulting page, provide the following information and click Finish.
URL Policy for ApplicationServer-2
http://protectedresource-2.example.com:1081/agentsample/*
Make sure the hostname is typed in lowercase.
On the resulting page, click Save.
This procedure assumes you have just completed To Create a Test Referral Policy in the Access Manager Root Realm.
In the Access Manager console, under the Access Control tab, click the users realm link.
Click the Policies tab.
Under Policies, click New Policy.
In the Name field, enter URL Policy for ApplicationServer-2.
Under Rules, click New.
On the resulting page, make sure the default URL Policy Agent (with resource name) is selected and click Next.
On the resulting page, provide the following information and click Finish.
agentsample
From the list, select http://protectedresource-2.example.com:1081/agentsample/*
The value of this property is populated when you select the Parent Resource Name. It should read http://protectedresource-2.example.com:1081/agentsample/*.
Mark this check box and verify that Allow is selected.
Mark this check box and verify that Allow is selected.
The rule agentsample is now added to the list of Rules.
Under Subjects, click New.
On the resulting page, select Access Manager Identity Subject and click Next.
On the resulting page, provide the following information and click Search.
agentsampleGroup
Select Group.
Manager-Group and Employee-Group are displayed in the Available list.
Select Manager-Group and Employee-Group and click Add.
The groups are now displayed in the Selected list.
Click Finish.
Click OK.
The new policy subject is included in the list of Policies.
Log out of the Access Manager console.
Modify AMAgent.properties.
Log in as a root user to the ProtectedResource–2 host machine.
Change to the config directory.
# cd /export/J2EEPA2/j2ee_agents/am_wl92_agent/agent_001/config |
Backup AMAgent.properties before you modify it.
Modify these properties in AMAgent.properties as follows.
com.sun.identity.agents.config.notenforced.uri[0] = /agentsample/public/* com.sun.identity.agents.config.notenforced.uri[1] = /agentsample/images/* com.sun.identity.agents.config.notenforced.uri[2] = /agentsample/styles/* com.sun.identity.agents.config.notenforced.uri[3] = /agentsample/index.html com.sun.identity.agents.config.notenforced.uri[4] = /agentsample com.sun.identity.agents.config.access.denied.uri = /agentsample/authentication/accessdenied.html com.sun.identity.agents.config.login.form[0] = /agentsample/authentication/login.html com.sun.identity.agents.config.login.url[0] = http://LoadBalancer-3.example.com:7070/ amserver/UI/Login?realm=users com.sun.identity.agents.config.privileged.attribute. type[0] = group com.sun.identity.agents.config.privileged.attribute. tolowercase[group] = false |
Set these remaining properties as follows.
This is specific to this deployment example. For more information see The agentadmin -getUuid command fails for amadmin user on Access Manager 7 with various agents (6452713) in Sun Java System Access Manager Policy Agent 2.2 Release Notes.
Retrieve the Universal IDs.
They were saved in To Create Manager and Employee Groups Using Access Manager for J2EE Policy Agent Test.
Convert all uppercase to lowercase and append a back slash (\) in front of each equal sign (=).
Set the properties.
com.sun.identity.agents.config.privileged.attribute. mapping[id\=manager-group,ou\=group,o\=users,ou\=services, dc\=example,dc\=com] = am_manager_role com.sun.identity.agents.config.privileged.attribute. mapping[id\=employee-group,ou\=group,o\=users,ou\=services, dc\=example,dc\=com] = am_employee_role |
Save AMAgent.properties and close the file.
Restart the Application Server 2 administration server and managed server.
Change to the bin directory.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-2/bin |
Stop the managed server.
# ./stopManagedWebLogic.sh ApplicationsServer-2 t3://localhost:7001 |
Stop the administration server.
# ./stopWebLogic.sh |
Start the administration server.
# ./startWebLogic.sh & |
Start the managed server.
# ./startManagedWebLogic.sh ApplicationServer-2 t3://localhost:7001 & |
Log out of the ProtectedResource–2 host machine.
Use these steps to access the agent sample application and test policies against it.
Access http://ProtectedResource-2.example.com:1081/agentsample/index.html, the sample application URL, from a web browser.
The Sample Application welcome page is displayed.
Click the J2EE Declarative Security link.
On the resulting page, click Invoke the Protected Servlet.
You are redirected to the Access Manager login page.
Log in to the Access Manager console as testuser1.
testuser1
password
If you can successfully log in as testuser1 and the J2EE Policy Agent Sample Application page is displayed, the first part of the test has succeeded and authentication is working as expected.
Click the J2EE Declarative Security link again.
On the resulting page, click Invoke the Protected Servlet.
If the Success Invocation message is displayed, the second part of the test has succeeded as the sample policy for the manager role has been enforced as expected.
Click the J2EE Declarative Security link to return.
On the resulting page, click Invoke the Protected EJB via an Unprotected Servlet.
If the Failed Invocation message is displayed, the third part of the test has succeeded as the sample policy for the employee role has been enforced as expected.
Log out and close the browser.
In a new browser session, access http://ProtectedResource-2.example.com:1081/agentsample/index.html, the sample application URL, again.
The Sample Application welcome page is displayed.
Click the J2EE Declarative Security link.
On the resulting page, click Invoke the Protected EJB via an Unprotected Servlet.
You are redirected to the Access Manager login page.
If you are not redirected to the Access Manager login page for authentication, clear your browser's cache and cookies and try again.
Log in to the Access Manager console as testuser2
testuser2
password
The Failed Invocation message is displayed. This is a known issue.
Click the J2EE Declarative Security link.
On the resulting page, click Invoke the Protected EJB via an Unprotected.
The Successful Invocation message is displayed as the sample policy for the employee role has been enforced as expected.
Click the J2EE Declarative Security link to return.
On the resulting page, click Invoke the Protected Servlet.
If the Access to Requested Resource Denied message is displayed, this part of the test has succeeded as the sample policy for the manager role has been enforced as expected.
Log out and close the browser.
Use the following list of procedures as a checklist to configure the policy agent to point to the secure port of the Access Manager Load Balancer 3.
To Import the CA Root Certificate into the Application Server 2 Keystore
To Configure the J2EE Policy Agent 2 to Access the Distributed Authentication User Interface
Log in as a root user to the ProtectedResource–2 host machine.
Change to the config directory.
# cd /export/J2EEPA2/j2ee_agents/am_wl92_agent/agent_001/config |
Backup AMAgent.properties before you modify it.
Modify these properties in AMAgent.properties as follows.
com.sun.identity.agents.config.login.url[0] = https://LoadBalancer-3.example.com:9443/amserver/UI/Login?realm=users com.sun.identity.agents.config.cdsso.cdcservlet.url[0] = https://LoadBalancer-3.example.com:9443/amserver/cdcservlet com.sun.identity.agents.config.cdsso.trusted.id.provider[0] = https://LoadBalancer-3.example.com:9443/amserver/cdcservlet com.iplanet.am.naming.url= https://LoadBalancer-3.example.com:9443/amserver/namingservice com.iplanet.am.server.protocol=https com.iplanet.am.server.port=9443 |
Save AMAgent.properties and close the file.
The Certificate Authority (CA) root certificate enables the J2EE policy agent to trust the certificate from the Access Manager Load Balancer 3, and to establish trust with the certificate chain that is formed from the CA to the certificate. Import the same CA root certificate used in To Import a Certificate Authority Root Certificate on the Access Manager Load Balancer.
This procedure assumes you have just completed To Configure the J2EE Policy Agent 2 for SSL Communication. In this example, the root certificate is a file named /export/software/ca.cer.
Change to the directory where the cacerts keystore is located.
# cd /usr/local/bea/jdk150_04/jre/lib/security |
Backup cacerts before you modify it.
Import the root certificate.
# /usr/local/bea/jdk150_04/bin/keytool -import -trustcacerts -alias OpenSSLTestCA -file /export/software/ca.cer -keystore /usr/local/bea/jdk150_04/jre/lib/security/cacerts -storepass changeit Owner: EMAILADDRESS=nobody@nowhere.com, CN=OpenSSLTestCA, OU=Sun, O=Sun, L=Santa Clara, ST=California, C=US Issuer: EMAILADDRESS=nobody@nowhere.com, CN=OpenSSLTestCA, OU=Sun, O=Sun, L=Santa Clara, ST=California, C=US Serial number: 97dba0aa26db6386 Valid from: Tue Apr 18 07:55:19 PDT 2006 until: Tue Jan 13 06:55:19 PST 2009 Certificate fingerprints: MD5: 9F:57:ED:B2:F2:88:B6:E8:0F:1E:08:72:CF:70:32:06 SHA1: 31:26:46:15:C5:12:5D:29:46:2A:60:A1:E5:9E:28:64:36:80:E4:70 Trust this certificate? [no]: yes Certificate was added to keystore |
Verify that the certificate was successfully added to the keystore.
# /usr/local/bea/jdk150_04/bin/keytool -list -keystore /usr/local/bea/jdk150_04/jre/lib/security/cacerts -storepass changeit | grep -i openssl openssltestca, Sept 19, 2007, trustedCertEntry, |
Restart the Application Server 1 administration server and managed instance.
Change to the bin directory.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-2/bin |
Stop the managed instance.
# ./stopManagedWebLogic.sh ApplicationsServer-2 t3://localhost:7001 |
Stop the administration server.
# ./stopWebLogic.sh |
Start the administration server.
# ./startWebLogic.sh & |
Start the managed instance.
# ./startManagedWebLogic.sh ApplicationServer-2 t3://localhost:7001 & |
Log out of the ProtectedResource–2 host machine.
Use these steps to access the agent sample application and test policies against it.
Access http://ProtectedResource-2.example.com:1081/agentsample/index.html, the sample application URL, from a web browser.
The Sample Application welcome page is displayed.
Click the J2EE Declarative Security link.
On the resulting page, click Invoke the Protected Servlet.
You are redirected to the Access Manager login page.
Log in to the Access Manager console as testuser1.
testuser1
password
If you can successfully log in as testuser1 and the J2EE Policy Agent Sample Application page is displayed, this first part of the test has succeeded and authentication is working as expected.
Click the J2EE Declarative Security link to return.
On the resulting page, click Invoke the Protected Servlet.
If the Success Invocation message is displayed, this second part of the test has succeeded as the sample policy for the manager role has been enforced as expected.
Click the J2EE Declarative Security link to go back.
On the resulting page, click Invoke the Protected EJB via an Unprotected Servlet.
If the Failed Invocation message is displayed, this third part of the test succeeded as the sample policy for the employee role has been enforced as expected.
Log out and close the browser.
In a new browser session, access http://ProtectedResource-2.example.com:1081/agentsample/index.html, the sample application URL.
The Sample Application welcome page is displayed.
Click the J2EE Declarative Security link.
On the resulting page, click Invoke the Protected EJB via an Unprotected Servlet.
You are redirected to the Access Manager login page.
If you are not redirected to the Access Manager login page for authentication, clear your browser's cache and cookies and try again.
Log in to the Access Manager console as testuser2.
testuser2
password
The Failed Invocation message is displayed. This is a known issue.
Click the J2EE Declarative Security link.
On the resulting page, click Invoke the Protected EJB via an Unprotected Servlet.
The Successful Invocation message is displayed. The sample policy for the employee role has been enforced as expected.
Click the J2EE Declarative Security link to return.
On the resulting page, click Invoke the Protected Servlet.
If the Access to Requested Resource Denied message is displayed, this part of the test is successful as the sample policy for the manager role has been enforced as expected.
Log out and close the browser.
Modify AMAgent.properties.
Log in as a root user to the ProtectedResource–2 host machine.
Change to the config directory.
# cd /export/J2EEPA2/j2ee_agents/am_wl92_agent/agent_001/config |
Backup AMAgent.properties before you modify it.
Set the following property.
com.sun.identity.agents.config.login.url[0] = https://LoadBalancer-4.example.com:9443/distAuth/UI/Login?realm=users |
Save AMAgent.properties and close the file.
Restart the Application Server 1 managed server.
Log out of the ProtectedResource–2 host machine.
Verify that the agent is configured properly.
Access http://ProtectedResource-2.example.com:1081/agentsample/index.html, the sample application URL, form a web browser.
The Sample Application Welcome page is displayed.
Click the J2EE Declarative Security link.
On the resulting page, click Invoke the Protected Servlet.
You are redirected to the Distributed Authentication User Interface at https://loadbalancer-4.example.com:9443/distAuth/UI/Login.
(Optional) Double-click the gold lock in the lower left corner of the browser.
In the Properties page, you see the certificate for LoadBalancer–4.example.com.
Log in to the Access Manager console as testuser1.
testuser1
password
If you can successfully log in as testuser1 and the J2EE Policy Agent Sample Application page is displayed, user authentication worked through the Distributed Authentication User Interface.
Log out of the console.
Two load balancers are configured for the policy agents in this deployment example. Load Balancer 5 balances traffic passing through the web policy agents. Load Balancer 6 balances traffic passing through the J2EE policy agents. Both load balancers are configured for simple persistence so that browser requests from the same IP address will always be directed to the same policy agent. This chapter contains detailed procedures for the following tasks:
Load Balancer 5 handles traffic for the web policy agents, and is configured for simple persistence so that browser requests from the same IP address will always be directed to the same policy agent. From a performance perspective, each policy agent validates the user session and evaluates applicable policies. The results are subsequently cached by the individual policy agent to improve performance. If load balancer persistence is not set, each agent must build up its own cache, effectively doubling the workload on the Access Manager servers, and cutting overall system capacity in half. The problem becomes even more acute as the number of policy agents increases. Simple persistence guarantees that the requests from the same user session will always be sent to the same policy agent.
In situations where each web policy agent instance is protecting identical resources, some form of load balancer persistence is highly recommended for the performance reasons. The actual type of persistence may vary when a different load balancer is used, as long as it achieves the goal of sending the requests from the same user session to the same policy agent.
The following illustration shows the architecture of the policy agents and load balancers.
When firewalls are configured, Load Balancer 5 can be located in a less secure zone.
Use the following list of procedures as a checklist for configuring the web policy agents' load balancer:
To Configure Policy for the Web Policy Agents Using Access Manager
To Verify the Web Policy Agents Load Balancer Configuration is Working Properly
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.
Access https://is-f5.example.com, the Big IP load balancer login page, from a web browser.
Log in using the following credentials:
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:
WebAgent-Pool
Round Robin
Add the IP address and port number of both Protected Resource host machines: ProtectedResource-1:1080 and ProtectedResource-2:1080.
Click Done.
Add a Virtual Server.
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-5.example.com
90
WebAgent-Pool
Continue to click Next until you reach the Pool Selection dialog box.
In the Pool Selection dialog box, assign the WebAgent-Pool Pool.
Click Done.
Add Monitors.
Monitors are required for the load balancer to detect the backend server failures.
In the left frame, click Monitors.
Click Add.
In the Add Monitor dialog provide the following information:
WebAgent-http
Choose http.
Click Next.
On the resulting Configure Basic Properties page, click Next.
In the Send String field under Configure ECV HTTP Monitor, enter GET /monitor.html and click Next.
On the Destination Address and Service (Alias) page, click Done.
The monitor just added is in the list of monitors under the Monitors tab.
Click the Basic Associations tab.
Mark the Add checkbox next to the IP addresses for ProtectedResource-1 and ProtectedResource-2.
At the top of the Node column, choose the monitor that you just added, WebAgent-http.
Click Apply.
Configure the load balancer for simple persistence.
The web policy agents load balancer is configured with simple persistence. With simple persistence, all requests sent within a specified interval from the same user are routed to the same agent. This significantly reduces the number of agent requests to sent to Access Manager for validation thus reducing the overall load on the Access Manager servers.
Simple persistence tracks connections based on the client IP address only, returning a client to the same node to which it connected previously.
Log out of the console.
Modify AMAgent.properties to point Protected Resource 1 and Protected Resource 2 to Load Balancer 5.
As a root user, log in to the ProtectedResource–1 host machine.
Change to the config directory.
# cd /export/WebPA1/web_agents/sjsws_agent/Agent_001/config |
Backup AMAgent.properties before you modify it.
Make the following changes to AMAgent.properties.
Add the following entry:
com.sun.am.policy.agents.config.fqdn.map = valid|LoadBalancer-5.example.com |
Append the following to the end of the value string for the com.sun.am.policy.agents.config.notenforced_list property:
http://ProtectedResource-1.example.com:1080/monitor.html http://LoadBalancer-5.example.com:90/monitor.html
Save the file and close it.
Create a monitor.html file to be used by the load balancer.
# cd /opt/SUNWwbsvr/https-ProtectedResource-1.example.com/docs # cat > monitor.html <HTML> </HTML> Hit Control D to terminate the command ^D |
Restart Web Server 1 on the Protected Resource 1 host machine.
# cd /opt/SUNWwbsvr/https-ProtectedResource-1.example.com/bin # ./stopserv; ./startserv |
Log out of the ProtectedResource–1 host machine.
As a root user, log in to the ProtectedResource–2 host machine.
Change to the config directory.
# cd /export/WebPA2/web_agents/sjsws_agent/Agent_001/config |
Make the following changes to the AMAgent.properties file.
Backup AMAgent.properties before you modify it.
Add the following entry:
com.sun.am.policy.agents.config.fqdn.map = valid|LoadBalancer-5.example.com |
Append the following to the end of the value string for the com.sun.am.policy.agents.config.notenforced_list property:
http://ProtectedResource-2.example.com:1080/monitor.html http://LoadBalancer-5.example.com:90/monitor.html
Save the file and close it.
Create a monitor.html file to be used by the load balancer.
# cd /opt/SUNWwbsvr/https-ProtectedResource-2.example.com/docs # cat > monitor.html <HTML> </HTML> Hit Control D to terminate the command ^D |
Restart Web Server 2 on the Protected Resource 2 host machine.
# cd /opt/SUNWwbsvr/https-ProtectedResource-2.example.com/bin # ./stopserv; ./startserv |
Log out of the ProtectedResource–2 host machine.
Use the Access Manager console to configure policy for the Web Policy Agents.
Access the Access Manager server, http://AccessManager-1.example.com:1080/amserver/UI/Login, from a web browser.
Log in to the Access Manager console as the administrator.
amadmin
4m4dmin1
Modify the referral policy for access to Load Balancer 5.
On the Access Control tab, click the top-level realm example.
Click the Policies tab.
Click the Referral URL Policy for users realm link.
On the Edit Policy page, under Rules, click New.
On the resulting page, select URL Policy Agent (with resource name) and click Next.
This selection is used to define policies that protect HTTP and HTTPS URLs.
On the resulting page, provide the following information:
URL Rule for LoadBalancer-5
http://LoadBalancer-5.example.com:90/*
Click Finish.
On the resulting page, click Save.
The new rule is in the Rules list.
Create a policy in the users sub-realm.
On the Access Control tab, click the users link.
Click the Policies tab, and then New Policy.
In the Name field, enter URL Policy for LoadBalancer-5.
Under Rules, click New.
On the resulting page, accept the default URL Policy Agent (with resource name) and click Next.
On the resulting page, provide the following information:
LoadBalancer-5.
In the list, select http://LoadBalancer-5.example.com:90/*.
http://LoadBalancer-5.example.com:90/* is automatically entered when you select the Parent Resource Name.
Mark this checkbox and select Allow.
Mark this checkbox and select Allow.
Click Finish.
On the New Policy page again, under Subjects, click New.
On the resulting page, verify that Access Manager Identity Subject is selected, and click Next.
On the resulting page, provide the following information:
LoadBalancer-5_Groups
In the drop-down list, select Group and click Search.
The search returns a list of available groups.
Select Employee-Group and Manager-Group and click Add.
The Employee-Group and Manager-Group groups are in the Selected List.
Click Finish.
On the resulting page, click OK.
The policy you just created is now included in the list of Policies.
Log out of the Access Manager console and close the browser.
Access http://loadbalancer-5.example.com:90/index.html, the Access Manager load balancer, from a web browser.
Log in to the Access Manager console as testuser1.
testuser1
password
If the default Web Server index.html page is displayed, the load balancer is configured properly.
Verify that Load Balancer 5 monitors are monitoring the Web Server instances properly.
Log in as a root user to the ProtectedResource–1 host machine.
Run the tail command.
# cd /opt/SUNWwbsvr/https-ProtectedResource-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 - - [21/Sep/2007:13:59:48 -0700] "GET /monitor.html" 200 15 |
If you do not see "GET /monitor.html", you must troubleshoot the load balancer configuration.
Log in as a root user to the ProtectedResource–2 host machine.
Run the tail command.
# cd /opt/SUNWwbsvr/https-ProtectedResource-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 - - [21/Sep/2007:13:59:48 -0700] "GET /monitor.html" 200 15 |
If you do not see "GET /monitor.html", you must troubleshoot the load balancer configuration.
Log out of both Protected Resource host machines after you have verified that the monitors are working properly.
Load Balancer 6 handles traffic for the J2EE policy agents, and is configured for simple persistence so that browser requests from the same IP address will always be directed to the same policy agent. From a performance perspective, each policy agent validates the user session and evaluates applicable policies. The results are subsequently cached by the individual policy agent to improve performance. If load balancer persistence is not set, each agent must build up its own cache, effectively doubling the workload on the Access Manager servers, and cutting overall system capacity in half. The problem becomes even more acute as the number of policy agents increases. Simple persistence guarantees that the requests from the same user session will always be sent to the same policy agent.
In situations where each J2EE policy agent instance is protecting identical resources, some form of load balancer persistence is highly recommended for the performance reasons. The actual type of persistence may vary when a different load balancer is used, as long as it achieves the goal of sending the requests from the same user session to the same policy agent.
The following illustration shows the architecture of the policy agents and load balancers.
When firewalls are configured, Load Balancer 6 can be located in a less secure zone.
Use the following list of procedures as a checklist for configuring the J2EE policy agents' 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.
Access https://is-f5.example.com, the Big IP load balancer login page, from 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:
J2EEAgent-Pool
Round Robin
Add the Application Server IP addresses and port numbers: ProtectedResource-1:1081 and ProtectedResource-2:1081.
Click Done.
In the List of Pools, click J2EEAgent-Pool.
Click the Persistence tab and provide the following information:
Choose Active Http Cookie
Active Http Cookie persistence uses an HTTP cookie stored on a client computer to allow the client to reconnect to the same server previously visited.
Choose Insert
Click Apply.
Add a Virtual Server.
If you encounter JavaScript errors or otherwise cannot proceed to create a virtual server, try using Internet Explorer for this step.
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-6.example.com
91
J2EEAgent-Pool
Continue to click Next until you reach the Pool Selection dialog box.
In the Pool Selection dialog box, assign the J2EEAgent-Pool pool.
Click Done.
Add Monitors.
Log out of the load balancer console.
Modify the AMAgent.properties file to point Protected Resource 1 and Protected Resource 2 to Load Balancer 6.
As a root user, log in to the ProtectedResource–1 host machine.
Change to the config directory.
# cd /export/J2EEPA1/j2ee_agents/am_wl92_agent/agent_001/config |
Backup AMAgent.properties before you modify it.
Make the following change to the AMAgent.properties file.
com.sun.identity.agents.config.fqdn.mapping[LoadBalancer-6.example.com] = LoadBalancer-6.example.com
Save the file and close it.
Log out of the ProtectedResource–1 host machine.
As a root user, log in to the ProtectedResource–2 host machine.
Change to the config directory.
# cd /export/J2EEPA2/j2ee_agents/am_wl92_agent/agent_001/config |
Backup AMAgent.properties before you modify it.
Make the following change to the AMAgent.properties file.
com.sun.identity.agents.config.fqdn.mapping[LoadBalancer-6.example.com] = LoadBalancer-6.example.com
Save the file and close it.
Log out of the ProtectedResource–2 host machine.
The policies you create here are used in To Verify the J2EE Policy Agent Load Balancer Configuration is Working Properly.
Access the Access Manager server, http://AccessManager-1.example.com:1080/amserver/UI/Login, from a web browser.
Log in to the Access Manager console as the administrator.
amadmin
4m4dmin1
Modify the referral policy for access to Load Balancer 6.
On the Access Control tab, click the top-level realm example.
Click the Policies tab.
Click the Referral URL Policy for users realm link.
On the Edit Policy page, under Rules, click New.
On the resulting page, select URL Policy Agent (with resource name) and click Next.
This selection is used to define policies that protect HTTP and HTTPS URLs.
On the resulting page, provide the following information:
URL Rule for LoadBalancer-6
http://loadbalancer-6.example.com:91/*
Make sure all letters are lowercase.
Click Finish.
On the resulting page, click Save.
The new rule is in the Rules list.
Create a policy in the users sub-realm.
On the Access Control tab, click the users link.
Click the Policies tab, and then New Policy.
In the Name field, enter URL Policy for LoadBalancer-6.
Under Rules, click New.
On the resulting page, accept the default URL Policy Agent (with resource name) and click Next.
On the resulting page, provide the following information:
LoadBalancer-6.
From the list, select, http://loadbalancer-6.example.com:91/*.
http://loadbalancer-6.example.com:91/* is automatically entered when you select the Parent Resource Name.
Mark the checkbox and select Allow.
Mark the checkbox and select Allow.
Click Finish.
On the New Policy page again, under Subjects, click New.
On the resulting page, verify that Access Manager Identity Subject is selected, and click Next.
On the resulting page, provide the following information:
LoadBalancer-6_Groups
In the drop-down list, select Group and click Search.
The search returns a list of available groups.
Select Employee-Group and Manager-Group and click Add.
The Employee-Group and Manager-Group groups are in the Selected List.
Click Finish.
On the resulting page, click OK.
The policy you just created is now included in the list of Policies.
Log out of the Access Manager console and close the browser.
Restart the Application Servers.
As a root user, log in to the ProtectedResource–1 host machine.
Change to the bin directory.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-1/bin |
Stop Application Server 1 managed instance.
# ./stopManagedWebLogic.sh ApplicationsServer-1 t3://localhost:7001 |
Stop the Application Server 1 administration server.
# ./stopWebLogic.sh |
Start the Application Server 1 administration server.
# ./startWebLogic.sh & |
Start Application Server 1 managed instance.
# ./startManagedWebLogic.sh ApplicationServer-1 t3://localhost:7001 |
Log out of the ProtectedResource–1 host machine.
As a root user, log in to the ProtectedResource–2 host machine.
Change to the bin directory.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-2/bin |
Stop the Application Server 2 managed instance.
# ./stopManagedWebLogic.sh ApplicationsServer-2 t3://localhost:7001 |
Stop the Application Server 2 administration server.
# ./stopWebLogic.sh |
Start the Application Server 2 administration server.
# ./startWebLogic.sh & |
Start the Application Server 2 managed instance.
# ./startManagedWebLogic.sh ApplicationServer-2 t3://localhost:7001 |
Log out of the ProtectedResource–2 host machine.
Access http://LoadBalancer-6.example.com:91/agentsample/index.html from a web browser.
The Sample Application welcome page is displayed.
Click the J2EE Declarative Security link.
On the resulting page click Invoke the Protected Servlet.
The policy agent redirects to the Access Manager login page.
Log in to the Access Manager console as testuser1.
testuser1
password
If you can successfully log in as testuser1 and the J2EE Policy Agent Sample Application page is displayed, this first part of the test succeeded and authentication is working as expected.
Click the J2EE Declarative Security link to return.
On the resulting page, click Invoke the Protected Servlet.
If the Successful Invocation message is displayed, this second part of the test has succeeded and the sample policy for the employee role has been enforced as expected.
Close the browser.
Open a new browser and access http://LoadBalancer-6.example.com:91/agentsample/index.html.
The Sample Application welcome page is displayed.
Click the J2EE Declarative Security link.
On the resulting page click Invoke the Protected Servlet.
The policy agent redirects to the Access Manager login page.
Log in to the Access Manager console as testuser2.
testuser2
password
If the Access to Requested Resource Denied message is displayed, this third part of the test succeeded and the sample policy for the manager role has been enforced as expected.
Click the J2EE Declarative Security link to return.
On the resulting page, click Invoke the Protected EJB via an Unprotected Servlet.
If the Successful Invocation message is displayed, the sample policy for the employee role has been enforced as expected.
Close the browser.
Sun Java™ System Access Manager provides a web container-independent session failover feature that uses Sun Java System Message Queue. Message Queue is a messaging middleware product that enables distributed applications to communicate and exchange data by sending and receiving messages. Access Manager uses Message Queue as a communications broker, and uses the Berkeley DB by Sleepycat Software, Inc. for the backend session store databases. This chapter contains the following sections:
When session failover is implemented for Access Manager, session information is replicated in two backend session store databases. This ensures that if one Access Manager fails or stops, the information stored in the backend session databases can be used to keep the user continuously authenticated. If session failover is not implemented and the Access Manager server in which a user's session was created fails, the user will have to reauthenticate to perform an operation that requires a session token. The following diagram illustrates the session failover architecture.
For more information about Access Manager and session failover, see Chapter 6, Implementing Session Failover, in Sun Java System Access Manager 7.1 Postinstallation Guide.
Use the following list of procedures as a checklist for installing the Access Manager session failover components.
To Install Access Manager Session Failover Components on Message Queue 1
To Install Access Manager Session Failover Components on Message Queue 2
As a root user, log in to the MessageQueue–1 host machine.
Create a directory into which the Message Queue and Berkeley Database bits can be downloaded and change into it.
# mkdir /export/AMSFO # cd /export/AMSFO |
Copy amSessionTools.zip from the AccessManager–1 host machine to the MessageQueue–1 host machine.
amSessionTools.zip is included in the AccessManager7_1RTM.zip file downloaded in To Generate an Access Manager WAR File on the Access Manager 1 Host Machine. amSessionTools.zip can be found under the tools directory.
Unzip amSessionTools.zip.
# cd /export/AMSFO # unzip amSessionTools.zip -d amSessionTools |
Modify the permissions on the setup script and run it to initialize the session failover tools.
# cd /export/AMSFO/amSessionTools # chmod +x setup # ./setup |
When prompted, enter amserver as the Directory to install the scripts (example: amserver).
The directory location should be relative to the current directory.
When the script is finished, the following messages are displayed:
The scripts are properly setup under directory /export/AMSFO/amSessionTools/amserver JMQ is properly setup under directory jmq. BerkeleyDB is properly setup under directory bdb. |
Change to the bin directory.
# cd /export/AMSFO/amSessionTools/jmq/imq/bin |
Run the imqbrokerd command to create a new broker instance named msgqbroker.
# ./imqbrokerd -name msgqbroker -port 7777 & |
Run netstat to verify that the new Message Queue broker instance is up and running.
# netstat -an | grep 7777 *.7777 *.* 0 0 49152 0 LISTEN |
Add a new user named msgquser.
This user will connect to the Message Queue broker instance on servers where Message Queue is installed. This user will be used only for session failover purposes, and does not assume the privileges of the guest user. It is a good practice to create a custom user for such purposes, and not to rely on the known user accounts or default user accounts to help prevent brute force or DOS attacks.
# ./imqusermgr add -u msgquser -g admin -p m5gqu5er -i msgqbroker |
Disable the guest user.
This step ensures that the guest user will not be able to access the Access Manager server.
# ./imqusermgr update -u guest -a false -i msgqbroker User repository for broker instance: msgqbroker Are you sure you want to update user guest? (y/n) y User guest successfully updated. |
Modify the amsfo.conf file.
amsfo.conf has parameters that are consumed by the Access Manager session failover startup script, amsfo.
Change to the lib directory.
# cd /export/AMSFO/amSessionTools/amserver/config/lib |
Backup amsfo.conf before you modify it.
Set the following properties:
CLUSTER_LIST=MessageQueue-1.example.com:7777,MessageQueue-2.example.com:7777 BROKER_INSTANCE_NAME=msgqbroker USER_NAME=msgquser BROKER_PORT=7777 |
The port used for BROKER_PORT should be the same as the one used in the value of the CLUSTER_LIST.
Save the file and close it.
Run the amsfopassword command.
This command generates an encrypted password, creates a new file named .password, and stores the encrypted password in the new file.
amsfopassword creates the .password file in a default location based on where the scripts were installed. If a different location is used, the PASSWORDFILE property in amsfo.conf should be changed accordingly.
Change to the bin directory.
# cd /export/AMSFO/amSessionTools/amserver/bin |
Run amsfopassword.
# cd /export/AMSFO/amSessionTools/amserver/bin # ./amsfopassword -e m5gqu5er -f /export/AMSFO/amSessionTools/amserver/.password os.name=SunOS SUCCESSFUL |
(Optional) View the encrypted password.
# more /export/AMSFO/amSessionTools/amserver/.password M27OGb6U4ufRu+oWAzBdWw== |
(Optional) Modify the amsessiondb script if necessary.
The amsessiondb script (located in the /export/AMSFO/amSessionTools/amserver/bin directory) starts the Berkeley Database client, creates the database, and sets specific database values. It is called when the amsfo script is run for the first time. The amsessiondb script contains variables that specify default paths and directories. If any of the following components are not installed in their default directories, edit the amsessiondb script to set the variables to the correct locations.
JAVA_HOME=/usr/jdk/entsys-j2se IMQ_JAR_PATH=/export/AMSFO/amSessionTools/jmq/imq/lib JMS_JAR_PATH=/export/AMSFO/amSessionTools/jmq/imq/lib BDB_JAR_PATH=/export/AMSFO/amSessionTools/bdb/usr/lib BDB_SO_PATH=/export/AMSFO/amSessionTools/bdb/usr/lib AM_HOME=/export/AMSFO/amSessionTools |
Backup amsessiondb before you modify it.
Restart the Access Manager session failover components.
Change to the bin directory.
# cd /export/AMSFO/amSessionTools/jmq/imq/bin |
Stop the Message Queue instance using the product's command line interface.
See the Message Queue documentation for more information.
Run the netstat command to verify that the MessageQueue-1 broker instance is stopped.
# netstat -an | grep 7777 |
If netstat returns no result, the MessageQueue-1 broker instance is stopped.
If the MessageQueue-1 broker instance is not stopped, kill the process using the following procedure.
Get the Java process IDs.
# ps -ef | grep java |
Kill the Java process IDs that were returned.
# kill -9 #### #### |
Run netstat again.
Restart the MessageQueue-1 broker instance.
# ./amfso start |
Run the netstat command to verify that the Message Queue port is open and listening.
# netstat -an | grep 7777 *.7777 *.* 0 0 49152 0 LISTEN |
Log out of the MessageQueue–1 host machine.
As a root user, log in to the MessageQueue–2 host machine.
Create a directory into which the Message Queue and Berkeley Database bits can be downloaded and change into it.
# mkdir /export/AMSFO # cd /export/AMSFO |
Copy amSessionTools.zip from the AccessManager–1 host machine to the MessageQueue–2 host machine.
amSessionTools.zip is included in the AccessManager7_1RTM.zip file downloaded in To Generate an Access Manager WAR File on the Access Manager 1 Host Machine. amSessionTools.zip can be found under the tools directory.
Unzip amSessionTools.zip.
# cd /export/AMSFO # unzip amSessionTools.zip -d amSessionTools |
Modify the permissions on the setup script and run it to initialize the session failover tools.
# cd /export/AMSFO/amSessionTools # chmod +x setup # ./setup |
When prompted, enter amserver as the Directory to install the scripts (example: amserver).
The directory location should be relative to the current directory.
When complete, the following messages are displayed:
The scripts are properly setup under directory /export/AMSFO/amSessionTools/amserver JMQ is properly setup under directory jmq. BerkeleyDB is properly setup under directory bdb. |
Change to the bin directory.
# cd /export/AMSFO/amSessionTools/jmq/imq/bin |
Run the imqbrokerd command to create a new broker instance named msgqbroker.
# ./imqbrokerd -name msgqbroker -port 7777 & |
Run netstat to verify that the new Message Queue instance is up and running.
# netstat -an | grep 7777 *.7777 *.* 0 0 49152 0 LISTEN |
Add a new user named msgquser.
This is the user that will be used to connect to the Message Queue broker on servers where Message Queue is installed. This user will be used only for session failover purposes, and does not assume the privileges of the guest user. It is a good practice to create a custom user for such purposes, and not to rely on the known user accounts or default user accounts. This helps to prevent brute force or DOS attacks.
# ./imqusermgr add -u msgquser -g admin -p m5gqu5er -i msgqbroker |
Disable the guest user.
This step ensures that the guest user will not be able to access the Access Manager server.
# ./imqusermgr update -u guest -a false -i msgqbroker User repository for broker instance: msgqbroker Are you sure you want to update user guest? (y/n) y User guest successfully updated. |
Stop the Message Queue instance using the product's command line interface.
Modify the amsfo.conf file.
amsfo.conf has parameters that are consumed by the Access Manager session failover startup script, amsfo.
Change to the lib directory.
# cd /export/AMSFO/amSessionTools/amserver/config/lib |
Backup amsfo.conf before you modify it.
Set the following properties:
CLUSTER_LIST=MessageQueue-1.example.com:7777,MessageQueue-2.example.com:7777 BROKER_INSTANCE_NAME=msgqbroker USER_NAME=msgquser BROKER_PORT=7777 |
The port used for BROKER_PORT should be the same as the one used in the value of the CLUSTER_LIST.
Save the file and close it.
Run the amsfopassword command.
This command generates an encrypted password, creates a new file named .password, and stores the encrypted password in the new file.
amsfopassword creates the .password file in a default location based on where the scripts were installed. If a different location is used, the PASSWORDFILE property in amsfo.conf should be changed accordingly.
Change to the bin directory.
# cd /export/AMSFO/amSessionTools/amserver/bin |
Run amsfopassword.
# cd /export/AMSFO/amSessionTools/amserver/bin # ./amsfopassword -e m5gqu5er -f /export/AMSFO/amSessionTools/amserver/.password os.name=SunOS SUCCESSFUL |
(Optional) View the encrypted password.
# more /export/AMSFO/amSessionTools/amserver/.password M27OGb6U4ufRu+oWAzBdWw== |
(Optional) Modify the amsessiondb script if necessary.
The amsessiondb script (located in the /export/AMSFO/amSessionTools/amserver/bin directory) starts the Berkeley Database client, creates the database, and sets specific database values. It is called when the amsfo script is run for the first time. The amsessiondb script contains variables that specify default paths and directories. If any of the following components are not installed in their default directories, edit the amsessiondb script to set the variables to the correct locations.
JAVA_HOME=/usr/jdk/entsys-j2se IMQ_JAR_PATH=/export/AMSFO/amSessionTools/jmq/imq/lib JMS_JAR_PATH=/export/AMSFO/amSessionTools/jmq/imq/lib BDB_JAR_PATH=/export/AMSFO/amSessionTools/bdb/usr/lib BDB_SO_PATH=/export/AMSFO/amSessionTools/bdb/usr/lib AM_HOME=/export/AMSFO/amSessionTools |
Backup amsessiondb before you modify it.
Restart the Access Manager session failover components.
Change to the bin directory.
# cd /export/AMSFO/amSessionTools/amserver/bin |
Stop the MessageQueue-2 broker instance.
# ./amsfo stop |
The port socket should be relinquished before you restart. If not, session failover problems may occur.
Run the netstat command to verify that the MessageQueue-2 broker instance is stopped.
# netstat -an | grep 7777 |
If netstat returns no result, the MessageQueue-2 broker instance is stopped.
If the MessageQueue-2 broker instance is not stopped, kill the process using the following procedure.
Get the Java process IDs.
# ps -ef | grep java |
Kill the Java process IDs that were returned.
# kill -9 #### #### |
Run netstat again.
Restart the MessageQueue-2 broker instance.
# ./amfso start |
Run the netstat command to verify that the Message Queue port is open and listening.
# netstat -an | grep 7777 *.7777 *.* 0 0 49152 0 LISTEN |
Log out of the MessageQueue–2 host machine.
Use the following list of procedures as a checklist for configuring and verifying session failover.
Access http://LoadBalancer-3.example.com:7070/amserver/UI/Login from a web browser.
Log in to the Access Manager console as the administrator.
amadmin
4m4dmin1
Click the Configuration tab.
Under Global properties, click Session.
Under Secondary Configuration Instance, click New.
In the Add Sub Configuration page, provide the following information.
Enter the load balancer URL https://loadbalancer-3.example.com:9443
The case of the load balancer URL should match that of the Primary Site ID.
Enter msgquser
Enter m5gqu5er
Enter m5gqu5er
Keep the default value of 5000.
Enter MessageQueue-1.example.com:7777,MessageQueue-2.example.com:7777.
This is the Message Queue broker address list. Enter multiple values using a comma and no space.
Click Add.
Click Save.
Log out of the Access Manager console.
Restart the Web Server 1 instance.
Restart the Web Server 2 instance.
Both Access Manager 1 and Access Manager 2 should be up and running before you begin this verification procedure.
As a root user, log in to the AccessManager–2 host machine.
Change to the bin directory.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com/bin |
Stop Access Manager 2.
# ./stopserv |
Access http://LoadBalancer-3.example.com:7070/amserver/UI/Login from a web browser.
Log in to the Access Manager console as the administrator.
amadmin
4m4dmin1
Click the Sessions tab.
In the View field, select Access Manager-1.example.com:1080 from the drop down list.
Verify that only amadmin exists in the Sessions table.
In the View field, select Access Manager-2.example.com:1080 from the drop down list.
You will see an error message indicating the server is down.
Leave this browser window 1 open.
Start Access Manager 2.
# ./startserv |
As a root user, log in to the AccessManager–1 host machine.
Change to the bin directory.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com/bin |
Stop Access Manager 1.
# ./stopserv |
Going back to the Access Manager console in browser window 1, under the Sessions tab, select Access Manager-1.example.com:1080 from the View drop down list.
You will see an error message indicating the server is down.
Now select Access Manager-2.example.com:1080 from the View drop down list.
Verify that only amadmin exists in the Sessions table. This indicates that although AccessManager–1 was stopped, the Access Manager LoadBalancer-3 directed the request to AccessManager–2 and a session for amadmin was successfully created in AccessManager–2. If session failover was not enabled, it would have resulted in a login page.
This procedure assumes that you have just completed To Verify That the Administrator Session Fails Over.
Access http://LoadBalancer-3.example.com:7070/amserver/UI/Login?realm=users from a second browser window.
Log in to the Access Manager console as testuser1.
testuser1
password
The Edit User page for testuser1 is displayed. Because Access Manager 1 was stopped, the user session is created in Access Manager 2.
Leave browser window 2 open.
Using browser window 1, click the Sessions tab.
In the View field, select Access Manager-2.example.com:1080 from the drop down list.
Verify that amadmin and testuser1 exist in the Sessions table.
On the AccessManager–1 host machine, change to the bin directory.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com/bin |
Start AccessManager–1.
# ./startserv |
Both Access Manager–1 and Access Manager–2 are up and running.
On the AccessManager–2 host machine, change to the bin directory.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com/bin |
Stop Access Manager–2.
# ./stopserv |
Using browser window 1, click the Sessions tab.
In the View field, select Access Manager-1.example.com:1080.
Verify that amadmin and testuser1 exist in the Sessions table. This indicates that the session successfully failed over to AccessManager–1.
If testuser1 is not displayed, refresh the browser window 2 page.
In the View field, select Access Manager-2.example.com:1080
You will see an error message indicating the server is down.
Log out of the consoles and the host machines.