How DB2 for Windows NT/2000 Works with Windows NT/2000 Security

Security is one of the most important features of any database management system. It is important to keep data safe and to limit data access to those with a need to know only. DB2 UDB has many security features of its own, but on Windows NT/2000, it also relies on the security features of the Windows NT/2000 operating system itself.

To understand security for DB2 UDB on Windows NT/2000, we must understand not only the many security features of DB2 UDB, but also the Windows NT/2000 security model and how it's used by DB2.

Terminology

Table 4.8 defines Windows NT/2000 and DB2 UDB terminology.

Table 4.8. Windows NT/2000 and DB2 UDB Terminology
Term	Description
Windows NT	Either Windows NT Workstation or Windows NT Server. Reference will be made to the common Windows NT features of the two products.
Windows NT Workstation	The Windows NT Workstation product. Cannot be a domain controller.
Windows NT Server	The Windows NT Server product. It is a superset of the NT Workstation product. A machine running Windows NT Server may be a Windows NT Workstation or a domain controller.
Workgroup	A collection of Windows Workstation. It can contain computers running any number of operating systems, including DOS, Windows 3.x, Windows for Workgroups, Windows 95/98, Windows NT Workstation, and Windows NT Server, and is identified by a unique name.
Domain	A domain is an arrangement of client and server computers, referenced by a specific (unique) name, that share a single user accounts database.
Domain Controller	Refers to the computer running Windows NT Server that manages all aspects of user-domain interactions and uses the information in the domain user accounts database to authenticate users logging onto domain accounts.
Primary Domain Controller	In a Windows NT server domain, the computer running the Windows NT server that authenticates domain logons and maintains the user accounts database for the domain. There can be only one per domain. It can also be referred to as the primary domain controller (PDC).
Trust Relationship	An administration and communications 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 these accounts are actually defined. Domains use established trust relationships to share account information and validate the rights and permissions of users and global groups residing in the trusted domain. Trusts, therefore, simplify administration by combining two or more domains into a single administrative unit.
Backup Domain Controller	These are servers that contain up-to-date and accurate copies of the user accounts database. These servers can also authenticate workstations in the absence of a primary domain controller (PDC). They can also be referred to as BDCs.
Server	A Windows NT Server that is part of a domain as a file, print, or application server but is not a domain controller.
Workstation	A machine running Windows NT Workstation or Windows NT Server in a domain that is not a domain controller or a file, print, or application server.
Right	The ability of a user or group of users to perform a Windows NT operation. Examples of rights are logging on to a server and performing backups. Rights apply to the computer as a whole, as opposed to permissions, which apply to specific objects. These can also be termed user rights.
Permission	Authority in Windows NT granted to a user or group of users to perform operations on specific objects, such as files, directories, printers, and other resources. Examples of permissions are read, change, full control, and no access. Permissions are applied on a user-by-user or group-by-group basis.
Instance	DB2 Administration unit. On a server, it represents an independent set of databases. A DB2 Server Instance runs as an NT Service.
Privilege	Within DB2 UDB, the right of a particular user or group of users to create, access, or modify an object.

A Windows NT domain is an arrangement of client and server computers referenced by a specific and unique name and sharing a single user accounts database called the Security Access Manager (SAM). One of the computers in the domain is the domain controller. The domain controller manages all aspects of user-domain interactions. The domain controller uses the information in the domain user accounts database to authenticate users logging onto domain accounts. For each domain, one domain controller is the primary domain controller (PDC). Within the domain, there may also be backup domain controllers (BDCs), which authenticate user accounts when there is no PDC or when the PDC is not available. Backup domain controllers hold a copy of the SAM database, which is regularly synchronized against the master copy on the PDC.

User accounts, user IDs, and passwords need to be defined only at the PDC to be able to access domain resources.

During the setup procedure, when a Windows NT server is installed, you may select to create:

A PDC in a new domain.
A BDC in a known domain.
A stand-alone server in a known domain.

Selecting "controller" in a new domain makes that server the PDC.

The user may log on to the local machine or, when the machine is installed in a Windows NT domain, the user may log on to the domain. DB2 for Windows NT supports both of these options. To authenticate the user, DB2 checks the local machine first, then the domain controller for the current domain, and finally any trusted domains known to the domain controller.

Windows NT/2000 Authentication

We have discussed the concepts of Windows NT user accounts, local and global groups, and domains. The next logical topic is authentication. The actual process of user authentication is relatively simple. Authentication is verifying that a user is who they say they are.

