Skip navigation.

Installing the Administration Server

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents View as PDF   Get Adobe Reader

Installing

The following sections describe how to install the Administration Server on both Windows and UNIX systems:

 


Before you Begin

Before you begin this installation procedure, make sure to do the following:

The following topics provide additional information to assist you in preparing for an installation:

System Security and BEA AquaLogic Enterprise Security

Like any component running on a system, the infrastructure it provides is only as secure as the operating environment where it is installed. When BEA AquaLogic Enterprise Security is installed on a system, it makes use of that system's security infrastructure to lock itself down and integrate with the security of its environment. Through the use of user, group, and file system permissions, BEA AquaLogic Enterprise Security allows limited access to many operations depending upon these permissions. For more information on users, groups, and file system permission, see the following topics:

System Users

BEA AquaLogic Enterprise Security uses two user identities when installed on a system. These identities are selected when the first product in BEA AquaLogic Enterprise Security family is installed and are referred to as the Administration User and the Service Control Manager User.

The Service Control Manager user is the identity assumed by the Service Control Manager when it starts. The Service Control Manager is the component that brokers trust between the local system and the Administration Server.

The other identity on the system is the Administration User. The Administration user owns all files (other than the Service Control Manager) and, on an Administration Server, is the identity the Administration Server assumes when it starts.

System Groups

Two groups are used in addition to the user identities to secure the Application Security Infrastructure.

File System Permissions

File system permissions are used to enforce user and group based restrictions. With each product, and instance a lockdown script is created and run when installation occurs: lockdown.bat (Windows) or lockdown.sh (Unix or Linux). This lockdown script can be run again at a later time to restore the installation to the recommended file system permissions.

There are two directories that contain executable tools and utilities: adm and bin. The adm directory contains tools and utilities that only an administrator can run, for example enrollment. The bin directory contains tools and utilities that all security users can run, for example set-env. The log directory is writable by all security users, but can only be read by security administrators (or on UNIX, only the instance owner). The work directory is a temporary directory that can only be read and written to by security users.

Secure Usernames and Passwords

AquaLogic Enterprise Security implements a sophisticated username and password schema to protect the application itself and to ensure secure communications. Understanding this schema is important to installing the product and ensuring that it operates properly in either a development or production environment.

There are three levels of password protection: local system usernames and passwords (protect the AquaLogic Enterprise Security components), passwords for keystores (secure communication between components), and a password to protect the private keys (the Certificate Authority). Understanding your enterprise and how responsibilities in your organization are separated is essential to establishing a secure environment. For example, the person who maintains the database is usually not the person who designs and implements security. The person who deploys applications is usually not the person who administers system usernames and passwords. And, while you may not be as concerned with a more formal authorization scheme in your development environment, your production environment needs to be firmly secured and responsibilities clearly defined.

AquaLogic Enterprise Security user accounts on Windows platforms, like asiadmin and scmuser are special (see System Users and System Groups), and cannot be used to logon to any interactive session; these passwords are used for registration purposes only. They can only be used to start and stop component services. After the installer collects all of the passwords, it encrypts them in an internal password file. Later on, the service engine uses the username and password to register AquaLogic Enterprise Security as a Windows service. Therefore, the user may not need to change the password for the newly created specific usernames like asiadmin and scmuser; but, optionally, they can be changed if necessary.

Note: If these usernames already exist (they were generated as a part of a previous install process), you must enter the correct password. Remember to write down all usernames and passwords and store them in a safe place.

Usernames and passwords are required to access the components listed and described in Table 3-1.

Table 3-1 Usernames and Passwords 

Component

Description

Default

Database Server

A database server account used to connect to the database server where the policy data is stored, and update policy data using the policy import and export tools.

none

Administration Server

A local user account used to start the Administration Server and all Administration Server components.

User: asiadmin
Group: asiadgrp

Service Control Manager

A local user account used to start the Service Control Manager.

User: scmuser

Security Group

A local group that includes all users of AquaLogic Enterprise Security. All users of AquaLogic Enterprise Security must be members of this security group, including administrators.

Group: asiusers

Certificate Authority

Sets the password for the private key for the Certificate Authority. All trust within the enterprise domain originates from this authority.

Randomly generated

Identity Key Passwords (Keystore Passwords)

You also need to supply private key passwords for each of the following identities:

  • Service Control Manager

  • Security Service Module

  • Administration Application

Private key passwords validate process authenticity by using the Certificate Authority chain of trust. Identities with invalid or untrusted keys cannot participate in the trust relationships in the enterprise domain.

