Use these steps to configure local
operating system registries.
Before you begin
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.
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 Solaris HP-UX Linux Windows]](../images/dist.gif)
In WebSphere Application Server Version 6.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.
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.
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.
![[Windows]](../images/windows.gif)
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
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.
- If you 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.
About this task
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.
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 Solaris HP-UX Linux Windows]](../images/dist.gif)
The
following steps are needed to perform this task initially when setting
up security for the first time.
Procedure
- Click Security > Global security.
- Under User account repository, select Local operating
system and click Configure.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
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 administrative console or used
by wsadmin.
If SAF authorization is not enabled, 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 administrative console or used by wsadmin.
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.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
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 Version 6.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.
Select either the Automatically generated
server identity or User identity for the z/OS started task.
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 administrative console. The administrative user 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, you can select any valid user
ID in the registry to use as the administrative user ID or server
user ID.
For the
Primary administrative user name field,
you 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 you want to
use as the Primary administrative user name has a defined group ID
number. If the Group ID field is set to *NONE, you
can use the user profile as the Primary administrative user name.
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 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. 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 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 operating system registry to identify authorized
users.
What to do next
Complete any remaining steps for enabling
security. For more information, see Enabling security.