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. These steps set up security based on the local operating system user registry on which WebSphere Application Server is installed.
(dist) 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 later in this topic.
In WAS v6.1, we 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.
(zos) When a local operating system registry is chosen, the started task identity is chosen as the server identity. A user ID and password are not required to configure the server.
(zos) Important: Each started task, for example, a controller, servant, or daemon might have a different identity. Because you should give differing resource authorizations to each, you should give differing user IDs to controllers and servants. The z/OS Profile Management Tool sets up these identities.
(dist) 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.
- WebSphere Application Server 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.
- If we use a Windows domain user ID to install and run WebSphere Application Server, the ID must have the following privileges:
- Be a member of the domain administrative groups in the domain controller
- Have the Act as part of the operating system privilege in the domain security policy on the domain controller.
- Have the Act as part of the operating system privilege in the local security policy on the local machine.
- Have the Log on as a service privilege on the local machine if the server runs as a service.
- 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.
(dist) 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.
- We might need to have the password shadow file in the system.
(zos) When you set up a user registry for WebSphere Application Server, the System Authorization Facility (SAF) works in conjunction with the user registry to authorize applications to run on the server. For more information on the SAF capabilities, see System Authorization Facility user registries. Complete the following steps to configure additional properties associated with the local OS user registry and SAF configuration.
(zos) Important: The local operating system is not a valid user account repository when we have a mixed cell environment that includes both z/OS platform and non-z/OS platform nodes.
The following steps are needed to perform this task initially when setting up security for the first time.
- Click Security > Global security.
- Under User account repository, select Local operating system and click Configure.
- Enter a valid user name in the Primary administrative user name field. Name of a user with administrative privileges defined in the registry. This user name is used to access the console or used by wsadmin.
- (zos) If SAF authorization is not enabled, enter a valid user name in the Primary administrative user name field. Name of a user with administrative privileges defined in the registry. This user name is used to access the console or used by wsadmin.
- (zos) Optional: Select the Ignore case for authorization option to enable WebSphere Application Server to perform a case insensitive authorization check when you use the default authorization.
- Click Apply.
- Select either the Automatically generated server identity or Server identity stored in the repository option. If we select the Server identity stored in the repository option, enter the following information:
- Server user ID or administrative user on a Version 6.0.x node
- Specify the short name of the account chosen in the second step.
- Server user password
- Specify the password of the account chosen in the second step.
- (zos) Select either the Automatically generated server identity or User identity for the z/OS started task.
- (iseries) Enter a valid user profile name in the Primary administrative user name field.
The Primary administrative user name specifies the user profile to use when the server authenticates to the underlying operating system. This identity is also the user that has initial authority to access the administrative application through the console. The admin ID is common to all user registries. The administrative ID is a member of the chosen registry and it has special privileges in WebSphere Application Server. However, it does not have any special privileges in the registry that it represents. In other words, we can select any valid user ID in the registry to use as the admin ID or server user ID.
For the Primary administrative user name field, we can specify any user profile that meets this criteria:
- The user profile has a status of *ENABLED.
- The user profile has a valid password.
- The user profile is not used as a group profile.
Important: A group profile is assigned a unique group ID number, which is not assigned to a regular user profile. Run the DSPUSRPRF Display User Profile command to determine if the user profile to use as the Primary administrative user name has a defined group ID number. If the Group ID field is set to *NONE, we can use the user profile as the Primary administrative user name.
- (zos) Optional: Enable and configure SAF authorization.
- Click Security > Global security > External authorization provider.
- Select the System Authorization Facility (SAF) authorization option to enable SAF as the authorization provider.
- Under Related items, click z/OS SAF authorization to configure SAF authorization. To see an explanation of the SAF authorization options, see z/OS System Authorization Facility authorization.
- 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 Global security panel. First, make sure selected 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 Global security panel and click OK or Apply to validate the changes. If the changes are not validated, the server might not start.
Important: Until you authorize other users to perform administrative functions, we can only access the console with the server user ID and password that specified. For more information, see Authorizing access to administrative roles.
Results
For any changes in this panel to be effective, we need to save, stop, and start all the product servers, including deployment managers, nodes and application servers. If the server comes up without any problems, the setup is correct.
After completed these steps, we have configured WebSphere Application Server 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 Enable security.
Subtopics
- Local operating system registries
With the registry implementation for the local operating system, the WAS authentication mechanism can use the user accounts database of the local operating system.
- Configure user ID for proper privileges for local operating system registries
Use this page to configure a user ID for proper privileges or to log on as a service on the Windows platform.
- Local operating system settings
Use this page to configure local operating system registry settings.
- Local operating system wizard settings
Use this security wizard page to configure local operating system registry settings.
Related concepts
Standalone Lightweight Directory Access Protocol registries (zos) System Authorization Facility user registries
(zos) System Authorization Facility considerations for the operating system and application levels
Related tasks
Select a registry or repository Enable security (zos) Controlling access to console users when using a Local OS Registry
Authorizing access to administrative roles
(zos) z/OS System Authorization Facility authorization