WebSphere Application Server - Express, Version 6.0.x     Operating Systems: AIX, HP-UX, Linux, Solaris, Windows

Local operating system user registries

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.

A local OS user registry is not a centralized user registry like LDAP.

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 Lightweight Directory Access Protocol (LDAP) user registry implementation discussed later.
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 20003 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.

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.

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.

Exceptions include a Windows domain registry, which is a centralized registry and Network Information Services (NIS), which is not supported by WebSphere Application Server.

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.

Even though Java client certificates function correctly, the following error displays in the SystemOut.log file:

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.

Using Windows operating system user registries

When enabling security on Windows operating systems, if the local operating system (Local OS) is selected as the user registry, consider the following points:

Required privileges

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 stand-alone machine or a machine that is part of a domain or is the domain controller, the access requirements vary.

  • For a stand-alone machine, the user:
    • Is a member of the administrative group.
    • Has the Act as part of the operating system privilege.
    • Has the Log on as a service privilege, if the server is run as a service.
  • For a machine that is a member of a domain, only a domain user can start the server process and:
    • Is a member of the domain administrative groups in the domain controller.
    • Has the Act as part of the operating system privilege in the Domain security policy on the domain controller.
    • Has the Act as part of the operating system privilege in the Local security policy on the local machine.
    • Has the Log on as a service privilege on the local machine, if the server is run as a service.

      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.

  • For a domain controller machine, the user:
    • Is a member of the domain administrative groups in the domain controller.
    • Has the Act as part of the operating system privilege in the Domain security policy on the domain controller.
    • Has the Log on as a service privilege on the domain controller, if the server is run as a service.
To give a user the Act as part of the operating system or Log on as a service on Windows 2000 systems:
  1. Click Start > Settings > Control Panel > Administrative Tools > Local Security Policy > Local Policies > User Rights Assignments > Act as part of the operating system (or Log on as a service) .
    Note: If the machine is a stand-alone machine and not a member of a domain, you must add a machineName\userID, where the userID is the owner of the process, such as WebSphere Application Server. If you run WebSphere Application Server as a service, you can log on with localsystem as the service.

    If the machine is a member of a domain, add domainName\userID, where the userID is the owner of process (such as WebSphere Application Server). Start WebSphere Application Server as a service with login ID domainName\userID. If WebSphere Application Server is already in service, go to the service and right-click IBM WebSphere Application Server > properties >Logon to change the logon ID and password to restart WebSphere Application Server.

  2. Add the user name by clicking Add.
  3. Restart the machine.

    Windows 2000 domain controller users: For a Windows 2000 domain controller, replace Local Security Policy with Domain Security Policy in the previous step.

    Note: In all of the previous configurations, the server can be run as a service using LocalSystem for the Log On As entry. The LocalSystem entry has the required privileges and there is no need to give special privileges to any user. However, because the LocalSystem entry has special privileges, make sure that it is appropriate to use in your environment.
If the user running the server does not have the required privilege, you might see one of the following exception messages in the log files:
  • A required privilege is not held by the client.
  • Access is denied.

Domain and local user registries

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.

Using both the domain user registry and the local user 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, "Using both the domain registry and local registry" 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.

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 localor 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.

Using UNIX system user registries

When using UNIX system user registries, the process ID that runs the WebSphere Application Server process needs the root authority to call the local operating system APIs for authentication and for obtaining user or group information.
Note: In UNIX systems, only the local machine user registry is used. Network Information Service (NIS) (Yellow Pages) is not supported.

Using Linux and Solaris system user registries

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.

Remote user registries

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 using Local OS as the user registry, every product process must run with privilege access.

[UNIX][Windows]For example, root in UNIX and Act as part of operating system in Windows systems.

If this process is not practical, you can use a remote user registry from the node or from a cell. Be aware that using a remote user registry affects performance and potentially creates a single point of failure.
Tip: Use remote user registries only in rare situations.

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.

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.




Related reference
Simple WebSphere authentication mechanism
Custom user registries

Concept topic    

Terms of Use | Feedback

Last updated: Jun 8, 2005 12:45:23 PM EDT
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/csec_localos.html

© Copyright IBM Corporation 2002, 2005. All Rights Reserved.
This information center is powered by Eclipse technology. (http://www.eclipse.org)