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.
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.
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. 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.
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.
The
following steps are needed to perform this task initially when setting
up security for the first time.
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.