User Authentication with DB2 for Windows NTUser authentication can cause problems for Windows NT users because of the way the operating system authenticates. DB2 for Windows NT User Name and Group Name RestrictionsThe following are the limitations in this environment:
Groups and User Authentication on Windows NTUsers are defined on Windows NT by creating user accounts using the Windows NT administration tool called the User Manager. An account that contains other accounts, also called members , is a group. Groups give Windows NT administrators the ability to grant rights and permissions to the users within the group at the same time, without having to maintain each user individually. Groups, like user accounts, are defined and maintained in the SAM database. There are two types of groups: local and global.
The PDC holds the SAM for the domain. This SAM is replicated to any BDCs in the domain. Domain controllers do not have a local SAM database. They hold user and group data for the domain. In this sense, any groups created on the PDC, local or global, are domain groups. Windows NT machines that are not domain controllers (NT Workstations and some NT servers) will each have their own SAM databases. User accounts and groups created on those machines are local to that machine. There is no Create Global Group option on machines that are not domain controllers. Trust Relationships Between Domains on Windows NTTrust relationships are an administration and communication link between two domains. A trust relationship between two domains enables user accounts and global groups to be used in a domain other than the domain where the accounts are defined. Account information is shared to validate the rights and permissions of user accounts and global groups residing in the trusted domain without being authenticated. Trust relationships simplify user administration by combining two or more domains into a single administrative unit. There are two domains in a trust relationship:
Trust relationships are not transitive. This means that explicit trust relationships need to be established in each direction between domains. For example, the trusting domain may not necessarily be a trusted domain. DB2 for Windows NT Security ServiceIn DB2 UDB, we have integrated the authentication of user names and passwords into the DB2 System Controller. The Security Service is required only when a client is connected to a server that is configured for authentication CLIENT. Installing DB2 on a Backup Domain ControllerIn a Windows NT 4.0 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 PDC and one or more BDCs at each site. Users can then be authenticated on the BDC at their site instead of requiring a call to the 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 PDC. 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 BDC 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 BDC: db2set DB2DMNBCKCTLR= xxx where xxx is the Windows NT domain name for the DB2 server. With this setting, authentication will occur on the BDC, based on the following conditions:
DB2 for Windows NT Authentication with Groups and Domain SecurityDB2 UDB allows you to specify either a local group or a global group when granting privileges or defining authority levels. A user is determined to be a member of a group if the user's account is defined explicitly in the local or global group, or implicitly by being a member of a global group defined to be a member of a local group. 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 UDB 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: For global settings: db2set g DB2_GRP_LOOKUP=local For instance settings: db2set i <instance name> DB2_GRP_LOOKUP=local After issuing this command, you must stop and start the DB2 instance for the change to take effect. Then create local groups and include domain accounts or global groups in the local group. To view all DB2 profile registry variables that are set, type: db2set all 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:
If DB2 is running on a machine that is a PDC or BDC in the resource domain, it is able to locate any domain controller in any trusted domain. This occurs because the names of the domains of BDCs in trusted domains are known only to a domain controller. If DB2 is not running on a domain controller, you should issue: db2set g DB2_GRP_LOOKUP=DOMAIN This command tells DB2 to use a domain controller in its own domain to find the name of a domain controller in the accounts domain. That is, when DB2 finds out that a particular user account is defined in domain x , rather than attempting to locate a domain controller for domain x , it sends that request to a domain controller in its own domain. The name of the domain controller in the account domain will be found and returned to the machine DB2 is running on. There are two advantages to this method:
|