Local operating system registries

 

+

Search Tips   |   Advanced Search

 

With the registry implementation for the local operating system, the WAS (WAS) authentication mechanism can use the user accounts database of the local operating system.

LDAP is a centralized registry. Most local operating system registries are not centralized registries.

WAS provides implementations for...

Windows Active Directory is supported through the LDAP user registry implementation.

for an Active Directory (domain controller), the three group scopes are...

For an Active Directory (Domain Controller), the two group types are...

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, WAS only supports Global groups that are the Security type.

IBM recommends 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.

WAS 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 operating system registry in a WAS environment where appservers 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...

...are centralized registries.

The Windows domain registry is supported by WAS.

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.

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.

 

Required privileges

The user that is running the WAS process requires enough operating system privilege to call the Windows systems 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.

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:

 

Domain and local user registries

When WAS 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.

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

 

Use both the domain user registry and the local operating system registry

When the machine that hosts the WAS 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.

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.

 

Use either the local or the domain user registry

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 console:

  1. Click...

    Security | Secure administration, applications, and infrastructure | User account repository | Available realm definitions drop-down list | Local operating system | Configure | Additional properties | 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.

 

Use UNIX system user registries

[AIX HP-UX Solaris]

When using UNIX system user registries, the process ID that runs the WAS process needs the root authority to call the local operating system APIs for authentication and for obtaining user or group information.

In UNIX systems, only the local machine user registry is used. Network Information Service (NIS) (Yellow Pages) is not supported. [HP-UX]

If you are using the local operating system user registry, HP-UX must be configured in untrusted mode. Trusted mode is not supported if using the local operating system user registry.

 

Use Linux and Solaris system user registries [Linux] [Solaris]

For WAS local operating system 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 administrative security and configuring the registry as local operating system.

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.


 

Related concepts

User registries and repositories