Administration Application Installation
Installing
The following sections describe how to install the Administration Application 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 Weblogic 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 WebLogic 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 WebLogic Enterprise Security allows limited access to many operations depending upon these permissions. For more information on users, groups, and file system permiission, see the following topics:
System Users
BEA WebLogic Enterprise Security uses two user identities when installed on a system. These identities are selected when the first product in BEA WebLogic 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.
- The Security Administrators Group allows users other than the Service Control Manager user or the Administrative user to perform log maintenance, creation and destruction of new instances, and other administrative tasks.
- The Security Users Group permits users on the system to have the necessary permissions to use and execute applications protected by WebLogic Enterprise Security. All WebLogic Enterprise Security users, including administrators, must belong to this group.
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 User Names and Passwords
WebLogic 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 WebLogic 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 the 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 in your development environment, your production environment needs to be firmly secured and responsibilities clearly defined.
WebLogic 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 WebLogic Enterprise Security as a Windows service. So, the user may not need to change the password for the newly created specific user names like asiadmin and scmuser; but, optionally, they can be changed if necessary.
Note: If these user names 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.
User names and passwords are required to access the following components. Table 4-1 lists each component that requires a value and lists the default values.
Table 4-1 User Names 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 Application 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 WebLogic Enterprise Security. All users of WebLogic 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:
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:
- Development Environment—In a development environment, you can either use the default values generated during the installation process or you can assign your own user names and passwords to protect your public and private keys.
- Production Environment—In a production environment, you must choose all passwords explicitly. These passwords may be needed for future maintenance of the public key infrastructure (PKI), for example, in the case of a failure. Make sure to write down all password information and retain it in a secure location.
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 line or script:
- For Windows platforms:
wles422admin_win32.exe -log=D:\bea\logs\wles_install.log
- For the Sun Solaris platform:
wles422admin_solaris32.bin -log=/bea/logs/wles_install.log
- For the Linux Red Hat Advanced Server platform:
wles422admin_linux32.bin -log=/bea/logs/wles_install.log
Note: The -log parameter is optional. By default, the installation log is put in the log directory where you install the Administration Server.
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.
- Ensure the database client directories have the correct permissions.
Set the file permissions on the database client directories so that all users can read and execute the files. Run the following command:
cacls C:\oracle /T /E /G Everyone:F
Where:
C:\oracle is the location of your database application
- Ensure the PATH is set correctly.
It is also important to include the /bin directory of your database client in the system PATH (the path available to all users) rather than the user PATH (the path only available to the current user). If this is changed, you must reboot before the change becomes available to processes running as services (which is how the Administration Application initializes itself).
To install the application in a Microsoft Windows environment:
- Shut down any programs that are running.
- Log in to the local Administrators group.
- If you are installing from a CD-ROM, go to step 4. If you are installing by downloading from the BEA web site:
- Go to the directory where you downloaded the installation file and double-click wles422admin_win32.exe.
The WebLogic Enterprise Security Administration Application window appears as shown in Figure 4-1.
- If you are installing from a CD-ROM:
- Insert Disk 1 into the CD-ROM drive.
If the installation program does not start automatically, open Windows Explorer and double-click the CD-ROM icon.
- From the installation CD, double-click
wles422admin_win32.exe.
The WebLogic Enterprise Security Administration Application window appears as shown in Figure 4-1.
Figure 4-1 WebLogic Enterprise Security Administration Application 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.
- Ensure the database client directories have the correct permissions.
Set the file permissions on the database client directories so that all users can read and execute the files. Run the following command:
chmod -R o+rx /opt/ora92
- Ensure the PATH is set correctly.
It is also important to add the /bin directory to PATH and the /lib directory to LD_LIBRARY_PATH. If these settings are changed, you must reboot before the changes become available to processes running as services (which is how the Administration Application initializes itself).
Note: BEA recommends setting these variables in /etc/profile so they are available to all processes starting from init.
- Ensure that the location into which you do the install is accessible to all users at both the parent and the child directory levels.
For example, if the installation directory is /opt/beahome/wles42-admin and the /opt/ directory is only accessible by root, post installation scripts that run as a user other than root cannot access the directory where they reside. Therefore, the directory into which you do the install (for example, /opt/beahome/wles42-admin) must have execute permissions for other. Run the following command to reset the permissions:
chmod o+x /opt/
The beahome and wles42-admin directories already have permissions set appropriately.
To install the application on a Sun Solaris platform:
- Log in to the machine as root.
- Set your
DISPLAY variable if needed.
- If you are installing from a CD-ROM, go to step 4. If you are installing by downloading from the BEA web site:
- Go to the directory where you downloaded the file and change the protection on the install file:
chmod u+x wles422admin_solaris32.bin
- Start the installation
: ./wles422admin_solaris32.bin
The WebLogic Enterprise Security Administration Application window appears as shown in Figure 4-1.
- If you are installing from a CD-ROM:
- Insert Disk 1 into the CD-ROM drive.
- From the installation CD, execute wles422admin_solaris32.bin.
The WebLogic Enterprise Security Administration Application window appears as shown in Figure 4-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.
- Ensure the database client directories have the correct permissions.
Set the file permissions on the database client directories so that all users can read and execute the files. Run the following command:
chmod -R o+rx /opt/ora92
- Ensure the PATH is set correctly.
It is also important to add the /bin directory to PATH and the /lib directory to LD_LIBRARY_PATH. If these settings are changed, you must reboot before the changes become available to processes running as services (which is how the Administration Application initializes itself).
Note: BEA recommends setting these variables in /etc/profile so they are available to all processes starting from init.
- Ensure that the location into which you do the install is accessible to all users at both the parent and the child directory levels.
For example, if the installation directory is /opt/beahome/wles42-admin and the /opt/ directory is only accessible by root, post installation scripts that run as a user other than root cannot access the directory where they reside. Therefore, the directory into which you do the install (for example, /opt/beahome/wles42-admin) must have execute permissions for other. Run the following command to reset the permissions:
chmod o+x /opt/
The beahome and wles42-admin directories already have permissions set appropriately.
To install the application on a Linux platform:
- Log in to the machine as root.
- Set your
DISPLAY variable if needed.
- If you are installing from a CD-ROM, go to step 4. If you are installing by downloading from the BEA web site:
- Go to the directory where you downloaded the file and change the protection on the file:
chmod u+x wles422admin_linux32.bin
- Start the installation
: ./wles422admin_linux32.bin
The WebLogic Enterprise Security Administration Application window appears as shown in Figure 4-1.
- If you are installing from a CD-ROM:
- Insert Disk 1 into the CD-ROM drive.
- From the installation CD, execute wles422
admin_linux32.bin.
The WebLogic Enterprise Security Administration Application window appears as shown in Figure 4-1.
Running the Installation Program
The installation program prompts you to enter specific information about your system and configuration, as described in Table 4-2.
Note: You must install the Administration Application 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:
- For Windows, a username and password for the Administration Application account
- For Windows, a username and password for the Service Control Manager account
- Name of the
BEA HOME directory
- Name of the product directory
- Database connection information (see your database administrator and Setting Up and Administering the Database for details).
Table 4-2 Administration Application Installation
|
In this Window:
|
Perform this Action:
|
|
Welcome
|
Click Next to proceed or cancel the installation at any time by clicking Exit.
|
|
BEA License Agreement
|
Read the BEA Software License Agreement, and then select Yes to indicate your acceptance of the terms of the agreement. To continue with the installation, you must accept the terms of the license agreement, click Yes, and then click Next.
|
|
Choose BEA Home Directory
|
Specify the BEA Home directory that serves as the central support directory for all BEA products installed on the target system. If you already have a BEA Home directory on your system, you can select that directory (recommended) or create a new BEA Home directory. If you choose to create a new directory, the installer program automatically creates the directory for you.
|
|
Choose Product Directory
|
Specify the directory in which to install the Administration Application software. You can accept the default product directory (wles42-admin) or create a new product directory.
If you choose to create a new directory, the installation program automatically creates the directory for you, if necessary.
Click Next to continue.
|
|
Choose Service Control Manager Directory
|
Specify the directory in which to install the Service Control Manager. You can accept the default directory (wles42-scm) or you can create a new one.
Click Next to continue.
|
|
Select Users and Groups
|
Specify the user names and group names to use for the Service Control Manager and Administration Application. You can accept the default settings or create new ones.
Note: When installing this product for use in a production environment, BEA recommends that you set these passwords to known values; otherwise you will not be able to modify them later. For example, you may want to modify these passwords to comply with organizational requirements.
Admin User (asiadmin)
A local user account used to start the Administration Application components.
Admin Group (asiadgrp)
Administration Application group. Members of this group have full access to Administration Application and log files; they can start and stop the Administration Application components.
SCM User (scmuser)
A local user account used to start the Service Control Manager.
Security Group (asiusers)
Service Control Manager Group. Members of this group are allowed to use the WebLogic Enterprise Security product.
Click Next to continue.
|
|
Confirm User Selection
|
If the name of the user and group do not yet exist, they are created for you. Verify the values you entered are correct, and then click Next.
|
|
Select User Passwords
(Windows only)
|
Specify the password for the Administration Application User and Service Control Manager User. You can also accept the default passwords that are randomly generated.
Note: If any of the users exist you must enter their passwords; the passwords are not generated randomly.
Note: Passwords are case sensitive. If you are installing the Administration Application in a production environment, BEA recommends using secure user names and passwords, and not those that are randomly generated.
Click Next to continue.
|
|
Choose Network Interfaces
|
Select the network interfaces to which to bind the Service Control Manager. This is the IP Address used to listen for requests to provision policy and configuration data.
Note: If you are installing the Administration Application in a production environment with more than one network card, you want to select a protected (internal) interface; you do not want to expose the Service Control Manager through a public address.
Click Next to continue.
|
|
Configure Administration Application
|
Enterprise Domain Name
Enter the name to assign to this domain. The Enterprise Domain represents the
collection of Security Service Modules administered by this BEA WebLogic
Enterprise Security Administration Application. Make a note of the Enterprise
Domain Name you entered as you will need this to install any subsequent
security service modules.
Note: The Enterprise Domain Name must be entered in all lower case; and may not contain any spaces or punctuation marks.
|
|
Configure Administration Application (Continued)
|
Administration Application
HTTP Port
Enter the HTTP port number for the WebLogic Server 8.1 Administration
Console to use.
SSL Port
Enter the HTTPS port number for the Administration Application to use.
When you enter the SSL port number, make sure that at least six consecutive
port numbers are also available. These port numbers are used by services
required by the BEA WebLogic Enterprise Security Administration
Application to operate properly, and the Administration Application always
runs on a secure connection using this port.
|
|
Configure Administration Application (Continued)
|
Certificate Authority Duration (years)
Enter the number of years the security certificate remains in effect. The Certificate Authority is used to generate and sign certificates for other components in the BEA WebLogic Enterprise Security system.
Secondary Server URL
This URL is only necessary if you plan on installing the Security Service Modules on the same machine as your Administration Server and plan on configuring the Security Service Modules with a backup Administration Application. Otherwise, you can leave this URL blank.
Click Next to continue.
|
|
Configure Database Connection
|
Database Client
Select the type and version of database client you are using (Sybase or Oracle)
on this machine. The prompts that appear differ depending on the type of client
you select.
Database Connection
For Oracle:
Oracle Service Name
Local service name (Oracle System Identifier SID).
Database JDBC URL
Change the <SID> and <SERVER> name to complete the JDBC URL:
jdbc:oracle:thin:@<SERVER>:1521:<SID>
Database JDBC Driver
The Oracle driver to use by default:
oracle.jdbc.driver.OracleDriver
|
|
Configure Database Connection (Continued)
|
Database Connection
For Sybase:
Sybase Host Name
Sybase server entry you configured in this local machine, used to connect to
Sybase database server running elsewhere.
Sybase Database Name
Name of the Sybase database; that is, the name of policy database.
Database JDBC URL
Change the <hostname_or_IP> and <databaseName> name to
complete the JDBC URL, assuming the Sybase server is running on
port 4100:
The <hostname_or_IP> is the hostname or IP address of the machine
running Sybase server, and <databaseName> is the policy database
name. You may need to change port number if necessary. The Sybase
server usually listens on port 5000 on Windows platform and 4100 on
other platforms:
jdbc:sybase:Tds:<hostname_or_IP>:4100/<databaseName>
or
jdbc:sybase:Tds:<hostname_or_IP>:4100
You can use the later when the default database for Login ID is set to the
policy database.
Database JDBC Driver
The Sybase driver to use by default:
com.sybase.jdbc2.jdbc.SybDriver
|
|
Configure Database Connection (Continued)
|
Database Login
Login ID, Password, Confirm Password
The database login id and password to use to connect to the database; you must
confirm the password.
Click Next to continue.
|
|
Configure Certificate Authority
|
The Certificate Authority is used to generate and sign certificates for other components in the BEA WebLogic Enterprise Security system.
Key Password
You can either choose to use a randomly generated password or you can
specify the private key password. You must confirm the password.
Note: You should write down or remember all passwords and store them in a safe location should you ever need to use them again. For example, if you plan on installing redundant servers, you need to use the same keystore and key passwords.
Click Next to continue.
|
|
Configure Keys
|
Enter the following key passwords to secure communications of internal processes. These are components of the Administration Application. Private key passwords are used to validate process authenticity by using the Certificate Authority chain of trust. Identities with invalid or untrusted keys cannot participate in the trust relationships of the enterprise domain.
|
|
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.
|
|
Installation Complete
|
This page indicates the Administration Application completed successfully. If you want to install the database schema now.
Check the Install Database Schema check box. If you are installing a failover server for backup and failover purposes, you do not want to install the database schema again, so clear this check box.
Note: Make sure to write down the name of the Administration Application URL. You will need this URL when you are installing additional components.
Click Done to complete the installation.
|
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 Application.
Installing a Secondary Administration Application
You may want to install and configure a second Administration Application to support failover. For information on failover considerations, see "Failover and System Reliability in the BEA WebLogic 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.
- Install the Weblogic Server 8.1.
- Run the installation program on the secondary Administration Server.
- Enter the following information:
- When prompted for the Enterprise Domain, make sure to enter the same domain name that you entered during the primary installation (default is asi).
- 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 Application. In this case, specify the URL of the primary Administration Application.
- When entering the Database Configuration, make sure to use the exact same configuration that you specified during the primary installation.
- The database password used by the primary and backup Administration Applications are independent of each other. This allows you to use instance specific passwords to protect the various sensitive artifacts on the Administration Applications. 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.
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.
- Initialize the Backup Administration Application Trust Stores.
Before starting the backup Administration Application, you must synchronize the various trust stores used by the backup Administration Application with those of the primary. If this is not done, the backup Administration Application 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 Application trust stores, do the following:
- Copy the primary Administration Application and primary Service Control Manager ssl directories to the machine that hosts the backup Administration Application. 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 Application 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 Application.
- 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 Application 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.
- Delete the ssl directories on the removable media.
- Start the backup Administration Application as you normally would a primary.
- Configure the Backup Server Trust Synchronization Mechanism.
Even though the backup Administration Application 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 Application. The trust stores of the primary Administration Application 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 Application 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 Application has a trust synchronization mechanism that should be enabled on the backup Administration Application. The trust synchronization mechanism on the backup Administration Application 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 Application.
See "Configuring the Administration Server for Failover" in the Administration Application Console Help for details on how to configure the backup server.
