Configuring local operating system user registries

Use these steps to configure local operating system user registries.

Before you begin

For detailed information about using the local operating system user registry, see Local operating system user registries. These steps set up security based on the local operating system user registry on which WebSphere Application Server is installed.

[AIX HP-UX Linux Solaris Windows] For security purposes, the WebSphere Application Server provides and supports the implementation for Windows operating system registries, AIX, Solaris and multiple versions of Linux operating systems. The respective operating system application programming interface (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.

[AIX HP-UX Linux Solaris Windows] Before configuring the Local OS user registry you need to know the user name (ID) and password to use. This user can be any valid user in the user 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, this server ID and password are authenticated with the user 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 the product server user ID or password need to change in the user registry, ensure that the changes are performed when all the product servers are up and running. After the changes are completed in the user registry, use the following steps to change the ID and the password information. Save, stop, and restart all the servers so that the product can use the new ID or password. If any problem arises after starting the product 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.

[z/OS] When a local OS user 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.

[z/OS] Important: Each started task, for example, a controller, servant, or node agent might have a different identity. The z/OS customization dialog sets up these identities. See the z/OS customization dialog for more information.
[Windows] [AIX HP-UX Linux Solaris Windows] 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.
  • WebSphere Application Server 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.
[AIX HP-UX Linux Solaris Windows] Consider the following points:
  • [AIX] [AIX HP-UX Solaris] [Solaris] 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.
  • [AIX HP-UX Solaris] The user that enables global security must have the root privilege if you use the local OS user registry. Otherwise, a failed validation error is displayed.
  • [Linux] You might need to have the password shadow file in your system.

About this task

[z/OS] 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 that are associated with the local OS user registry and SAF configuration.

[z/OS] Important: The local operating system is not a valid user account repository when you have a mixed cell environment that includes both z/OS platform and non-z/OS platform nodes.

[AIX HP-UX Linux Solaris Windows] The following steps are needed to perform this task initially when setting up security for the first time.

Procedure

  1. Click Security > Global security.
  2. Under user registries, click Local OS.
  3. [AIX HP-UX Linux Solaris Windows] Enter a valid user name in the Server user ID field.
  4. [AIX HP-UX Linux Solaris Windows] Enter the user password in the Server user password field.
  5. 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.
  6. [z/OS] Optional: Click z/OS SAF properties under additional properties to specify the MVS user ID that is used to represent unprotected servlet requests.
  7. [z/OS] Optional: Click the Authorization option to use SAF EJBROLE profiles for user to role authorization.
  8. [z/OS] Optional: Return to the configuration panel for the local OS user registry. To return to the configuration panel for the local OS user registry, complete the first two steps for this task.
  9. [z/OS] Under Additional properties, click Custom properties. You can configure the following custom properties for the local OS user registry:
    com.ibm.security.SAF.unauthenticated
    This property indicates the MVS user ID that is used to represent unprotected servlet requests and is used for the following functions:
    • Authorization, if an unprotected servlet invokes an entity bean.
    • Identification of an unprotected servlet for invoking a z/OS connector (Customer Information Control System (CICS), Information Management System (IMS)) that uses a current identity when res-auth=container.
    com.ibm.security.SAF.authorization
    This property can be set to true or false. When this property is set to true, SAF EJBROLE profiles are used for user-to-role authorization for both Java 2 Platform, Enterprise Edition (J2EE) applications and the role-based authorization requests (naming and administration) that are associated with the WebSphere Application Server run time.
    com.ibm.security.SAF.delegation
    This property specifies that SAF EJBROLE definitions are assigned the MVS user ID that becomes the active identity when you select the RunAs specified role.
    com.ibm.security.SAF.EJBROLE.Audit.Messages.Suppress
    With this property, you can turn ICH408I messages on or off. The default value for this property is false, which does not suppress messages. You can set this value to true to suppress the ICH408I messages.
    System Management Facility (SMF) records access violations no matter what value is specified for this new property. This property affects access violation message generation for both application-defined roles and for WebSphere Application Server run-time-defined roles for the naming and administrative subsystems. EJBROLE profile checks are done for both declarative and programmatic checks:
    • Declarative checks are coded as security constraints in Web applications, and deployment descriptors are coded as security constraints in Enterprise JavaBeans (EJB) files. This property is not used to control messages in this case. Instead, a set of roles is permitted, and if an access violation occurs, an ICH408I access violation message indicates a failure for one of the roles. SMF then logs a single access violation for that role.
    • Program logic checks or access checks are performed using the programmatic isCallerinRole(x) for enterprise beans or isUserInRole(x) for Web applications. The com.ibm.security.SAF.EJBROLE.Audit.Messages.Suppress property controls the messages generated by this call.

    For more information on SAF authorization, refer toControlling access to console users when using a Local OS Registry. For more information on administrative roles, refer to Administrative roles.

  10. Click OK.

    The administrative 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. If you are enabling security for the first time, complete the other steps and navigate to the Global Security panel. Make sure that Local OS is selected as 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 start.

    Important: Until you authorize other users to perform administrative functions, you can only access the administrative 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, you 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, you have configured WebSphere Application Server to use the local OS user registry to identify authorized users.

What to do next

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




In this information ...


IBM Redbooks, demos, education, and more

(Index)

Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience.

This feature requires Internet access.

Task topic    

Terms of Use | Feedback

Last updated: Sep 20, 2010 11:08:29 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=vela&product=was-nd-mp&topic=tseclocalos
File name: tsec_localos.html