With the user registry implementation for the local operating system, the WebSphere Application Server authentication mechanism can use the user accounts database of the local operating system.
Lightweight
Directory Access Protocol (LDAP) is a centralized registry. Most local
operating system user registries are not centralized registries.
WebSphere
Application Server provides implementations for the Windows local
accounts registry and domain registry, as well as implementations
for the Linux, Solaris, and AIX user accounts registries. Windows
Active Directory is supported through the LDAP user registry implementation
discussed later.
Do
not use a Local OS user registry in a WebSphere Application Server
environment where application servers are dispersed across more than
one machine because each machine has its own user registry.
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.
As
mentioned previously, the access IDs taken from the user registry
are used during authorization checks. Because these IDs are typically
unique identifiers, they vary from machine to machine, even if the
exact users and passwords exist on each machine.
Web
client certificate authentication is not currently supported when
using the local operating system user registry. However, Java client
certificate authentication does function with a local operating user
registry. Java client certificate authentication maps the first attribute
of the certificate domain name to the user ID in the user registry.
CWSCJ0337E: The mapCertificate method is not supported
The error is intended for Web client certificates; however, it also displays for Java client certificates. Ignore this error for Java client certificates. A local
OS user registry is a centralized registry within a sysplex.
WebSphere
Application Server uses the System Authorization Facility (SAF) interfaces.
SAF interfaces are defined by MVS to enable applications to use system
authorization services or user registries to control access to resources
such as data sets and MVS commands. SAF allows security authorization
requests to be processed directly through the Resource Access Control
Facility (RACF) or a third party z/OS security provider. You must
provide a mapping from a user registry identity to a SAF user ID unless
you select local operating system as the user registry. For more information,
see Custom System Authorization Facility mapping modules.
Web client
certificate authentication is supported when using the local operating
system user registry. Digital certificates can be mapped to MVS identities
by both Web and Java clients when you select Local OS. A certificate
name filter can be used to simplify the mapping. If you are using
RACF as the security server, the RACDCERT MAP command creates
a resource profile that maps multiple user identities to a digital
certificate to simplify administration of certificates, conserve storage
space in the RACF database, maintain accountability, or maintain access
control granularity.
The user that is running the WebSphere Application Server process requires enough operating system privilege to call the Windows systems application programming interface (API) for authenticating and obtaining user and group information from the Windows operating system. This user logs into the machine, or if running as a service, is the Log On As user. Depending on the machine and whether the machine is a standalone machine or a machine that is part of a domain or is the domain controller, the access requirements vary.
The user is a domain user and not a local user, which implies that when a machine is part of a domain, only a domain user can start the server.
When WebSphere Application Server is started, the security run-time initialization process dynamically attempts to determine if the local machine is a member of a Windows domain. If the machine is part of a domain then by default both the local registry users or groups and the domain registry users or groups can be used for authentication and authorization purposes with the domain registry taking precedence. The list of users and groups that is presented during the security role mapping includes users and groups from both the local user registry and the domain user registry. The users and groups can be distinguished by the associated host names.
WebSphere Application Server does not support trusted domains.
If the machine is not a member of a Windows system domain, the user registry local to that machine is used.
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.
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.
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.
Only a centralized repository can be used if more than one node is involved. This usage implies that only the domain user registry can be used because the user and group unique IDs (SIDs) differ on various nodes, as previously mentioned.
. 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 clicking Custom Properties in the Security > User Registries > Local OS panel in the administrative console or by using scripts. 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.
For WebSphere
Application Server Local OS security user registry to work on the
Linux and Solaris platforms, a shadow password file must exist. The
shadow password file is named shadow and is located in the /etc directory.
If the shadow password file does not exist, an error occurs after
enabling global security
and configuring the user registry as Local OS.
To create the shadow file, run the pwconv command (with no parameters). This command creates an /etc/shadow file from the /etc/passwd file. After creating the shadow file, you can enable local operating system security successfully.
By default, the user registry is local to all of the product processes. The performance is higher because there is no need for remote calls and the user registry also increases availability. Any failing process does not effect other processes.
When
you use Local OS as the user registry, every product process must
run with privilege access.
For example, root in
UNIX and Act as part of operating system in Windows systems.
When using
Local OS as the user registry, every product process must run with
privilege access.
The node and the cell processes are meant for manipulating configuration information and for hosting the user registry for all the application servers that create traffic and cause problems.
Use remote
registries only when a very limited number of application servers
exist in a Network Deployment environment.
Using a node agent instead of the cell to host the remote user registry is preferable because the cell process is not designed to be highly available. Using a node to host the remote user registry indicates that only the application servers in that node are using it. Because the node agent does not contain any application code, giving it the access required privilege is not a concern.
You can set up a remote user registry by setting the WAS_UseRemoteRegistry property in the Global Security panel using the Custom Properties link at the bottom of the administrative console panel. Use either the Cell or the Node case insensitive value. If the value is Cell, the cell user registry is used by all of the product processes including the node agent and all of the application servers. If the cell process is down for any reason, restart all of the processes after the cell is restarted. If the node agent user registry is used for the remote user registry, set the WAS_UseRemoteRegistry value to node. In this case, all the application server processes use the node agent user registry. In this case, if the node agent fails and does not start automatically, you might need to restart all the application servers after the node agent is started.