Recall that user IDs and passwords are stored in the SAM database on Windows NT machines, but a user's user ID and password do not necessarily have to reside on the machine from which they log on. When Windows NT authenticates a user, it follows a simple hierarchy to look for a user ID and password. If you choose a workstation or local logon, Windows NT will look at only the local SAM. If the user is not in the local SAM, authentication will fail.

If you choose domain authentication, the domain controller that does the authentication can be either the PDC or a BDC. BDCs have a copy of the PDC's SAM database. To determine which domain controller will perform the authentication, a broadcast message is sent out from the user's machine, and the first domain controller to respond to the message will perform the authentication.

If the user is not known to the domain, (that is, the user ID is not in the SAM database of the PDC), then domain controllers of any trusted domains are queried. Either the PDC or a BDC can respond to an authentication request from a trusting domain.

Once the userid has been found and the password authenticated, any account or policy restrictions are determined, as well as a list of groups of which the user is a member.

Trust Relationships Between Domains

We have discussed the concept of a single domain; however, an enterprise may wish to establish more than one domain. These domains do not have to exist independently, nor do separate user accounts have to exist for each domain a given user wishes to log into. Interdependent multiple domains can be achieved through relationships between domains, called trusts.

Trusted Domains

Trust relationships between domains are established so that users from one domain can access resources in another domain without being re-authenticated.

There are two characteristics of a trust relationship:

One domain trusts another to authenticate users on its behalf and, therefore, grants access to resources in its domain without re-authenticating users.
An administrator from one domain trusts an administrator from another domain to administer resources in that domain.

The two domains in a trust relationship are called the trusting and the trusted domains. A trust relationship lets an administrator of one domain (the trusting domain) grant rights and permissions to global groups and users of another domain (the trusted domain). The administrator of the trusted domain must be, in turn, trusted because this administrator can control which users are members of global groups.

Trust relationships are not transitive. This means that explicit trust relationships need to be established in each direction between domains. There is no concept of an implicit or piggybacked trust relationship.

Models of Domain Trust

Choosing the right domain trust architecture for an enterprise can be an involved and complex task, with a number of considerations to be taken into account. To assist in this process, let's look at four common models of domain organization. They are:

1 The single domain model

All servers and workstations belong to one domain. There are no trust relationships to any other domain.

Advantages of this model include:

It's easy to implement.
It's a suitable design for a small to medium sized network.
There are no trust relationships to establish or maintain.
It has one set of administrators.

Disadvantages of this model include:

The list of users and machines can grow to an undesirable size.
Network and server performance problems may arise.

An example of a single domain model might be a small network with an independent domain. This could be a production environment, where it is desirable to keep the production data separate from the development environment. You might also have a number of small domains for an organization where the sharing or dividing of resources such as databases is not required. The ability to administer each domain separately is not an issue.

The most compelling reason not to implement this model, especially in a production environment, is generally the size of the domain, specifically the number of users and machines. These factors affect the size of the SAM database on the domain controllers.

2 The master domain model

This is the domain where all users are defined. All other domains trust the master domain. Domains other than the master domain have no users defined. The other domains are called resource or slave domains.

Advantages of this model include:

Administration for the enterprise is centralized.
It supports logical grouping of resources (such as divisions or departments).
It supports geographical division of an enterprise.
Global groups are defined only once.

Disadvantages of this model include:

Performance may degrade on a WAN or with a large number of users.
Local groups must be defined on each domain.
Global administration can be cumbersome to establish.
Master domain can be a single point of failure.

You might find the master domain model implemented where each department in an organization is on its own domain. However, all administration and authentication occurs in the master domain. The enterprise is split geographically, and resources are grouped accordingly. However, users are all defined and administered centrally. This model easily supports movement of personnel across domains.

3 The multiple master domain model

The master domains have trust relationships between each other and can each authenticate for the resource domains.

Advantages of this model include:

It supports a large number of users with acceptable performance.
Resources are grouped logically.
Resource domains can be managed independently for security.

Disadvantages of this model include:

Groups may need to be defined more than once for different domains.
There are many trust relationships to manage.
Maintenance of user accounts is more difficult because they are in multiple domains.

A multiple master domain may be established for the same reasons as a master domain. You may choose the multiple master model if you have too many users for one domain to handle all the authentication requests. To ease network traffic and speed user authentication requests, multiple master domains are created to service the resource domains.

4 The complete trust model

Domains exist with trust relationships to and from all other domains on the network. An example of a suitable environment where the complete trust model might be implemented is a development environment.

Advantages of this model include:

