Configure local operating system registries

 

Use these steps to configure local operating system registries.

For detailed information about using the local operating system user registry, see Local operating system registries. As installed, security is disabled for WAS. These steps set up security based on the local operating system user registry on which WAS is installed.

For security purposes, the WAS provides and supports the implementation for Windows operating system registries, AIX, Solaris and multiple versions of Linux operating systems. The respective operating system API are called by the product processes (servers) for authenticating a user and other security-related tasks (for example, getting user or group information). Access to these APIs are restricted to users who have special privileges. These privileges depend on the operating system and are described below.

In WAS V6.1, you can use an internally-generated server ID because the Security WebSphere Common Configuration Model (WCCM) model contains a new tag, internalServerId. You do not need to specify a server user ID and a password during security configuration except in a mixed-cell environment. See Administrative roles and naming service authorization for more detailed information about the new internal server ID.

Consider the following issues:

• The server ID needs to be different from the Windows machine name where the product is installed. For example, if the Windows machine name is vicky and the security server ID is vickyy, the Windows system fails when getting the information (group information, for example) for user vicky.

• WAS dynamically determines whether the machine is a member of a Windows system domain.

• WAS does not support Windows trusted domains.

• If a machine is a member of a Windows domain, both the domain user registry and the local user registry of the machine participate in authentication and security role mapping.

• The domain user registry takes precedence over the local user registry of the machine and can have undesirable implications if users with the same password exist in both user registries.

• The user that the product processes run under requires the Administrative and Act as part of the operating system privileges to call the Windows operating system APIs that authenticate or collect user and group information. The process needs special authority, which is given by these privileges. The user in this example might not be the same as the security server ID (the requirement for which is a valid user in the registry). This user logs into the machine (if using the command line to start the product process) or the Log On User setting in the services panel if the product processes have started using the services. If the machine is also part of a domain, this user is a part of the Domain Admin group in the domain to call the operating system APIs in the domain in addition to having the Act as part of operating system privilege in the local machine.

Consider the following points:

• 

  The user that the product processes run under requires the root privilege. This privilege is needed to call the operating system APIs to authenticate or to collect user and group information. The process needs special authority, which is given by the root privilege. This user might not be the same as the security server ID (the requirement is that it should be a valid user in the registry). This user logs into the machine and is running the product processes.

• The user that enables administrative security must have the root privilege if you use the local operating system registry. Otherwise, a failed validation error is displayed.

• You might need to have the password shadow file in your system.

 

Overview

The following steps are needed to perform this task initially when setting up security for the first time.

 

Procedure

1. Click Security > Secure administration, applications, and infrastructure.

2. Under User account repository, select Local operating system and click Configure.

3. Enter a valid user name in the Primary administrative user name field. This value is the name of a user with administrative privileges that is defined in the registry. This user name is used to access the console or used by wsadmin.

4. Click Apply.

5. Select either the Automatically generated server identity or Server identity that is stored in the repository option. If you select the Server identity that is stored in the repository option, enter the following information:

   Server user ID or administrative user on a V6.0.x node

   Specify the short name of the account that is chosen in the second step.

   Server user password

   Specify the password of the account that is chosen in the second step.

6. Click OK.

   The console does not validate the user ID and password when you click OK. Validation is only done when you click OK or Apply in the Secure administration, applications, and infrastructure panel. First, make sure that you select Local operating system as the available realm definition in the User account repository section, and click Set as current. If security was already enabled and you had changed either the user or the password information in this panel, make sure to go to the Secure administration, applications, and infrastructure panel and click OK or Apply to validate your changes. If your changes are not validated, the server might not start.

   Until you authorize other users to perform administrative functions, you can only access the console with the server user ID and password that you specified. For more information, see Authorizing access to administrative roles.

 

Results

For any changes in this panel to be effective, save, stop, and start all the product servers, including deployment managers, nodes and appservers. If the server comes up without any problems, the setup is correct.

After completed these steps, you have configured WAS to use the local operating system registry to identify authorized users.

 

What to do next

Complete any remaining steps for enabling security. For more information, see Enabling security.

---

Configure user ID for proper privileges

Local operating system settings

Local operating system wizard settings

 

Related concepts

Standalone Lightweight Directory Access Protocol registries

 

Related tasks

Enabling security
Authorizing access to administrative roles
Selecting a registry or repository