Learning Visually with Examples [Electronic resources] نسخه متنی

10.7. Windows Domain Considerations

In almost all production environments, database administrators group users together and grant certain privileges or database authorities to those groups. As you can imagine, this is more efficient than maintaining privileges for each individual user. Given that DB2 does not maintain any user and group authentication information, it is important to understand how the groups are being looked up for the users. Windows domain environments in particular have different types of user groups that warrant some discussion.

10.7.1. Windows Global Groups and Local Groups

For example, a DB2 server is defined on the Windows domain MMDOM, and within the domain, a domain controller is a server that maintains a master database of all the domain users' credentials. It is also used to authenticate domain logons. In Figure 10.37 you can see that a user ID

db2admin is a member of global group MMDBA in the domain MMDOM. To use global groups, you must include them inside a local group on the DB2 server. When DB2 enumerates all the groups that a person is a member of, it also lists the local groups the user is a member of indirectly. Permission to access the database and/or object must be granted to this local group.

Figure 10.38 shows a second scenario, where the same user ID,

db2admin , is also defined locally at the DB2 server and is a member of a local group called DB2DBA.

A user connects to the database as

db2admin and tries to drop a table. Which group do you want DB2 to enumerate for

db2admin ? It is important for DB2 to enumerate the right group because local group DB2DBA might only hold SELECT privileges on the table, whereas the global group MMDBA has SYSADM authority.

The first option is to include the Windows domain with the user ID during authentication, such as in the

CONNECT statement or the

attach command. The fully qualified DB2 authentication ID can be as long as 30 characters. This makes group lookup on Windows more deterministic.

CONNECT TO sample USER mmdba/db2admin USING password 

Note that the fully qualified authentication ID also works in

GRANT and

REVOKE statements. For example:

GRANT SELECT ON TABLE employee TO USER mmdba/db2admin 

Alternatively, use the DB2 registry variable DB2_GRP_LOOKUP to tell DB2 where to validate user accounts and perform group member lookup. Set the variable to LOCAL to force DB2 to always enumerate groups and validate user accounts locally on the DB2 server. Set the variable to DOMAIN to force DB2 to always enumerate groups and validate user accounts on the Windows domain to which the user account belongs. For example:

db2set DB2_GRP_LOOKUP = DOMAIN 

10.7.2. Access Tokens

If a user wants to log onto his or her laptop as a domain user in a disconnected environment, Windows supports this via cached credentials. When a credential is cached, information kept from the last logon is referenced if the machine cannot contact the domain controller. DB2 supports this behavior by using an access token.

An access token is created after a user has successfully logged on to the system. The token is an object that describes the security context of a process or thread. The information in an access token includes the identity, all of the groups the user belongs to, and privileges of the user account associated with the process or thread.

You can also use the DB2_GRP_LOOKUP registry variable to enable access token support. Besides LOCAL and DOMAIN, there are three other valid values: TOKEN, TOKENLOCAL, and TOKENDOMAIN. These values can be used with LOCAL or DOMAIN to determine where to look up groups if an access token is not available. Table 10.11 highlights the behavior of these values.