It supports a large number of users.
It does not require central administration.
Resources and users are grouped logically into domains (from a browser perspective).
Resources are managed independently for each domain.

Disadvantages of this model include:

Lack of central administration can cause potentially severe network problems.
There are a large number of trust relationships to manage.

To illustrate how this works, suppose that the DB2 instance requires Server authentication. The configuration is shown in Figure 4.1.

Figure 4.1. Server authentication configuration.

graphics/04fig01.gif

Each machine has a security database, Security Access Management, unless a client machine is running Windows 9x. Windows 9x machines do not have a SAM database. DC1 is the domain controller, in which the client machine, Ivan, and the DB2 for Windows NT server, Servr, are enrolled. TDC2 is a trusted domain controller for DC1, and the client machine, Abdul, is a member of TDC2's domain.

A DB2 for Windows NT Scenario with Server Authentication

Abdul logs on to the TDC2 domain (i.e., he is known in the TDC2 SAM database).
Abdul then connects to a DB2 database that is cataloged to reside on Servr:
```
db2 connect to remotedb user Abdul using xxxxxx
```
Servr determines where Abdul is known. The API that is used to find this information first searches the local machine (Servr), then the domain controller (DC1), before trying any trusted domains. Username Abdul is found on TDC2. This search order requires a single namespace for users and groups.
Servr then:
1. Validates the username and password with TDC2.
2. Finds out whether Abdul is an administrator by asking TDC2.
3. Enumerates all Abdul's groups by asking TDC2.

A DB2 for Windows NT Scenario with Client Authentication and a Windows NT Client Machine

Dale, the administrator, logs on to Servr and changes the authentication for the database instance to Client:
```
db2 update dbm cfg using authentication client
db2stop
db2start
```
Ivan, at a Windows client machine, logs on to the DC1 domain (i.e., he is known in the DC1 SAM database).
Ivan then connects to a DB2 database that is cataloged to reside on Servr:
```
db2 connect to remotedb user Ivan using yyyyyy
```
Ivan's machine validates the username and password. The API used to find this information first searches the local machine (Ivan), then the domain controller (DC1), before trying any trusted domains. Username Ivan is found on DC1.
Ivan's machine then validates the username and password with DC1.
Servr then:
1. Determines where Ivan is known.
2. Finds out whether Ivan is an administrator by asking DC1.
3. Enumerates all Ivan's groups by asking DC1.

NOTE

Before attempting to connect to the DB2 database, ensure that DB2 Security Service has been started. The Security Service is installed as part of the Windows installation. To start the DB2 Security Service, enter the NET START DB2NTSECSERVER command.

A DB2 for Windows NT Scenario with Client Authentication and a Windows 9x Client Machine

Dale, the administrator, logs on to Servr and changes the authentication for the database instance to Client:
```
db2 update dbm cfg using authentication client
db2stop
db2start
```
Ivan, at a Windows 9x client machine, logs on to the DC1 domain (i.e., he is known in the DC1 SAM database).
Ivan then connects to a DB2 database that is cataloged to reside on Servr:
```
db2 connect to remotedb user Ivan using yyyyyy
```
Ivan's Windows 9x machine cannot validate the username and password. The username and password are, therefore, assumed to be valid.
Servr then:
1. Determines where Ivan is known.
2. Finds out whether Ivan is an administrator by asking DC1.
3. Enumerates all Ivan's groups by asking DC1.

Support for Global Groups (on Windows)

DB2 also supports global groups. To use global groups, you must include global groups inside a local group. 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 (by the virtue of being in a global group that is itself a member of one or more local groups).

Global groups are used in two possible situations:

Included inside a local group. Permission must be granted to this local group.
Included on a domain controller. Permission must be granted to the global group.

Using a Backup Domain Controller with DB2

If the server you use for DB2 also acts as a backup domain controller (BDC), you can improve DB2 performance and reduce network traffic if you configure DB2 to use the BDC.

You specify the BDC to DB2 by setting the DB2DMNBCKCTLR registry variable.

If you know the name of the domain for which DB2 server is the BDC, use:

DB2DMNBCKCTLR=<domain_name>

where domain_name must be in uppercase.

To have DB2 determine the domain for which the local machine is a BDC, use:

DB2DMNBCKCTLR=?

NOTE

DB2 does not use an existing BDC by default because a BDC can get out of sync with the PDC, causing a security exposure. Domain controllers get out of sync when the PDC's security database is updated but the changes are not propagated to a BDC. This can happen if there are network latencies or if the computer browser service is not operational.