Randomly generated

Configure Keystores

You need to supply keystore passwords for each of the Identity, Peer and Trust keystores.

Identity Keystore - stores and protects the private keys that represent the processes identity or identities.

Peer Keystore - stores and protects the public keys for all trusted identities within the installed component (Administration Application, Security Service Module or Service Control Manager).

Trust Keystore - stores and protects public keys for Certificate Authorities that originate the chain of trust.

Randomly generated


 

BEA recommends following these guidelines:

Note: BEA does not recommend the use of randomly generated passwords, as the generation mechanism for these passwords is not secure. In a production environment, BEA does not recommend installing Security Service Modules on the same machine as the Administration Server.

Generating a Verbose Installation Log

If you start the installation process from the command line or from a script, you can specify the -log option to generate a verbose installation log. The installation log lists messages about events that occur during the installation process, including informational, warning, error, and fatal messages. This can be especially useful for silent installations.

Note: You may see some warning messages in the installation log. However, unless there is a fatal error, the installation program completes the installation successfully. The installation user interface indicates the success or failure of the installation, and the installation log file includes an entry indicating that the installation was successful.

To create a verbose log file during installation, use the following command lines or scripts:

Note: The -log parameter is optional. By default, the installation log is put in the log directory where you install the Administration Server. If for some reason, the installer fails, use this switch to generate an even more verbose output: -log_priority=debug.

The path must be the full path to a file name. If the file does not exist, all folders in the path must exist before you execute the command or the installation program does not create the log file.

 


Starting the Installation Program on Windows Platforms

Note: Do not install the software from a network drive. Download the software to a local drive on your machine and install it from there.

Before running the installer, ensure the following two things are done.

To install the application in a Microsoft Windows environment:

  1. Shut down any programs that are running.
  2. Log in to the local Administrators group.
  3. If you are installing from a CD-ROM, go to step 4. If you are installing by downloading from the BEA web site:
    1. Go to the directory where you downloaded the installation file and double-click ales210admin_win32.exe.
    2. The AquaLogic Enterprise Security Administration Server window appears as shown in Figure 3-1.

  4. If you are installing from a CD-ROM:
    1. Insert Disk 1 into the CD-ROM drive.
    2. If the installation program does not start automatically, open Windows Explorer and double-click the CD-ROM icon.

    3. From the installation CD, double-click ales210admin_win32.exe.
    4. The AquaLogic Enterprise Security Administration Server window appears as shown in Figure 3-1.

    Figure 3-1 AquaLogic Enterprise Security Administration Server Installer Window

    AquaLogic Enterprise Security Administration Server Installer Window


     

 


Starting the Installation Program on a Sun Solaris Platform

To run graphical-mode installation, your console must support a Java-based GUI. If the installation program determines that your system cannot support a Java-based GUI, the installation program automatically starts console-mode installation.

Before running the installer, ensure the following three things are done.

To install the application on a Sun Solaris platform:

  1. Log in to the machine as root.
  2. Set your DISPLAY variable if needed.
  3. If you are installing from a CD-ROM, go to step 4. If you are installing by downloading from the BEA web site:
    1. Go to the directory where you downloaded the file and change the protection on the install file:
    2. chmod u+x ales210admin_solaris32.bin
    3. Start the installation: ./ales210admin_solaris32.bin

    The AquaLogic Enterprise Security Administration Server window appears as shown in Figure 3-1.

  4. If you are installing from a CD-ROM:
    1. Insert Disk 1 into the CD-ROM drive.
    2. From the installation CD, execute ales210admin_solaris32.bin.
    3. The AquaLogic Enterprise Security Administration Server window appears as shown in Figure 3-1.

 


Starting the Installation Program on a Linux Platform

To run graphical-mode installation, your console must support a Java-based GUI. If the installation program determines that your system cannot support a Java-based GUI, the installation program automatically starts console-mode installation.

Before running the installer, ensure the following three things are done.

To install the application on a Linux platform:

  1. Log in to the machine as root.
  2. Set your DISPLAY variable if needed.
  3. If you are installing from a CD-ROM, go to step 4. If you are installing by downloading from the BEA web site:
    1. Go to the directory where you downloaded the file and change the protection on the file:
    2. chmod u+x ales210admin_linux32.bin
    3. Start the installation: ./ales210admin_linux32.bin

    The AquaLogic Enterprise Security Administration Server window appears as shown in Figure 3-1.

  4. If you are installing from a CD-ROM:
    1. Insert Disk 1 into the CD-ROM drive.
    2. From the installation CD, execute ales210admin_linux32.bin.

    The AquaLogic Enterprise Security Administration Server window appears as shown in Figure 3-1.

 


