Configure local operating system user registries
Overview
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 APIs are called by WAS 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.
Before configuring the LocalOS registry you need to know the user name (ID) and password to use here. This user can be any valid user in the registry. This user is referred to as either a product security server ID, a server ID or a server user ID in the documentation. Having a server ID means that a user has special privileges when calling protected internal methods. Normally, this ID and password are used to log into the administrative console after security is turned on. You can use other users to log in if those users are part of the administrative roles.
When security is enabled in WAS, this server ID and password are authenticated with the registry during product startup. If authentication fails, the server does not come up. So it is important to choose an ID and password that do not expire or change often. If WAS server user ID or password need to change in the registry, ensure that the changes are performed when all WAS servers are up and running. After the changes are completed in the registry, use the following steps to change the ID and the password information. Save, stop, and restart all the servers so that WAS can use the new ID or password. If any problem arises after starting WAS because of authentication problems (that cannot be fixed), disable security before the server can start up. To avoid this step, make sure that the changes are validated in the Global Security panel. After the server is up, change the ID and password information and enable security.
When using the Windows operating system, consider the following issues:
- The server ID needs to be different from the Windows machine name where WAS is installed. For example, if the Windows machine name is vicky and the security server ID is vicky, 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 WAS 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 WAS process) or the Log On User setting in the services panel if WAS 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.
When using the UNIX operating systems (AIX and Solaris) and Linux, consider the following points:
- The user that WAS processes run under requires the root privilege. This privilege is needed to call the UNIX 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 may 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 WAS processes.
- When using the Linux operating system, 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.
Steps for this task
- Enter a valid user name in the Server User ID field.
- Enter the user password in the Server User Password field.
- Click OK. Validation of the user and password does not happen in this panel. Validation is only done when you click OK or Apply in the Global Security panel. If you are enabling security for the first time, complete the other steps and go to the Global Security panel. Make sure that LocalOS is the Active User Registry. 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 your changes. If your changes are not validated, the server might not come up.
Results
The Local OS user registry has been configured.
What to do next
- If you are enabling security, complete the remaining steps. As the final step, ensure that you validate the user and password by clicking OK or Apply in the Global Security panel. Save, stop, and start all WAS servers.
- For any changes in this panel to be effective, you need to save, stop and start all WAS servers (deployment managers, nodes and Application Servers).
- If the server comes up without any problems the setup is correct.
Local operating system user registries
Lightweight Directory Access Protocol
Configuring global security
Custom user registries
Local operating system user registry settings