test

Deployment Example 1: Access Manager 7.0 Load Balancing, Distributed Authentication UI, and Session Failover

10.2 Installing the Access Manager Session Failover Components

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:

  1. Install Access Manager session failover components on Message Queue 1.

  2. Install Access Manager session failover components on Message Queue 2.

  3. Edit the Access Manager Web Server configuration files.

  4. Verify that Session Failover works properly.

ProcedureTo Install Access Manager Session Failover Components on Message Queue 1

  1. As root, log in to the host MessageQueue-1.

  2. Use the pkgadd command to install the Access Manager session failover component packages.

    1. Add the BerkeleyDB-Base and BerkeleyDB-Java packages.


      # cd /mnt/Solaris_sparc/Product/shared_components/Packages
# pkgadd -d . SUNWbdb SUNWbdbj

    2. Add the Access Manager Session Failover DB components.


      # cd /mnt2/Solaris_sparc/Product/identity_svr/Packages
# pkgadd -d . SUNWamsfodb

  3. 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.

    1. 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

    2. 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

    3. 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.

  4. 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

  5. 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==

  6. 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.

  7. 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

  8. Restart the Access Manager session failover components.

    1. Stop the Message Queue broker instance.


      # cd /opt/SUNWam/bin
# ./amsfo stop

    2. 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.

      Tip –

      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.

    3. Restart the Message Queue broker instance.


      # ./amsfo start

    4. 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

ProcedureTo Install Access Manager Session Failover Components on Message Queue 2

  1. As root, log in to the host MessageQueue-2.

  2. Use the pkgadd command to install the Access Manager session failover component packages.

    1. Add the BerkeleyDB-Base and BerkeleyDB-Java packages.


      # cd /mnt/Solaris_sparc/Product/shared_components/Packages
# pkgadd -d . SUNWbdb SUNWbdbj

    2. Add the Access Manager Session Failover DB components.


      # cd /mnt2/Solaris_sparc/Product/identity_svr/Packages
# pkgadd -d . SUNWamsfodb

  3. 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.

    1. 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

    2. Add a new user named msgquser.

      # /bin/imqusermgr add -u msgquser -g admin -p m5gqu5er -i msgqbroker

    3. 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.

  4. 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

  5. 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==

  6. 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.

  7. 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

  8. Restart the Access Manager session failover components.

    1. Stop the Message Queue broker instance.


      # cd /opt/SUNWam/bin
# ./amsfo stop

    2. 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.

      Tip –

      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.

    3. Restart the Message Queue broker instance.


      # ./amsfo start

    4. 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

  9. 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

ProcedureTo Identify The Session Store Components In Access Manager

Create a new secondary configuration instance for the Access Manager load balancer.

  1. Go to the Access Manager URL:

    https://LoadBalancer-3.example.com:9443/amserver/UI/Login

  2. Log in to the Access Manager console using the following information:

    Username

    amadmin

    Password

    4m4dmin1

  3. Click Configuration > Global Properties > Session > Secondary Configuration Instance.

  4. Click New, and add the following values:

    Name:

    Load balancer URL. Example:

    https://LoadBalancer-3.example.com:9443

    Session Store User:

    msgquser

    Session Store Password:

    m5gqu5er

    Session Store Password (Confirm):

    m5gqu5er

    Maximum Wait Time:

    5000 (This is the default value.)

    Database URL:

    Message Queue broker address list. Example:


    MessageQueue-1.example.com:7777,
MessageQueue-2.example.com:7777

  5. Click Add, and then click Save.

ProcedureTo Edit the Access Manager Web Server Configuration Files

  1. Log in as a root user to the host Access Manager 1.


    # cd /opt/SUNWwbsvr/https-AccessManager-1.example.com/config

  2. Edit file server.xml.

    Make a backup of this file, and then make the following changes:

    1. In server.xml, locate this entry:

      <JAVA javahome="/usr/jdk/entsys-j2se" serverclasspath=

    2. At the end of the serverclasspath attribute, append these values:


      /usr/share/lib/jms.jar:/usr/share/lib/imq.jar:

    3. Save the file.

  3. Edit the file sun-web.xml.


    cd /opt/SUNWwbsvr/https-AccessManager-1.example.com/is-web-apps/services/WEB-INF

    1. Make a copy of sun-web.xml.

    2. In the <cookie-properties> element, add the following property:


      <property name="encodeCookies" value="false"/>

    3. Save the file.

  4. Log in as a root user to the host Access Manager 2.


    # cd /opt/SUNWwbsvr/https-AccessManager-2.example.com/config

  5. Edit file server.xml.

    Make a backup of this file, and then make the following changes:

    1. In server.xml, locate this entry:

      <JAVA javahome="/usr/jdk/entsys-j2se" serverclasspath=

    2. At the end of the serverclasspath attribute, append these values:


      /usr/share/lib/jms.jar:/usr/share/lib/imq.jar:

    3. Save the file.

  6. Edit the file sun-web.xml.


    cd /opt/SUNWwbsvr/https-AccessManager-2.example.com/is-web-apps/services/WEB-INF

    1. Make a copy of sun-web.xml.

    2. In the <cookie-properties> element, add the following property:


      <property name="encodeCookies" value="false"/>

    3. Save the file.

  7. Restart Access Manager 1 and Access Manager 2.

    # cd /opt/SUNWwbsvr/https-AccessManager-1

    # ./stop; ./start

    # cd /opt/SUNWwbsvr/https-AccessManager-2

    # ./stop; ./start

ProcedureTo Verify that Session Failover Works Properly

Before You Begin

Both Access Manager 1 and Access Manager 2 should be up and running before you begin this verification procedure.

  1. Stop Access Manager 1.


    # cd /opt/SUNWwbsvr/https-AccessManager-1
# ./stop

  2. 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

  3. Log in to the Access Manager console using the following information:

    Username

    testuser1

    Password

    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.

  4. 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.

  5. Open a second browser (Browser 2) and go to the following Access Manager URL:


    http://accessmanager-1.example.com:1080/amserver/UI/Login

  6. Log in to the Access Manager console using the following information:

    Username

    amadmin

    Password

    4m4dmin1

  7. On the Realms page, click the Sessions tab.

    1. In the View: field, select Access Manager-2.example.com:1080.

      Verify that only one User Id, named testuser1, exists in the Sessions list.

    2. In the View: field, select Access Manager-1.example.com:1080

      Verify that only one User Id, named amAdmin, exists in the Sessions list.

      Leave Browser 2 open.

  8. 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.

  9. 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.

  10. 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.

  11. Start Access Manager 2.


    # cd /opt/SUNWwbsvr/https-AccessManager-2
# ./start

    Both Access Manager 1 and Access Manager 2 are now up and running.

  12. Stop Access Manager 1.


    # cd /opt/SUNWwbsvr/https-AccessManager-1
# ./stop

    Access Manager now down, and Access Manager 2 is still up and running.

  13. In a new browser (Browser 3), go to the following Access Manager URL:


    http://accessmanager-2.example.com:1080/amserver/UI/Login

  14. Log in to the Access Manager console using the following information:

    Username

    amadmin

    Password

    4m4dmin1

    Leave the browser open.

    1. On the Realms page, click the Sessions tab.

    2. In the View field, select AccessManager-2.example.com:1080.

    3. Click the Search button.

      Under Sessions, only one UserID named amAdmin exists in the Session list.

      Leave the Browser 3 open.

  15. 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.

  16. 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.