With the registry implementation for the local operating
system, the WebSphere® Application Server authentication
mechanism can use the user accounts database of the local operating
system.
Note: For an Active Directory (domain controller),
the three group scopes are Domain Local Group, Global Group, and Universal
Group. For an Active Directory (Domain Controller), the two group
types are Security and Distribution.
When a group is created,
the default value is Global and the default type is Security. With Windows NT
® domain registry support for Windows
® 2000 and 2003 domain controllers, WebSphere Application Server only supports
Global groups that are the Security type. It is recommended that you
use the Active Directory registry support rather than a Windows NT domain registry if you use Windows 2000 and 2003 domain controllers
because the Active Directory supports all group scopes and types.
The Active Directory also supports a nested group that is not support
by Windows NT domain registry. The Active
Directory is a centralized control registry.
Note: WebSphere Application
Server does not have to install the member of the domain because it
can be installed on any machine on any platform. Note that the Windows NT domain native call returns
the support group only without an error.
The Windows domain
registry and Network Information Services (NIS) are exceptions. Both
the Windows domain registry and Network Information
Services (NIS) are centralized registries. The Windows domain
registry is supported by WebSphere Application Server;
however, NIS is not supported.
Using both the
domain user registry and the local operating system registry
When
the machine that hosts the WebSphere Application Server
process is a member of a domain, both the local and the domain user
registries are used by default. The following section describes more
on this topic and recommends some best practices to avoid unfavorable
consequences.
Note: Although this section does not directly describe z/OS® considerations,
you should be aware that overall security operations are affected
by how well you set up these registries.
- Best practices
In general, if the local and the domain
registries do not contain common users or groups, it is simpler to
administer and it eliminates unfavorable side effects. If possible,
give users and groups access to unique security roles, including the
server ID and administrative roles. In this situation, select the
users and groups from either the local user registry or the domain
user registry to map to the roles.
In cases where the same users
or groups exist in both the local user registry and the domain user
registry, it is recommended that at least the server ID and the users
and groups that are mapped to the administrative roles be unique in
the registries and exist only in the domain.
If a common set
of users exists, set a different password to make sure that the appropriate
user is authenticated.
- How it works
When a machine is part of a domain, the
domain user registry takes precedence over the local user registry.
For example, when a user logs into the system, the domain user registry
tries to authenticate the user first. If authentication fails, the
local user registry is used. When a user or a group is mapped to a
role, the user and group information is first obtained from the domain
user registry. In case of failure, the local user registry is tried.
However,
when a fully qualified user or a group name, one with an attached
domain or host name, is mapped to a role, only that user registry
is used to get the information. Use the administrative console or
scripts to get the fully qualified user and group names, which is
the recommended way to map users and groups to roles.
Tip: A
user, Bob, on one machine in the local OS user registry,
for example, is not the same as the user Bob on another machine
in the domain user registry, for example, because the unique ID of Bob,
which is the security identifier [SID] in this case, is different
in different user registries.
- Examples
The
MyMachine machine is part of the
MyDomain domain.
The
MyMachine machine contains the following users and groups:
- MyMachine\user2
- MyMachine\user3
- MyMachine\group2
The
MyDomain domain contains the following users
and groups:
- MyDomain\user1
- MyDomain\user2
- MyDomain\group1
- MyDomain\group2
Here are some scenarios that assume the previous set
of users and groups:
- When user2 logs into the system, the domain user registry
is used for authentication. If the authentication fails because the
password is different, for example, the local user registry is used.
- If the MyMachine\user2 user is mapped to a role, only
the user2 user in MyMachine machine has access.
Thus, if the user2 password is the same on both the local
and the domain user registries, the user2 user cannot access
the resource because the user2 user is always authenticated
using the domain user registry. If both user registries have common
users, it is recommended that you have different passwords.
- If the group2 group is mapped to a role, only the users
who are members of the MyDomain\group2 group can access the
resource because group2 information is first obtained from
the domain user registry.
- If the MyMachine\group2 group is mapped to a role, only
the users who are members of the MyMachine\group2 group can
access the resource. A specific group is mapped to the role (MyMachine\group2 instead
of just group2).
- Use either the user3 user or the MyMachine\user3 user
to map to a role because the user3 user is unique as it exists
in one user registry only.
Authorizing with the domain user registry first can cause
problems if a user exists in both the domain and local user registries
with the same password. Role-based authorization can fail in this
situation because the user is first authenticated within the domain
user registry. This authentication produces a unique domain security
ID that is used in WebSphere Application Server
during the authorization check. However, the local user registry is
used for role assignment. The domain security ID does not match the
unique security ID that is associated with the role. To avoid this
problem, map security roles to domain users instead of local users.
Using either the local or
the domain user registry
. If you want to access users and
groups from either the local or the domain user registry, instead
of both, set the com.ibm.websphere.registry.UseRegistry property.
This property can be set to either local or domain.
When this property is set to local (case insensitive) only
the local user registry is used. When this property is set to domain,
(case insensitive) only the domain user registry is used.
Set
this property by completing the following steps to access the
Custom
Properties panel in the administrative console:
- Click Security > Global security
- Under User account repository, click the Available realm definitions drop-down
list, select Local operating system, and click Configure.
- Under Additional properties, click Custom properties.
You can also use wsadmin to configure this property. When the
property is set, the privilege requirement for the user who is running
the product process does not change. For example, if this property
is set to
local, the user that is running the process requires
the same privilege, as if the property was not set.
Using system user registries
The following
notes apply when you use system user registries: