User Authentication with DB2 for Windows NT User 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 Restrictions The following are the limitations in this environment: User names are limited to 30 characters within DB2 Group names are limited to 8 characters User names under Windows NT are not case sensitive; however, passwords are case sensitive User names and group names can be a combination of upper- and lowercase characters However, they are usually converted to uppercase when used within DB2 For example, if you connect to the database and create the table schema1.table1, this table is stored as SCHEMA1.TABLE1 within the database (If you wish to use lowercase object names, issue commands from the command line processor, enclosing the object names in quotation marks, or use third-party ODBC front-end tools.) A user cannot belong to more than 64 groups DB2 supports a single namespace That is, when running in a trusted domains environment, you should not have a user account of the same name that exists in multiple domains or that exists in the local SAM of the server machine and in another domain Groups and User Authentication on Windows NT Users 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 Local groups A local group can include user accounts created in the local accounts database If the local group is on a machine that is part of a domain, the local group can also contain domain accounts and groups from the Windows NT domain If the local group is created on a workstation, it is specific to that workstation Global groups A global group exists only on a domain controller and contains user accounts from the domain's SAM database That is, a global group can contain only user accounts from the domain on which it is created; it cannot contain any other groups as members A global group can be used in servers and workstations of its own domain and in trusting domains 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 NT Trust 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: The trusting domain This domain trusts another domain to authenticate users for them The trusted domain This domain authenticates users on behalf of (in trust for) another domain 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 Service In 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 Controller In 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: The DB2 for Windows NT server is installed on the BDC The DB2DMNBCKCTLR profile registry variable is set appropriately 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: The cachedPrimaryDomain is a registry value set to the name of the domain to which this machine belongs (You can find this setting under HKEY_LOCAL_MACHINE, Software, Microsoft, Windows NT, Current Version, WinLogon.) The Server Manager shows the BDC as active and available The registry for the DB2 Windows NT server indicates that the system is a BDC on the specified domain 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: The machine is configured as a BDC for the specified domain (If the machine is set up as a BDC for another domain, this setting will result in an error.) DB2 for Windows NT Authentication with Groups and Domain Security DB2 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: Local groups Global groups Global groups as members of local 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 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: DB2 first tries to find the user on the same machine If the user name is defined locally, the user is authenticated locally If the user is not found locally, DB2 attempts to find the user name on its domain, then on trusted domains 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: A BDC is found when the PDC is unavailable A BDC is found that is close when the PDC is geographically remote ... commands: For global settings: db2set g DB2_ GRP_LOOKUP=local For instance settings: db2set i DB2_ GRP_LOOKUP=local After issuing this command, you must stop and start the DB2 instance for the change to take effect... 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... The machine is configured as a BDC for the specified domain (If the machine is set up as a BDC for another domain, this setting will result in an error.) DB2 for Windows NT Authentication with Groups and Domain Security DB2 UDB allows you to specify either a local group or a global