Running the Installation Program

The installation program prompts you to enter specific information about your system and configuration, as described in Table 3-2.

Note: You must install the Administration Server first, before installing your Security Service Modules. BEA does not recommend installing Security Service Modules on the same machine as the Administration Server in a production environment.

To complete this procedure you need the following information:

 


What's Next

Now that you have installed the necessary software, you must start the necessary services. For additional instructions, see Post Installation Tasks. If you want to install a second Administration Server to use as a backup, see Installing a Secondary Administration Server.

 


Installing a Secondary Administration Server

You may want to install and configure a second Administration Server to support failover. For information on failover considerations, see "Failover and System Reliability in the BEA AquaLogic Enterprise Security Administration Guide.

The secondary Administration Server must be set up in the same manner as the primary and installed on a separate machine.

  1. Install the servlet container, Weblogic Server 8.1 or Apache Tomcat.
  2. Run the installation program to install the secondary Administration Server.
  3. Enter the following information:
    1. When prompted for the Enterprise Domain, make sure to enter the same domain name that you entered during the primary installation (default is asi).
    2. When prompted for the Secondary Server URL, leave this blank, unless you plan on installing one of the Security Service Modules on the machine that hosts the backup Administration Server. In this case, specify the URL of the primary Administration Server.
    3. When entering the Database Configuration, make sure to use the exact same configuration that you specified during the primary installation.
    4. The database password used by the primary and backup Administration Servers are independent of each other. This allows you to use instance specific passwords to protect the various sensitive artifacts on the Administration Servers. For example, you may use different key passwords for the CA, Admin, SSM, and SCM identities that you entered in the primary installation. The same applies to the Identity, Peer, and Trust key store passwords.
    5. Note: Do not install the database schema at the conclusion of the backup installation process. Do not run the initialize_backup_trust.bat (on Windows platforms) or initialize_backup_trust.sh (on Unix platforms) command after installing the backup.

  4. Initialize the Backup Administration Server Trust Stores.
  5. Before starting the backup Administration Server, you must synchronize the various trust stores used by the backup Administration Server with those of the primary. If this is not done, the backup Administration Server will not trust the Security Service Modules currently enrolled with the primary, and as a result, failover will not work.

    To initialize the backup Administration Server trust stores, do the following:

    1. Copy the primary Administration Server and primary Service Control Manager ssl directories to the machine that hosts the backup Administration Server. One way to do this is to copy the primary Service Control Manager ssl directory onto a floppy disk or other removable media, and rename the ssl directory to scm-ssl. Likewise, copy the primary Administration Server ssl directory to the same removable media and rename the ssl directory to admin-ssl. Mount the removable media on the machine that hosts the backup Administration Server.
    2. Execute the initialize_backup_trust.bat (on Windows platforms) or initialize_backup_trust.sh (on Unix platforms) command from the bin directory of the backup Administration Server install. When prompted for the primary Service Control Manager SSL directory, enter the path to the scm-ssl directory created in the previous step. Likewise, when prompted for the primary Admin SSL directory, enter the path to the admin-ssl directory created in the previous step.
    3. Delete the ssl directories on the removable media.
  6. Start the backup Administration Server as you normally would a primary.
  7. Configure the Backup Server Trust Synchronization Mechanism.
  8. Even though the backup Administration Server trust stores are synchronized with those of the primary in step 4, it is possible for them to become out of sync over time. This happens when a new Security Service Module or Service Control Manager is enrolled with the primary Administration Server. The trust stores of the primary Administration Server are updated with the new Security Service Module or Service Control Manager certificate during enrollment, but since an Security Service Module or Service Control Manager should only be enrolled with its primary, the backup Administration Server trust stores do not have the new certificate.

    A similar trust situation occurs during Security Service Module or Service Control Manager unenrollment. To prevent the trust stores from becoming unsynchronized, the Administration Server has a trust synchronization mechanism that should be enabled on the backup Administration Server. The trust synchronization mechanism on the backup Administration Server periodically pools the primary for any updates to its trust store, and if a change has occurred, the mechanism updates the backup trust store with the contents of the primary. It is very important that you only enable the trust synchronization mechanism on the backup Administration Server.

    See "Configuring the Administration Server for Failover" in the Administration Server Console Help for details on how to configure the backup server.

 

Skip navigation bar  Back to Top Previous Next