Chapter 5, Installing and Configuring the Access Manager Servers
Chapter 6, Installing and Configuring the Distributed Authentication UI Servers
Chapter 8, Installing and Configuring the Protected Resources with Policy Agents
This chapter contains the following topics:
This guide provides instructions for building an environment for this Deployment Example. These instructions were used to build, deploy and test this Deployment Example in a lab facility. When using this guide, you'll obtain the best results if you perform the tasks in the exact sequence in which they are presented. Use the Table of Contents as a master task list. Tasks are numbered for your convenience.
The last step in each task is a verification procedure. Be sure to verify the success of each task before moving on to the next task in the sequence.
This guide is designed to demonstrate just one way to deploy Access Manager with load-balancers to optimize performance and high availability. 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 do plan to deviate from the task sequence or details described in this guide, you should refer to the relevant product documentation for information on differences in platforms, software versions or other requirement constraints.
See 2.2 Host Names and Main Service URLs Used in Examples for a quick reference of server names and component names used in this deployment example. See Part III, Reference: Summaries of Server and Component Configurations for more detailed information.
The following table describes the typographic conventions that are used in this deployment example.
Table 3–1 Typographic Conventions
Typeface |
Meaning |
Example |
---|---|---|
AaBbCc123 |
The names of commands, files, and directories, and onscreen computer output |
Edit your .login file. Use ls -a to list all files. machine_name% you have mail. |
AaBbCc123 |
What you type, contrasted with onscreen computer output |
machine_name% su Password: |
aabbcc123 |
Placeholder: replace with a real name or value |
The command to remove a file is rm filename. |
AaBbCc123 |
Book titles, new terms, and terms to be emphasized |
Read Chapter 6 in the User's Guide. A cache is a copy that is stored locally. Do not save the file. Note: Some emphasized items appear bold online. |
Installation as described in this document includes the installation and basic configuration of a Java Enterprise System (Java ES) solution. Installation, as used in this document, means using the Java ES 2004Q5 installer to copy the files for Java ES components to computer systems. You can download and unpack the installer zip files onto one host computer system, and then mount the cd image on any remote host computer systems where you must install Directory Server, Access Manager, or Web Server.
Download the Java ES installer zip files.
Start a browser, and go to http://www.sun.com/software/solaris/get.jsp.
Choose Java Enterprise System.
Follow the instructions for downloading two zip files that together will form the CD image.
Log in as a root user to a host computer system where you want to run the installer.
Copy the Java Enterprise System installer zip files to this host computer system.
Unzip each zipped file. Example:
#ls java_es_05Q4-ga-solaris-sparc-1-iso.zip java_es_05Q4-ga-solaris-sparc-2-iso.zip # unzip java_es_05Q4-ga-solaris-sparc-1-iso.zip inflating: java_es_05Q4-ga-solaris-sparc-1.iso... # unzip java_es_05Q4-ga-solaris-sparc-2-iso.zip inflating: java_es_05Q4-ga-solaris-sparc-2.iso... |
Create three directories for mounting the .iso files. Example:
# mkdir /mnt # mkdir /mnt2 # mkdir /jes-complete
Mount the .iso files.
In the following examples, replace /download-directory/ with the path to your .iso file:
# lofiadm -a /download-directory/java_es_05Q4-ga-solaris-sparc-1.iso /dev/lofi/1 # mount -F hsfs -o ro /dev/lofi/1 /mnt |
If the /dev/lofi/1 device is already in use, run this command:
# lofiadm —d /dev/lofi/1
and then retry using the lofiad -a command.
To mount the second iso file:
# lofiadm -a /download-directory/java_es_05Q4-ga-solaris-sparc-2.iso /dev/lofi/2 # mount -F hsfs -o ro /dev/lofi/2 /mnt2 # lofiadm Block Device File dev/lofi/1 /export/temp/java_es_05Q4-ga-solaris-sparc-1.iso /dev/lofi/2 /export/temp/java_es_05Q4-ga-solaris-sparc-2.iso |
Copy both mounted .iso files to the same directory.
The two .iso files together form the complete JES package, so you must copy both files into the same directory. As an alternative, you can burn each ISO onto a CD, and then run the installer from a CD drive.
# cd /mnt1 # cp -r * /jes-complete # cd /mnt2 # cp -r * /jes-complete |
After you mount the .iso files and copy them to the same directory, the installer is located in the here:
/jes-complete/Solaris_sparc
In this Deployment Example, you start the installer with the -nodisplay option:
# /jes-complete/Solaris_sparc/installer —nodisplay
You will need load balancing hardware and software to replicate this deployment environment. 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.
The following tasks require load-balancing hardware and software:
You will need to obtain root certificate authority (CA) certificates and server 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 require SSL certificates:
To Request an SSL Certificate for the Access Manager Load Balancer
To Install an SSL Certificate on the Access Manager Load Balancer
To Install a Root CA Certificate on the Access Manager Load Balancer
There are many ways to resolve host names used in this deployment. For example, you can us a DNS naming service, or you can include entries in a DNS database. For this particular deployment, the following entries were added to the local host file on all Unix hosts. The entries were also added to equivalent files on Windows hosts, and on client machines for where browsers are used.
xxx.xx.72.122 DirectoryServer-1 DirectoryServer-1.example.com xxx.xx.72.121 DirectoryServer-2 DirectoryServer-2.example.com xxx.xx.72.84 AccessManager-1 AccessManager-1.example.com xxx.xx.72.85 AccessManager-2 AccessManager-2.example.com xxx.xx.72.120 AuthenticationUI-1 AuthenticationUI-1.example.com xxx.xx.72.73 AuthenticationUI-2 AuthenticationUI-2.example.com xxx.xx.72.151 ProtectedResource-1 ProtectedResource-1.example.com xxx.xx.72.152 ProtectedResource-2 ProtectedResource-2.example.com xxx.xx.69.246 MessageQueue-1 MessageQueue-1.example.com xxx.xx.69.247 MessageQueue-2 MessageQueue-2.example.com xxx.xx.69.14 LoadBalancer-1 LoadBalancer-1.example.com LoadBalancer-3 LoadBalancer-3.example.com LoadBalancer-2 LoadBalancer-2.example.com xxx.xx.69.17 LoadBalancer-4 LoadBalancer-4.example.com xxx.xx.69.16 LoadBalancer-5 LoadBalancer-5.example.com LoadBalancer-6 LoadBalancer-6.example.com |
See Appendix H, Known Issues and Limitations for descriptions of problems encountered when implementing the deployment examples. The list will be updated as new information becomes available.
This chapter contains detailed instructions for the following tasks:
Use the following as your checklist for installing the Directory Servers:
The Java ES installer must be mounted on the host computer system where you will install Directory Server. See the section “To Download and Unpack the Java Enterprise System 2005Q4 Installer”3.2 Downloading and Mounting the Java Enterprise System 2005Q4 Installer in this document.
As a root user, log in to the host DirectoryServer–1.
Start the installer with the nodisplay option. Example:
# cd /mnt/Solaris_sparc # ./installer -nodisplay
When prompted, provided the following information:
|
Press Enter. |
|
|
Press Enter. |
|
|
Enter y. |
|
|
Enter 8 to select “English only.” |
|
|
Enter 6,20. Be sure you've specified Sun Java System Administration Server 5 2005Q4 and Sun Java System Directory Server 5 2005Q4. |
|
|
Press Enter. |
|
|
If upgrades are required, enter 1 to upgrade shared components. |
|
|
Accept the default value for each product. |
|
|
Enter 1 to continue. |
|
|
Enter 1 to configure now. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
For this example, enter d1r4dmin. |
|
|
Enter the same password again. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
For this example, enter d1r4dmin. |
|
|
Enter the same password again. |
|
|
Accept the default value. |
|
|
For this example, enter d1rm4n4ger. |
|
|
Enter the same password again. |
|
|
Accept the default value. |
|
|
Enter ds-config. |
|
|
Enter 1390. |
|
|
Enter dc=example,dc=com. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Enter 1 to choose “The new instance will be the configuration directory server.” |
|
|
Enter 1 to store data in the new directory server. |
|
|
Enter 4 to choose “Populate with no data.” |
|
|
Enter n. |
|
|
Accept the default value. |
|
|
Enter 1391. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
For this example, enter d1r4dmin. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Enter 1 to install now. |
(Optional) During installation, you can monitor the log to watch for installation errors. Example:
# cd /var/sadm/install/logs
# tail —f Java_Enterprise_System_install.B xxxxxx
Upon successful installation, enter ! to exit.
Verify that Directory Server was successfully installed.
As a root user, log into the host DirectoryServer–1.
Start the Directory Server.
# cd /var/opt/mps/serverroot/slapd-ds-config # ./stop-slapd; ./start-slapd
Use the tail command to monitor the Directory Server error log and see that the server successfully starts up.
# tail -50 logs/errors
Use the netstat command to verify that the Directory Server port is open and listening.
# netstat -an | grep 1390 * 1390 *.* 0 0 49152 0 LISTEN
Start the Administration Server that manages Directory Server.
cd /var/opt/mps/serverroot ./stop-admin; ./start-admin
Installation is successful if the Administration Server displays a start-up message.
Use the netstat command to verify that the Administration Server port is open and listening.
# netstat -an | grep 1391 * 1391 *.* 0 0 49152 0 LISTEN
As a root user, log in to the host DirectoryServer–2.
Start the installer with the nodisplay option. Example:
# cd /mnt/Solaris_sparc # ./installer -nodisplay
When prompted, provided the following information:
|
Press Enter. |
|
|
Press Enter. |
|
|
Enter y. |
|
|
Enter 8 to select “English only.” |
|
|
Enter 6,20. Be sure you've specified Sun Java System Administration Server 5 2005Q4 and Sun Java System Directory Server 5 2005Q4. |
|
|
Press Enter. |
|
|
If upgrades are required, enter 1 to upgrade shared components. |
|
|
Accept the default value for each product. |
|
|
Enter 1 to continue. |
|
|
Enter 1 to configure now. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
For this example, enter d1r4dmin. |
|
|
Enter the same password again. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
For this example, enter d1r4dmin. |
|
|
Enter the same password again. |
|
|
Accept the default value. |
|
|
For this example, enter d1rm4n4ger. |
|
|
Enter the same password again. |
|
|
Accept the default value. |
|
|
Enter ds-config. |
|
|
Enter 1390. |
|
|
Enter dc=example,dc=com. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Enter 1 to choose “The new instance will be the configuration directory server.” |
|
|
Enter 1 to store data in the new directory server. |
|
|
Enter 4 to choose “Populate with no data.” |
|
|
Enter n. |
|
|
Accept the default value. |
|
|
Enter 1391. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
For this example, enter d1r4dmin. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Enter 1 to install now. |
(Optional) During installation, you can monitor the log to watch for installation errors. Example:
# cd /var/sadm/install/logs
# tail —f Java_Enterprise_System_install.B xxxxxx
Upon successful installation, enter ! to exit.
Verify that Directory Server was successfully installed.
Log in as a root user to DirectoryServer–2.
Start the Directory Server.
# cd /var/opt/mps/serverroot/slapd-ds-config # ./stop-slapd; ./start-slapd
Use the tail command to monitor the Directory Server error log and verify that the server successfully starts up.
# tail -50 logs/errors
Use the netstat command to verify that the Directory Server port is open and listening.
# netstat -an | grep 1390 * 1390 *.* 0 0 49152 0 LISTEN
Start the Administration Server that manages Directory Server.
cd /var/opt/mps/serverroot ./stop-admin; ./start-admin
Installation is successful if the Administration Server displays a start-up message.
Use the netstat command to verify that the Administration Server port is open and listening.
# netstat -an | grep 1391 * 1391 *.* 0 0 49152 0 LISTEN
Create a new data instance for storing the Access Manager configuration data. This ensures that if you ever have to uninstall or restore Access Manager configuration, the Directory Server configuration remains untouched and will not have to be restored.
As a root user, log in to host DirectoryServer-1.
Set the X window display variable, and start the Directory Server console.
# cd /var/opt/mps/serverroot/ # export DISPLAY=DirectoryServer-1.example.com:1 # ./startconsole &
Log in to the Directory Server 1 console using the following information:
cn=Directory Manager
d1rm4n4ger
http://DirectoryServer-1.example.com:1391
In the Directory Server console, under the Servers and Applications tab, expand the Server Administration domain list until you see the Server Group item.
Right-click on Server Group, and choose “Create an instance of Sun Directory Server.”
In the Create New Instance dialog box, provide the following information:
Enter am-config.
Enter 1389.
Enter o=example.com.
Enter cn=Directory Manager
For this example, enter d1rm4n4ger.
Enter the same password to confirm it.
Enter nobody.
Click OK, and then close the status window.
Verify that the new Directory Server instance named am-config successfully starts up .
As a root user, log into host DirectoryServer–2.
Set the X window display variable, and start the Directory Server console.
# cd /var/opt/mps/serverroot/ # export DISPLAY=DirectoryServer-2.example.com:1 # ./startconsole &
Log in to the Directory Server 2 console using the following information:
cn=Directory Manager
d1rm4n4ger
http://DirectoryServer-2.example.com:1391
In the Directory Server console, under the Servers and Applications tab, expand the Server Administration domain list until you see Server Group item.
Right-click on Server Group, and choose “Create an instance of Sun Directory Server.”
In the Create New Instance dialog box, provide the following information:
Enter am-config.
Enter 1389.
Enter o=example.com.
Enter cn=Directory Manager
For this example, enter d1rm4n4ger.
Enter the same password to confirm it.
Enter root.
Click OK, and then close the status window.
Verify that the new Directory Server instance named am-config successfully starts up .
As a root user, log into host DirectoryServer–2.
Start the new data Directory Server instance.
# cd /var/opt/mps/serverroot/slapd-am-config # ./stop-slapd; ./start-slapd |
Use the tail command to monitor the Directory Server error log and see that the server starts up successfully.
# tail —f logs/errors |
In this procedure you enable multi-master replication (MMR) between two directory masters. Then you use the data and schema from the first directory master to initialize the second directory master. When you're finished, you will have two Directory Servers, and each will contain two instances. The instance named ds-config stores Directory Server administration configuration. The instance named am-config stores the user data and Access Manager configuration.
On each Directory Server, the ds-config instance is a local configuration instance. Do not replicate this instance to other host systems. On each Directory Server, the am-config instance is the directory data instance. You enable the am-config instance for MMR with its counterpart on the other Directory Server host.
Use the following as your checklist for enabling multi-master replication:
On Directory Server 1, start the Directory Server console.
# cd /var/opt/mps/serverroot/ # ./startconsole & |
Log in to the Directory Server 1 console using the following information:
cn=Directory Manager
d1rm4n4ger
http://DirectoryServer-1.example.com:1391
In the Directory Server console, under the Servers and Applications tab, expand the Server Administration domain list until you see the Server Group item.
Click to expand the Server Group.
You should see three items: an Administration Server, a Directory Server (am-config), and a Directory Server (ds-config).
Double-click the instance name Directory Server (am-config) to display the console for managing the instance am-config.
Click the Configuration tab and navigate to the Replication pane.
Click the “Enable replication” button to start the Replication Wizard.
Select Master Replica, and then click Next to continue.
Enter a Replica ID, and then click Next.
For this example, when enabling replication on DirectoryServer-1, assign the number 11.
If you have not already been prompted to select the change log file, you are prompted to select one now.
The default change log file is shown in the text field. If you do not wish to use the default, type in a filename for the change log, or click Browse to display a file selector. If the change log has already been enabled, the wizard will skip this step.
If you have not already been prompted to enter and confirm a password for the default replication manager, you are prompted now.
The replication manager is not used in the case of single-master replication, but you must still enter a password to proceed. For this example, enter replm4n4ger.
The Replication Wizard displays a status message while updating the replication configuration.
Click Close when replication is finished.
On Directory Server 2, start the Directory Server console.
# cd /var/opt/mps/serverroot/ # ./startconsole & |
Log in to the Directory Server 2 console using the following information:
cn=Directory Manager
d1rm4n4ger
http://DirectoryServer-2.example.com:1391
In the Directory Server console, under the Servers and Applications tab, expand the Server Administration domain list until you see the Server Group item.
Click to expand the Server Group.
You should see three items: an Administration Server, a Directory Server (am-config), and a Directory Server (ds-config).
Double-click the instance name Directory Server (am-config) to display the console for managing the instance am-config.
Click the Configuration tab and navigate to the Replication pane.
Click the “Enable replication” button to start the Replication Wizard.
Select Master Replica, and then click Next to continue.
Enter a Replica ID, and then click Next.
For this example, when enabling replication on DirectoryServer-2, assign the number 22.
If you have not already been prompted to select the change log file, you are prompted to select one now.
The default change log file is shown in the text field. If you do not wish to use the default, type in a filename for the change log, or click Browse to display a file selector. If the change log has already been enabled, the wizard will skip this step.
If you have not already been prompted to enter and confirm a password for the default replication manager, you are prompted now.
The replication manager is not used in the case of single-master replication, but you must still enter a password to proceed. For this example, enter replm4n4ger .
The Replication Wizard displays a status message while updating the replication configuration.
Click Close when replication is finished.
On DirectoryServer-1, in the Directory Server console, display the general properties for the Directory Server instance named am-config .
Navigate through the tree in the left panel to find the Directory Server instance named am-config, and click on the instance name to display its general properties.
Click the Open button to display the console for managing the am-config instance.
Click the Configuration tab and navigate to the Replication pane.
Click the New button.
In the Replication Agreement dialog box, click the Other button.
In the Remote Server dialog box, provide the following information, and then click OK.
DirectoryServer-2.example.com
1389
Leave this box unmarked.
In the Replication Agreement dialog, for the distinguished name (DN) of the replication manager entry on the consumer server, accept the default value.
By default, the DN is that of the default replication manager.
For the password of the replication manager, enter replm4n4ger.
(Optional) Provide a description string for this agreement.
For this example, enter Replication from DirectoryServer-1 to DirectoryServer-2.
Click OK when done.
In the confirmation dialog, click Yes to test the connection to the server and port number.
Use the given replication manager and password replm4n4ger.
If the connection fails, you will still have the option of using this agreement. For example, the parameters are correct but the server is offline. When you have finished, the agreement appears in the list of replication agreements for this master replica.
On DirectoryServer-2, in the Directory Server console, display the general properties for the Directory Server instance named am-config.
Navigate through the tree in the left panel to find the Directory Server instance named am-config, and click on the instance name to display its general properties.
Click the Open button to display the console for managing the am-config instance.
Click the Configuration tab and navigate to the Replication pane.
Click the New button.
In the Replication Agreement dialog box, click the Other button.
In the Remote Server dialog box, provide the following information, and then click OK.
DirectoryServer-1.example.com
1389
Leave this box unmarked.
In the Replication Agreement dialog, for the distinguished name (DN) of the replication manager entry on the consumer server, accept the default value.
By default, the DN is that of the default replication manager.
For the password of the replication manager, enter replm4n4ger.
(Optional) Provide a description string for this agreement.
For this example, enter Replication from DirectoryServer-2 to DirectoryServer-1.
Click OK when done.
In the confirmation dialog, click Yes to test the connection to the server and port number.
Use the given replication manager and password.
If the connection fails, you will still have the option of using this agreement. For example, the parameters are correct but the server is offline. When you have finished, the agreement appears in the list of replication agreements for this master replica.
On DirectoryServer–1, in the Directory Server console, navigate through the tree in the left panel to find the Directory Server instance named am-config, and click on the instance name to display its general properties.
Double-click the instance name Directory Server (am-config) in the tree to display the console for managing the data.
Click the Configuration tab and navigate to the Replication pane.
In the list of defined agreements, select the replication agreement corresponding to DirectoryServer-2, the consumer you want to initialize.
Click Action > Initialize remote replica.
A confirmation message warns you that any information already stored in the replica on the consumer will be removed.
In the Confirmation dialog, click Yes.
Online consumer initialization begins immediately. The icon of the replication agreement shows a red gear to indicate the status of the initialization process.
Click Refresh > Continuous Refresh to follow the status of the consumer initialization.
Any messages for the highlighted agreement will appear in the text box below the list.
Verify that replication is working properly.
Log in to both Directory Server hosts as a root user, and start both Directory Server consoles.
Log in to each Directory Server console.
In each Directory Server console, enable the audit log on both Directory Server instances.
Go to Configuration > Logs > Audit Log. Check Enable Logging, and then click Save.
In separate terminal windows , use the tail -f command to watch the audit log files change.
On DirectoryServer-1, in the Directory Server console, create a new user entry.
Go to the Directory tab, and right-click the suffix o=example. Then click New > Group.
Name the new group People, and then click OK.
Click People, and then right-click to choose New > User.
In the Create New User dialog, enter a first name and last name, an then click OK.
Note the user entry is created in the instance audit log. Check to be sure the same entry is also created in on DirectoryServer-2 in the Directory Server instance audit log
On DirectoryServer-2, in the Directory Server console, create a new user entry.
Go to the Directory tab, and right—click the suffix o=example.comClick People, and then right-click to choose New > User.
In the Create New User dialog, enter a first name and last name, an then click OK.
Note the user entry is created in the instance audit log. Check to be sure the same entry is also created in on DirectoryServer-1 in the Directory Server instance audit log
Delete both new user entries in the Directory Server 2 console.
Look in the Directory Server 1 console to verify that both users have been deleted.
In the following procedures, you configure the load balancer in front of the two Directory Servers. Then you configure the load balancer for simple persistence. When the load balancer is configured for simple persistence, all Access Manager requests sent within a specified interval are sent to the same Directory Server for processing. Simple persistence ensures that within the specified interval, no errors or delays occur due to replication time or redirects when retrieving data.
When a request requires information to be written to Directory Server 1, that information is also replicated in Directory Server 2. But the replication takes time to complete. During that time, if a related request is directed by the load balancer to Directory Server 2, the request may fail.
For example, when simple persistence is not configured properly, creating a realm from the Access Manager administration console could fail in the following way. A request for the parent entry creation is routed to Directory Server 1, and a second request to create the subentry is routed to Directory Server 2. But if the parent entry request is not yet fully replicated to Directory Server 2, the subentry request fails. The result is a partially created realm which may not contain all its subentries such as realm administration roles. Simple persistence eliminates this type of error. When persistence is properly configured, both the parent entry request and the subentry request are routed to Directory Server 1. The requests are processed in consecutive order. The parent entry is fully created before the subentry request begins processing.
Contact your network administrator to obtain an available virtual IP address for the load balancer you want to configure.
You must also 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.
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.
You must also have ready the IP addresses for Directory Server 1 and Directory Server 2.
To obtain these IP addresses, on each Directory Server host, run the following command:
ifconfig —a
Create a Pool.
A pool contains all the backend server instances.
Go to URL for the Big IP load balancer login page.
Open the Configuration Utility.
Click “Configure your BIG-IP (R) using the Configuration Utility.”
In the left pane, click Pools.
On the Pools tab, click the Add button.
In the Add Pool dialog, provide the following information:
Example: directoryserver-pool
Round Robin
Add the IP address of both Directory Server hosts. In this case, add the IP address and port number for DirectoryServer-1:1389 and for DirectoryServer-2:1389.
Click the Done button.
Add a Virtual Server.
If you encounter Javascript errors or otherwise cannot proceed to create a virtual server, try using Microsoft Internet Explorer for this step.
In the left frame, Click Virtual Servers.
On the Virtual Servers tab, click the Add button.
In the Add a Virtual Server dialog box, provide the following information:
xxx.xx.69.14 (for LoadBalancer-1.example.com )
389
directoryserver-pool
Continue to click Next until you reach the Pool Selection dialog box.
In the Pool Selection dialog box, assign the Pool (DirectoryServer-POOL) that you have just created.
Click the Done button.
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.
Three columns exist on this page: Node, Node Address, and Service. In the Node column, locate the IP address and port number DirectoryServer–1:1389. 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 for DirectoryServer–2:1389 . 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.
Simple persistence returns a client to the same node to which it connected previously. 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 of each Directory Server.
On each Directory Server host, use the tail command to monitor the Directory Server access log.
# cd /var/opt/mps/serverroot/slapd-am-config/logs
# tail -f access
You should see connections to the load balancer IP address opening and closing. Example:
[12/Oct/2006:13:10:20-0700] conn=54 op=-1 msgId=-1 — fd=22 slot=22 LDAP connection from xxx.xx.69.18 to xxx.xx.72.33
[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 multiple times against the Directory Server load balancer:
# cd /var/opt/mps/serverroot/shared/bin/ # ./ldapsearch -h LoadBalancer-1.example.com -p 389 -b "o=example.com" -D "cn=directory manager" -w d1rm4n4ger "(objectclass=*)" |
The ldapsearch operation should return entries. Make sure the LDAP search operations display in the same Directory Server access log.
Stop Directory Server 1, and again perform the following LDAP search against the Directory Server load balancer:
# cd /var/opt/mps/serverroot/slapd-am-config # ./stop # cd /var/opt/mps/serverroot/shared/bin/ # ./ldapsearch -h LoadBalancer-1.example.com -p 389 -b "o=example.com" -D "cn=directory manager" -w d1rm4n4ger "(objectclass=*)" |
The ldapsearch operation should return entries. Verify that the Directory Server access entries display in only one Directory Server access log.
You may encounter the following error message:
# ./ldapsearch —h LoadBalancer-1.example.com —p 1389 —b “o=example.com“ —D “cn=Directory Manager” —w d1rm4n4ger
ldap_simple_bind: Cant' connect to the LDAP server — Connection refused
The load balancer may not fully detect that Directory Server 1 is stopped. Or 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 can wait ten seconds to start the search again. Or you can reset the timeout properties to a lower value.
Click the Monitors tab, and 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.
The default is 16 seconds. You can change this number to any value. In this deployment example, the BigIP documentation recommends the value should be at least three times the interval number of seconds plus one second.
Click Apply.
Repeat the LDAP search.
Restart the stopped Directory Server 1, and then stop Directory Server 2.
Confirm that the requests are forwarded to the running Directory Server 2.
Perform the following LDAP search against the Directory Server load balancer.
# cd /var/opt/mps/serverroot/shared/bin/ # ./ldapsearch -h LoadBalancer-1.example.com -p 389 -b "o=example.com" -D "cn=Directory Manager" -w d1rm4n4ger "(objectclass=*)" |
The ldapsearch operation should return entries. Make sure the directory access entries display in only the one Directory Server access log.
This chapter contains detailed instructions for the following tasks:
Use the following as your checklist for installing the Access Manager servers:
Configure the Access Manager infrastructure to work with multiple instances.
Back up the Access Manager configuration in Directory Server.
You must have a CD image of the Sun Java Enterprise System product mounted on the host computer system where you are installing Access Manger. For information on obtaining and mounting the Sun Java Enterprise System, see 3.2 Downloading and Mounting the Java Enterprise System 2005Q4 Installer in this document.
As a root user, log into host AccessManager-1.
Unzip the two zip files that comprise the Java Enterprise System installer binaries.
Start the installer with the -nodisplay option.
# cd /mnt/Solaris_sparc # ./installer -nodisplay |
When prompted, provide the following information:
|
Press Enter. |
|
|
Press Enter. |
|
|
Enter n. |
|
|
Enter y. |
|
|
Enter 8 for “English only.” |
|
|
Press ENTER to continue. |
|
|
Enter 3,9,12 to select Web Server, Access Manager, and Message Queue. The Message Queue packages you install now will be used when you implement session failover later in the deployment. |
|
|
Enter -20 to deselect Directory Server. |
|
|
Press Enter. |
|
|
Enter D. |
|
|
Press Enter. |
|
|
Enter 2. |
|
|
Enter 1. |
|
|
Enter 1. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Enter 1 to configure now. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
For this example, enter web4dmin. |
|
|
Enter the same password again. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
For this example, enter web4dmin. |
|
|
Enter the same password again. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Enter root. |
|
|
Enter root. |
|
|
Enter 1080. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
For this example, enter 4m4dmin1. |
|
|
Enter the same password again. |
|
|
Accept the default value. |
|
|
For this example, enter 4mld4puser. Much later in the deployment, in a subsequent task, you use this password as the Web Policy Agent “shared secret.” |
|
|
Enter the same password again. |
|
|
Accept the default value and make note of this key string. You will need it when you install Access Manager 2. |
|
|
Enter Realm. |
|
|
Enter 2. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Enter DirectoryServer-1.example.com. |
|
|
Enter 1389. This is the port number you entered for the data instance of Directory Server. |
|
|
Enter o=example.com |
|
|
Accept the default value. |
|
|
For this example, enter d1rm4n4ger. |
|
|
Accept the default value No. |
|
|
First, see the next numbered (Optional) step. When you're ready to install, enter 1 to start the installation. |
(Optional) During installation, you can monitor the log to watch for installation errors. Example:
# cd /var/sadm/install/logs
# tail —f Java_Enterprise_System_install.B xxxxxx
Upon successful installation, enter ! to exit.
Start the Access Manager Web Server.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com
# ./stop; # ./start
Verify that Access Manager has been installed successfully.
Go to the Access Manager login URL:
http://AccessManager-1.example.com:1080/amserver/console
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
You should be able to log in successfully and to navigate to various areas of the console with no error messages.
If you have configured everything so far according to these instructions, and the following error message is displayed “No such Organization found,” it is probably due to the mixed— case Access Manager host names used in this deployment example. For example, the host name AccessManager-1.example.com includes both upper and lower case letters. For more detailed information, see Appendix H, Known Issues and Limitations.
You must have a CD image of the Sun Java Enterprise System product mounted on the host computer system where you are installing Access Manger. For information on obtaining and mounting the Sun Java Enterprise System, see 3.2 Downloading and Mounting the Java Enterprise System 2005Q4 Installer in this document.
As a root user, log in to host AccessManager-2.
Unzip the two zip files that comprise the Java Enterprise System installer binaries.
Start the installer with the -nodisplay option.
# cd /mnt/Solaris_sparc # ./installer -nodisplay |
When prompted, provide the following information:
|
Press Enter. |
||
|
Press Enter. |
||
|
Enter n. |
||
|
Enter yes. |
||
|
Enter 8 for “English only.” |
||
|
Press ENTER to continue. |
||
|
Enter 3,9, 12 to select Web Server, and Access Manager, and Message Queue. The Message Queue packages you install now will be used when you implement session failover later in the deployment. |
||
|
Enter -20 to deselect Directory Server. |
||
|
Press Enter. |
||
|
Enter D. |
||
|
Press Enter. |
||
|
Enter 2. |
||
|
Enter 1. |
||
|
Enter 1. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Enter 1 to configure now. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
For this example, enter web4dmin. |
||
|
Enter the same password again. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
For this example, enter web4dmin. |
||
|
Enter the same password again. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Enter root. |
||
|
Enter root. |
||
|
Enter 1080. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
For this example, enter 4m4dmin1. |
||
|
Enter the same password again. |
||
|
Accept the default value. |
||
|
For this example, enter 4mld4puser. Much later in the deployment, in a subsequent task, you use this password as the Web Policy Agent “shared secret.” |
||
|
Enter the same password again. |
||
|
This password encryption key must be identical to the key that was generated and entered when you installed Access Manager 1. In this deployment example, the string is
|
||
|
Enter Realm. |
||
|
Enter 2. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Enter DirectoryServer-2.example.com. |
||
|
Enter 1389. This is the port number you entered for the data instance of Directory Server. |
||
|
Enter o=example.com |
||
|
Accept the default value. |
||
|
For this example, enter d1rm4n4ger. |
||
|
Accept the default value No. |
||
|
First, see the next numbered (Optional) step. When you're ready to install, enter 1 to start the installation. |
(Optional) During installation, you can monitor the log to watch for installation errors. Example:
# cd /var/sadm/install/logs
# tail —f Java_Enterprise_System_install.Bxxxxxx
Upon successful installation, enter ! to exit.
Start the Access Manager Web Server.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com
# ./stop
# ./start
Add the lowercase host name accessmanager-2.example.com to the Realm alias list.
This eliminates the need to enter the full path to the user's organization each time you want to log in to Access Manager.
Go to the following URL:
http://AccessManager-1.example.com:1080/amserver/UI/Login?org=example.com
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
On the Access Control tab, under Realms, click the example.com realm name.
On the General tab, under Realm Attributes, in the Add field enter the name accessmanager-2.example.com (all lowercase).
Click Add, and then click Save.
Click “Log Out.”
Verify that Access Manager has been installed successfully.
Go to the Access Manager login URL:
http://AccessManager-2.example.com:1080/amserver/console
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
You should be able to log in successfully and to navigate to various areas of the console with no error messages.
Do not try to log in to the second Access Manager server because the instance is not fully configured to be used yet. Access Manager 2 is enabled in the following procedure.
In this procedure, you configure both Access Manager 1 and Access Manager 2 to operate as two instances of a single server. All configuration takes place on the Access Manager 1 host. There is no need to repeat the steps on the Access Manager 2 host.
On AccessManager-1, start a new browser, and go to the URL for the Access Manager console.
Example: http://AccessManager-1.example.com:1080/amserver/console
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
On the Access Control tab, under Realm Name, click the top-level realm.
In this example, the top-level realm is example.
On the General tab, under Realm Attributes, add AccessManager—2.example.com to the Realms/DNS Aliases list.
Go to Realms > Configuration.
On the Configuration tab, click System Properties > Platform.
On the Platform page, add a new instance name.
Click the Log Out button to log out of the console.
Verify that both Access Manager servers are configured properly.
As a root user, log in to host AccessManager-1.
Restart the Access Manager server by restarting the Web Server.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com # ./stop; ./start |
Check for errors on the start-up screen and in the Web Server error log as the server restarts.
As a root user, log in to host AccessManager-2.
Restart the Access Manager server by restarting the Web Server.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com # ./stop; ./start |
Check for errors on the start-up screen and in the Web Server error log as the server restarts.
Start a new browser and to go the URL for the other Access Manager server.
Example: http://AccessManager-2.example.com:1080/amserver/console
Log in as to the Access Manager console using the following information:
amadmin
4m4dmin1
If you can log in successfully, close the browser.
If you cannot log in successfully, restart Access Manager 2. Be sure that the Access Manager 2 host can access the Directory Server 1 host.
Log out of the Access Manager console.
When you cannot log in successfully, one way to troubleshoot is to log in using the fully qualified name for the user amadmin . If you can authenticate using the fully qualified name, you can focus on issues other than authentication and log in. In the file /etc/opt/SUNWam/config/AMConfig.properties, look for the following entry:
com.sun.identity.authentication.super.user=uid=amAdmin,ou=People,o=example.com
Use the fully qualified User Name uid=amAdmin,ou=People,o=example.com to log in.
Backing up your Access Manager configuration ensures that if you run into problems later in the deployment, you can revert to this configuration without having to re-install Access Manager.
On Directory Server 1, in the slapd-am-config directory, run the db2ldif script.
# cd /var/opt/mps/serverroot/slapd-am-config/ # ./stop # ./db2ldif -n userroot ldiffile: /var/opt/mps/serverroot/slapd-am-config/ldif/2006_03_14_111537.ldif [14/Mar/2006:11:15:40 -0800] - export userRoot: Processed 112 entries (31%). [14/Mar/2006:11:15:41 -0800] - export userRoot: Processed 224 entries (62%). [14/Mar/2006:11:15:42 -0800] - export userRoot: Processed 338 entries (94%). [14/Mar/2006:11:15:42 -0800] - export userRoot: Processed 360 entries (100%). |
(Optional) You can create a readme file that describes the contents of the new ldif file.
# cd /var/opt/mps/serverroot/slapd-am-config/ldif # ls 2006_03_14_111537.ldif Example-Plugin.ldif Example.ldif European.ldif Example-roles.ldif # cat > README 2006_03_14_111537.ldif: backup after post-am install, pre-patch application ^D # ls -l 2006_03_14_111537.ldif Example-Plugin.ldif Example.ldif European.ldif Example-roles.ldif README |
The Access Manager 7 2005Q4 SP5 patch must be copied to the Access Manager host computer system. Patches are available for systems that use the SolarisTM Operating System (Solaris OS) or Linux operation system. You can download the following patches for from SunSolve Online (http://sunsolve.sun.com/).
Solaris OS on SPARC® based systems |
http://sunsolve.sun.com/search/document.do?assetkey=1-21-120954-03 |
Solaris OS on x86 platforms |
http://sunsolve.sun.com/search/document.do?assetkey=1-21-120955-03 |
Linux systems |
http://sunsolve.sun.com/search/document.do?assetkey=1-21-120956-03 Note – No Linux systems were used in this deployment. For Linux detailed patch instructions, see the Readme file that comes with the patch. |
Use the following as your checklist for applying Service Patch 5:
As a root user, log in to host AccessManager-1.
Unzip the patch file. Example:
# cd /temp # ls 120954-05.zip # unzip 120954-03.zip |
Run the patchadd command.
(On Solaris 10) # patchadd -G /temp/120954-05
For other platforms, see the Readme file that comes with the patch.
After successful installation ,a draft amsilent file is created in /opt/SUNWamdirectory. This amsilent is based on /opt/SUNWam/bin/amsamplesilent , but with some required parameters set according to the AM config files on this system.
Redeploy the Access Manager applications.
For detailed information about the following substeps, see the Release Notes (120954-05/rel_notes.html) that come with the patch.
In the amsilent file, use a text editor to uncomment and modify the value of each password parameter, and verify the accuracy of other parameters in this file.
In the following example, the entries in bold have been uncommented and modified.
# cd opt/SUNWam
# vi amsilent
... # The following entries contain sample values! # These should be modified for your specific installation # and then uncommented (remove the # from the line) # SERVER_NAME=AccessManager-1 SEVER_HOST=AccessManager-1.example.com SERVER_PORT=1080 ADMIN_PORT=8888 DS_HOST=DirectoryServer-1.example.com DS_DIRMGRPASSWD=d1rm4n4ger ROOT_SUFFIX="o=example.com" ADMINPASSWD=4m4dmin1 AMLDAPUSERPASSWD=4mld4puser COOKIE_DOMAIN=example.com AM_ENC_PWD=13MRBS4UH1fXNnfp3i/44elABip5CTnk NEW_OWNER=rootNEW_GROUP=otherPAM_SERVICE_NAME=other WEB_CONTAINER=WS6 ... DIRECTORY_MODE=5 DS_PORT=1389 ...
Run the following amconfig command:
# cd /opt/SUNWam/bin
# ./amconfig -s /opt/SUNWam/amsilent
Update the Access Manager schema.
In the directory where you unzipped the patch files, run the updateschema.sh command.
Provide information when prompted. See the following example:
# cd /tmp/120954-05 # ./udpateschema.sh Executing updateschema.sh, the lof file is /var/opt/SUNWam/logs/AM70Patch.upgrade.schema.03080833 Directory Server fully-qualified hostname (LoadBalancer-1.example.com): DirectoryServer-1.example.com Directory manager dn (cn=Directory Manager): Directory manager password: Top-Level Administrator DN (uid=amAdmin,ou=People,o=example.com): Top-Level Adminsitrator password: loading /etc/opt/SUNWam/accountLockout.ldif..... modifying entry cn=schema updateschema.sh done! |
Restart Directory Server 1.
# cd /var/opt/mps/serverroot/slapd-am-config # ./stop; start |
Check the error log to be sure there are no startup errors.
Restart Directory Server 2.
# cd /var/opt/mps/serverroot/slapd-am-config # ./stop; start |
Check the error log to be sure there are no startup errors.
Change the Server Name to Load Balancer 1 in the serverconfig.xml file.
This step is necessary because a load balancer is used between the two Access Manager servers.
# cd /etc/opt/SUNWam/config # vi serverconfig.xml <iPlanetDataAccessLayer> <ServerGroup name="default" minConnPool="1" maxConnPool="10"> <Server name="Server1" host="LoadBalancer-1.example.com" port="389" type="SIMPLE" /> <User name="User1" type="proxy"> <DirDN> cn=puser,ou=DSAME Users,o=example.com </DirDN> <DirPassword> AQICMvvJ0xQN1lpFwZ9IjTPISL2TOx1yX2N8 </DirPassword> </User> <User name="User2" type="admin"> <DirDN> cn=dsameuser,ou=DSAME Users,o=example.com </DirDN> <DirPassword> AQICMvvJ0xQN1lpFwZ9IjTPISL2TOx1yX2N8 </DirPassword> </User> <BaseDN> o=example.com </BaseDN> </ServerGroup> </iPlanetDataAccessLayer> |
Save the file.
Verify that the patch was successfully installed.
Restart the Access Manager 1 Web Server.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com # ./stop; ./start
Use the version command to display installed patches.
# cd /opt/SUNWam/bin # ./amadmin --version Sun Java System Access Manager 7 2005Q4 patch 120954-05 |
On AccessManager-1, start a new browser and go to the URL of Access Manager 1.
http://AccessManager-1:1080/amserver/console
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
If you can log in successfully, close the browser.
As a root user, log in to host AccessManager-2.
Unzip the patch file. Example:
# cd /temp # ls 120954-05.zip # unzip 120954-03.zip |
Run the patchadd command.
(On Solaris 10) # patchadd -G /temp/120954-05
For other platforms, see the Readme file that comes with the patch.
After successful installation ,a draft amsilent file is created in /opt/SUNWamdirectory. This amsilent is based on /opt/SUNWam/bin/amsamplesilent , but with some required parameters set according to the AM config files on this system.
Redploy the Access Manager applications.
For detailed information about the following substeps, see the Release Notes (120954-05/rel_notes.html) that come with the patch.
In the amsilent file, use a text editor to uncomment and modify the value of each password parameter, and verify the accuracy of other parameters in this file.
In the following example, the entries in bold have been uncommented and modified.
# cd opt/SUNWam
# vi amsilent
... # The following entries contain sample values! # These should be modified for your specific installation # and then uncommented (remove the # from the line) # SERVER_NAME=AccessManager-2 SEVER_HOST=AccessManager-2.example.com SERVER_PORT=1080 ADMIN_PORT=8888 DS_HOST=DirectoryServer-2.example.com DS_DIRMGRPASSWD=d1rm4n4ger ROOT_SUFFIX="o=example.com" ADMINPASSWD=4m4dmin1 AMLDAPUSERPASSWD=4mld4puser COOKIE_DOMAIN=example.com AM_ENC_PWD=13MRBS4UH1fXNnfp3i/44elABip5CTnk NEW_OWNER=rootNEW_GROUP=otherPAM_SERVICE_NAME=other WEB_CONTAINER=WS6 ... DIRECTORY_MODE=5 DS_PORT=1389 ...
Run the amconfig command:
# cd /opt/SUNWam/bin
# ./amconfig -s /opt/SUNWam/amsilent
Update the Access Manager schema.
In the directory where you unzipped the patch files, run the updateschema.sh command.
Provide information when prompted. See the following example:
# cd /tmp/120954-05 # ./udpateschema.sh Executing updateschema.sh, the lof file is /var/opt/SUNWam/logs/AM70Patch.upgrade.schema.03080833 Directory Server fully-qualified hostname (LoadBalancer-1.example.com): DirectoryServer-2.example.com Directory manager dn (cn=Directory Manager): Directory manager password: Top-Level Administrator DN (uid=amAdmin,ou=People,o=example.com): Top-Level Adminsitrator password: loading /etc/opt/SUNWam/accountLockout.ldif..... modifying entry cn=schema updateschema.sh done! |
Restart Directory Server 1.
# cd /var/opt/mps/serverroot/slapd-am-config # ./stop; start |
Check the error log to be sure there are no startup errors.
Restart Directory Server 2.
# cd /var/opt/mps/serverroot/slapd-am-config # ./stop; start |
Check the error log to be sure there are no startup errors.
Change the Server Name to Load Balancer 1 in the serverconfig.xml file.
This step is necessary because a load balancer is used between the two Access Manager servers.
# cd /etc/opt/SUNWam/config # vi serverconfig.xml <iPlanetDataAccessLayer> <ServerGroup name="default" minConnPool="1" maxConnPool="10"> <Server name="Server1" host="LoadBalancer-1.example.com" port="389" type="SIMPLE" /> <User name="User1" type="proxy"> <DirDN> cn=puser,ou=DSAME Users,o=example.com </DirDN> <DirPassword> AQICMvvJ0xQN1lpFwZ9IjTPISL2TOx1yX2N8 </DirPassword> </User> <User name="User2" type="admin"> <DirDN> cn=dsameuser,ou=DSAME Users,o=example.com </DirDN> <DirPassword> AQICMvvJ0xQN1lpFwZ9IjTPISL2TOx1yX2N8 </DirPassword> </User> <BaseDN> o=example.com </BaseDN> </ServerGroup> </iPlanetDataAccessLayer> |
Save the file.
Verify that the patch was successfully installed.
Restart the Access Manager 2 Web Server.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com # ./stop; ./start
Use the version command to display installed patches.
# cd /opt/SUNWam/bin # ./amadmin --version Sun Java System Access Manager 7 2005Q4 patch 120954-05 |
On AccessManager-2, start a new browser and go to the URL of Access Manager 2.
http://AccessManager-1:1080/amserver/console
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
If you can log in successfully, close the browser.
During the Access Manager installation, the installer requires that Access Manager run as a root user. If you want administrators who don't have root permissions to perform any administration tasks on Access Manager, you must reconfigure Access Manager to run as a non-root user.
You must use a port number higher than 1024. If the Web Server port is below 1024, then even after configuring the Access Manager server to run as a non-root user, you still must start Access Manager Web Server in a root shell.
As a root user, log into host AccessManager-1.
Stop Access Manager 1.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com/ # ./stop |
Stop the Web Server administration server.
# cd /opt/SUNWwbsvr/https-admserv/ # ./stop |
Change the “runs as” user ID from root to nobody.
# cd /opt/SUNWwbsvr/ # chown -R nobody:nobody https-AccessManager-1.example.com/* httpacl alias \ /var/opt/SUNWam /etc/opt/SUNWam # rm -rf /tmp/https-* |
Edit the magnus.conf file.
It is a good practice to make a backup of this or any other configuration file before making changes to the file.
# vi https-AccessManager-1.example.com/config/magnus.conf |
Change the User property value from root to nobody.
Verify that Access Manager successfully runs as a non-root user.
Log in as a root user to the Access Manager host.
Start the Access Manager server.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com/ # ./start |
Confirm that the Web Server start process actually runs as nobody.
# ps -ef | grep SUNWwbsvr |
Start a new browser and go to the Access Manager URL.
Example: http://AccessManager-1.example.com:1080/amserver/console
Close the browser if successful.
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
If you can log in successfully, close the browser.
As a root user, log into host AccessManager-2.
Stop Access Manager 2.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com/ # ./stop |
Stop the Web Server administration server.
# cd /opt/SUNWwbsvr/https-admserv/ # ./stop |
Change the “runs as” user ID from root to nobody.
# cd /opt/SUNWwbsvr/ # chown -R nobody:nobody https-AccessManager-2.example.cm/* httpacl alias /var/opt/SUNWam /etc/opt/SUNWam # rm -rf /tmp/https-* |
Edit the magnus.conf file.
# vi https-AccessManager-2.example.com/config/magnus.conf |
Change the User property value from root to nobody.
Verify that Access Manager 2 successfully runs as a non-root user.
As a root user, log into host AccessManager-2.
Start the Access Manager server.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com/ # ./start |
Confirm that the Web Server start process actually runs as nobody.
ps -ef | grep SUNWwbsvr |
Start a new browser and go to the Access Manager URL.
Example: http://AccessManager-2.example.com:1080/amserver/console Close the browser if successful.
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
If you can log in successfully, close the browser.
In this procedure, you reconfigure the administration server for each of the Web Servers that contain Access Manager. Although this is not required, it's a good practice to run the Access Manager Web Servers and their administration servers as the same non-root user ID. This eliminates permissions problems. For example, if the Access Manager Web Server runs as a non-root user, and its administration server runs as a root user, then files created by the administration server may not be readable by the Access Manager Web Server.
As a root user, log into host AccessManager-1.
Stop the Web Server administration server by issuing the commands:
# cd /opt/SUNWwbsvr/https-admserv # ./stop |
Change the “runs as” user ID from root to nobody.
# cd /opt/SUNWwbsvr/ # chown -R nobody:nobody https-admserv/* httpacl/ alias # rm -rf /tmp/https-admserv |
Edit the magnus.conf file.
Make a backup of this file before making changes to the file.
# vi https-admserv/config/magnus.conf |
Change the User property value from root to nobody.
Verify that the Web Server administration server successfully runs as a non–root user.
As a root user, log into host AccessManager-2.
Stop the Web Server administration server by issuing the commands:
# cd /opt/SUNWwbsvr/https-admserv # ./stop |
Change the “runs as” user ID from root to nobody.
# cd /opt/SUNWwbsvr/ # chown -R nobody:nobody https-admserv/* httpacl/ alias # rm -rf /tmp/https-admserv |
Edit the magnus.conf file.
# vi https-admserv/config/magnus.conf |
Change the User property value from root to nobody.
Verify that the Web Server administration server successfully runs as a non–root user.
In this procedure, you configure the Access Manager servers to access the Directory Server through the load balancer. All configuration changes you implement through the Access Manager 1 console will be replicated to Access Manager 2, so there is no need to repeat these steps on the Access Manager 2 console. However, you must also edit XML files in this task. You must manually edit the XML files on Access Manager 1 and on Access Manager 2.
The load balancer hardware and software used in the lab facility for this deployment is BIG-IP® manufactured by F5 Networks. If you are using different load balancer software, see the documentation that comes with that product for detailed settings information.
Use the following as your checklist for configuring the Access Manager load balancer:
Configure the Access Manager servers to access the Directory Server load balancer.
Verify successful Directory Server load balancing and system failover.
Verify that the Access Manager load balancer is configured properly.
Request an SSL certificate for the Access Manager load balancer.
Install a root CA certificate on the Access Manager load balancer.
Install an SSL certificate on the Access Manager load balancer.
Configure SSL termination on the Access Manager load balancer.
Go to the Access Manager URL.
http://AccessManager-1.example.com:1080/amserver/console
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
Click the Configuration tab.
Under Authentication, edit the following service configurations. Edit the service configurations to reflect the LDAP server name and port number LoadBalancer-1.example.com:1389
Under Authentication, for the following services, change the Primary LDAP server name and port to the load-balancer name and port. In this example, the new name is LoadBalancer-1.example.com:389 .
Under Authentication, click LDAP.
In the Primary LDAP Server list, Add LoadBalancer-1.example.com:389 and delete the default server from the list. Click Save, and the return to the Configuration tab.
Under Authentication, click Membership.
In the Primary LDAP Server list, Add LoadBalancer-1.example.com:389 and delete the default server from the list. Click Save, and the return to the Configuration tab.
Under Authentication, click MSISDN.
In the Primary LDAP Server list, Add LoadBalancer-1.example.com:389 and delete the default server from the list. Click Save, and the return to the Configuration tab.
Under Global Properties, click Policy Configuration.
In the Primary LDAP Server, add LoadBalancer-1.example.com:389 and delete the default server from the list. Click Save, and the return to the Configuration tab.
Edit the following property files on AccessManager–1.
Still logged in to the Access Manager server as a root user, use an editor to modify the file /etc/opt/SUNWam/config/serverconfig.xml.
Change LDAP serer host name and port number to the fully-qualified name and port number for Load Balancer 1 Example:
<iPlanetDataAccessLayer> <ServerGroup name="default" miConnPool="1" maxConnPool="10"> <Server name="Server1" host="LoadBalancer-1.example.com" port="389" type="SIMPLE"/> ... |
Use an editor to modify the file /etc/opt/SUNWam/config/AMConfig.properties.
Set the following properties:
com.iplanet.am.directory.port=389
com.iplanet.am.directory.host=LoadBalancer-1.example.com
com.sun.am.event.connection.idle.timeout=3
The connection idle time out value is set to 3 minutes. This value is less than the value for the Firewall 3–to-Load Balancer 1 connection timeout which is 5 minutes in this example. By setting this value to be 3 minutes, the Access Manager server will assume its persistent search connections may be silently dropped by Firewall 3–to-Load Balancer 1. The Access Manager server will re-establish the persistent search connections every 3 minutes. Otherwise, the Access Manager server may forever block on the persistent search because it is not made aware that the TCP connection is dropped silently.
Edit the following property files on AccessManager–2.
Still logged in to the Access Manager server as a root user, use an editor to modify the file /etc/opt/SUNWam/config/serverconfig.xml.
Change LDAP serer host name and port number to the fully-qualified name and port number for Load Balancer 1. Example:
<iPlanetDataAccessLayer> <ServerGroup name="default" miConnPool="1" maxConnPool="10"> <Server name="Server1" host="LoadBalancer-1.example.com" port="389" type="SIMPLE"/> ... |
Use an editor to modify the file /etc/opt/SUNWam/config/AMConfig.properties.
Set the following properties:
com.iplanet.am.directory.port=389
com.iplanet.am.directory.host=LoadBalancer-1.example.com
com.sun.am.event.connection.idle.timeout=3
Restart both Access Manager servers in order for the changes to take place.
For each of the Access Manager servers, perform the following steps to confirm its directory accesses are all directed to one and only one Directory Server instance, and that system failover and recover work properly. The following section describes how to perform the sanity check for the first Access Manager instance. Substitute the console URL with that of the second Access Manager instance when you perform the task for the second Access Manager instance.
Confirm that the load balancer is properly configured for simple persistence.
As a root user, log into host DirectoryServer-1 and host DirectoryServer-2.
For each server, use the tail command to watch the Directory Server access log.
# tail-f logs/access
Start a new browser and go to the Access Manager 1 URL.
Example: http://AccessManager-1.example.com:1080/amserver/console
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
Navigate inside the Access Manager console while paying attention to the Directory Server access log.
In the access log, you should see all directory accesses are directed to one Directory Server instance only, excluding the health check probing from the load balancer device. The navigation should not have any errors. Logout and close the browser if successful.
Confirm that Directory Server failover works properly.
Shut down Directory Server 1.
Start a new browser and go to the Access Manager URL.
Example: http://AccessManager-1.example.com:1080/amserver/console
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
Navigate inside the Access Manager console while paying attention to the Directory Server access logs.
# cd /var/opt/mps/serverroot/slapd-data/logs
In the access logs, you should see all directory accesses are directed only to Directory Server 2. The navigation should not have any errors. Log out and close the browser if successful.
Restart Directory Server 1, and stop Directory Server 2.
Start a new browser go to the Access Manager URL.
Example: http://AccessManager-1.example.com:1080/amserver/console
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
Navigate inside the Access Manager console,
Watch the access logs of both Directory Server instances. You should see all directory accesses (excluding health checks by load balancer) are directed to only Directory Server 1. The navigation should not have any errors.
Log out and close the browser if successful.
Restart Directory Server 2.
Confirm that both Directory Servers are restarted and running.
Users internal to your company will access the Access Manager servers through the internal-facing load balancer. The internal-facing load balancer is optional, and enables you to customize an internal-facing login page that is different from the external-facing login page. Users external to your company will first access the Distributed Authentication UI servers, which in turn route requests to the external-facing load balancer. Internal users will access port 90 while External users will access port 9443.
Load Balancer 3 sends the user and agent requests to the server where the session originated. SSL is terminated at Load Balancer 3 before a request is forwarded to the Access Manager Servers. Otherwise the load balancer cannot inspect the traffic for proper routing.
Load Balancer 3 is capable of the following types of load balancing:
Cookie-based |
The load balancer makes decisions based on client's cookies. The load balancer looks at the request and detects the presence of a cookie by a specific name. If the cookie is detected in the request, the load balancer routes the request to the specific server to which the cookie has been assigned. If the cookie is not detected in the request, the load balancer balances client requests among the available servers. |
IP-based |
This is similar to cookie-based load balancing, but the decision is based on the IP address of the client. The load balancer sends requests from a specific client to the same server. So a request from the client will always be processed by the server that last processed the request from that client. |
TCP |
The load balancer mainstreams session affinity. This means that all requests related to a TCP session, are forwarded to the same server. In this deployment example, Load Balancer 3 forwards all requests from a single client to exactly the same server. When the session is started and maintained by one client, session affinity is guaranteed. This type of load-balancing is applicable to the TCP-based protocols. |
Contact your network administrator to obtain two available virtual IP addresses.
The load balancer hardware and software used in the lab facility for this deployment is BIG-IP® manufactured by F5 Networks. If you are using different load balancer software, see the documentation that comes with that product for detailed settings information.
Create a Pool.
A pool contains all the backend server instances.
Go to URL for the Big IP load balancer log in.
Open the Configuration Utility.
Click “Configure your BIG-IP (R) using the Configuration Utility.”
In the left pane, click Pools.
On the Pools tab, click the Add button.
In the Add Pool dialog, provide the following information:
Example: AccessManager-Pool
Round Robin
Add all the Access Manager servers IP addresses. In this example, add the IP address and port number for AccessManager-1:1080 and for AccessManager-2:1080.
Click the Done button.
Configure the load balancer for persistence.
Add a Virtual Server.
If you encounter Javascript errors or otherwise cannot proceed to create a virtual server, try using Microsoft Internet Explorer for this step.
In the left frame, Click Virtual Servers.
On the Virtual Servers tab, click the Add button.
In the Add a Virtual Server dialog box, provide the following information:
xxx.xx.69.13 (for LoadBalancer-3.example.com )
90
AccessManager-Pool
Continue to click Next until you reach the Pool Selection dialog box.
In the Pool Selection dialog box, assign the Pool (AccessManager-Pool) that you have just created.
Click the Done button.
Add Monitors.
The load balancer has a built-in HTTP monitor that probes the Access Manager TCP port periodically. Successive probing failure indicates the server is down. However, this probing does not address the case where the Access Manager server responds to a TCP connection request, but fails to process any further Access Manager requests because of internal errors such as deadlocks. Access Manager comes with a JSP file /amserver/isAlive.jsp to address this challenge. In the following steps, you create a custom monitor that periodically accesses the JSP. If a success response can be obtained, it means not only that Access Manager is responding to TCP connection request, but also that free threads exist to process the request.
Click the Monitors tab, and then the click Add button.
In the Add Monitor dialog, provide the following information:
AccessManager-http
Choose http.
Click Next.
In the Configure Basic Properties page, click Next.
In the “Configure ECV HTTP Monitor” dialog, in the Send String field, enter the following:
GET /amserver/isAlive.jsp
In the Destination Address and Service (Alias) page, click Done.
On the Monitors tab, the monitor you just added is now contained in the list of monitors.
Click the Basic Associations tab.
Look for the IP address for AccessManager-1:1080 and AccessManager-2:1080.
Mark the Add checkbox for AccessManager-1 and AccessManager-2.
At the top of the Node column, choose the monitor that you just added, AccessManager-http.
Click Apply.
Log in as root to the host AccessManager–1.
Run the tail command to view the access log.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com/logs # tail -f access |
If you see frequent entries similar to this one:
xxx.xx.69.18--[12/Oct/2006:13:10:20-0700] "GET/amserver/isAlive.jsp" 200 118 |
then the custom monitor is configured properly. If you do not see “GET /amserver/isAlive.jsp” then you must troubleshoot the load balancer configuration.
Log in as root to the host AccessManager-2.
Run the tail command to view the access log.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com/logs # tail -f access |
If you see frequent entries similar to this one:
xxx.xx.69.18--[12/Oct/2006:13:10:20-0700] "GET /amserver/isAlive.jsp" 200 118 |
then the custom monitor is configured properly. If you do not see “GET /amserver/isAlive.jsp” then you must troubleshoot the load balancer configuration.
Start a new browser and go to the internal-facing load balancer URL.
Example: http://LoadBalancer-2.example.com:90/ . Do not supply the amserver prefix.
If the browser successfully renders the default Sun Web Server default document root page, close the browser.
Open a browser, go to the BIG-IP URL:
https://is-F5.example.com
Log in to the BIG-IP console using the following information:
username
password
Click “Configure your BIG-IP (R) using the Configuration Utility.”
In the left pane, click Proxies.
Click the Cert-Admin tab.
On the SSL Certificate Administration page, click the button named “Generate New Key Pair/Certificate Request.”
In the Create Certificate Request page, provide the following information:
LoadBalancer-3.example.com
Deployment
LoadBalancer-3.example.com
password
password
Click the button “Generate Key Pair/Certificate Request.”
On the SSL Certificate Request page, the request is generated in the Certificate Request field.
Copy all the text contained in the Certificate Request field.
Save the text in a text file to keep it handy for later use.
Send the text of the certificate request to a Certificate Authority of your choice.
A Certificate Authority is an entity that issues certified digital certificates. VersiSign, Thawte , Entrust, and GoDaddy are just a few examples of Certificate Authority companies. In this deployment example, CA certificates were obtained from OpenSSL. Follow the instructions provided by the Certificate Authority for submitting a certificate request.
The root Certificate Authority certificate proves that a Certificate Authority such as VeriSign or Entrus actually issued the digital server certificate you received. You install the root certificate on Load Balancer 3 to ensure that the link between the Load Balancer 3 SSL certificate can be maintained with the issuing company.
In the BIG-IP load balancer console, click Proxies.
Click the Cert-Admin tab.
Click the Import link.
In the Import Type field, choose Certificate, and then click Continue.
In the Install SSL Certificate page, in the Certificate File field, click Browse.
In the Choose File dialog, choose Browser.
Navigate to the file that includes the root CA Certificate, and click Open.
In the Certificate Identifier field, enter OpenSSL_CA_cert.
Click Install Certificate.
In the Certificate OpenSSL_CA_Cert page, click Return to Certificate Administration.
The new certificate OpenSSL_CA_Cert is now included in the Certificate ID list.
Once you've received the SSL certificate from a Certificate Authority, in the BIG-IP load balancer console, click Proxies.
Click the Cert-Admin tab.
The key LoadBalancer-3.example.com is in the Key List. This was generated in a previous step when you generated a key pair and a certificate request.
In the Certificate ID column, click the Install button for LoadBalancer-3.example.com.
In the Certificate File field, click Browse.
In the Choose File dialog, navigate to the text file in which you saved the certificate text sent to you by the certificate issuer, and then click Open.
Click Install Certificate.
In the Certificate LoadBalancer-3.example.com page, click Return to Certificate Administration Information link.
In the SSL Certificate Administration page, verify that the Certificate ID indicates LoadBalancer-3.example.com.
In this deployment example, Secure Socket Layer (SSL) termination at Load Balancer 3 increases the performance at the server level, and simplifies SSL certificate management. Clients will access Load Balancer 3 using SSL-encrypted data. Load Balancer 3 decrypts the data and then sends the unencrypted data on to the Access Manager server. The Access Manager server or Authentication UI server does not have to perform decryption, and the burden on its processor is relieved. Load Balancer 3 then load-balances the decrypted traffic to the appropriate Access Manager server. Finally, Load Balancer 3 encrypts the responses from server, and sends encrypted responses to the client.
Load Balancer 3 sends the user and agent requests to the server where the session originated. SSL is terminated at Load Balancer 3 before a request is forwarded to the Access Manager Servers. Otherwise the load balancer cannot inspect the traffic for proper routing.
In this deployment example, you set up a proxy server using BIG-IPTM hardware and software.
Configure the new proxy service.
Log in to the BIG-IP load balancer using the following information:
username
password
Click the link “Configure your BIG-IP using the Configuration Utility.”
In the load balancer console, in the left pane, click Proxies.
On the Proxies tab, click Add.
In the Add Proxy dialog, provide the following information:
Check the SSL checkbox.
xxx.xx.69.14 (The IP address of Load Balancer 3, the Access Manager server load balancer.)
9443 (The port number of the new proxy you are setting up.)
xxx.xx.69.14
90
Choose Local Virtual Server.
Choose LoadBalancer-3.example.com.
Choose LoadBalancer-3.example.com.
Check this checkbox.
Click Next.
In the Rewrite Redirects field, choose Matching.
Click Done.
The new proxy server is now added to the Proxy Server list.
Verify that you can access the Access Manager server using the new proxy server port number.
Open a browser, and go to the following URL:
https://LoadBalancer-3.example.com:9443/index.html
A message may be displayed indicating that the Access Manager server doesn't recognize the certificate issuer. When this happens, install the root Certificate Authority certificate in the browser so that the browser recognizes the certificate issuer. See your browser's online help system for information on installing a root CA certificate.
Log out of Access Manager, and close the browser.
Use the following as your checklist for importing the root CA certificate into the Access Manager Web Servers:
Import the root CA certificate into the Access Manager 1 Web Server.
Import the root CA certificate into the Access Manager 2 Web Server.
To to the Web Server administration URL:
http://AccessManager-1.example.com:8888/https-admserv/bin/index |
Log in to the Web Server console using the following information:
admin
web4d4min
On the Servers tab, select the server AccessManager-1.example.com, and then click Manage.
Click on the Security tab, and then initialize the Trust Database by providing the following information:
password
password
Click OK.
In the left frame, click Install Certificate. In the Install a Server Certificate page, provide the following information:
Choose Trusted Certificate Authority (CA)
Choose this option, and then paste into the text box the root certificate you received from the CA. To Request an SSL Certificate for the Distributed Authentication UI Load Balancer. The root certificate will look similar to this:
-----BEGIN CERTIFICATE----- UbM77e50M63v1Z2A/5O5MA0GCSqGSIb3DQEOBAU AMF8xCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0 EgRGF0YSBTZWN1cml0eSwgSW5jLjEuMCwGA1UEC xMlU2VjdXJlIFNlcnZlciBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTAeFw0wMTA4MDIwMDAwMDBaFw0 wMzA4MDIyMzU5NTlaMIGQMQswCQYDVQQGEwJVUz ERMA8GA1UECBMIVmlyZ2luaWExETAPBgNVBAcUC FJpY2htb25kMSAwHgYDVQQKFBdDYXZhbGllciBU ZWxlcGhvYm9uZGluZy5jYXZ0ZWwuY29tMIGfMA0 GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8x/1dxo 2YnblilQLmpiEziOqb7ArVfI1ymXo/MKcbKjnY2 -----END CERTIFICATE REQUEST----- |
Click OK.
On the “Add Trusted CA Certificate page,” click “Add Server Certificate.”
In the left frame, click Manage Certificates.
In the list of certificates, you will see the certificate you just added. In this deployment example, the certificate name OpenSSLTestCA-Sun is displayed in the list.
Close the browser.
As a root user, log into the Access Manager 1 host.
To verify that the certificate was imported properly, go to the following directory:
/opt/SUNWwbsvr/alias |
In a directory listing, notice that certificate filename is formed by joining the prefix https-AccessManager-1.example.com and database file name cert8.db.
#ls https-AccessManager-1.example.com-AccessManager-1-cert8.db https-AccessManager-1.example.com-AccessManager-1-key3.db https-AccessManager-1.example.com-cert8.db https-AccessManager-1.example.com-key3.db secmod.db |
Run the certutil list command, specifying the prefix from certificate filename:
# cd /opt/SUNWwbsvr/bin/https/admin/bin # ./certutil -L -d /opt/SUNWwbsvr/alias/ -P "https-AccessManager-1.example.com-" OpenSSLTestCA - Sun |
The OpenSSLTestCA — Sun certificate you imported is displayed.
As a root user, log in to the Access Manager 1 host.
Go to the following directory:
/etc/opt/SUNWam/config |
Make a backup of the AMConfig.properties file before making any changes to the file.
In the AMConfig.properties file, verify that the certificate database directory is specified correctly as in this example:
com.iplanet.am.admin.cli.certdb.dir=/opt/SUNWWwbsvr/alias |
For the value of the following property, add the prefix from the certificate filename as in this example:
com.iplanet.am.admin.cli.certdb.prefix=https-AccessManager-1.example.com- |
Notice that the following property points to a file wtpass which doesn't exist yet:
com.iplanet.am.admin.cli.certdb. |
You will create this file in the next step.
Save the file.
Create the wtpass file.
In the file, enter the name of the password you used to create the certificate database. Example:
# cd /etc/opt/SUNWam/config # vi .wtpass password |
Save the file.
Verify that the file was created properly.
# cat .wtpass password |
Restart the Web Server.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com # ./stop; ./start |
To to the Web Server administration URL:
http://AccessManager-2.example.com:8888/https-admserv/bin/index |
Log in to the Web Server console using the following information:
admin
web4d4min
On the Servers tab, select the server AccessManager-2.example.com, and then click Manage.
Click on the Security tab, and then initialize the Trust Database by providing the following information:
password
password
Click OK.
In the left frame, click Install Certificate. In the Install a Server Certificate page, provide the following information:
Choose Trusted Certificate Authority (CA)
Choose this option, and then paste into the text box the root certificate you received from the CA. To Request an SSL Certificate for the Distributed Authentication UI Load Balancer. The root certificate will look similar to this:
-----BEGIN CERTIFICATE----- UbM77e50M63v1Z2A/5O5MA0GCSqGSIb3DQEOBAU AMF8xCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0 EgRGF0YSBTZWN1cml0eSwgSW5jLjEuMCwGA1UEC xMlU2VjdXJlIFNlcnZlciBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eTAeFw0wMTA4MDIwMDAwMDBaFw0 wMzA4MDIyMzU5NTlaMIGQMQswCQYDVQQGEwJVUz ERMA8GA1UECBMIVmlyZ2luaWExETAPBgNVBAcUC FJpY2htb25kMSAwHgYDVQQKFBdDYXZhbGllciBU ZWxlcGhvYm9uZGluZy5jYXZ0ZWwuY29tMIGfMA0 GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC8x/1dxo 2YnblilQLmpiEziOqb7ArVfI1ymXo/MKcbKjnY2 -----END CERTIFICATE REQUEST----- |
Click OK.
On the “Add Trusted CA Certificate page,” click “Add Server Certificate.”
In the left frame, click Manage Certificates.
In the list of certificates, you will see the certificate you just added. In this deployment example, the certificate name OpenSSLTestCA-Sun is displayed in the list.
Close the browser.
As a root user, log into the Access Manager 2 host.
To verify that the certificate was imported properly, go to the following directory:
/opt/SUNWwbsvr/alias |
In a directory listing, notice that certificate filename is formed by joining the prefix https-AccessManager-1.example.com and database file name cert8.db.
#ls https-AccessManager-1.example.com-AccessManager-2-cert8.db https-AccessManager-1.example.com-AccessManager-2-key3.db https-AccessManager-2.example.com-cert8.db https-AccessManager-1.example.com-key3.db secmod.db |
Run the certutil list command, specifying the prefix from certificate filename:
# cd /opt/SUNWwbsvr/bin/https/admin/bin # ./certutil -L -d /opt/SUNWwbsvr/alias/ -P "https-AccessManager-2.example.com-" OpenSSLTestCA - Sun |
The OpenSSLTestCA — Sun certificate you imported is displayed.
As a root user, log in to the Access Manager 2 host.
Go to the following directory:
/etc/opt/SUNWam/config |
Make a backup of the AMConfig.properties file before making any changes to the file.
In the AMConfig.properties file, verify that the certificate database directory is specified correctly as in this example:
com.iplanet.am.admin.cli.certdb.dir=/opt/SUNWWwbsvr/alias |
For the value of the following property, add the prefix from the certificate filename as in this example:
com.iplanet.am.admin.cli.certdb.prefix=https-AccessManager-2.example.com- |
Notice that the following property points to a file wtpass which doesn't exist yet:
com.iplanet.am.admin.cli.certdb. |
You will create this file in the next step.
Save the file.
Create the wtpass file.
In the file, enter the name of the password you used to create the certificate database. Example:
# cd /etc/opt/SUNWam/config # vi .wtpass password |
Save the file.
Verify that the file was created properly.
# cat .wtpass password |
Restart the Web Server.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com # ./stop; ./start |
Access Manager 7 2005Q4 introduces the site concept which provides centralized configuration management for an Access Manager deployment. In this example, you configure two Access Manager servers to work as a single site. Once configured as a site, all client requests always go through a load balancer. In this example, requests go through either the internal or external load balancer. This flow simplifies the deployment by resolving firewall issues between the client and the back-end Access Manager servers.
Use the following as your checklist for creating an Access Manager site:
Complete the following steps on the Access Manager 1 host. It is not necessary to repeat the steps on the Access Manager 2 host.
Start a browser, and access the Access Manager 1 server.
http://AccessManager-1:1080/amserver/console
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
In the Access Manager console, click the Access Control tab, and then click the top-level Realm Name example.
In the Realm/DNS Aliases field, add the name of the internal load balancer.
For this example, enter LoadBalancer-3.example.com:90, and then click Add.
Do not remove the host names AccessManager-1 and AccessManager-2 from the alias list. These allow administrators to log in to the console directly in the event of a load balancer failure.
For this deployment example, add an entry for the same host name using all lowercase.
Example: loadbalancer-3.example.com:90
Click Save.
In the Access Manager console, click the Realms link, and then navigate through the following:
Configuration > System Properties > Platform >
Under Site Name, click New, and enter the following values for the external load balancer:
https://loadbalancer-3.example.com:9443
11
Click OK, and then click Save.
Under Site Name, click New. Enter the following values for the internal load balancer:
http://loadbalanacer-3.example.com:90
12
Click OK, and then click Save.
On the same Platform page, under Instance Name, click AccessManager-1.
Change the site ID from 01 to 01|11|12.
http://AccessManager-1.example.com:1080:01|11|12
Click OK, and then click Save.
On the Platform page, under Instance Name, click AccessManager-2.
Change the site ID from 02 to 02|11|12.
http://AccessManager-2.example.com:1080:02|11|12
Click OK, and then click Save.
Restart AccessManager-1 and AccessManager-2 for the changes to take effect.
Go to the Access Manager Site URL:
http://LoadBalancer-3.example.com:90/amserver/UI/Login |
If an error message is displayed indicating that the browser cannot connect to either AccessManager- 1.example.com or AccessManager-2.example.com, then the site configuration is not correct. If the site configuration is correct, all browser interactions will always occur with the Site URL.
If the Access Manager login page is displayed, verify that the browser URL still contains the Site URL.
If it does not contain the Site URL, then the site configuration is incorrect. If the site configuration is correct, all browser interactions will always occur with the Site URL
If the Access Manager login page is displayed, and the browser URL contains the Site URL, log in to the Access Manager console using the following information:
amadmin
4m4dmin1
Verify that you can successfully login to the Access Manager console.
Log out of the Access Manager console.
This chapter contains detailed instructions for the following tasks:
6.1 Installing and Deploying the Distributed Authentication UI Servers
6.2 Configuring the Distributed Authentication UI Servers Load Balancer
Use the following as your checklist for installing and Deploying the Distributed Authentication UI servers:
Install a container for Distributed Authentication UI Server 1.
Install a container for Distributed Authentication UI Server 2.
Import the root CA certificate for the Access Manager load balancer into Authentication UI Server 1.
Verify that authentication through Authentication UI Server 1 is successful.
Import the root CA certificate for the Access Manager load balancer into Authentication UI Server 2.
Verify that authentication through Authentication UI Server 2 is successful.
The Java ES installer must be mounted on the host AuthenticationUI-1 where you will install Web Server. See the section “To Download and Unpack the Java Enterprise System 2005Q4 Installer”3.2 Downloading and Mounting the Java Enterprise System 2005Q4 Installer in this document.
As a root user, log in to host Authentication UI-1.
Start the Java Enterprise System installer with the -nodisplay option.
# /mnt/Solaris_sparc # ./installer -nodisplay |
When prompted, provide the following information:
Log in as a root user to AccessManager-1.
For this example, log into AccessManager-1.
Copy the Distributed Authentication UI files to another workspace on the AccessManager-1.
# cd /opt/SUNWcomm/SUNWam # cp README.distAuthUI amauthistui.war Makefile.distAuthUI /opt/SUNWam |
Edit the Makefile.distAuthUI file and set the following properties:
JAVA_HOME=/usr/jdk/entsys-j2se/ SERVER_PROTOCOL=http SERVER_HOSTNAME=LoadBalancer-3.example.com SERVER_PORT=90 SERVER_DEPLOY_URI=amserver DISTAUTH_PROTOCOL=http DISTAUTH_HOSTNAME=AuthenticationUI-1.example.com DISTAUTH_PORT=1080 DISTAUTH_DEPLOY_URI=/distAuth APPLICATION_USERNAME=amadmin APPLICATION_PASSWORD=4m4dmin1 NOTIFICATION_URL=http://AuthenticationUI-1.example.com:1080/ distAuth/notificationservice DEBUG_LEVEL=message DEBUG_DIR=/tmp/distAuth COOKIE_ENCODE=false DISTAUTH_VERSION=7.0 |
Create the war file by issuing the following command
# /usr/sfw/bin/gmake -f Makefile.distAuthUI |
This creates a war file named distAuthUI.war .
Rename the generated file.
# mv distAuthUI.war distAuth_AccessManager-1.war |
Copy distAuth_AccessManager-1.war from the local host where you built the Distributed Authentication UI server (AccessManager–1) to the remote host where the Distributed Authentication UI server will be deployed (AuthenticationUI-1).
In this deployment example, the desintation directory is /tmp.
Log in as a root user to the Authentication UI-1 Web Server.
Start the Authentication UI-1 Web Server.
# cd /opt/SUNWwbserver # #cd https-AuthenticationUI-1.example.com # # ./start |
Deploy the Distributed Authentication UI WAR file.
On the host AuthenticationUI-1, in the directory where you copied the distAuth_AuthenticationUI-1.war file, run the wdeploy command using the following form:
wdeploy deploy -u uri_path -i instance -v vs_id
[ [-V verboseLevel ]| [-q] ] [-n] [-d directory] war_file
For example, in this Deployment Example:
# cd /opt/SUNWwbsvr/bin/https/bin # ./wdeploy deploy -u /distAuth -i https-AuthenticationUI-1.example.com -v https-AuthenticationUI-1.example.com -d /opt/SUNWwbsvr/https-AuthenticationUI-1.example.com/webapps/distAuth /tmp/distAuth_AuthenticationUI-1.war |
Restart Web Server.
# cd /opt/SUNWwbserver # cd https-AuthenticationUI-1.example.com # ./stop; ./start server has been shutdown # Sun ONE Web Server 6.1SP5 B06/23/2005 18:00 info: CORE3016: daemon is running as super-user info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_04] from [Sun Microsystems Inc.] # info: WEB0100: Loading web module in virtual server [https-AuthenticationUI-1.example.com] at [/distAuth] info: WEB0100: Loading web module in virtual server [https-AuthenticationUI-1.example.com] at [/search] info: HTTP3072: [LS ls1] http://AuthenticationUI-1.example.com:8080 ready to accept requests startup: server started successfully |
The web module is loaded in the following directory:
/opt/SUNWwbsvr/https-AuthenticationUI-1.example.com/webapps/distAuth
As a root user, log in to host AuthenticationUI-2.
Start the Java Enterprise System installer with the -nodisplay option.
# /mnt/Solaris_sparc # ./installer -nodisplay |
When prompted, provide the following information:
|
Press Enter. |
|
|
Press Enter. |
|
|
Enter y. |
|
|
Enter 8 for “English only.” |
|
|
Enter 3 to select Web Server. |
|
|
Press Enter. |
|
Enter 1 to upgrade these shared components and 2 to cancel [1] |
You are prompted to upgrade shared components only if the installer detects that an upgrade is required. Enter 1 to upgrade shared components. |
|
|
Accept the default value. |
|
|
Enter 1. |
|
|
Enter 1. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Enter admin. |
|
|
For this example, enter web4dmin. |
|
|
Enter the same password to confirm it. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Enter admin. |
|
|
For this example, enter web4dmin. |
|
|
Accept the default value. |
|
|
Enter 1080. |
|
|
Accept the default value. |
|
|
Enter root. |
|
|
Enter root. |
|
|
Enter 8888. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
When ready to install, enter 1. |
Log in as a root user to an Access Manager host.
For this example, log into AccessManager-2.
Copy the Distributed Authentication UI files to another workspace on the same (local) host.
cd /opt/SUNWcomm/SUNWam cp README.distAuthUI amauthistui.war Makefile.distAuthUI /opt/SUNWam |
Edit the Makefile.distAuthUI file and set the following properties:
JAVA_HOME=/usr/jdk/entsys-j2se/ SERVER_PROTOCOL=http SERVER_HOSTNAME=LoadBalancer-3.example.com SERVER_PORT=90 SERVER_DEPLOY_URI=amserver DISTAUTH_PROTOCOL=http DISTAUTH_HOSTNAME=AuthenticationUI-2.example.com DISTAUTH_PORT=1080 DISTAUTH_DEPLOY_URI=/distAuth APPLICATION_USERNAME=amadmin APPLICATION_PASSWORD=4m4dmin1 NOTIFICATION_URL=http://AuthenticationUI-2.example.com:1080/ distAuth/notificationservice DEBUG_LEVEL=message DEBUG_DIR=/tmp/distAuth COOKIE_ENCODE=false DISTAUTH_VERSION=7.0 |
Create the war file by issuing the following command
gmake -f Makefile.distAuthUI.war |
This creates a war file named distAuth_deploy.war.
Rename the generated file.
mv distAuthUI.war distAuth_AccessManager-2.war |
Copy distAuth_AccessManager-2.war from the local host where you built the Distributed Authentication UI (AccessManager—2) to the remote host where the Distributed Authentication UI will be deployed (AuthetnicationUI-2).
# cp distAuth_AccessManager-2.war /net/AuthenticationUI-2/ tmp/distAuth_ AuthenticationUI-2.war |
Deploy the Distributed Authentication UI WAR file.
On the host AuthenticationUI-2, in the directory where you copied the distAuth_ AuthenticationUI-2.war file, run the wdeploy command using the following form:
wdeploy deploy -u uri_path -i instance -v vs_id
[ [-V verboseLevel ]| [-q] ] [-n] [-d directory] war_file
For example, in this Deployment Example:
# ./wdeploy deploy -u /distAuth -i https-AuthenticationUI-2.example.com -v https-AuthenticationUI-2.example.com -d /opt/SUNWwbsvr/https-AuthenticationUI-2.example.com/webapps/distAuth /tmp/distAuth_ AuthenticationUI-2.war |
Restart Web Server.
# cd /opt/SUNWwbserver # cd https-AuthenticationUI-2.example.com # ./stop; ./start server has been shutdown # Sun ONE Web Server 6.1SP5 B06/23/2005 18:00 info: CORE3016: daemon is running as super-user info: CORE5076: Using [Java HotSpot(TM) Server VM, Version 1.5.0_04] from [Sun Microsystems Inc.] # info: WEB0100: Loading web module in virtual server [https-AuthenticationUI-2.example.com] at [/distAuth] info: WEB0100: Loading web module in virtual server [https-AuthenticationUI-2.example.com] at [/search] info: HTTP3072: [LS ls1] http://AuthenticationUI-2.example.com:8080 ready to accept requests startup: server started successfully |
The web module is loaded in the following directory:
/opt/SUNWwbsvr/https-AuthenticationUI-2.example.com/webapps/distAuth/distAuth
In this procedure, you import a Certificate Authority (CA) certificate. The certificate enables the Authentication UI server to trust the certificate from the Access Manager load balancer (Load Balancer 3), and to establish trust with the certificate chain that is formed from the CA to the certificate.
Log in as root to Authentication UI Server 2.
Copy the root CA certificate into a directory.
After the certificate authority (CA) sends you the certificate, copy the certificate text into a file. In this example, the file is /export/software/ca.cer.
Import the root CA certificate into the Java certificate store.
# /usr/jdk/entsys-j2se/jre/bin/keytool -import -trustcacerts -alias OpenSSLTestCA -file /export/software/ca.cer -keystore /usr/jdk/entsys-j2se/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 root CA certificate was imported into the keystore.
# /usr/jdk/entsys-j2se/jre/bin/keytool -list -keystore ./cacerts -storepass changeit | grep -i open openssltestca, Nov 8, 2006, trustedCertEntry |
Restart AuthenticationUI-1.
# cd /opt/SUNWwwbsvr/https-AuthenticationUI-1.example.com # ./stop server has been shutdown #./start Sun ONE Web Server 6.1SP5 B06/23/2005 18:00 info: CORE3016: daemon is running as super-user info: CORE5076: Using [Java HotSpot(TM) Server VM, version 1.5.0_04 ] from [Sun Microsystems Inc.] info: WEB0100: Loading web module in virtual server https-AuthenticationUI-1.example.com] at [/distAuth] info: WEB0100: Loading web module in virtual server https-AuthenticationUI-1.example.com] at [/search] info: HTTP3072: [LS is 1] http://AuthenticationUI-1.example.com:1080 ready to accept requests startup: server started successfully |
Find a host that has direct network connectivity to both Authentication UI servers and the external facing load balancer of the Access Manager servers. One natural place is the Distributed Authentication UI server host itself.
Open a web browser and go to the following URL:
http://AuthenticationUI-1.example.com:1080/distAuth/UI/Login?goto= http://LoadBalancer-3.example.com:90 |
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
After successful authentication, you should be redirected to the index page for Access Manager's Web Server.
Log out of the Access Manager console.
In this procedure, you import a Certificate Authority (CA) certificate. The certificate enables the Authentication UI server to trust the certificate from the Access Manager load balancer (Load Balancer 3), and to establish trust with the certificate chain that is formed form the CA to the certificate.
Log in as a root user to Authentication UI Server 2.
Copy the root CA certificate into a directory.
After the certificate authority (CA) sends you the certificate, copy the certificate text into a file. In this example, the file is /export/software/ca.cer.
Import the root CA certificate into the Java certificate store.
# /usr/jdk/entsys-j2se/jre/bin/keytool -import -trustcacerts -alias OpenSSLTestCA -file /export/software/ca.cer -keystore /usr/jdk/entsys-j2se/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 root CA certificate was imported into the keystore.
# /usr/jdk/entsys-j2se/jre/bin/keytool -list -keystore ./cacerts -storepass changeit | grep -i open openssltestca, Nov 8, 2006, trustedCertEntry |
Restart AuthenticationUI-2.
# cd /opt/SUNWwwbsvr/https-AuthenticationUI-2.example.com # ./stop server has been shutdown #./start Sun ONE Web Server 6.1SP5 B06/23/2005 18:00 info: CORE3016: daemon is running as super-user info: CORE5076: Using [Java HotSpot(TM) Server VM, version 1.5.0_04 ] from [Sun Microsystems Inc.] info: WEB0100: Loading web module in virtual server [https-AuthenticationUI-2.example.com] at [/distAuth] info: WEB0100: Loading web module in virtual server [https-AuthenticationUI-2.example.com] at [/search] info: HTTP3072: [LS is 1] http://AuthenticationUI-2.example.com:1080 ready to accept requests startup: server started successfully |
Find a host that has direct network connectivity to both Authentication UI servers and the external facing load balancer of the Access Manager servers. One natural place is the Distributed Authentication UI server host itself.
Open a web browser and go to the following URL:
http://AuthenticationUI-2.example.com:1080/distAuth/UI/Login?goto= http://LoadBalancer-3.example.com:90 |
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
After successful authentication, you should be redirected to the index page for Access Manager's Web Server.
Configure the Distributed Authentication UI servers load balancer.
Configure Distributed Authentication UI servers to authenticate to Access Manager as a custom user.
Configure the load balancer cookies for the Distributed Authentication UI servers.
Request an SSL certificate for the Distributed Authentication UI load balancer.
Install a root CA certificate on the Distributed Authentication UI load balancer.
Install an SSL certificate on the Distributed Authentication UI load balancer.
Configure SSL termination on the Distributed Authentication UI load balancer.
Contact your network administrator to obtain an available virtual IP address.
The load balancer hardware and software used in the lab facility for this deployment is BIG-IP® manufactured by F5 Networks. If you are using different load balancer software, see the documentation that comes with that product for detailed settings information.
Create a Pool.
A pool contains all the backend server instances.
Go to URL for the Big IP load balancer and log in.
Open the Configuration Utility.
Click “Configure your BIG-IP (R) using the Configuration Utility.”
In the left pane, click Pools.
On the Pools tab, click the Add button.
In the Add Pool dialog, provide the following information:
Example: AuthenticationUI-Pool
Round Robin
Add IP addresses for the Distributed Authentication UI server hosts. For this example, add AuthenticationUI-1:1080 and AuthenticationUI-2:1080.
Click the Done button.
Configure the load balancer for persistence.
Add a Virtual Server.
In the left frame, Click Virtual Servers.
On the Virtual Servers tab, click the Add button.
In the Add Virtual Server wizard, enter the virtual server IP address and port number.
In this example, enter the IP address for Load Balancer 4, and enter the port number 90.
Continue to click Next until you reach the Pool Selection dialog box.
In the Pool Selection dialog box, assign the AuthenticationUI-Pool that you have just created.
Click the Done button.
Add monitors.
Monitors are necessary for the load balancer to detect any backend server failures that may occur.
Verify that the Distributed Authentication UI server load balancer is configured properly.
Start a new browser and go to the Distributed Authentication UI load balancer URL. Example:
http://LoadBalancer-4.example.com:90/.
If the browser successfully renders the default Sun Web Server default document root page, close the browser.
Set up a custom user.
Open a browser and go to the Access Manager login URL.
https://LoadBalancer-3.example.com:9443/amserver/UI/Login
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
On the Access Control tab, click the top-level realm example.com.
Click the Subjects tab.
Click the Agents tab.
On the Agents tab, click the New button.
In the New Agent page, provide the following information, and then click Create.
authuiadmin
4uthu14dmin
On the Agent tab, in the list of Agent names, click on authuiadmin.
Log out of the console.
Define authuiadmin as a special user in Access Manager 1.
As a root user, log in to host AccessManager–1.
Locate the /etc/opt/SUNWam/config/AMConfig.properties file.
Make a backup of this file before you modify it.
In the file, locate the following property:
com.sun.identity.authentication.special.users
At end of the list of values, add the UniversalID that you obtained and saved from the Agents list:
|uid=authuiadmin,ou=agents,o=example.com
This step authorizes the user to authenticate remote applications to the Access Manager server using the Access Manager Client SDK.
Define authuiadmin as a special user in Access Manager 2.
As a root user, log into host AccessManager–2.
Locate the /etc/opt/SUNWam/config/AMConfig.properties file.
Make a backup of this file before you modify it.
In the file, locate the following property:
com.sun.identity.authentication.special.users
At end of the list of values, add the UniversalID that you obtained and saved from the Agents list:
|uid=authuiadmin,ou=agents,o=example.com
This step authorizes the user to authenticate remote applications to the Access Manager server using the Access Manager Client SDK.
Restart both Access Manager 1 server and Access Manager 2 server.
Log out of Access Manager 1 and log out of Access Manager 2.
Define the custom user as a special user on the Authentication UI 1 server.
As a root user log into host AuthenticationUI— 1.
Locate the following file:
opt/SUNWwbsvr/https-AuthenticationUI-1.example.com/ webapps/distAuth/WEB-INF/classes/AMConfig.properties |
Make a backup of this file before you modify it.
In the file, set the following properties:
com.sun.identity.agents.app.username=authuiadmin
com.iplanet.am.service.password=4uthu14dmin
Define the custom user as a special user on the Authentication UI 2 server.
As a root user, log into host AuthenticationUI–2.
Locate the following file:
opt/SUNWwbsvr/https-AuthenticationUI-2.example.com/ webapps/distAuth/WEB-INF/classes |
Make a backup of this file before you modify it.
In the file, set the following properies:
com.sun.identity.agents.app.username=authuiadmin
com.iplanet.am.service.password=4uthu14dmin
Restart Authentication UI 1 server and Authentication UI 2 server.
# cd /opt/SUNWwbsvr/https-AuthenticationUI-1.example.com
# ./stop ; ./start
# cd /opt/SUNWwbsvr/https-AuthenticationUI-2.example.com
# ./stop ; ./start
Log out of Authentication UI 1 server and log out of Authentication UI 2 server.
Verify that everything works.
On Directory Server 1 and Directory Server 2, go to logs directory and run the tail command.
# cd /var/opt/mps/serverroot/slapd-am-config/logs
# tail -f access | grep authuiadmin
In a browser, go to following URL to open the Access Manager login page.
https://LoadBalancer-4.example.com:9443/distAuth/UI/Login?goto=https://LoadBalancer-3.example.com:9443/amserver/UI/Login
Using this URL, you will be able to view entries for the Authentication UI server binding to the Directory Server as the special user authuiadmin.
In the logs, look for entries similar to this:
[12/Jul/2006:21:08:33 -0700] conn=43430 op=0 msgId=1059 - BIND dn="uid=authuiadmin,ou=agents,o=example.com" method=128 version=3 [12/Jul/2006:21:08:33 -0700] conn=43430 op=0 msgId=1059 - RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=authuiadmin,ou=agents,o=example.com"
When you see err=0 in either log, you know that the Authentication UI server successfully logged into the Access Manager server. If the err value is anything other an 0, you must troubleshoot the configuration.
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
If you can successfully log in, you know that authentication worked successfully
Log out of the console.
Log in as a root user to Authentication UI 1 host.
Go to the following directory:
# cd /webapps/distAuth/WEB-INF/classes
Modify the AMconfig.properties file.
Make a backup of this file.
At the end of the file, uncomment the last two lines and set the following values:
com.iplanet.am.lbcookie.name=AuthenticationUILBCookie com.iplanet.am.lbcookie.value=AuthenticationUI-1
Restart the Authentication UI 1 host.
As a root user log into host AuthenticationUI–2 .
Go to the following directory:
# cd /webapps/distAuth/WEB-INF/classes
Modify the AMconfig.properties file.
Make a backup of this file.
At the end of the file, uncomment the last two lines and set the following values:
com.iplanet.am.lbcookie.name=AuthenticationUILBCookie com.iplanet.am.lbcookie.value=AuthenticationUI-2
Restart the Distributed Authentication UI 1 server.
Open a browser, go to the BIG-IP URL:
https://is-F5.example.com
Log in to the BIG-IP console using the following information:
username
password
Click “Configure your BIG-IP (R) using the Configuration Utility.”
In the left pane, click Proxies.
Click the Cert-Admin tab.
On the SSL Certificate Administration page, click the button named “Generate New Key Pair/Certificate Request.”
In the Create Certificate Request page, provide the following information:
LoadBalancer-4.example.com
Deployment
LoadBalancer-4.example.com
password
password
Click the button “Generate Key Pair/Certificate Request.”
On the SSL Certificate Request page, the request is generated in the Certificate Request field.
Copy all the text contained in the Certificate Request field.
Save the text in a text file to keep it handy for later use.
Send the text of the certificate request to a Certificate Authority of your choice.
A Certificate Authority is an entity that issues certified digital certificates. VersiSign, Thawte , Entrust, and GoDaddy are just a few examples of Certificate Authority companies. In this deployment example, CA certificates were obtained from OpenSSL. Follow the instructions provided by the Certificate Authority for submitting a certificate request.
The root Certificate Authority certificate proves that a Certificate Authority such as VeriSign or Entrus actually issued the digital server certificate you received. You install the root certificate on Load Balancer 3 to ensure that the link between the Load Balancer 3 SSL certificate can be maintained with the issuing company.
In the BIG-IP load balancer console, click Proxies.
Click the Cert-Admin tab.
Click the Import link.
In the Import Type field, choose Certificate, and then click Continue.
In the Install SSL Certificate page, in the Certificate File field, click Browse.
In the Choose File dialog, choose Browser.
Navigate to the file that includes the root CA Certificate, and click Open.
In the Certificate Identifier field, enter OpenSSL_CA_cert.
Click Install Certificate.
In the Certificate OpenSSL_CA_Cert page, click Return to Certificate Administration.
The new certificate OpenSSL_CA_Cert is now included in the Certificate ID list.
Once you've received the SSL certificate from a Certificate Authority, in the BIG-IP load balancer console, click Proxies.
Click the Cert-Admin tab.
The key LoadBalancer-4.example.com is in the Key List. This was generated in a previous step when you generated a key pair and a certificate request.
In the Certificate ID column, click the Install button for LoadBalancer-4.example.com.
In the Certificate File field, click Browse.
In the Choose File dialog, navigate to the text file in which you saved the certificate text sent to you by the certificate issuer, and then click Open.
Click Install Certificate.
In the Certificate LoadBalancer-3.example.com page, click Return to Certificate Information link.
In the SSL Certificate Administration page, verify that the Certificate ID indicates LoadBalancer-4.example.com.
In this deployment example, Secure Socket Layer (SSL) termination at Load Balancer 4 increases the performance at the server level, and simplifies SSL certificate management. Clients will access Load Balancer 4 using SSL-encrypted data. Load Balancer 4 decrypts the data and then sends the unencrypted data on to the Access Manager server. The Access Manager server or Authentication UI server does not have to perform decryption, and the burden on its processor is relieved. Load Balancer 3 then load-balances the decrypted traffic to the appropriate Access Manager server. Finally, Load Balancer 34encrypts the responses from server, and sends encrypted responses to the client.
In this deployment example, an SSL certificate is required only at the Load Balancer 4, and not required for each Access Manager server. This simplifies SSL certificate management. 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.
In this deployment example, you set up a proxy server using BIG-IPTM hardware and software.
Configure the new proxy service.
Log in to the BIG-IP load balancer using the following information:
username
password
Click the link “Configure your BIG-IP using the Configuration Utility.”
In the load balancer console, in the left pane, click Proxies.
On the Proxies tab, click Add.
In the Add Proxy dialog, provide the following information:
Check the SSL checkbox.
xxx.xx.69.14 (The IP address of Load Balancer 3, the Access Manager server load balancer.)
9443 (The port number of the new proxy you are setting up.)
xxx.xx.69.14
90
Choose Local Virtual Server.
Choose LoadBalancer-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.
Verify that you can access the Access Manager server using the new proxy server port number.
Open a browser, and go to the following URL:
https://LoadBalancer-4.example.com:9443/distAuth/UI/Login?goto= https://LoadBalancer-3.example.com:9443/amserver/UI/Login
You may see a message indicating that the Access Manager server doesn't recognize the certificate issuer. When this happens, install the root Certificate Authority certificate in the browser so that the browser recognizes the certificate issuer. See your browser's online help system for information on installing a root CA certificate.
Log out of Access Manager, and close the browser.
This chapter contains detailed instructions for the following tasks:
In this deployment example, the new user data store is created within the same Directory Servers as the Access Manager configuration store. In most cases, the new data store would be created in a different Directory Server.
As a root user log in to the Directory Server 1 host.
Run the netstat command to be sure the that the Directory Server administration port is open.
# cd /var/opt/mps/serverroot
# netstat —an | grep 1391
* 1390 *.* 0 0 49152 0 LISTEN
If the administration server is not running, start it now:
# ./start-admin
Start the Directory Server console.
# ./startconsole &
Log in to the Directory Server console using the following information:
cn=Directory Manager
d1rm4n4ger
http://DirectoryServer-1.example.com:1391
Expand the example.com domain, the DirectoryServer-1.example.comnode, and the Server Group object.
You should see three Directory Server objects: an Administration Server, Directory Server (ds-config), and Directory Server (am-config).
Right-click the Server Group object, and choose “Create Instance Of.”
Choose Sun JavaTM System Directory Server.
In the Create New Instance dialog, provide the following information and then click OK:
am-users
1489
dc=company,dc=com
cn=Directory Manager
d1rm4n4ger
d1rm4n4ger
nobody
In the navigation tree, the new instance Directory Server (am-users) is added to the Server Group list.
In the navigation tree, click the Directory Server (am-users) to open its console.
Verify that the Server status indicates “Started.”
Click Open, then click the Directory tab.
In the DirectoryServer-1.example.com:1489 node, you should see the new user data store base suffix dc=company,dc=com .
As a root user log in to the Directory Server 2 host.
Run the netstat command to be sure the that the Directory Server administration port is open.
# cd /var/opt/mps/serverroot
# netstat —an | grep 1391
* 1390 *.* 0 0 49152 0 LISTEN
If the administration server is not running, start it now:
# ./start-admin
Start the Directory Server console.
# ./startconsole &
Log in to the Directory Server console using the following information:
cn=Directory Manager
d1rm4n4ger
http://DirectoryServer-2.example.com:1391
Expand the example.com domain, the DirectoryServer-2.example.comnode, and the Server Group object.
You should see three Directory Server objects: an Administration Server, Directory Server (ds-config), and Directory Server (am-config).
Right-click the Server Group object, and choose “Create Instance Of.”
Choose Sun Java System Directory Server.
In the Create New Instance dialog, provide the following information and then click OK:
am-users
1489
dc=company,dc=com
cn=Directory Manager
d1rm4n4ger
d1rm4n4ger
nobody
In the navigation tree, the new instance Directory Server (am-users) is added to the Server Group list.
In the navigation tree, click the Directory Server (am-users) to open its console.
Verify that the Server status indicates “Started.”
Click Open, then click the Directory tab.
In the DirectoryServer-2.example.com:1489 node, you should see the new user data store base suffix dc=company,dc=com .
You only have to perform these steps on Directory Server 1. With multi-master replication enabled, all changes to the directory are automatically replicated to Directory Server 2.
Log in to the Directory Server 1 console using the following information.
cn=Directory Manager
d1rm4n4ger
http://DirectoryServer-1.example.com:1391
In the navigation pane, expand the example.com suffix, and expand the Server Group objects.
Under Server Group, click the am-usersinstance.
In the am-users console properties page, click Open.
Click the Directory tab,
Select New Instance, and then open the new instance.
Click the Directory tab.
Right click the dc=company, dc=com suffix, and choose “Create a new Organization Unit.”
In the Create New Organizational Unit dialog, in the Name field, enter users, and then click OK.
On the Directory tab, click the dc=company,dc=com suffix. You should see the new users instance in the list.
In this procedure, you create four special accounts for the following users:
The user userdbadmin will be used by the AccessManager servers to connect to the user data store for data management purposes.
The user userdbauthadmin will be used by the AccessManager servers to authenticate users to the user data store.
The user testuser1 will be used to verify that the Policy Agent is configured properly.
The user testuser2 will be used to verify the working of the Policy Agent.
Create an LDIF file named /tmp/am-users.ldif.
The file should contain the following users:
dn: uid=userdbadmin,ou=users,dc=company,dc=com uid: userdbadmin givenName: UserDB objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson sn: Admin cn: UserDB Admin userPassword: 4serd84dmin dn: uid=userdbauthadmin,ou=users,dc=company,dc=com uid: userdbauthadmin givenName: UserDB objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson sn: AuthAdmin cn: UserDB AuthAdmin userPassword: 4serd84uth4dmin dn: uid=testuser1,ou=users,dc=company,dc=com uid: testuser1 givenName: Test objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson sn: User1 cn: Test User1 userPassword: password dn: uid=testuser2,ou=users,dc=company,dc=com uid: testuser2 givenName: Test objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson sn: User2 cn: Test User2 userPassword: password
Import the LDIF file into the Directory Server-1 server.
# cd /var/opt/mps/serverroot/shared/bin # ./ldapmodify -h DirectoryServer-1.example.com -p 1489 -D "cn=Directory Manager" -w d1rm4n4ger -a -f /tmp/am-users.ldif adding new entry uid=userdbadmin,ou=users,dc=company,dc=com adding new entry uid=userdbauthadmin,ou=users,dc=company,dc=com |
Verify that the new users were imported to Directory Server 1 with no errors.
In this procedure you enable multi-master replication (MMR) between two directory masters. Then you use the data and schema from the first directory master to initialize the second directory master. When you're finished, you will have two Directory Servers, and each will contain two instances. The instance named ds-config stores Directory Server administration configuration. The instance named am-config stores the user data and Access Manager configuration.
On each Directory Server, the ds-config instance is a local configuration instance. Do not replicate this instance to other host systems. On each Directory Server, the am-config instance is the directory data instance. You enable the am-config instance for MMR with its counterpart on the other Directory Server host.
Use the following as your checklist for enabling multi-master replication:
On Directory Server 1, start the Directory Server console.
# cd /var/opt/mps/serverroot/ # ./startconsole & |
Log in to the Directory Server 1 console using the following information:
cn=Directory Manager
d1rm4n4ger
http://DirectoryServer-1.example.com:1391
In the Directory Server console, under the Servers and Applications tab, expand the Server Administration domain list until you see the Server Group item.
Click to expand the Server Group.
You should see the following items: an Administration Server, a Directory Server (am-config), a Directory Server (ds-config), and a Directory Server (am-users).
Double-click the instance name Directory Server (am-users) to display the console for managing the instance am-users.
Click the Configuration tab and navigate to the Replication pane.
Click the “Enable replication” button to start the Replication Wizard.
Select Master Replica, and then click Next to continue.
Enter a Replica ID, and then click Next.
For this example, when enabling replication on DirectoryServer-1, assign the number 11.
If you have not already been prompted to select the change log file, you are prompted to select one now.
The default change log file is shown in the text field. If you do not wish to use the default, type in a filename for the change log, or click Browse to display a file selector. If the change log has already been enabled, the wizard will skip this step.
If you have not already been prompted to enter and confirm a password for the default replication manager, you are prompted now.
The replication manager is not used in the case of single-master replication, but you must still enter a password to proceed. For this example, enter replm4n4ger.
The Replication Wizard displays a status message while updating the replication configuration.
Click Close when replication is finished.
On Directory Server 2, start the Directory Server console.
# cd /var/opt/mps/serverroot/ # ./startconsole & |
Log in to the Directory Server 2 console using the following information:
cn=Directory Manager
d1rm4n4ger
http://DirectoryServer-2.example.com:1391
In the Directory Server console, under the Servers and Applications tab, expand the Server Administration domain list until you see the Server Group item.
Click to expand the Server Group.
You should see the following items: an Administration Server, a Directory Server (am-config), a Directory Server (ds-config), and a Directory Server (am-users).
Double-click the instance name Directory Server (am-users) to display the console for managing the instance am-config.
Click the Configuration tab and navigate to the Replication pane.
Click the “Enable replication” button to start the Replication Wizard.
Select Master Replica, and then click Next to continue.
Enter a Replica ID, and then click Next.
For this example, when enabling replication on DirectoryServer-2, assign the number 22.
If you have not already been prompted to select the change log file, you are prompted to select one now.
The default change log file is shown in the text field. If you do not wish to use the default, type in a filename for the change log, or click Browse to display a file selector. If the change log has already been enabled, the wizard will skip this step.
If you have not already been prompted to enter and confirm a password for the default replication manager, you are prompted now.
The replication manager is not used in the case of single-master replication, but you must still enter a password to proceed. For this example, enter replm4n4ger.
The Replication Wizard displays a status message while updating the replication configuration.
Click Close when replication is finished.
On DirectoryServer-1, in the Directory Server console, display the general properties for the Directory Server instance named am-users .
Navigate through the tree in the left panel to find the Directory Server instance named am-users, and click on the instance name to display its general properties.
Click the Open button to display the console for managing the am-users instance.
Click the Configuration tab and navigate to the Replication pane.
Click the New button.
In the Replication Agreement dialog box, click the Other button.
In the Remote Server dialog box, provide the following information, and then click OK.
DirectoryServer-2.example.com
1489
Leave this box unmarked.
In the Replication Agreement dialog, for the distinguished name (DN) of the replication manager entry on the consumer server, accept the default value.
By default, the DN is that of the default replication manager.
For the password of the replication manager, enter replm4n4ger.
(Optional) Provide a description string for this agreement.
For this example, enter Replication from DirectoryServer-1 to DirectoryServer-2.
Click OK when done.
In the confirmation dialog, click Yes to test the connection to the server and port number.
Use the given replication manager and password replm4n4ger.
If the connection fails, you will still have the option of using this agreement. For example, the parameters are correct but the server is offline. When you have finished, the agreement appears in the list of replication agreements for this master replica.
On DirectoryServer-2, in the Directory Server console, display the general properties for the Directory Server instance named am-users.
Navigate through the tree in the left panel to find the Directory Server instance named am-users, and click on the instance name to display its general properties.
Click the Open button to display the console for managing the am-users instance.
Click the Configuration tab and navigate to the Replication pane.
Click the New button.
In the Replication Agreement dialog box, click the Other button.
In the Remote Server dialog box, provide the following information, and then click OK.
DirectoryServer-1.example.com
1489
Leave this box unmarked.
In the Replication Agreement dialog, for the distinguished name (DN) of the replication manager entry on the consumer server, accept the default value.
By default, the DN is that of the default replication manager.
For the password of the replication manager, enter replm4n4ger.
(Optional) Provide a description string for this agreement.
For this example, enter Replication from DirectoryServer-2 to DirectoryServer-1.
Click OK when done.
In the confirmation dialog, click Yes to test the connection to the server and port number.
Use the given replication manager and password.
If the connection fails, you will still have the option of using this agreement. For example, the parameters are correct but the server is offline. When you have finished, the agreement appears in the list of replication agreements for this master replica.
On DirectoryServer–1, in the Directory Server console, navigate through the tree in the left panel to find the Directory Server instance named am-users, and click on the instance name to display its general properties.
Double-click the instance name Directory Server (am-users) in the tree to display the console for managing the data.
Click the Configuration tab and navigate to the Replication pane.
In the list of defined agreements, select the replication agreement corresponding to DirectoryServer-2, the consumer you want to initialize.
Click Action > Initialize remote replica.
A confirmation message warns you that any information already stored in the replica on the consumer will be removed.
In the Confirmation dialog, click Yes.
Online consumer initialization begins immediately. The icon of the replication agreement shows a red gear to indicate the status of the initialization process.
Click Refresh > Continuous Refresh to follow the status of the consumer initialization.
Any messages for the highlighted agreement will appear in the text box below the list.
Verify that replication is working properly.
Log in to both Directory Server hosts as a root user, and start both Directory Server consoles.
Log in to each Directory Server console.
In each Directory Server console, enable the audit log on both Directory Server instances.
Go to Configuration > Logs > Audit Log. Check Enable Logging, and then click Save.
In separate terminal windows , use the tail -f command to watch the audit log files change.
On DirectoryServer-1, in the Directory Server console, create a new user entry.
Go to the Directory tab, and expand the suffix dc=company,dc=com.
Right-click users, and then choose New > User.
In the Create New User dialog, enter a first name and last name, an then click OK.
Note the user entry is created in the instance audit log. Check to be sure the same entry is also created in on DirectoryServer-2 in the Directory Server instance audit log
On DirectoryServer-2, in the Directory Server console, create a new user entry.
Go to the Directory tab, and expand the suffix dc=company,dc=com.
Right-click users, and then choose New > User.
In the Create New User dialog, enter a first name and last name, an then click OK.
Note the user entry is created in the instance audit log. Check to be sure the same entry is also created in on DirectoryServer-1 in the Directory Server instance audit log
Delete both new user entries in the Directory Server 2 console.
Look in the Directory Server 1 console to verify that both users have been deleted.
Contact your network administrator to obtain an available virtual IP address for the load balancer you want to configure.
You must also 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.
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.
You must also have ready the IP addresses for Directory Server 1 and Directory Server 2.
To obtain these IP addresses, on each Directory Server host, run the following command:
ifconfig —a
Create a Pool.
A pool contains all the backend server instances.
Go to URL for the Big IP load balancer login page.
Open the Configuration Utility.
Click “Configure your BIG-IP (R) using the Configuration Utility.”
In the left pane, click Pools.
On the Pools tab, click the Add button.
In the Add Pool dialog, provide the following information:
Example: DirectoryServer-UserData-Pool
Round Robin
Add the IP address of both Directory Server hosts. In this case, add the IP address and port number for DirectoryServer-1:1489 and for DirectoryServer-2:1489.
Click the Done button.
Add a Virtual Server.
If you encounter Javascript errors or otherwise cannot proceed to create a virtual server, try using Microsoft Internet Explorer for this step.
In the left frame, Click Virtual Servers.
On the Virtual Servers tab, click the Add button.
In the Add a Virtual Server dialog box, provide the following information:
xxx.xx.69.14 (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 the Pool (DirectoryServer-POOL) that you have just created.
Click the Done button.
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.
Three columns exist on this page: Node, Node Address, and Service. In the Node column, locate the IP address and port number DirectoryServer-1:1489 . 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 for DirectoryServer–2:1489. 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.
Verify the Directory Server load balancer configuration.
Log in as a root user to the host of each Directory Server.
On each Directory Server host, use the tail command to monitor the Directory Server access log.
# cd /var/opt/mps/serverroot/slapd-am-users/logs
# tail -f access
You should see connections to the load balancer IP address opening and closing. Example:
[12/Oct/2006:13:10:20-0700] conn=54 op=-1 msgId=-1 — fd=22 slot=22 LDAP connection from xxx.xx.69.18 to xxx.xx.72.33
[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:
# cd /var/opt/mps/serverroot/shared/bin/ # ./ldapsearch -h LoadBalancer-2.example.com -p 1489 -b "dc=company,dc=com" -D "cn=directory manager" -w d1rm4n4ger "(objectclass=*)" |
The ldapsearch operation should return entries. Make sure the directory access entries display in only one Directory Server access log.
Stop Directory Server 1, and again perform the following LDAP search against the Directory Server load balancer:
# cd /var/opt/mps/serverroot/slapd-am-config # ./stop # cd /var/opt/mps/serverroot/shared/bin/ # ./ldapsearch -h LoadBalancer-2.example.com -p 1489 -b "dc=company,dc=com" -D "cn=directory manager" -w d1rm4n4ger "(objectclass=*)" |
The ldapsearch operation should return entries. Verify that the Directory Server access entries display in only one Directory Server access log.
You may encounter the following error message:
ldap_simple_bind: Cant' connect to the LDAP server — Connection refused
In the Load Balancer configuration page, reset the timeout properties to lower values.
Click the Monitors tab, and click the ldap-tcp monitor name.
In the Interval field, set the value to 5.
In the Timeout field, set the value to 16.
The default is 16 seconds. You can change this number to any value. In this deployment example, the BigIP documentation recommends the value should be at least three times the interval number of seconds plus one second.
Click Apply.
Repeat the LDAP search.
Restart the stopped Directory Server 1, and then stop Directory Server 2.
Confirm that the requests are forwarded to the running Directory Server 1.
Perform the following LDAP search against the Directory Server load balancer.
# cd /var/opt/mps/serverroot/shared/bin/ # ./ldapsearch -h LoadBalancer-2.example.com -p 1489 -b "dc=company,dc=com" -D "cn=Directory Manager" - w d1rm4n4ger "(objectclass=*)" |
The ldapsearch operation should return entries. Make sure the directory access entries display in only the one Directory Server access log.
Create a new realm that you can use to authenticate against only the existing Directory Server. The two Access Manager servers share configuration, so you configure the new realm on just one Access Manager server.
Use the following as your checklist for creating a user realm:
Start a new browser and log in to the first Access Manager server.
Go to the URL http://AccessManager-1.example.com:1080/amserver/console
Log in as a root user to the Access Manager console using the following information:
amadmin
4m4dmin1
Click the Access Control tab, and then click New.
In the New Realm page, in the Name field, enter users .
Click OK.
On the Access Control tab, under Realms, click the Realm Name users.
On the General tab for users-Properties, add users to the Realm/DNS/Aliases list.
In the Add field enter users, and then click Add.
Click Save.
Modify the User Profile.
Click Realms.
On the Access Control tab, under Realms, select the new realm users.
Click the Authentication tab.
In the General section, click Advanced Properties.
In the Core page, in the Realm Attributes section, change the User Profile attribute to Ignored.
Access Manager is configured to use only the existing Directory Server for authentication, and a full User Profile may not exist. That's why the attribute is set to Ignored in this example.
Click Save.
The changes are saved, and the Core > Realm Attributes page is displayed.
Create a new authentication module.
Configure the new realm.
In the users — Authentication page, in the New Module Instances section, click the New Instance named usersLDAP.
In the LDAP > Realm Attributes page, set the following attributes:
In the Add field, enter the hostname and port number for the load balancer for the user data store:LoadBalancer-2.example.com:489 .
In the server listbox, select the default server, then click Remove.
In the Add field, enter dc=company,dc=com and then click Add.
Select the default entry o=example.com, and then click Remove.
uid=userdbauthadmin,ou=users,dc=company,dc=com
4serd84uth4dmin
4serd84uth4dmin
These values were imported into the user data store in a previous task. See To Import Users into the User Data Store.
Click Save.
The changes are saved, and the users — Authentication page is displayed.
Configure the default ldapService chain to use the new authentication module.
Remove the LDAP authentication module.
This module is automatically inherited from the default realm and it authenticates against the Access Manager configuration directory. The module is no longer needed now that the usersLDAP module will be used for authentication.
On the users — Authentication page, click Save.
Changes you made in the previous steps are saved.
This procedure is not required to make Access Manager work in all scenarios because not all scenarios require role support. The procedure is required in this deployment example because policies are created in later procedures, and the policies will refer to roles.
On the Access Control tab, under Realms, click the users link.
Click the Data Stores tab, and then click the usersLDAP link.
On the Edit Data Store page, in the section “LDAPv3 Plugin Supported Types and Operations,” in the Add field, enter role=read,create,edit,delete, and then click Add.
In the section, “LDAP User Attributes,” in the Add field, enter nsrole, and then click Add.
In the Add field, enter nsroledn, and then click Add.
Click Save.
Edit the Top-Level Realm.
Click Edit Realm.
Click Subjects > Role.
Two roles employee and manager are in the Roles list.
Click the Users tab, and then click the testuser1 link.
Click on the Role tab.
Verify that testuser1 is added to the manager role. The role manager is displayed in the list of selected roles.
Click Edit Realm —users, and then click the testuser2 link.
Click on the Role tab.
Verify that testuser2 is added to the employee role. The role employee is displayed in the list of selected roles.
Click Edit Realm —users, and then click the testuser2 link.
Delete the default data store.
Create a new data store.
Click New .
In the “Step 1 of 2: Select Type of Data Store” page, set the following attributes:
Enter usersLDAP.
Choose “LDAPv3 Repository Plug-In.”
Click Next.
In the “Step 2 of 2: New Data Store” page, set the following attributes:
In the Add field, enter the hostname and port number for the existing directory. Use the form LoadBalancer-2.example.com:489
Select the default DirectoryServer-1.example.com:1389 , and then click Remove.
Enter uid=userdbadmin,ou=users,dc=company,dc=com .
4serd84dmin
4serd84dmin
Enter dc=company,dc=com.
users
When this field is empty, the search for users will start from the root suffix.
Enter dc=company,dc=com.
These values were imported into the user data store in a previous task. See To Import Users into the User Data Store.
Click Finish and log out of the Access Manager console.
Restart each Access Manager server for the changes to take place.
Log in to each Access Manager host system, and restart the Web Server on each host system.
Verify that in the Access Manager console you can see the users in the external user data store.
Go to the Access Manager URL.
http://AccessManager-1.example.com:1080/amserver/UI/Login
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
Click on Users Realm.
Click on Subjects tab.
You should see three new users: authuiadmin, userdbadmin, and userdbauthadmin.
Verify that a user can successfully authenticate against the new realm.
Start a new browser session and log in to Access Manager.
Go to the following URL:
http://AccessManager-1.example.com:1080/amserver/UI/Login?realm=users
The parameter realm=users specifies the new realm to use for authentication. Without the parameter, the default realm is used.
On the login page, provide a user login and password from the existing directory.
authuiadmin
4uthu14dmin
You should be able to log in successfully.
If the login is not successful, watch the existing Directory Server access log to troubleshoot the problem.
At this point, a user can log in against the existing Directory Server if he invokes the realm=users parameter. If such a parameter is absent, the default realm is used.
Administrators who want to access the Access Manager console should log in to the default realm.
You can user the Access Manager console to create, edit, and delete user profiles in your existing data store. The procedures in this section are optional.
Access Manager typically is used more for policy management than for user management. In most cases, the user repository is a different repository than the one used by Access Manager to store its configuration. Administrators usually prefer to manage the user repository separately or differently from the Access Manager repository. However, at some times administrators find it necessary to manage the assignment of Access Manager services to users or roles. For convenience, administrators can to do this through the Access Manager console. The relevant AM objectclasses must be imported into the user repository so that Access Manager can read and write Access Manager service properties into the relevant entries in the user repository.
Use the following as your checklist for enabling Access Manager to manage users in the existing data store:
Configure Access Manager to manage users in an existing user data store.
Verify that user management with the existing data store works properly.
Copy Access Manager schema to Directory Server 1.
Copy Access Manager schema to Directory Server 2.
Start the Directory Server 1 console.
# cd /var/opt/mps/serverroot # ./startconsole & |
Log in to the Directory Server 1 console using the following information:
cn=Directory Manager
d1rm4n4ger
http://DirectoryServer-1.example.com:1391
Create a new Access Control Instruction (ACI).
In the Directory Server console, in the navigation tree, expand the Server Group object and then click on the am-users instance.
On the Directory Server page for am-users, click Open.
Click the Directory tab.
In the navigation tree, click the dc=company, dc=com suffix.
Double-click the Directory Administrators group.
On the Edit Entry page for Directory Administrators, click Members.
On the Static Group page, click Add.
In the Search dialog, click Search.
In the results list, click the User ID userdbadmin.
The Member User ID userdbadmin is now added to the Static Group list.
Click OK.
Set access permissions.
On the Directory tab, in the navigation tree, right— click the dc=company, dc=com suffix, and the select Set Access Permissions.
In the Manage Access Control dialog, click New.
In the Edit ACI dialog, in the ACI name field, enter Directory Administrators.
In the list of Users/Groups, select All Users, and then click Remove.
Click Add.
In the Add Users and Groups, click Search.
In the Search results list, select Directory Administrators, and then click Add.
Click OK.
The group Directory Administrators group is now displayed in the list of Users/Groups who have access permission.
Click the Target tab.
In the “Target directory entry,” click This Entry.
The dc=company,dc=com suffix is displayed.
Click OK.
The Directory Administrators group is displayed in the Manage Access Control dialog.
Click OK, and then log out of Directory Server 1.
Restart both Directory Server 1 and Directory Server 2.
Log in as a root user to the Directory Server 1 host.
# cd /var/opt/mps/serverroot # ./restart |
Log in as a root user to the Directory Server 2 host.
# cd /var/opt/mps/serverroot # ./restart |
If you see errors such as the following on the command line:
[13/Oct/2006:12:43:39 -0700] - ERROR<5895> - Schema - conn=-1 op=-1 msgId=-1 - User error: Entry "cn=schema", single-valued attribute "modifyTimestamp" has multiple values |
then run the following commands:
# cd config/schema # edit file 98am-schema.ldif # remove the entries: modifiersName: cn=directory manager modifyTimestamp: 20060913190551Z # cd ../.. # ./restart-slapd |
Restart both Access Manager 1 and Access Manager 2.
In a browser, go to the following Access Manager URL:
https://loadbalancer-3.example.com:9443/amserver/UI/Login
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
Add a new user.
On the Realms page, click the users link.
Click the Subjects tab.
On the User page, under User, click New.
On the New User page, provide the following information, and then click Create:
johndoe
John
Doe
John Doe
password
password
John Doe is now displayed in the list of Users. This indicates the user created in Access Manager was also created in Directory Server. Changes to the user profile were updated in Directory Server.
Modify the John Doe entry.
Log in as a root user to the host DirectoryServer-1.
Start the Directory Server console:
# cd /var/opt/mps/serverroot # ./startconsole & |
Log in to the Directory Server console using the following information:
cn=Directory Manager
d1rm4n4ger
http://DirectoryServer-1.example.com:1391
In the navigation tree, expand the DirectoryServer-1 node, and expand the Server Group.
Click the am-users instance.
On the Directory Server page for am-users , click Open.
Click the Directory tab.
Click the dc=company,dc=com suffix, and then click the users group.
In the list of users, double-click the johndoeentry.
In the Edit User page, verify that the information is the same as the information you entered through the Access Manager console in the previous steps.
Leave the Directory Server console open.
In the Access Manager console, create a new role and add John Doe to the role.
In the Realms page for users, click the Subjects tab.
Click the Role tab.
Under Roles, click New Role.
In the Role page, in the Name field, enter testRole.
Click Create.
The new role testRole is now displayed in the list of roles.
Click the testRole link.
Click the User tab.
In the Edit Role page for testRole, in the Available list, select johndoe.
Click Add.
The user johndoe is added to the Selected list.
Click Save.
John Doe is now added to the testRole role.
Verify that the new user and role are created in Directory Server.
This chapter contains detailed instructions for the following tasks:
Use the following as your checklist for installing Web Server 1 and Web Policy Agent 1:
Import the root CA certificate into the Web Server 1 key store.
Configure the Web Policy Agent to use the new agent profile.
For this part of the deployment, you must have the JES 5 installer and Web Policy Agent installer mounted on the host Protected Resource 1. See 3.2 Downloading and Mounting the Java Enterprise System 2005Q4 Installer at the beginning of this manual.
As a root user, log into host ProtectedResource-1.
Start the Java Enterprise System installer with the -nodisplay option.
# cd /mnt/Solaris_sparc # ./installer -nodisplay |
When prompted, provide the following information:
|
Press Enter. |
|
|
Press Enter. |
|
|
Enter y. |
|
|
Enter 8 for “English only.” |
|
|
Enter 3 to select Web Server. |
|
|
Press Enter. |
|
Enter 1 to upgrade these shared components and 2 to cancel [1] |
You are prompted to upgrade shared components only if the installer detects that an upgrade is required. Enter 1 to upgrade shared components. |
|
|
Accept the default value. |
|
|
Enter 1. |
|
|
Enter 1. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Enter admin. |
|
|
For this example, enter web4dmin. |
|
|
Enter the same password to confirm it. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
For this example, enter web4dmin. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Enter root. |
|
|
Enter root. |
|
|
Enter 1080. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
First, see the next numbered (Optional) step. When ready to install, enter 1. |
(Optional) During installation, you can monitor the log to watch for installation errors. Example:
# cd /var/sadm/install/logs
# tail —f Java_Enterprise_System_install.B xxxxxx
Upon successful installation, enter ! to exit.
Verify that the Web Server is installed properly.
Start the Web Server administration server to verify it starts with no errors.
# cd /opt/SUNWwbsvr/https-admserv
# ./stop; ./start
Run the netstat command to verify that the Web Server ports are open and listening.
# netstat -an | grep 8888 *.8888 *.* 0 0 49152 0 LISTEN |
Go to the Web Server URL.
http://ProtectedResource-1.example.com:8888
Log in to the Web Server using the following information:
admin
web4dmin
You should be able to see the Web Server console. You can log out of the console now.
Start the Protected Resource 1 instance.
# cd /opt/SUNWwbsvr/https-ProtectedResource-1.example.com # ./stop; ./start |
Run the netstat command to verify that the Web Server ports are open and listening.
# netstat -an | grep 1080 *.1080 *.* 0 0 49152 0 LISTEN |
Go to the instance URL.
http://ProtectedResource-1.example.com:1080
You should see the default Web Server index page.
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 http://docs.sun.com/app/docs/doc/819-2796/6n52flfoq?a=view#adtcd.
As a root user, log into to host ProtectedResource–1.
Download the Java System Web Policy Agents 2.2 package from the following website:
Unpack the downloaded package.
In this example, the package was downloaded into the directory /temp.
# cd /temp # gunzip sun-one-policy-agent-2.2-es6-solaris_sparc.tar.gz # tar —xvof sun-one-policy-agent-2.2-es6-solaris_sparc.tar |
Start the Web Policy Agents installer.
# ./setup -nodisplay
When prompted, provide the following information:
|
Press Enter. |
||
|
Press Enter. |
||
|
Enter y. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Enter
|
||
|
Enter 1080. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
For this example, enter the external-facing load balancer host name. Example: LoadBalancer-3.example.com |
||
|
Enter the load balancer HTTP port number. For this example, enter 90. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Enter the amldapuser password that was entered when Access Manager was installed. For this example, enter 4mld4puser . |
||
|
Enter the 4mld4puser password again to confirm it. |
||
|
Accept the default value. |
||
|
First, see the next (Optional) numbered step. When you are ready to start installation, press Enter. |
(Optional) During installation, you can monitor the log to watch for installation errors. Example:
# cd /var/sadm/install/logs # tail —f var/sadm/install/logs/ Sun_Java_tm__System_Access_Manager_Policy_Agent_install.Bxxxxxxxx |
Modify the AMAgent.properties file.
# cd /etc/opt/SUNWam/agents/es6/ config/_opt_SUNWwbsvr_https-ProtectedResource-1.example.com |
Make a backup of AMAgent.properties before setting the following property:
com.sun.am.policy.am.login.url = https://LoadBalancer-4.example.com:9443/distAuth/UI/Login?realm=users
Restart the Web Server.
# cd /opt/SUNWwbsvr/https-ProtectedResource-1.example.com # ./stop; ./start |
Examine the Web Server log for startup errors.
# /opt/SUNWwbsvr/https-ProtectedResource-1.example.com/logs # vi errors |
Start a new browser and go to the Access Manager URL.
Example: https://loadbalancer-3.example.com:9443/amserver/console
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
Create a referral policy in the top-level realm.
On the Access Control tab, under Realms, click example.com.
Click the Policies tab.
On the Policies tab for example.com-Policies, click New Referral.
In 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.
Select a Service Type.
On the page “Step 1 of 2: Select Service Type for the Rule,” select URL Policy Agent (with resource name)
Click Next.
On the page “Step 2 of 2: New Rule,” provide the following information:
URL Rule for ProtectedResource-1
http://ProtectedResource-1.example.com:1080/*
Click Finish.
On the same page, in the Referrals section, click New.
In the New Referral — Sub Realm page, provide the following information:
Sub-Realm users
Type an asterisk (*), and then click Search.
In the list, choose users.
Click Finish.
On the New Policy page, click Create.
In the Policies tab for example.com — Policies, you should see the policy named “Referral URL Policy for users realm.”
Create a policy in the users realm.
Click Realms.
On the Access Control tab, under Realms, click the Realm Name users.
Click the Policies tab.
On the Policies tab for users-Policies, click New Policy.
In 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.
On the page “Step 1 of 2: Select Service Type for the Rule,” click Next.
The Service Type “URL Policy Agent (with resource name) is the only choice.
On the page “Step 2 of 2: New Rule,” provide the following information:
URL Rule for ProtectedResource-1
Click the URL listed in the Parent Resource Name list: http://ProtectedResource-1.example.com:1080/*
The URL is automatically added to the Resource Name field.
Mark this checkbox, and select the Allow value.
Mark this checkbox, and select the Allow value.
Click Finish.
Create a new subject.
On the New Policy page, in the Subjects section, click New.
Select the subject type and then click Next.
On the page “Step 1 of 2: Select Subject Type,” select the “Access Manager Identity Subject” type.
On the page “Step 2 of 2: New Subject — Access Manager Identity Subject,” provide the following information:
Enter Test Subject.
Choose User, and then click Search. Four users are added to the Available list.
In the list, selecttestuser1, and then click Add.
The user testuser1 is added to the Selected list.
Click Finish.
In the New Policy page, click Create.
On the Policies tab for users-Policies, the new policy “URL Policy for ProtectedResource-1” is now in the Policies list.
Log out of the console.
Verify that an authorized user can access the Web Server 1.
Go to the following URL:
http://ProtectedResource-1.example.com:1080
Log in to Access Manager using the following information:
testuser1
password
You should see the default index.html page for Web Server 1.
The user testuser1 was configured in the test policy to be allowed to access Protected Resource 1.
Verify that an unauthorized user cannot access the Web Server 1.
Go to the following URL:
http://ProtectedResource-1.example.com:1080
Log in to Access Manager using the following information:
testuser2
password
You should see the message, “You're not authorized to view this page.”
The user testuser2 was not included in the test policy tat allows access to Protected Resource 1.
The Web Policy Agent on Protected Resource 1 connects to Access Manager servers through Load Balancer 3. The load balancer is SSL-enabled, so the agent must be able to trust the load balancer SSL certificate in order to establish the SSL connection. To do this, import the root CA certificate that issued the Load Balancer 3 SSL server certificate into the Web Policy Agent certificate store.
Obtain the root CA certificate, and copy it to ProtectedResource-1.
Copy the root CA certificate to Protected Resource 1.
Open a browser, and go to the Web Server 1 administration console.
http://ProtectedResource-1.example.com:8888
Log in to the Web Server 2 console using the following information:
admin
web4dmin
In the Select a Server field, select ProtectedResource-1.example.com, and then click Manage.
If a “Configuration files have not been loaded” message is displayed, it may be that the administration server has never been accessed, and so the configuration files have never been loaded. First click Apply, and then click Apply Changes. The configuration files are read, and the server is stopped and restarted.
Click the Security tab.
On the Initialize Trust Database page, enter a Database Password.
Enter the password again to confirm it, and then click OK.
In the left frame, click Install Certificate and provide the following information, and then click OK:
Choose Trusted Certificate Authority (CA).
password
OpenSSL_CA_Cert
/export/software/ca.cert
Click Add Server Certificate.
Click Manage Certificates.
The root CA Certificate name OpenSSL_CA_Cert is included in the list of certificates.
Click the Preferences tab.
Restart Web Server 2.
On the Server On/Off page, click Server Off. When the server indicates that the administration server is off, click Server On.
Configure the Web Policy Agent 1 to point to the Access Manager SSL port.
Edit the AMAgent.properties file.
# cd /opt/SUNWam/agents/es5/config/ _optSUNWwbsvr_https=ProtectedResource-1.example.com
Make a backup of the AMAgent.properties file before setting the following property:
# com.sun.am.naming.url = https://LoadBalancer-3.example.com:9443/amserver/namingservice
Save the file.
Restart Web Server 1.
# cd /opt/SUNWwbsvr/https-ProtectedResource-1.example.com # ./stop; ./start
Verify that an authorized user can access the Web Server 1.
Go to the following URL:
http://ProtectedResource-1.example.com:1080
Log in to Access Manager using the following information:
testuser1
password
You should see the default index.html page for Web Server 1.
The user testuser1 was configured in the test policy to be allowed to access Protected Resource 1.
Verify that an unauthorized user cannot access the Web Server 1.
Go to the following URL:
http://ProtectedResource-1.example.com:1080
Log in to Access Manager using the following information:
testuser2
password
You should see the message, “You're not authorized to view this page.”
The user testuser2 was not included in the test policy tat allows access to Protected Resource 1.
The web agent will, by default, use the account with the uid UrlAccessAgent to authenticate to Access Manager. Creating an agent profile is not a requirement for Web Policy Agents. You can use the default values and never change the Web Policy Agent 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.
Create an agent profile on Access Manager.
This new account will be used by Web Policy Agent 1 to access the Access Manager server.
Go to Access Manage load balancer URL:
https://LoadBalancer-3.example.com:9443/amserver/UI/Login
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
On the Access Control tab, under Realms, click the realm name example.com.
Click the Subjects tab.
Click the Agents tab.
On the Agent page, click New.
On the New Agent page, provide the following information:
webagent-1
web4gent1
web4gent1
Choose Active.
Click Create.
The new agent webagent–1 is now display in the list of Agent Users.
Log in to as a root user to Protected Resource 1.
Run the cypt_util utility.
The utility encrypts the password.
# cd /opt/SUNWam/agents/bin # ./crypt_util web4gent1 BXxzBswD+PZdMRDRMXQQA==
Copy the encrypted password, and save it in a text file.
Edit the AMAgent.properties file.
# cd /etc/opt/SUNWam/agents/es6/ config/_opt_SUNWwbsvr_https-ProtectedResource-1.example.com |
Make a backup of AMAgent.properties you make the following change in the file:
com.sun.am.policy.am.password = webagent-1 com.sun.am.policy.am.password = BXxzBswD+PZdMRDRMXQQA==
Use the encrypted password obtained in the previous step.
Save the file.
Restart Web Server 1.
# cd /opt/SUNWwbsvr/https-ProtectedResource-1.example.com # ./stop; ./start
Verify that an authorized user can access the Web Server 1.
Go to the following URL:
http://ProtectedResource-1.example.com:1080
Log in to Access Manager using the following information:
testuser1
password
You should see the default index.html page for Web Server 1.
The user testuser1 was configured in the test policy to be allowed to access Protected Resource 1.
Verify that an unauthorized user cannot access the Web Server 1.
Go to the following URL:
http://ProtectedResource-1.example.com:1080
Log in to Access Manager using the following information:
testuser2
password
You should see the message, “You're not authorized to view this page.”
The user testuser2 was not included in the test policy tat allows access to Protected Resource 1.
You must have the WebLogic Application Server installer and the Sun J2EE Policy Agent installer mounted on Protected Resource 1.
Use the following as your checklist for installing Application Server 1 and the J2EE Policy Agent 1:
Obtain the Application Server installer from the BEA .
Start the installer.
# /download_directory/export/weblogic/server910_solaris32.bin |
Provide the following information when prompted:
|
Enter Next. |
|
|
Enter 1. |
|
|
Press Enter to accept the default value and continue. |
|
|
Enter 2. |
|
|
Press Enter to continue. |
|
|
Press Enter to accept the default value and continue. |
|
|
Press Enter to confirm the default value and continue. |
|
|
Press Enter. |
Create a new domain.
Start the BEA WebLogic Configuration Wizard.
# cd /usr/local/bea/weblogic91/common/bin # ./config.sh |
Provide the following information:
|
Press Enter to accept the default value 1. |
|
|
Press Enter to accept the default value 1. |
|
|
Press Enter to accept the default value and continue. |
|
|
Enter 2 to modify the user password. |
|
|
Enter w3bl0g1c. |
|
|
Enter 3 to confirm user password. |
|
|
Enter w3bl0g1c. |
|
|
Press Enter to accept the values and continue. |
|
|
Enter 2 to select Production Mode. |
|
|
Press Enter to accept the default value and continue. |
|
|
Enter 1 . |
|
|
Press Enter to Continue. |
|
|
Enter ApplicationServer-1. |
|
|
Enter 3 to modify the Listen port. |
|
|
Enter 1081. |
|
|
Press Enter to continue. |
|
|
Press Enter to continue. |
|
|
Press Enter to continue. |
|
|
Enter ProtectedResource-1. |
|
|
Press Enter to accept these values. |
|
|
Enter 1 to add a Unix machine. |
|
|
Enter ProtectedResource-2. |
|
|
Press Enter to accept these values. |
|
|
Press Enter to continue. |
|
|
Press Enter to continue. |
|
|
Enter ProtectedResource-1. |
|
|
Press Enter to continue. |
|
|
Press Enter. |
Create two files necessary to automate Application Server 1 startup.
Create one file in the directory for the Application Server 1 administration server, and create one file in the Application Server 1 instance directory. The administrative user and password are stored in each file. Application Server 1 uses this information during server start-up. Without these files, Application Server 1 will fail to start. Application Server 1 encrypts the file, so there is no security risk even though you enter the user name and password in clear text.
# cd /usr/local/bea/user_projects/domains/ ProtectedResource-1/servers/AdminServer # mkdir security # cd security/ # cat > boot.properties username=weblogic password=w3bl0g1c ^D # cd /usr/local/bea/user_projects/domains/ ProtectedResource-1/servers/ApplicationServer-1/ # mkdir security # cd security/ # cat > boot.properties username=weblogic password=w3bl0g1c ^D |
Start the servers.
# cd /usr/local/bea/user_projects/domains/ ProtectedResource-1/bin/ # nohup ./startWebLogic.sh & #tail -f nohup.out ... # netstat -an | grep 7001 xxx.xx.72.151.7001 *.* 0 0 49152 0 LISTEN 127.0.0.1.7001 *.* 0 0 49152 0 LISTEN # # cd /usr/local/bea/user_projects/domains/ProtectedResource-1/bin/ # nohup ./startManagedWebLogic.sh ApplicationServer-1 http://ProtectedResource-1.example.com:7001 & # cd /usr/local/bea/user_projects/domains/ ProtectedResource-1/bin/ # netstat -an | grep 1081 xxx.xx.72.151.1081 *.* 0 0 49152 0 LISTEN 127.0.0.1.1081 *.* 0 0 49152 0 LISTEN xxx.xx.72.151.33425 xxx.xx.72.151.1081 49152 0 49152 0 ESTABLISHED xxx.xx.72.151.1081 xxx.xx.72.151.33425 49152 0 49152 0 ESTABLISHED |
Verify that Application Server 1 is up and running.
Go to the following URL:
http://ProtectedResource-1.example.com:7001/console
Log in to the Application Server 1 console using the following information:
weblogic
w3bl0g1c
Verify that you can successfully log into the console.
Under Domain Structure , expand the Environment object
Click Servers.
On the Summary of Servers page, verify that both AdminServer(admin) and ApplicationServer-1 are running and OK.
This new account will be used by J2EE Policy Agent 1 to authenticate to the Access Manager server.
Go to Access Manage load balancer URL:
https://LoadBalancer-3.example.com:9443/amserver/UI/Login
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
On the Access Control tab, under Realms, click the realm name example.com.
Click the Subjects tab.
Click the Agents tab.
On the Agent page, click New.
On the New Agent page, provide the following information:
j2eeagent-1
j2ee4gent1
j2ee4gent1
Choose Active.
Click Create.
The new agent j2eeagent–1 is now display in the list of Agent Users.
Log out of the Access Manager console.
Create a text file, and add the Agent Profile password to the file.
The J2EE Policy Agent installer requires this file for installation.
# cd /opt/j2ee_agents/amwl9_agent # cat > agent_pwd j2ee4gent1 ^D
Application Server 1 must be stopped when you install J2EE Policy Agent 1.
You must stop both the Application Server 1 instance and the administration server before installing J2EE Policy Agent 1.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-1/bin/ # ./stopManagedWebLogic.sh ApplicationServer-1 t3://localhost:7001 # cd /usr/local/bea/user_projects/domains/ProtectedResource-1/bin # ./stopWebLogic.sh |
Unpack the J2EE Policy Agent bits.
# cd /opt # /usr/sfw/bin/gtar -xvf /export/software/SJS_Weblogic_9_agent_2.2.tar |
Start the J2EE Policy Agent installer.
# cd /opt/j2ee_agents/am_wl9_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-1. |
||
|
Enter LoadBalancer-3.example.com. |
||
|
Enter 90. |
||
|
Enter http. |
||
|
Accept the default value. |
||
|
ProtectedResource-1.example.com |
||
|
Enter /usr/loca/bea/weblogic91. |
||
|
Enter 1081. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Enter j2eeagent-1. |
||
|
Enter /opt/j2ee_agent/am_w19_agent/agent_pwd. |
||
|
Accept the default value. |
||
|
Accept the default value. |
The J2EE Policy Agent installer creates a new file in the Application Server bin directory:
/usr/local/bea/user_projects/domains/ProtectedResource-1/bin/ setAgentEnv_ApplicationServer-1.sh |
Modify the Application Server startup script to reference the new file.
As a root user, log into ProtectedResource–1.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-1/bin/ |
Make a backup of setDomainEnv.sh.
In setDomainEnv.sh, insert the following line at the end of the file:
. /usr/local/bea/user_projects/domains/ProtectedResource-1/ bin/setAgentEnv_ApplicationServer-1.sh |
This command references the file the installer created in the Application Server bin directory.
Save the setDomainEnv.shfile.
Change permissions for the setAgentEnv_ApplicationServer-1.sh file:
# chmod 755 setAgentEnv_ApplicationServer-1.sh
Start the Application Server administration server.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-1/bin # nohup ./startWebLogic.sh & # tail -f nohup.out |
Watch for startup errors.
The J2EE Policy Agent is not yet ready to begin working. In the following procedures, you 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 as your checklist for completing the J2EE Policy Agent 1 installation:
Go to the following Protected Resource 1 directory.
The J2EE Policy Agent installer creates a new file in the Application Server bin directory:
# cd /usr/local/bea/user_projects/domains/ProtectedResource-1/bin
Make a backup of the file setDomainEnv.sh.
In the setDomainEnv.sh file, at the end of the file append the following:
echo "Setting Policy Agent Env..." . /usr/local/bea/user_projects/domains/ProtectedResource-1/bin/ setAgentEnv_ApplicationServer-1.sh |
This command references the file the installer created in the Application Server bin directory.
Save the setDomainEnv.sh file.
Change permissions for the setAgentEnv_ApplicationServer-1.sh file:
# cdmod 755 setAgentEnv_ApplicationServer-1.sh |
Stop Application Server 1.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-1/bin # ./stopManagedWebLogic.sh ApplicationServer-1 t3://localhost:7001
Stop the administration server.
#cd /usr/local/bea/user_projects/domains/ProtectedResource-1/bin ./stopWebLogic.sh
Start the administration server.
# nohup ./startWebLogic.sh & # tail -f nohup.out
Watch for startup errors.
Start Application Server 1.
# nohup ./startManageWebLogic sh ApplicatoinServer-1 http://ProtectedResource-1.example.com:7001 & tail -f nohup.out
Run the netstat command to verify that Application Server 1 is up and listening.
# netstat -an | grep 1081 xxx.xx.72.151.1081 *.* 0 0 49152 0 LISTEN 127.0.0.01.1081 *.* 0 0 49152 0 LISTEN
Go to the following Application Server URL:
http://ProtectedResource-1.example.com:7001/console
Log in to the Application Server console using the following information:
weblogic
w3bl0g1c
In the Application Server console, 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 the application directory: /opt/j2ee_agents/am_wl9_agent/etc/
Select agentapp.war, and then click Next.
In the Install Application Assistant page, choose “Install this deployment as an application,” and then click Next.
In the list of Servers, mark the checkbox for ApplicationServer-1, and then 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.
On the “Settings for agentapp” page, click Deployments.
On the Summary of Deployments page, mark the agentapp checkbox, and then click Start > “Servicing all requests.”
On the Start Deployments page, click Start.
You may encounter a Javascript error. The agent application will not start until you start the Application Server.
In the 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 Realm name myrealm link.
On the “Settings for myrealm” page, click the Providers tab.
On the Providers tab, under Authentication Providers, click New.
On the Create a New Authentication Provider page, provide the following information:
Agent-1
AgentAuthenticator
Click OK.
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 for OPTIONAL.
On the Settings for Agent-1 page, in the list of Authentication Providers, click DefaultAuthenticator.
On the Settings for DefaultAuthenticator page, set the Control Flag to OPTIONAL, and then click Save.
Return to the Providers page.
In the navigation tree near the top of the page, click Providers.
In the Change Center, click Activate Changes.
Make a backup of the following file:
/opt/j2ee_agents/am_wl9_agent/agent_001/config/AMAgent.properties
In the AMAgent.properties file, set the following property:
com.sun.identity.agents.config.bypass.principal[0] = weblogic
At end of the file, insert a new property.
com.sun.identity.session.resetLBCookie='true'
The default value for this property is false. You must add this property only if session failover has been configured for Access Manager. If session failover is not configured for Access Manager, and this property is added, it could impact performance negatively. If session failover is enabled for Access Manager, and this property is not added, then Access Manager sessions will still fail over, and the session failover functionality will work properly. However, the stickiness to the Access Manager server will not be maintained after failover occurs. Session stickiness to the Access Manager server helps performance. This property must be added to the AMConfig.properties file on the Access Manager servers, as well as to the AMAgent.properties for the J2EE Policy Agent servers. This property is not required for the Web Policy Agent servers. The Access Manager 7 2005Q4 Patch 3 in Sun Java System Access Manager 7 2005Q4 Release Notes Release Notes also references this property. See the sectionCR# 6440651: Cookie replay requires com.sun.identity.session.resetLBCookie property in Sun Java System Access Manager 7 2005Q4 Release Notes.
Save the file.
Use the following as your checklist for setting up a test for the J2EE Policy Agent 1:
The BEA Policy Agent comes with a sample application specifically created to help you test your access policies. Locate the sample application file here: opt/j2ee_agents/am_wl9_agent/sampleapp. For more information, see the file /opt/j2ee_agents/am_wl9_agent/sampleapp/readme.txt.
Go to the Application Server 1 URL:
http://ProtectedResource-1.example.com:7001/console
Log in to the Application Server using the following information:
weblogic
w3bl0g1c
In the Application Server console, 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: /opt/j2ee_agents/am_wl9_agent/sampleapp/dist
Select agentsample, and then click Next.
In the Install Application Assistant page, choose “Install this deployment as an application,” and then click Next.
In the list of Servers, mark the checkbox for ApplicationServer-1, and then 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.
In the “Settings for agentsample” page, click Activate Changes.
Under Domain Structure, click Deployments.
In the Deployments list, mark the checkbox for agentsample, and then click Start > Servicing All Requests.
On the Start Deployments page, click Yes.
The state of the deployment changes from Prepared to Active.
Log out of the Application Server 1 console.
You will use these roles to verify that the sample application has been successfully installed and configured.
Start the Directory Server 1 console, and log in:
cn=Directory Manager
d1rm4n4ger
http://DirectoryServer-1.example.com:1391
In the Directory Server console, expand the example.com suffix.
Click Server Group > am-users, and then click Open.
Click the Directory tab.
Right-click dc=company, dc=com, and then click New > Role.
In the Create New Role page, in the Role Name field, enter manager, and then click OK.
Right-click dc=company, dc=com, and then click New > Role.
In the Create New Role page, in the Role Name field, enter employee, and then click OK.
On the Directory Tab, for the suffix dc=company, dc=com, you should see the two users you just added: manager and employee.
Double-click the manager role.
In the Edit Role page, click Members and then click Add.
In the Search Users and Groups dialog, click Search.
In the list of results, select Test User 1 and then click OK.
In the Edit Role page, click OK.
Double-click the employee role.
In the Edit Role page, click Members and then click Add.
In the Search Users and Groups dialog, click Search.
In the list of results, select Test User 2 and then click OK.
In the Edit Role page, click OK.
Log out of the Directory Server console.
In the Access Manager 1 console, on the Access Control tab, click the example.com link.
Click the Policies tab.
Under Policies, click the “Referral URL Policy for users realm” link.
This is the policy that was created when setting up the Web Policy Agent.
On the Edit Policy page, under Rules, click New.
On the page “Step 1 of 2: Select Service Type for the Rule,” select “URL Policy Agent (with resource name),” and then click Next.
On the page “Step 2 of 2: New Rule,” provide the following information, and then click Next:
URL Policy for ApplicationServer-1
http://ProtectedResource-1.example.com:1081/agentsample/*
Click Finish.
In the Access Manager 1 console, on the Access Control tab, click the users 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 page “Step 1 of 2: Select Service Type for the Rule,” click Next.
The default “URL Policy Agent (with resource name)” should be selected.
On the page “Step 2 of 2: New Rule,” provide the following information:
agentsample
In the list, select http://ProtectedResource-1.example.com:1081/agentsample/*
The following is automatically entered when you select the Parent Resource Name above:
http://ProtectedResource-1.example.com:1081/agentsample/*
Mark this check box, and verify that the Allow value is selected.
Mark this check box, and verify that the Allow value is selected.
Click Finish.
The rule agentsample is now added to the list of Rules.
Under Subjects, click New.
On the page “Step 1 of 2: Select Subject Type,” select Access Manager Identity Subject, then click Next.
On the page “ Step 2 of 2: New Subject — Access Manager Identity Subject,” provide the following information:
agentsampleRoles
Select role.
Click Search.
In the Available list, the select manager and employee roles, and then click Add.
The roles are now displayed in the Selected list.
Click Finish.
Click Create.
The new policy is included in the list of Policies.
Log in as a root user to Protected Resource 2.
# cd /opt/j2ee_agents/am_wl9_agent/agent_001/config |
Make a back up the AMAgent.propertiesfile.
In the AMAgent.properties file, set the following 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 |
Save the file.
Restart the Application Server 2.
Stop Application Server 2 .
# cd /usr/local/bea/user_projects/domains/ ProtectedResource-2/bin # ./stopManagedWebLogic.sh ApplicationsServer-2 t3://localhost:7001
Stop the administration server.
# ./stopWebLogic.sh
Start the administration server.
# nohup ./startWebLogic.sh & # tail -f nohup.out
Start Application Server 2.
# nohup ./startManagedWebLogic.sh ApplicationServer-1 http://ProtectedResource-1.example.com:7001 &
Use these steps to access the agent sample application, and then test policies against that sample application.
Go to the Sample Application URL:
http://protectedresource-1.example.com:1081/agentsample/index.html
The Sample Application welcome page is displayed.
Click J2EE Declarative Security > “Invoke the Protected Servlet”
The Policy Agent redirects to the Access Manager login page.
Log in to the Access Manager console using the following information:
testuser1
password
If you can successfully log in as testuser1, and the J2EE Policy Agent Sample Application page is displayed, then this part of the test succeeded and authentication is working as expected.
Click the “J2EE Declarative Security” link.
On the J2EE Declarative Security page, click the “Invoke the Protected Servlet link”.
If the Success Invocation message is displayed, then this 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 go back.
Click the “Invoke the Protected EJB via an Unprotected Servlet” link.
If the Failed Invocation message is displayed, then this part of the test succeeded, and the sample policy for the employee role has been enforced as expected.
Close the browser.
In a new browser session, go to the Sample Application URL:
http://protectedresource-1.example.com:1081/agentsample/index.html
The Sample Application welcome page is displayed.
Click the “J2EE Declarative Security” link.
On the J2EE Declarative Security page, click the “Invoke the Protected EJB via an Unprotected Servlet” link.
The Policy Agent redirects to the Access Manager login page.
Log in to the Access Manager console using the following information:
testuser1
password
If you can successfully log in as testuser1, and the J2EE Policy Agent Sample Application page is displayed, then this part of the test succeeded and authentication is working as expected.
Click the “J2EE Declarative Security” link to go back.
On the J2EE Declarative Security page, click the “Invoke the Protected EJB via an Uprotected Servlet” link.
The Successful Invocation message is displayed. The sample policy for the employee role has been enforced as expected.
In this section, you configure the policy agent to point to the SSL port for the Access Manager load balancer.
Use the following as your checklist for configuring Access Manager to communicate over SSL:
Import the root CA certificate into the Application Server keystore.
Configure the Policy Agents to access the Distributed Authentication UI server.
In this procedure, you import a Certificate Authority (CA) certificate. The certificate enables the Authentication UI server to trust the certificate from the Access Manager load balancer (Load Balancer 3), and to establish trust with the certificate chain that is formed from the CA to the certificate.
Go to the directory where the keystore ( the cacerts file) is located:
#cd /usr/local/bea/jdk150_04/jre/lib/security/ |
Make a backup of the cacerts file.
Copy the CA certificate that you obtained from your Certificate Authority into a temporary directory. Example:
/export/software/ca.cer |
Import the 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 imported successfully:
# /usr/local/bea/jdk150_04/bin/keytool -list -keystore /usr/local/bea/jdk150_04/jre/lib/security/cacerts -storepass changeit | grep openssl openssltestca, Oct 2, 2006, trustedCertEntry, |
As a root user, log into host ProtectedResource–1.
# cd /opt/j2ee_agents/am_wl9_agent/agent_001/config
Make a backup of the AMAgent.properties file.
In the AMAgent.properties, set the following properties:
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 the file.
Stop Application Server 1 .
# cd /usr/local/bea/user_projects/domains/ProtectedResource-1/bin # ./stopManagedWebLogic.sh ApplicationsServer-1 t3://localhost:7001
Stop the administration server.
# ./stopWebLogic.sh
Start the administration server.
# nohup ./startWebLogic.sh & # tail -f nohup.out
Start Application Server 1.
# nohup ./startManagedWebLogic.sh ApplicationServer-1 http://ProtectedResource-1.example.com:7001 &
Use these steps to access the agent sample application, and then test policies against that sample application.
Go to the Sample Application URL:
http://protectedresource-1.example.com:1081/agentsample/index.html
The Sample Application welcome page is displayed.
Click J2EE Declarative Security > “Invoke the Protected Servlet”
The Policy Agent redirects to the Access Manager login page.
Log in to the Access Manager console using the following information:
testuser1
password
If you can successfully log in as testuser1, and the J2EE Policy Agent Sample Application page is displayed, then this part of the test succeeded and authentication is working as expected.
Click the “J2EE Declarative Security” link.
On the J2EE Declarative Security page, click the “Invoke the Protected Servlet link”.
If the Success Invocation message is displayed, then this 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 go back.
Click the “Invoke the Protected EJB via an Unprotected Servlet” link.
If the Failed Invocation message is displayed, then this part of the test succeeded, and the sample policy for the employee role has been enforced as expected.
Close the browser.
In a new browser session, go to the Sample Application URL:
http://protectedresource-1.example.com:1081/agentsample/index.html
The Policy Agent redirects to the Access Manager login page.
Log in to the Access Manager console using the following information:
testuser2
password
The Failed Invocation message is displayed.
Click the “J2EE Declarative Security” link.
On the J2EE Declarative Security page, click the “Invoke the Protected EJB via an Unprotected Servlet” link.
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.
Click the “Invoke the Protected Servlet” link.
If the Access to Requested Resource Denied message is displayed, then this part of the test is successful. The sample policy for the manager role has been enforced as expected.
Log in as a root user to Protected Resource 1.
# cd /opt/j2ee_agents/am_wl9_agent/agent_001/config
Make a backup of the file AMAgent.properties.
In the AMAgent.properties file, set the following properties:
com.sun.identity.agents.config.login.url[0] = https://LoadBalancer-4.example.com:9443/distAuth/UI/Login?realm=users
Save the file.
Restart the Application Server.
Stop Application Server 1.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-1/bin # ./stopManagedWebLogic.sh ApplicationServer-1 t3://localhost:7001
Stop the administration server.
#cd /usr/local/bea/user_projects/domains/ProtectedResource-1/bin ./stopWebLogic.sh
Start the administration server.
# nohup ./startWebLogic.sh & # tail -f nohup.out
Watch for startup errors.
Start Application Server 1.
# nohup ./startManageWebLogic.sh ApplicatoinServer-1 http://ProtectedResource-1.example.com:7001 & tail -f nohup.out
Verify that the agents are configured properly.
Go to the sample application URL:
http://ProtectedResource-1.example.com:1081/agentsample/index.html
In the left navigation bar, click “Invoke the Protected Servlet.”
You are redirected to the Distributed Authentication UI server URL https://loadbalancer-4.example.com:9443/distAuth/UI/login. The Access Manager login page is displayed.
Double-click the gold lock in the lower left corner of the browser.
In the Properties page, you see certificate for LoadBalancer–4.example.com.
Log in to the Access Manager console using the following information:
testuser1
password
You are redirected to the protected servlet of the Sample Application, and a success message is displayed. This indicates that authentication through the Distributed Authentication UI server was successful.
Use the following as your checklist for installing Web Server 2 and Web Policy Agent 2:
Import the root CA certificate into the Web Server 2 key store.
Configure the Web Policy Agent to use the new agent profile.
As root, log in to host ProtectedResource-2.
Start the Java Enterprise System installer with the -nodisplay option.
# cd /mnt/Solaris_sparc # ./installer -nodisplay |
When prompted, provide the following information:
|
Press Enter. |
|
|
Press Enter. |
|
|
Enter y. |
|
|
Enter 8 for “English only.” |
|
|
Enter 3 to select Web Server. |
|
|
Press Enter. |
|
Enter 1 to upgrade these shared components and 2 to cancel [1] |
You are prompted to upgrade shared components only if the installer detects that an upgrade is required. Enter 1 to upgrade shared components. |
|
|
Accept the default value. |
|
|
Enter 1. |
|
|
Enter 1. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Enter admin. |
|
|
For this example, enter web4dmin. |
|
|
Enter the same password to confirm it. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
For this example, enter web4dmin. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Enter root. |
|
|
Enter root. |
|
|
Enter 1080. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
First, see the next numbered (Optional) step. When ready to install, enter 1. |
(Optional) During installation, you can monitor the log to watch for installation errors. Example:
# cd /var/sadm/install/logs # tail —f Java_Enterprise_System_install.B xxxxxx |
Upon successful installation, enter ! to exit.
Verify that the Web Server is installed properly.
Start the Web Server administration server to verify it starts with no errors.
# cd /opt/SUNWwbsvr/https-admserv
# ./stop; ./start
Run the netstat command to verify that the Web Server ports are open and listening.
# netstat -an | grep 8888 *.8888 *.* 0 0 49152 0 LISTEN |
Go to the Web Server URL.
http://ProtectedResource-2.example.com:8888
Log in to the Web Server using the following information:
admin
web4dmin
You should be able to see the Web Server console. You can log out of the console now.
Start the Protected Resource 2 instance.
#cd /opt/SUNWwbsvr/https-ProtectedResource-2.example.com # ./stop; ./start |
Run the netstat command to verify that the Web Server ports are open and listening.
# netstat -an | grep 1080 *.1080 *.* 0 0 49152 0 LISTEN |
Go to the instance URL.
http://ProtectedResource-2.example.com:1080
You should see the default Web Server index page.
The Java System Web Policy Agents 2.2 package must be downloaded to each Protected Resource that will host a Web Policy Agent. You can download the package from the following website: http://www.sun.com/download
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 http://docs.sun.com/app/docs/doc/819-2796/6n52flfoq?a=view#adtcd.
Log in as a root user to host ProtectedResource-2.
Download the Java System Web Policy Agents 2.2 package from the following website:
Unpack the downloaded package.
In this example, the package was downloaded into the directory /temp.
# cd /temp
# gunzip sun-one-policy-agent-2.2-es6-solaris_sparc.tar.gz
# tar —xvof sun-one-policy-agent-2.2-es6-solaris_sparc.tar
Start the Web Policy Agents installer.
# ./setup -nodisplay
When prompted, provide the following information:
|
Press Enter. |
||
|
Press Enter. |
||
|
Enter y. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Enter .
|
||
|
Enter 1080. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
For this example, enter the external-facing load balancer host name. Example: LoadBalancer-3.example.com |
||
|
Enter the load balancer HTTP port number. For this example, enter 90. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Enter the amldapuser password that was entered when Access Manager was installed. For this example, enter 4mld4puser . |
||
|
Enter the 4mld4puser password again to confirm it. |
||
|
Accept the default value. |
||
|
First, see the next (Optional) numbered step. When you are ready to start installation, press Enter. |
(Optional) During installation, you can monitor the log to watch for installation errors. Example:
# cd /var/sadm/install/logs # tail —f /var/sadm/install/logs/ Sun_Java_tm__System_Access_Manager_Policy_Agent_install.Bxxxxxx |
Modify the AMAgent.properties file.
# cd /etc/opt/SUNWam/agents/es6/ config/_opt_SUNWwbsvr_https-ProtectedResource-2.example.com |
Make a backup of AMAgent.properties before setting the following property:
com.sun.am.policy.am.login.url = https://LoadBalancer-4.example.com:9443/distAuth/UI/Login?realm=users
Restart the Web Server.
Watch for errors as the server starts up.
# cd /opt/SUNWwbsvr/https-ProtectedResource-2.example.com
# ./stop; ./start
Start a new browser and go to the Access Manager URL.
Example: https://loadbalancer-3.example.com:9443/amserver/console
Log in to Access Manager using the following information:
amadmin
4m4dmin1
Create a referral policy in the top-level realm.
On the Access Control tab, under Realms, click example.com.
Click the Policies tab.
On the Policies tab for example.com-Policies, click the “Referral URL Policy for users realm” link.
In the Edit Policy page, under Rules, click New.
In the Edit Rule page, provide the following information.
On the same page, in the Rules section, click New.
Select a Service Type.
On the page “Step 1 of 2: Select Service Type for the Rule,” select URL Policy Agent (with resource name)
Click Next.
On the page “Step 2 of 2: New Rule,” provide the following information:
URL Rule for ProtectedResource-2
http://ProtectedResource-2.example.com:1080/*
Click Finish.
On the Edit Policy page, click Save.
In the Policies tab for example.com — Policies, you should see the policy named Referral URL Policy for users realm.
Create a policy in the users realm.
Click Realms.
On the Access Control tab, under Realms, click the Realm Name users.
Click the Policies tab.
On the Policies tab for users-Policies, click New Policy.
In the New Policy page, provide the following information:
URL Policy for ProtectedResource-2
Verify that the checkbox is marked.
On the same page, in the Rules section, click New.
On the page “Step 1 of 2: Select Service Type for the Rule,” click Next.
The Service Type “URL Policy Agent (with resource name) is the only choice.
On the page “Step 2 of 2: New Rule,” provide the following information:
URL Rule for ProtectedResource-2
Click the URL listed in the Parent Resource Name list: http://ProtectedResource-2.example.com:1080/*
The URL is automatically added to the Resource Name field.
Mark this checkbox, and select the Allow value.
Mark this checkbox, and select the Allow value.
Click Finish.
On the Policy page, in the Subjects section, click New.
Select the subject type.
On the page “Step 1 of 2: Select Subject Type,” select the Access Manager Identity Subject type.
On the page “Step 2 of 2: New Subject — Access Manager Identity Subject,” provide the following information:
Test Subject
Choose User, and then click Search. Four users are added to the Available list.
In the list, select testuser1, and then click Add.
The user testuser1 is added to the Selected list.
Click Finish.
In the New Policy page, click Create.
On the Policies tab for users-Policies, the new policy “URL Policy for ProtectedResource-2” is now in the Policies list.
Verify that the new policy works with Web Policy Agent 2.
The Web Policy Agent on Protected Resource 1 connects to Access Manager servers through Load Balancer 3. The load balancer is SSL-enabled, so the agent must be able to trust the load balancer SSL certificate in order to establish the SSL connection. To do this, import the root CA certificate that issued the Load Balancer 3 SSL server certificate into the Web Policy Agent certificate store.
Obtain the root CA certificate, and copy it to ProtectedResource-2.
Copy the root CA certificate to Protected Resource 2.
Open a browser, and go to the Web Server 2 administration console.
http://ProtectedResource-2.example.com:8888
Log in to the Web Server 2 console using the following information:
admin
web4dmin
In the Select a Server field, select ProtectedResource-2.example.com, and then click Manage.
If a “Configuration files have not been loaded” message is displayed, it may be that the administration server has never been accessed, and so the configuration files have never been loaded. First click Apply, and then click Apply Changes. The configuration files are read, and the server is stopped and restarted.
Click the Security tab.
On the Initialize Trust Database page, enter a Database Password.
Enter the password again to confirm it, and then click OK.
In the left frame, click Install Certificate and provide the following information, and then click OK:
Choose Trusted Certificate Authority (CA)
password
OpenSSL_CA_Cert
/export/software/ca.cert
Click Add Server Certificate.
Click Manage Certificates.
The root CA Certificate name OpenSSL_CA_Cert is included in the list of certificates.
Click the Preferences tab.
Restart Web Server 2.
On the Server On/Off page, click Server Off. When the server indicates that the administration server is off, click Server On.
Configure the Web Policy Agent 2 to point to the Access Manager SSL port.
Edit the AMAgent.properties file.
# cd /opt/SUNWam/agents/es5/config/ _optSUNWwbsvr_https=ProtectedResource-2.example.com
Make a backup of the AMAgent.properties file before setting the following property:
# com.sun.am.naming.url = https://LoadBalancer-3.example.com:9443/amserver/namingservice
Save the file.
Restart Web Server 2.
# cd /opt/SUNWwbsvr/https-ProtectedResource-2.example.com # ./stop; ./start
This new account will be used by J2EE Policy Agent 2 to access the Access Manager server.
Create an agent profile on Access Manager.
Go to Access Manage load balancer URL:
https://LoadBalancer-3.example.com:9443/amserver/UI/Login
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
On the Access Control tab, under Realms, click the realm name example.com.
Click the Subjects tab.
Click the Agents tab.
On the Agent page, click New.
On the New Agent page, provide the following information:
webagent-2
web4gent2
web4gent2
Choose Active.
Click Create.
The new agent webagent–2 is now display in the list of Agent Users.
Log in to as a root user to Protected Resource 2.
Run the cypt_util utility.
The utility encrypts the password.
# cd /opt/SUNWam/agents/bin # ./crypt_util web4gent2 BXxzBswD+PZdMRDRMXQQA==
Copy the encrypted password, and save it in a text file.
Edit the AMAgent.properties file.
# cd /etc/opt/SUNWam/agents/es6/ config/_opt_SUNWwbsvr_https-ProtectedResource-2.example.com |
Make a backup of AMAgent.properties you make the following change in the file:
com.sun.am.policy.am.password = webagent-2 com.sun.am.policy.am.password = BXxzBswD+PZdMRDRMXQQA==
Use the encrypted password obtained in the previous step.
Save the file.
Restart Web Server 2.
# cd /opt/SUNWwbsvr/https-ProtectedResource-2.example.com # ./stop; ./start
Use the following as your checklist for installing Application Server 2 and the J2EE Policy Agent 2:
Download the BEA WebLogic Server installer onto Protected Resource 2.
Follow the instructions provided by BEA for obtaining and using the software.
Extract the installer files:
# /download_directory/export/weblogic/server910_solaris32.bin |
|
Enter Next. |
|
|
Enter 1. |
|
|
Press Enter to accept the default value and continue. |
|
|
Enter 2 to choose custom install. |
|
|
Enter Next. |
|
|
Press Enter to accept the default value and continue. |
|
|
Press Enter to confirm the default value and continue. |
|
|
Press Enter. |
Create a new domain.
Start the BEA WebLogic Configuration Wizard.
# cd /usr/local/bea/weblogic91/common/bin # ./config.sh |
Provide the following information:
|
Press Enter to accept the default value 1. |
|
|
Press Enter to accept the default value 1. |
|
|
Press Enter to accept the default value and continue. |
|
|
Enter 2 to modify the user password. |
|
|
Enter w3bl0g1c. |
|
|
Enter 3 to confirm user password. |
|
|
Enter w3bl0g1c. |
|
|
Press Enter to accept the values and continue. |
|
|
Enter 2 to select Production Mode. |
|
|
Press Enter to accept the default value and continue. |
|
|
Enter 1 . |
|
|
Press Enter to Continue. |
|
|
Enter ApplicationServer-2. |
|
|
Enter 3 to modify the Listen port. |
|
|
Enter 1081. |
|
|
Press Enter to continue. |
|
|
Press Enter to continue. |
|
|
Press Enter to continue. |
|
|
Enter ProtectedResource-2. |
|
|
Press Enter to accept these values. |
|
|
Enter ProtectedResource-2. |
|
|
Press Enter to accept these values. |
|
|
Enter 1 to add a Unix machine. |
|
|
Press Enter to continue. |
|
|
Press Enter to continue. |
|
|
Enter ProtectedResource-2. |
|
|
Press Enter to continue. |
|
|
Press Enter. |
Create two files necessary to automate Application Server 2 startup.
Create one file in the directory for the Application Server 2 administration server, and create one file in the Application Server 2 instance directory. The administrative user and password are stored in each file. Application Server 2 uses this information during server start-up. Without these files, Application Server 2 will fail to start. Application Server 2 encrypts the file, so there is no security risk even though you enter the user name and password in clear text.
# cd /usr/local/bea/user_projects/domains/ ProtectedResource-2/servers/AdminServer # cat > boot.properties username=weblogic password=w3bl0g1c ^D # cd /usr/local/bea/user_projects/domains/ ProtectedResource-2/servers/ApplicationServer-2/ # mkdir security # cd security/ # cat > boot.properties username=weblogic password=w3bl0g1c ^D |
Start the servers.
# cd /usr/local/bea/user_projects/ domains/ProtectedResource-2/bin/ # ./startWebLogic.sh & # # netstat -an | grep 7001 xxx.xx.72.151.7001 *.* 0 0 49152 0 LISTEN 127.0.0.1.7001 *.* 0 0 49152 0 LISTEN # # cd /usr/local/bea/user_projects/domains/ProtectedResource-2/bin/ # ./startManagedWebLogic.sh ApplicationServer-2 http://ProtectedResource-2.example.com:7001 & # # ./startManagedWebLogic.sh ApplicationServer-2 http://ProtectedResource-2.example.com:7001 # cd /usr/local/bea/user_projects/domains/ ProtectedResource-1/bin/ # netstat -an | grep 7001 xxx.xx.72.151.1081 *.* 0 0 49152 0 LISTEN 127.0.0.1.1081 *.* 0 0 49152 0 LISTEN xxx.xx.72.151.33425 xxx.xx.72.151.1081 49152 0 49152 0 ESTABLISHED xxx.xx.72.151.1081 xxx.xx.72.151.33425 49152 0 49152 0 ESTABLISHED |
Verify that Application Server 2 is up and running.
Go to the following URL:
http://ProtectedResource-2.example.com:7001/console
Log in to Application Server 2 using the following information:
weblogic
w3bl0g1c
Verify that you can successfully log into the console.
Under Domain Structure > ProtectedResource-2, expand the Environment object.
Click Servers.
On the Summary of Servers page, verify that both AdminServer(admin) and ApplicationServer-2 are running and OK.
This new account will be used by J2EE Policy Agent 2 to authenticate to the Access Manager server.
Go to Access Manage load balancer URL:
https://LoadBalancer-3.example.com:9443/amserver/UI/Login
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
On the Access Control tab, under Realms, click the realm name example.com.
Click the Subjects tab.
Click the Agents tab.
On the Agent page, click New.
On the New Agent page, provide the following information:
j2eeagent-2
j2ee4gent2
j2ee4gent2
Choose Active.
Click Create.
The new agent j2eeagent–2 is now display in the list of Agent Users.
Log out of the Access Manager console.
Create a text file, and add the Agent Profile password to the file.
The J2EE Policy Agent installer requires this file for installation.
# cd /opt/j2ee_agents/amwl9_agent # cat > agent_pwd j2ee4gent2 ^D
Application Server 2 must not be running when you install J2EE Policy Agent 2.
You must stop both the Application Server 2 instance and the administration server before installing J2EE Policy Agent 2.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-2/bin/ # ./stopManagedWebLogic.sh ApplicationServer-2 t3://localhost:7001 # cd /usr/local/bea/user_projects/domains/ProtectedResource-2/bin # ./stopWebLogic.sh |
Unpack the J2EE Policy Agent bits.
cd /opt # /usr/sfw/bin/gtar -xvf /export/software/SJS_Weblogic_9_agent_2.2.tar # gunzip ../SJS_Weblogic_9_agent_2.2.tar.gz # /usr/sfw/bin/gtar -xvf ../SJS_Weblogic_9_agent_2.2.tar |
Start the J2EE Policy Agent installer.
# cd /opt/j2ee_agents/am_wl9_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 90. |
||
|
Enter http. |
||
|
Accept the default value. |
||
|
ProtectedResource-2.example.com |
||
|
Enter /usr/loca/bea/weblogic91. |
||
|
Enter 1081. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Accept the default value. |
||
|
Enter j2eeagent-1. |
||
|
Enter
. |
||
|
Accept the default value. |
||
|
Accept the default value. |
Check the installation log to make sure there are no problems reported.
Use the following as your checklist for completing the J2EE Policy Agent 2 installation:
The J2EE Policy Agent installer creates a new file in the Application Server bin directory:
/usr/local/bea/user_projects/domains/ProtectedResource-2/ bin/setAgentEnv_ApplicationServer-2.sh |
Make a backup of setDomainEnv.sh.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-2/bin/
In setDomainEnv.sh, insert the following at the end of the file:
. /usr/local/bea/user_projects/domains/ProtectedResource-2/ bin/setAgentEnv_ApplicationServer-2.sh |
This command references the file the installer created in the Application Server bin directory.
Save the file.
Change permissions for the setAgentEnv_ApplicationServer-2.sh file:
# chmod 755 setAgentEnv_ApplicationServer-2.sh
Start the Application Server administration server.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-2/bin # nohup ./startWebLogic.sh & # tail -f nohup.out |
Watch for startup errors.
Go to the following Application Server URL:
http://ProtectedResource-2.example.com:7001/console
Log in to the Application Server console using the following information:
weblogic
w3bl0g1c
In the Application Server console, under Domain Structure, click Deployments.
On the Summary of Deployments page, click “Lock & Edit.”
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: /opt/j2ee_agents/am_wl9_agent/etc/
Select agentapp.war, and then click Next.
In the Install Application Assistant page, choose “Install this deployment as an application,” and then click Next.
In the list of Servers, mark the checkbox for ApplicationServer-2, and then click Next.
In the Optional Settings page, click Next.
On the Summary of Deployments page, click Finish.
In the Change Center, click Activate Changes.
On the “Settings for agentapp” page, under Domain Structure, click Deployments.
On the Summary of Deployments page, mark the agentapp checkbox, and then click Start > Servicing All Requests.
On the Start Deployments page, clickYes.
You may encounter a Javascript error. The agent application will not start until you start the Application Server.
In the console, on the Summary of Deployments page, under Domain Structure, click Security Realms.
On the Summary of Security Realms page, in the Change Center click “Lock & Edit.”
Click the Realm name myrealm link.
On the “Settings for myrealm” page, click the Providers tab.
On the Providers tab, under Authentication Providers, click New.
On the Create a New Authentication Provider page, provide the following information:
Agent-1
AgentAuthenticator
Click OK.
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 for OPTIONAL.
On the Settings for Agent-1 page, in the list of Authentication Providers, click DefaultAuthenticator.
On the Settings for DefaultAuthenticator page, set the Control Flag to OPTIONAL, and then click Save.
Return to the Providers page.
In the navigation tree near the top of the page, click Providers.
Click Activate Changes.
Make a backup of the following file:
/opt/j2ee_agents/am_wl9_agent/agent_001/config/AMAgent.properties
In the AMAgent.properties file, set the following property:
com.sun.identity.agents.config.bypass.principal[0] = weblogic
At end of the file, insert a new property.
com.sun.identity.session.resetLBCookie='true'
The default value for this property is false. You must add this property only if session failover has been configured for Access Manager. If session failover is not configured for Access Manager, and this property is added, it could impact performance negatively. If session failover is enabled for Access Manager, and this property is not added, then Access Manager sessions will still fail over, and the session failover functionality will work properly. However, the stickiness to the Access Manager server will not be maintained after failover occurs. Session stickiness to the Access Manager server helps performance. This property must be added to the AMConfig.properties file on the Access Manager servers, as well as to the AMAgent.properties for the J2EE Policy Agent servers. This property is not required for the Web Policy Agent servers. The Access Manager 7 2005Q4 Patch 3 in Sun Java System Access Manager 7 2005Q4 Release Notes Release Notes also references this property. See the sectionCR# 6440651: Cookie replay requires com.sun.identity.session.resetLBCookie property in Sun Java System Access Manager 7 2005Q4 Release Notes.
Save the file.
Use the following as your checklist for setting up a test for the J2EE Policy Agent 2:
Deploy the sample application on Application Server 1.
Go to the Application Server 1 URL:
http://ProtectedResource-1.example.com:7001/console
Log in to the Application Server using the following information:
weblogic
w3bl0g1c
In the Application Server console, 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-2.example.com, click the root directory.
Navigate to the application directory: /opt/j2ee_agents/am_wl9_agent/sampleapp/dist
Select agentsample.ear, and then click Next.
In the Install Application Assistant page, choose “Install this deployment as an application,” and then click Next.
In the list of Servers, mark the checkbox for ApplicationServer-1, and then 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.
In the “Settings for agentsample” page, click Activate Changes.
Under Domain Structure, click Deployments.
In the Deployments list, mark the checkbox for agentsample, and then click Start > Servicing All Requests.
On the Start Deployments page, click Yes.
The state of the deployment changes from Prepared to Active.
Log out of the Application Server 1 console.
Go to the following Protected Resource 1 directory:
/usr/local/bea/user_projects/domains/ProtectedResource-1/bin
Stop Application Server 1.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-1/bin # ./stopManagedWebLogic.sh ApplicationServer-1 t3://localhost:7001
Stop the administration server.
#cd /usr/local/bea/user_projects/domains/ProtectedResource-1/bin ./stopWebLogic.sh
Start the administration server.
# nohup ./startWebLogic.sh & # tail -f nohup.out
Watch for startup errors.
Start Application Server 1.
# nohup ./startManageWebLogic.sh ApplicatoinServer-2 http://ProtectedResource-1.example.com:7001 & tail -f nohup.out
Run the netstat command to verify that Application Server 1 is up and listening.
# netstat -an | grep 1081 xxx.xx.72.151.1081 *.* 0 0 49152 0 LISTEN 127.0.0.01.1081 *.* 0 0 49152 0 LISTEN
In the Access Manager 1 console, on the Access Control tab, click the example.com link.
Click the Policies tab.
Under Policies, click the “Referral URL Policy for users realm” link.
This is the policy that was created when setting up the Web Policy Agent.
On the Edit Policy page, under Rules, click New.
On the page “Step 1 of 2: Select Service Type for the Rule,” select “URL Policy Agent (with resource name),” and then click Next.
On the page “Step 2 of 2: New Rule,” provide the following information, and then click Next:
URL Policy for ApplicationServer-2
http://ProtectedResource-2.example.com:1081/agentsample/*
Click Finish.
In the Access Manager 1 console, on the Access Control tab, click the users 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 page “Step 1 of 2: Select Service Type for the Rule,” click Next.
The default “URL Policy Agent (with resource name)” should be selected.
On the page “Step 2 of 2: New Rule,” provide the following information:
agentsample
Choose http://ProtectedResource-2.example.com:1081/agentsample/*
The following is automatically entered when you select the Parent Resource Name above:
http://ProtectedResource-2.example.com:1081/agentsample/*
Mark this check box, and verify that the Allow value is selected.
Mark this check box, and verify that the Allow value is selected.
Click Finish.
The rule agentsample is now added to the list of Rules.
Under Subjects, click New.
On the page “Step 1 of 2: Select Subject Type,” select Access Manager Identity Subject, then click Next.
On the page “ Step 2 of 2: New Subject — Access Manager Identity Subject,” provide the following information:
agentsampleRoles
Select role.
Click Search.
In the Available list, the select manager and employee roles, and then click Add.
The roles are now displayed in the Selected list.
Click Finish.
Click Create.
The new policy is included in the list of Policies.
Log in as a root user to Protected Resource 2.
# cd /opt/j2ee_agents/am_wl9_agent/agent_001/config |
Make a back up the AMAgent.properties file.
Set the following 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 |
Save the file.
Restart the Application Server 2.
Stop Application Server 2 .
# cd /usr/local/bea/user_projects/domains/ ProtectedResource-2/bin # ./stopManagedWebLogic.sh ApplicationsServer-2 t3://localhost:7001
Stop the administration server.
# ./stopWebLogic.sh
Start the administration server.
# nohup ./startWebLogic.sh & # tail -f nohup.out
Start Application Server 2.
# nohup ./startManagedWebLogic.sh ApplicationServer-2 http://ProtectedResource-2.example.com:7001 &
Go to the Sample Application URL:
http://protectedresource-2.example.com:1081/agentsample/index.html
The Sample Application welcome page is displayed.
Click J2EE Declarative Security > “Invoke the Protected Servlet”
The Policy Agent redirects to the Access Manager login page.
Log in to the Access Manager console using the following information:
testuser1
password
If you can successfully log in as testuser1, and the J2EE Policy Agent Sample Application page is displayed, then this part of the test succeeded and authentication is working as expected.
Click the “J2EE Declarative Security” link.
On the J2EE Declarative Security page, click the “Invoke the Protected Servlet link”.
If the Success Invocation message is displayed, then this 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 go back.
Click the “Invoke the Protected EJB via an Unprotected Servlet” link.
If the Failed Invocation message is displayed, then this part of the test succeeded, and the sample policy for the employee role has been enforced as expected.
Close the browser.
In a new browser session, go to the Sample Application URL:
http://protectedresource-2.example.com:1081/agentsample/index.html
The Sample Application welcome page is displayed.
Click the “J2EE Declarative Security” link.
On the J2EE Declarative Security page, click the “Invoke the Protected EJB via an Unprotected Servlet” link.
The Policy Agent redirects to the Access Manager login page.
Log in to the Access Manager console using the following information:
testuser2
password
If you can successfully log in as testuser2, and the J2EE Policy Agent Sample Application page is displayed, then this part of the test succeeded and authentication is working as expected.
Click the “J2EE Declarative Security” link to go back.
On the J2EE Declarative Security page, click the “Invoke the Protected EJB via an Uprotected Servlet” link.
The Successful Invocation message is displayed. The sample policy for the employee role has been enforced as expected.
Use the following as your checklist for configuring Access Manager to communicate over SSL:
Import a root CA certificate into the Application Server 2 key store.
Configure the J2EE Policy Agents to access the Distributed Authentication UI server.
Log in as a root user to Protected Resource 2.
# cd /opt/j2ee_agents/am_wl9_agent/agent_001/config
Make a backup of the AMAgent.properties file.
In the AMAgent.properties, set the following properties:
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 the AMAgent.properties file.
Log in as a root user to Protected Resource 2 and go to the following directory:
/usr/local/bea/jdk150_04/jre/lib/security/
Make a backup of cacerts.
Import the 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 the certificate was added to the key store.
# /usr/local/bea/jdk150_04/bin/keytool -list -keystore /usr/local/bea/jdk150_04/jre/lib/security/cacerts -storepass changeit | grep i openssl openssltestca, Oct 2, 2006, trustedCertEntry,
Stop Application Server 2 .
# cd /usr/local/bea/user_projects/domains/ProtectedResource-2/bin # ./stopManagedWebLogic.sh ApplicationServer-2 t3://localhost:7001
Stop the administration server.
# ./stopWebLogic.sh
Start the administration server.
# nohup ./startWebLogic.sh & # tail -f nohup.out
Start Application Server 2.
# nohup ./startManagedWebLogic.sh ApplicationServer-2 http://ProtectedResource-2.example.com:7001 &
Go to the Sample Application URL:
http://protectedresource-2.example.com:1081/agentsample/index.html
The Sample Application welcome page is displayed.
Click J2EE Declarative Security > “Invoke the Protected Servlet”
The Policy Agent redirects to the Access Manager login page.
Log in to the Access Manager console using the following information:
testuser1
password
If you can successfully log in as testuser1, and the J2EE Policy Agent Sample Application page is displayed, then this part of the test succeeded and authentication is working as expected.
Click the “J2EE Declarative Security” link.
On the J2EE Declarative Security page, click the “Invoke the Protected Servlet link”.
If the Success Invocation message is displayed, then this 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 go back.
Click the “Invoke the Protected EJB via an Unprotected Servlet” link.
If the Failed Invocation message is displayed, then this part of the test succeeded, and the sample policy for the employee role has been enforced as expected.
Close the browser.
In a new browser session, go to the Sample Application URL:
http://protectedresource-2.example.com:1081/agentsample/index.html
The Policy Agent redirects to the Access Manager login page.
Log in to the Access Manager console using the following information:
testuser2
password
The Failed Invocation message is displayed.
Click the “J2EE Declarative Security” link.
On the J2EE Declarative Security page, click the “Invoke the Protected EJB via an Unprotected Servlet” link.
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.
Click the “Invoke the Protected Servlet” link.
If the Access to Requested Resource Denied message is displayed, then this part of the test is successful. The sample policy for the manager role has been enforced as expected.
Log in as a root user to Protected Resource 2.
# cd /opt/j2ee_agents/am_wl9_agent/agent_001/config
Make a backup of the file AMAgent.properties.
In the AMAgent.properties file, set the following properties:
com.sun.identity.agents.config.login.url[0] = https://LoadBalancer-4.example.com:9443/distAuth/UI/Login?realm=users |
Save the file.
Restart the Application Server.
Stop Application Server 2.
# cd /usr/local/bea/user_projects/domains/ProtectedResource-2/bin # ./stopManagedWebLogic.sh ApplicationServer-2 t3://localhost:7001
Stop the administration server.
#cd /usr/local/bea/user_projects/domains/ProtectedResource-2/bin ./stopWebLogic.sh
Start the administration server.
# nohup ./startWebLogic.sh & # tail -f nohup.out
Watch for startup errors.
Start Application Server 2.
# nohup ./startManageWebLogic.sh ApplicatoinServer-2 http://ProtectedResource-2.example.com:7001 & tail -f nohup.out
Verify that the agents are configured properly.
Go to the sample application URL:
http://ProtectedResource-2.example.com:1081/agentsample/index.html
In the left navigation bar, click “Invoke the Protected Servlet.”
You are redirected to the Distributed Authentication UI server URL https://loadbalancer-4.example.com:9443/distAuth/UI/login. The Access Manager login page is displayed.
Double-click the gold lock in the lower left corner of the browser.
In the Properties page, you see certificate for LoadBalancer–4.example.com.
Log in to the Access Manager console using the following information:
testuser1
password
You are redirected to the protected servlet of the Sample Application, and a success message is displayed. This indicates that authentication through the Distributed Authentication UI server was successful.
This chapter contains detailed instructions for the following tasks:
Load Balancer 5 can be located in a less-secured zone, and handles traffic for the Web Policy Agents.
Load Balancer 5 is configured for simple persistence so that browser requests from the same IP address will always be directed to the same Web Policy Agent instance . This guarantees that the requests from the same user session will always be sent to the same Web Policy Agent instance. This is important from the performance perspective. Each Web Policy Agent must validate the user session and evaluate applicable policies. The results are subsequently cached on the individual Web Policy Agent to improve the performance. If no load balancer persistence is set, and the same user's requests are spread across two agents, then each agent must build up its own cache. To do so, both agents must validate the session and evaluate policies. This effectively doubles the workload on the Access Manager servers, and cuts the overall system capacity by half. The problem becomes even more acute as the number of Web Policy Agents increases further.
As a general rule, 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 Web Policy Agent instance.
Use the following as your checklist for configuring the Web Policy Agents load balancer:
Go to URL for the Big IP load balancer. login page and log in.
https://ls-f5.example.com
Log in using the following information:
username
password
Create a Pool.
A pool contains all the backend server instances.
Open the Configuration Utility.
Click “Configure your BIG-IP (R) using the Configuration Utility.”
In the left pane, click Pools.
On the Pools tab, click the Add button.
In the Add Pool dialog, provide the following information:
Example: WebAgent-Pool
Round Robin
Add all the Web Policy Agent IP addresses. In this example, add the IP address and port number for ProtectedResource-1:1080 and for ProtectedResource-2:1080.
Click the Done button.
Configure the load balancer for simple persistence.
Add a Virtual Server.
If you encounter Javascript errors or otherwise cannot proceed to create a virtual server, try using Microsoft Internet Explorer for this step.
In the left frame, Click Virtual Servers.
On the Virtual Servers tab, click the Add button.
In the Add a Virtual Server dialog box, provide the following information:
xxx.xx.69.14 (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 Pool (WebAgent-Pool) that you have just created.
Click the Done button.
Add Monitors.
Click the Monitors tab, and then click the Add button.
In the Add Monitor dialog provide the following information:
WebAgent-http
Choose http.
Click Next.
In the Configure Basic Properties page, click Next.
In the Configure ECV HTTP Monitor, in the Send String field, enter the following:
GET / launch.html
Click Next.
In the Destination Address and Service (Alias) page, click Done.
On the Monitors tab, the monitor you just added is now contained in the list of monitors.
Click the Basic Associations tab.
Look for the IP addresses for ProtectedResource-1:1080 and ProtectedResourece-2:1080.
Mark the Add checkbox for ProtectedResource-1 and ProtectedResource-2.
At the top of the Node column, choose the monitor that you just added, WebAgent-http.
Click Apply.
In this procedure you modify the AMAgent.properties file. Map Protected Resource 1 and Protected Resource 2 to Load Balancer 5.
Log in as a root user to Protected Resource 1.
# cd /etc/opt/SUNWam/agents/es6/ config/_opt_SUNWwbsvr_https-ProtectedResource-1.example.com |
Use a text editor to modify the AMAgent.properties file.
Make a backup of AMAgent.properties, and then add the following entry:
com.sun.am.policy.agents.config.fqdn.map = LoadBalancer-5.example.com|LoadBalancer-5.example.com |
For this property:
com.sun.am.policy.agents.config.notenforced_list
append the following to the end of the value string :
http://ProtectedResource-1.example.com:1080/launch.html http://LoadBalancer-5.example.com:90/launch.html
Save the file.
Log in as a root user to Protected Resource 2.
# cd /etc/opt/SUNWam/agents/es6/ config/_opt_SUNWwbsvr_https-ProtectedResource-2.example.com |
Use a text editor to modify the AMAgent.properties file.
Make a backup of AMAgent.properties, and then add the following entry:
com.sun.am.policy.agents.config.fqdn.map = LoadBalancer-5.example.com|LoadBalancer-5.example.com |
For this property:
com.sun.am.policy.agents.config.notenforced_list
append the following to the end of the value string :
http://ProtectedResource-2.example.com:1080/launch.html http://LoadBalancer-5.example.com:90/launch.html
Save the file.
The policies you create here are used in a the subsequent verification procedure.
Create a referral policy for Load Balancer 5.
Go to the Access Manager URL:
https://loadbalancer-3.example.com:9443/amserver/UI/Login
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
On the Access Control tab, click the realm name example.com.
Click the Policies tab.
Click the “Referral URL Policy for users realm” link.
In the Edit Policy page, under Rules, click New.
In the page “Step 1 of 2: Select Service Type for the Rule,” select “URL Policy Agent (with resource name), and then click Next.
In the page “Step 2 of 2: New Rule,” provide the following information:
URL Rule for LoadBalancer-5
http://LoadBalancer-5.example.com:90/*
Click Finish, and then click Save.
The new rules you added are now contained in the Rules list.
Create a policy in the users realm.
In the Edit Policy page, click the Realms link.
On the Access Control tab, click the users link.
Click the Policies tab, and then click New Policy.
In the Name field, enter URL Policy for LoadBalancer-5.
Under Rules, click NEW.
In the page “Step 1 of 2: Select Service Type for the Rule,” click Next.
In the page “Step 2 of 2: New Rule,” provide the following information:
Enter LoadBalancer-5.
Click http://LoadBalancer-5.example.com:90/* to select it.
The Parent Resource Name you selected is now contained in the Resource Name field.
Mark the checkbox, and verify that the Allow option is selected.
Mark the checkbox, and verify that the Allow option is selected.
Click Finish.
In the New Policy page, in the Subjects section, click New.
In the “Step 1 of 2: Select Subject Type” page, be sure that Access Manager Identity Subject is selected, and then click Next.
In the “Step 2 of 2: New Subject — Access Manager Identity Subject” page, provide the following information:
LoadBalancer-5_Roles
In the drop-down list, select Role. Then click Search. The search returns a list of available roles.
In the Available: list, select manager and employee, and then click Add.
The roles manager and employee are now contained in the Selected List.
Click Finish.
On the Policy page, click Create.
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 Web Server 1 on Protected Resource 1.
#cd /opt/SUNWwbsvr/https-ProtectedResource-1.example.com # ./stop; ./start |
Restart Web Server 2 on Protected Resource 2.
#cd /opt/SUNWwbsvr/https-ProtectedResource-2.example.com # ./stop; ./start |
In a browser, go to the following URL:
http://loadbalancer-5.example.com:90/index.html
The load balancer redirects the request to the Access Manager login page.
Log in to the Access Manager console using the following information:
testuser1
password
If the default Web Server index.html page is displayed, then the load balancer is configured properly.
Verify that Load Balancer 5 monitors are monitoring the Web Servers properly.
Log in as a root user to Protected Resource 1.
Run the tail command.
# cd /opt/SUNWwbsvr/https-ProtectedResource-1.example.com/logs # tail -f access |
If you see frequent entries similar to this one:
xxx.xx.69.18 - - [06/Oct/2006:13:53:07 -0700] "GET /launch.html" 200 8526 |
then the custom monitor is configured properly. If you do not see "GET /launch.html", then you must troubleshoot the load balancer configuration.
Log in as root to Protected Resource 2.
Run the tail command.
# cd /opt/SUNWwbsvr/https-ProtectedResource-1.example.com/logs # tail -f access |
If you see frequent entries similar to this one:
xxx.xx.69.18 - - [06/Oct/2006:13:53:07 -0700] "GET /launch.html" 200 8526 |
then the custom monitor is configured properly. If you do not see "GET /launch.html", then you must troubleshoot the load balancer configuration.
Load Balancer 6 can be located in a less-secured zone, and handles traffic for the J2EE Policy Agents.
Load Balancer 6 is configured for simple persistence so that browser requests from the same IP address will always be directed to the same J2EE Policy Agent instance . This guarantees that the requests from the same user session will always be sent to the same J2EE Policy Agent instance. This is important from the performance perspective. Each J2EE Policy Agent must validate the user session and evaluate applicable policies. The results are subsequently cached on the individual Web Policy Agent to improve the performance. If no load balancer persistence is set, and the same user's requests are spread across two agents, then each agent must build up its own cache. To do so, both agents must validate the session and evaluate policies. This effectively doubles the workload on the Access Manager servers, and cuts the overall system capacity by half. The problem becomes even more acute as the number of J2EE Policy Agents increases further.
As a general rule, 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 J2EE Policy Agent instance.
Use the following as your checklist for configuring the J2EE Policy Agents load balancer:
Go to URL for the Big IP load balancer login page and log in.
https://ls-f5.example.com
username
password
Create a Pool.
A pool contains all the backend server instances.
Open the Configuration Utility.
Click “Configure your BIG-IP (R) using the Configuration Utility.”
In the left pane, click Pools.
On the Pools tab, click the Add button.
In the Add Pool dialog, provide the following information:
Example: J2EEAgent-Pool
Round Robin
Add all the Application Server IP addresses. In this example, add the IP address and port number for ProtectedResource-1:1081 and for ProtectedResource-2:1081.
Click the Done button.
In the List of Pools, click the name of the pool you just created (J2EEAgent-Pool).
Click the Persistence tab, provide the following information, and then click Apply:
Choose “Active Http Cookie.”
Choose Insert.
Add a Virtual Server.
If you encounter Javascript errors or otherwise cannot proceed to create a virtual server, try using Microsoft Internet Explorer for this step.
In the left frame, Click Virtual Servers.
On the Virtual Servers tab, click the Add button.
In the Add a Virtual Server dialog box, provide the following information:
xxx.xx.69.14 (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 Pool (J2EEAgent-Pool) that you have just created.
Click the Done button.
Add Monitors.
In the AMAgent.properties file, map Protected Resource 1 and Protected Resource 2 to Load Balancer 6 .
Log in as root to Protected Resource 1.
Use a text editor to modify the AMAgent.properties file.
# cd /opt/j2ee_agents/am_wl9_agent/agent_001/config
Make a backup of AMAgent.properties, and then set the following property:
com.sun.identity.agents.config.fqdn.mapping[LoadBalancer-6.example.com] = LoadBalancer-6.example.com
Save the file.
Log in as root to Protected Resource 2.
Use a text editor to modify the AMAgent.properties file.
# cd /opt/j2ee_agents/am_wl9_agent/agent_001/config
Make a backup of AMAgent.properties, and then set the following property:
com.sun.identity.agents.config.fqdn.mapping[LoadBalancer-6.example.com] = LoadBalancer-6.example.com
Save the file.
The policies you create here are used in a subsequent procedure that verifies that the agents and load balancer work properly.
Create a referral policy for Load Balancer 6.
Go to the Access Manager URL:
https://loadbalancer-3.example.com:9443/amserver/UI/Login
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
On the Access Control tab, click the realm name example.com.
Click the Policies tab.
Click the “Referral URL Policy for users realm” link.
In the Edit Policy page, under Rules, click New.
In the page “Step 1 of 2: Select Service Type for the Rule,” select “URL Policy Agent (with resource name), and then click Next.
In the page “Step 2 of 2: New Rule,” provide the following information:
URL Rule for LoadBalancer-6
http://LoadBalancer-6.example.com:91/*
Click Finish, and then click Save.
The new rules you added are now contained in the rules list.
Create a policy for the users realm.
In the Edit Policy page, click the Realms link.
On the Access Control tab, click the users link.
Click the Policies tab, and then click New Policy.
In the Name field, enter URL Policy for LoadBalancer-6 .
Under Rules, click NEW.
In the page “Step 1 of 2: Select Service Type for the Rule,” click Next.
In the page “Step 2 of 2: New Rule,” provide the following information:
Enter LoadBalancer-6.
Click http://LoadBalancer-6.example.com:91/* to select it.
The Parent Resource Name selected is not contained in the Resource Name field.
Mark the checkbox, and verify that the Allow option is selected.
Mark the checkbox, and verify that the Allow option is selected.
Click Finish.
In the “Step 1 of 2: Select Subject Type” page, be sure that Access Manager Identity Subject is selected, and then click Next.
In the “Step 2 of 2: New Subject — Access Manager Identity Subject” page, provide the following information:
LoadBalancer-6_Roles
In the drop-down list, select Role. Then click Search. The search returns a list of available roles.
In the Available: list, select manager and employee, and then click Add.
The roles manager and employee are now contained in the Selected List.
Click Finish.
Log out of the Access Manager console and close the browser.
Restart the Application Servers.
Stop Application Server 1 .
# cd /usr/local/bea/user_projects/ domains/ProtectedResource-1/bin # ./stopManagedWebLogic.sh ApplicationsServer-1 t3://localhost:7001
Stop the administration server.
# ./stopWebLogic.sh
Start the administration server.
# nohup ./startWebLogic.sh & # tail -f nohup.out
Start Application Server 1.
# nohup ./startManagedWebLogic.sh ApplicationServer-1 http://ProtectedResource-1.example.com:7001 &
Stop Application Server 2 .
# cd /usr/local/bea/user_projects/domains/ ProtectedResource-2/bin # ./stopManagedWebLogic.sh ApplicationsServer-2 t3://localhost:7001
Stop the administration server.
# ./stopWebLogic.sh
Start the administration server.
# nohup ./startWebLogic.sh & # tail -f nohup.out
Start Application Server 2.
# nohup ./startManagedWebLogic.sh ApplicationServer-2 http://ProtectedResource-2.example.com:7001 &
Go to the Sample Application URL:
http://loadbalancer-6.example.com:91/agentsample/index.html
The Sample Application welcome page is displayed.
Click J2EE Declarative Security > “Invoke the Protected Servlet”
The Policy Agent redirects to the Access Manager login page.
Log in to the Access Manager console using the following information:
testuser1
password
If you can successfully log in as testuser1, and the J2EE Policy Agent Sample Application page is displayed, then this part of the test succeeded and authentication is working as expected.
Click the “J2EE Declarative Security” link.
On the J2EE Declarative Security page, click the “Invoke the Protected Servlet link”.
If the Success Invocation message is displayed, then this 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 go back.
Click the “Invoke the Protected EJB via an Unprotected Servlet” link.
If the Failed Invocation message is displayed, then this part of the test succeeded, and the sample policy for the employee role has been enforced as expected.
Close the browser.
In a new browser session, go to the Sample Application URL:
http://loadbalancer-6.example.com:91/agentsample/index.html
The Sample Application welcome page is displayed.
Click the “J2EE Declarative Security” link.
On the J2EE Declarative Security page, click the “Invoke the Protected EJB via an Unprotected Servlet” link.
The Policy Agent redirects to the Access Manager login page.
Log in to the Access Manager console using the following information:
testuser2
password
If you can successfully log in as testuser2, and the J2EE Policy Agent Sample Application page is displayed, then this part of the test succeeded and authentication is working as expected.
Click the “J2EE Declarative Security” link to go back.
On the J2EE Declarative Security page, click the “Invoke the Protected EJB via an Uprotected Servlet” link.
The Successful Invocation message is displayed. The sample policy for the employee role has been enforced as expected.
This chapter contains detailed instructions for the following tasks:
When session failover is implemented for Access Manager, session information is replicated in two backend session store databases. This ensures that when 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, when one Access Manager fails, if the user's session was created in the failed Access Manager server, the next time the user performs an operation that requires a session token, the user will have to use a login page to re-authenticate.
Use the following as your checklist for installing the Message Queue instances:
Access Manager provides a web container-independent session failover feature that uses Sun Java System Message Queue (Message Queue). Message Queue is a messaging middleware product that enables distributed applications to communicate and exchange data by sending and receiving messages. In this Deployment Example, Access Managers uses Message Queue as a communications broker, and uses the Berkeley DB by Sleepycat Software, Inc. for the backend session store databases.
For detailed information about how Access Manager and Message Queue interact, see Implementing Access Manager Session Failover in Sun Java System Access Manager 7 2005Q4 Deployment Planning Guide in the Access Manager Deployment Planning Guide.
The Java ES installer must be mounted on the host computer system where you will install Message Queue. See the section “To Download and Unpack the Java Enterprise System 2005Q4 Installer”3.2 Downloading and Mounting the Java Enterprise System 2005Q4 Installer in this document.
Log in as a root user to the host MessageQueue–1.
Start the installer with -nodisplay option. Example:
# cd /mnt/Solaris_sparc # ./installer -nodisplay
When prompted, provide the following information:
|
Press Enter. |
|
|
Press Enter. |
|
|
Enter 8 for English. |
|
|
Press Enter. |
|
|
Enter 12 for Message Queue. |
|
|
Press Enter. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Enter 1 for Configure Now. |
|
|
First, see the following (Optional) Step 4. When you're ready to install, press Enter to accept the default value. |
|
|
Enter ! when you're ready to exit the installer program. |
(Optional) Monitor the log files and watch for installation errors.
# cd /var/sadm/install/logs # tail -f Java_Enterprise_System_install.B10110830 |
Log in as a root user to the host MessageQueue–2.
Start the installer with -nodisplay option. Example:
# cd /mnt/Solaris_sparc # ./installer -nodisplay
When prompted, provide the following information:
|
Press Enter. |
|
|
Press Enter. |
|
|
Enter 8 for English. |
|
|
Press Enter. |
|
|
Enter 12 for Message Queue. |
|
|
Press Enter. |
|
|
Accept the default value. |
|
|
Accept the default value. |
|
|
Enter 1 for Configure Now. |
|
|
First, see the following (Optional) Step 4. When you're ready to install, press Enter to accept the default value. |
|
|
Enter ! when you're ready to exit the installer program. |
(Optional) Monitor the log files and watch for installation errors.
# cd /var/sadm/install/logs # tail -f Java_Enterprise_System_install.B10110830 |
The Java ES installer and amconfig script adds the Access Manager packages or RPMs required for the Berkeley DB client. However, if you want to install the Berkeley DB client on a server where you have not installed Access Manager, you must manually add the following packages or RPMs, depending on your operating system. In this deployment example, for the Solaris OS, you add the following packages using the pkgadd command: SUNWbdb, SUNWbdbj, and SUNWamsfodb. In this deployment example, it is not necessary to run the amsfoconfig utility.
Use the following as your checklist for installing the Access Manager session failover components:
Install Access Manager session failover components on Message Queue 1.
Install Access Manager session failover components on Message Queue 2.
As root, log in to the host MessageQueue-1.
Use the pkgadd command to install the Access Manager session failover component packages.
Add a new user and password.
These are the user and password you will use connect to the Message Queue broker on servers where Message Queue is installed. Using this new user ensures that the guest user will not be able to access the other Access Manager server.
Create a new instance named msgqbroker by running the following command:
/bin/imqbrokerd -name msgqbroker -port 7777 &
Run the netstat command 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.
For this deployment example, create a specific user who will be used only for session failover purposes. This new user 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.
# /bin/imqusermgr add -u msgquser -g admin -p m5gqu5er -i msgqbroker
Update the guest user.
This step effectively disables the guest user.
# /bin/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.
Edit the /opt/SUNWam/lib/amsfo.conf file.
Make a backup of the amsfo.conf file, and then set the following properties:
CLUSTER_LIST=MessageQueue-1.example.com:7777,MessageQueue-2.example.com:7777 BROKER_INSTANCE_NAME=msgqbroker USER_NAME=msgquser lbServerPort=9443 lbServerProtocol=https lbServerHost=LoadBalancer-3.example.com SiteID=11
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.
# cd /opt/SUNWam/bin
# ./amsfopassword -e m5gqu5er -f /opt/SUNWam/.password
To view the encrypted password:
# more /opt/SUNWam/.password
M27OGb6U4ufRu+oWAzBdWw==
Edit the /opt/SUNWam/bin/amsessiondb script.
Make a backup of the /opt/SUNWam/bin/amsessiondb script before making any changes to the script.
The amsessiondb script is called by the amsfo script to start the Berkeley DB client (amsessiondb ), create the database, and set specific database values. The script contains variables that specify various default paths and directories:
JAVA_HOME=/usr/jdk/entsys-j2se/ IMQ_JAR_PATH=/usr/share/lib JMS_JAR_PATH=/usr/share/lib BDB_JAR_PATH=/usr/share BDB_SO_PATH=/usr/lib AM_HOME=/opt/SUNWam |
If any of these components are not installed in their default directories, edit the amsessiondb script and set the variables, as needed, to the correct locations.
Edit the /opt/SUNWam/bin/amsfoscript.
Make a backup of the /opt/SUNWam/bin/amsfo script before making any changes to the script. In the following line, add the the parameter —name $BROKER_INSTANCE_NAME as follows:
$JMQEXECUTABLE -bgnd $BROKER_OPTIONS -vmargs $BROKER_VM_ARGS -name $BROKER_INSTANCE_NAME -port $BROKER_PORT -cluster $CLUSTER_LIST & -jmqpid=$! echo $_jmqpid > $JMQ_PID_FILE |
Restart the Access Manager session failover components.
Stop the Message Queue broker instance.
# cd /opt/SUNWam/bin # ./amsfo stop |
Run the netstat command to verify that the Message Queue broker instance is stopped.
# netstat -an | grep 7777 |
If netstat returns no result, then the Message Queue broker instance is stopped.
If the Message Queue broker instance is not stopped, run the following commands:
# cd /tmp/amsession/logs # cat *.pid |
Process IDs are displayed. Example:
4940 4924 |
Kill these Java processes. Example:
# kill -9 4940 4924 |
If you don't see the process-ids in that file, and the netstat is still listening on port 7777, then it's possible that the amsfo script did not stop properly. In this case, run the following command to identify the java processes:
# ps -ef | grep java |
Then kill those identified processes as shown in the kill command example above.
Then check with netstat again. The port socket should be relinquished before you start up amsfo again. Otherwise, session failover problems may occur.
Restart the Message Queue broker instance.
# ./amsfo 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
As root, log in to the host MessageQueue-2.
Use the pkgadd command to install the Access Manager session failover component packages.
Add a new user and password.
This is the user and password you will use connect to the Message Queue broker on servers where Message Queue is installed. Using this new user ensures that the guest user will not be able to access the other Access Manager server.
Create a new instance named msgqbroker by running the following command:
/bin/imqbrokerd -name msgqbroker -port 7777 &
Run the netstat command 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.
# /bin/imqusermgr add -u msgquser -g admin -p m5gqu5er -i msgqbroker
Update the guest user.
# /bin/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.
Edit the /opt/SUNWam/lib/amsfo.conf file.
Make a backup of the amsfo.conf file, and then set the following properties:
CLUSTER_LIST=MessageQueue-1.example.com:7777,MessageQueue-2.example.com:7777 BROKER_INSTANCE_NAME=msgqbroker USER_NAME=msgquser lbServerPort=9443 lbServerProtocol=https lbServerHost=LoadBalancer-3.example.com SiteID=11
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.
# cd /opt/SUNWam/bin
# ./amsfopassword -e m5gqu5er -f /opt/SUNWam/.password
To view the encrypted password:
# more /opt/SUNWam/.password
M27OGb6U4ufRu+oWAzBdWw==
Edit the /opt/SUNWam/bin/amsessiondb script.
Make a backup of the /opt/SUNWam/bin/amsessiondb script before making any changes to the script.
The amsessiondb script is called by the amsfo script to start the Berkeley DB client (amsessiondb ), create the database, and set specific database values. The script contains variables that specify various default paths and directories:
JAVA_HOME=/usr/jdk/entsys-j2se/ IMQ_JAR_PATH=/usr/share/lib JMS_JAR_PATH=/usr/share/lib BDB_JAR_PATH=/usr/share BDB_SO_PATH=/usr/lib AM_HOME=/opt/SUNWam |
If any of these components are not installed in their default directories, edit the amsessiondb script and set the variables, as needed, to the correct locations.
Edit the /opt/SUNWam/bin/amsfoscript.
Make a backup of the /opt/SUNWam/bin/amsfo script before making any changes to the script. In the following line, add the parameter —name $BROKER_INSTANCE_NAME as follows:
$JMQEXECUTABLE -bgnd $BROKER_OPTIONS -vmargs $BROKER_VM_ARGS -name $BROKER_INSTANCE_NAME -port $BROKER_PORT -cluster $CLUSTER_LIST & -jmqpid=$! echo $_jmqpid > $JMQ_PID_FILE |
Restart the Access Manager session failover components.
Stop the Message Queue broker instance.
# cd /opt/SUNWam/bin # ./amsfo stop |
Run the netstat command to verify that the Message Queue broker instance is stopped.
# netstat -an | grep 7777 |
If netstat returns no result, then the Message Queue broker instance is stopped.
If the Message Queue broker instance is not stopped, run the following commands:
# cd /tmp/amsession/logs # cat *.pid |
Process IDs are displayed. Example:
4940 4924 |
Kill these Java processes. Example:
# kill -9 4940 4924 |
If you don't see the process-ids in that file, and the netstat is still listening on port 7777, then it's possible that the amsfo script did not stop properly. In this case, run the following command to identify the java processes:
# ps -ef | grep java |
Then kill those identified processes as shown in the kill command example above.
Then check with netstat again. The port socket should be relinquished before you start up amsfo again. Otherwise, session failover problems may occur.
Restart the Message Queue broker instance.
# ./amsfo 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
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
Create a new secondary configuration instance for the Access Manager load balancer.
Go to the Access Manager URL:
https://LoadBalancer-3.example.com:9443/amserver/UI/Login
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
Click Configuration > Global Properties > Session > Secondary Configuration Instance.
Click New, and add the following values:
Load balancer URL. Example:
https://LoadBalancer-3.example.com:9443
msgquser
m5gqu5er
m5gqu5er
5000 (This is the default value.)
Message Queue broker address list. Example:
MessageQueue-1.example.com:7777, MessageQueue-2.example.com:7777 |
Click Add, and then click Save.
Log in as a root user to the host Access Manager 1.
# cd /opt/SUNWwbsvr/https-AccessManager-1.example.com/config |
Edit file server.xml.
Make a backup of this file, and then make the following changes:
Edit the file sun-web.xml.
cd /opt/SUNWwbsvr/https-AccessManager-1.example.com/is-web-apps/services/WEB-INF |
Log in as a root user to the host Access Manager 2.
# cd /opt/SUNWwbsvr/https-AccessManager-2.example.com/config |
Edit file server.xml.
Make a backup of this file, and then make the following changes:
Edit the file sun-web.xml.
cd /opt/SUNWwbsvr/https-AccessManager-2.example.com/is-web-apps/services/WEB-INF |
Restart Access Manager 1 and Access Manager 2.
# cd /opt/SUNWwbsvr/https-AccessManager-1
# ./stop; ./start
# cd /opt/SUNWwbsvr/https-AccessManager-2
# ./stop; ./start
Both Access Manager 1 and Access Manager 2 should be up and running before you begin this verification procedure.
Stop Access Manager 1.
# cd /opt/SUNWwbsvr/https-AccessManager-1 # ./stop |
Open a browser (Browser 1) and go to the following Access Manager load balancer URL:
https://LoadBalancer-3.example.com:9443/amserver/UI/Login?realm=users |
Log in to the Access Manager console using the following information:
testuser1
password
The Edit User page for testuser1 is displayed.
This indicates that although Access Manager 1 was stopped (see step 1), the Access Manager load balancer (LoadBalancer-3) directed your login request to Access Manager 2, and the session for testuser1 was successfully created in Access Manager 2.
Leave Browser 1 open.
On the host AccessManager–1, at the command line, start Access Manager 1.
# cd /opt/SUNWwbsvr/https-AccessManager-1 # ./start |
Both Access Manager 1 and Access Manager 2 are now up and running.
Open a second browser (Browser 2) and go to the following Access Manager URL:
http://accessmanager-1.example.com:1080/amserver/UI/Login |
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
On the Realms page, click the Sessions tab.
Stop Access Manager 2.
# cd /opt/SUNWwbsvr/https-AccessManager-2 # ./stop |
Access Manager 1 is still up and running, and Access Manager 2 is now stopped.
In Browser 1, in the Edit User page for testuser1, modify the user profile.
In the Full Name field, enter NewTestUser1, and then click Save.
The message “Profile was updated” is displayed.
In Browser 2, in the Realms page, click the Sessions tab.
In the View: list, select AccessManager-1.example.com:1080.
Verify that now two UserIds, named amAdmin and testuser1, exist in the Sessions list. This indicates that the session successfully failed over to Access Manager 1.
Close Browser 2.
Start Access Manager 2.
# cd /opt/SUNWwbsvr/https-AccessManager-2 # ./start |
Both Access Manager 1 and Access Manager 2 are now up and running.
Stop Access Manager 1.
# cd /opt/SUNWwbsvr/https-AccessManager-1 # ./stop |
Access Manager now down, and Access Manager 2 is still up and running.
In a new browser (Browser 3), go to the following Access Manager URL:
http://accessmanager-2.example.com:1080/amserver/UI/Login |
Log in to the Access Manager console using the following information:
amadmin
4m4dmin1
Leave the browser open.
In Browser 1, in the Edit User page for testuser1, modify the user profile.
In the Full Name field, change NewTestUser1 back to TestUser1, and then click Save.
The message “Profile is updated” is displayed.
In Browser 3, on the Sessions tab, click Search to refresh the page.
Under Sessions, two UserIDs, named amAdmin and testuser1 , are now displayed in the Sessions list. This indicates that the session successfully failed back to Access Manager 2.