User authentication can cause problems for Windows NT users because of the way the operating system authenticates. This section describes some considerations for user authentication under DB2 for Windows NT:
The following are the limitations in this environment:
In DB2 Universal Database we have integrated the authentication of user names and passwords into the DB2 System Controller. The Security Service is only required when connected a client to a server that is configured for authentication CLIENT.
In a Windows NT environment a user can be authenticated at either a primary or a backup controller. This feature is very important in large distributed LANs with one central primary domain controller and one or more backup domain controllers (BDC) at each site. Users can then be authenticated on the backup domain controller at their site instead of requiring a call to the primary domain controller (PDC) for authentication.
The advantage of having a backup domain controller, in this case, is that users are authenticated faster and the LAN is not as congested as it would have been had there been no BDC.
Authentication can occur at the BDC under the following conditions:
If the DB2DMNBCKCTLR profile registry variable is not set or is set to blank, DB2 for Windows NT performs authentication at the primary domain controller.
The only valid declared settings for DB2DMNBCKCTLR are "?" or a domain name.
If the DB2DMNBCKCTLR profile registry variable is set to a question mark (DB2DMNBCKCTLR=?) then DB2 for Windows NT will perform its authentication on the backup domain controller under the following conditions:
Under normal circumstances the setting DB2DMNBCKCTLR=? will work; however, it will not work in all environments. The information supplied about the servers on the domain is dynamic, and Computer Browser must be running to keep this information accurate and current. Large LANs may not be running Computer Browser and therefore Server Manager's information may not be current. In this case, there is a second method to tell DB2 for Windows NT to authenticate at the backup domain controller: set DB2DMNBCKCTLR=xxx where xxx is the Windows NT domain name for the DB2 server. With this setting, authentication will occur on the backup domain controller based on the following conditions:
DB2 for Windows NT supports the following types of groups:
DB2 for Windows NT enumerates the local and global groups that the user is a member of, using the security database where the user was found. DB2 Universal Database provides an override that forces group enumeration to occur on the local Windows NT server where DB2 is installed, regardless of where the user account was found. This override can be achieved using the following commands:
db2set -g DB2_GROUP_LOOKUP=local
db2set -i DB2_GROUP_LOOKUP=local
To view all DB2 profile variables that are set, type
db2set -all
For DB2 for Windows NT to work with domain security, you must grant authority and privileges to a local group. User names within the local and global groups MUST be defined on the same domain as the local or global group in order to be authenticated correctly.
If the DB2_GRP_LOOKUP profile registry variable is set to local, then DB2 tries to find a user on the local machine only. If the user is not found on the local machine, or is not defined as a member of a local or global group, then authentication fails. DB2 does not try to find the user on another machine in the domain or on the domain controllers.
If the DB2_GRP_LOOKUP profile registry variable is not set then:
The following examples illustrate how DB2 for Windows NT can support domain security. In this first example, the connection works because the user name and local group are on the same domain. In the second example, the connection does not work because the user name and local or global group are on different domains.
Example of a Successful Connection: The connection works in the following scenario because the user name and local or global group are on the same domain.
Note that the user name and local or global group do not need to be defined
on the domain where the database server is running, but they must be on the
same domain as each other.
Table 96. Successful connection using a domain controller
| Domain1 | Domain2 |
|---|---|
| A trust relationship exists with Domain2. |
|
The DB2 server runs in this domain. The following DB2 commands are
issued from it:
REVOKE CONNECT ON db FROM public GRANT CONNECT ON db TO GROUP grp2 CONNECT TO db USER id2 | |
| The local or global domain is scanned but id2 is not found. Domain security is scanned. | |
| The user name id2 is found on this domain. DB2 gets additional information about this user name (that is, it is part of the group grp2). | |
| The connection works because the user name and local or global group are on the same domain. |
Example of an Unsuccessful Connection: The connection does
not work in the following scenario because the user name is defined on a
different domain than where the local or global group is defined.
Table 97. Unsuccessful connection using a domain controller
| Domain1 | Domain2 |
|---|---|
| A trust relationship exists with Domain2. |
|
| |
| Domain1\grp1 is part of grp2. | |
The DB2 server runs in this domain. The following DB2 commands are
issued from it:
REVOKE CONNECT ON db FROM public GRANT CONNECT ON db TO GROUP grp2 CONNECT TO db USER id2 | |
| The local or global is scanned and id1 is found. DB2 gets information for this user name (that is, the user name id1 is part of grp1 and the group grp1 is part of Domain2\grp2). | |
| The group grp2 exists on this domain. | |
| The connection does not work because the local or global group is on
Domain2 and the actual user name is defined on Domain1.
The connection would work if the following command was issue instead: GRANT CONNECT ON db TO GROUP grp1 |