InfoCenter Home >
5: Securing applications -- special topics >
5.1: The WebSphere security components >
5.1.5 Using Windows NT or Windows 2000 with Local authorization

5.1.5 Using Windows NT or Windows 2000 with Local authorization

When enabling security on Windows NT or Windows 2000 systems, if Local Operating System (LocalOS) is selected as the authentication mechanism, keep the following in mind:

  • WebSphere Application Server dynamically determines whether the machine is a member of a Windows domain.
  • WebSphere Application Server does not support Windows NT trusted domains.
  • If a machine is a member of a Windows domain, both the domain user registry and the machine's local user registry participate in authentication and security role mapping.
  • The domain user registry takes precedence over the machine's local user registry and may have undesirable implications if users with the same password exist in both user registries.

When LocalOS is selected as the authentication mechanism, the user registry used for authentication depends on whether the machine is a member of a Windows domain. When WebSphere is started, the security runtime initialization process dynamically attempts to determine if the local machine is a member of a Windows domain. WebSphere Application Server relies on the Windows computer browser service to help determine which domain the machine is a member of.

If the machine is not a member of a Windows domain, the user registry local to that machine is used for authentication.

If the machine is a member of a Windows domain, both the domain user registry and the local user registry can be used for authorization. The Windows domain registry is used for authentication first. If the user cannot be authenticated there, authentication will be attempted at the machine's local user registry.

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 WebSpere Application Server during the authorization check. However, the local user registry is used for role assignment. The domain security ID will not match the unique security ID associated with the role. To avoid this problem, map security roles to domain users instead of local users.

Go to previous article: Delegation model Go to next article: Operating environment

 

 
Go to previous article: Delegation model Go to next article: Operating environment