How DB2 for Windows NT/2000 Works with Windows NT/2000 SecuritySecurity 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. TerminologyTable 4.8 defines Windows NT/2000 and DB2 UDB terminology. Table 4.8. Windows NT/2000 and DB2 UDB Terminology
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:
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 AuthenticationWe 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 DomainsWe 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 DomainsTrust 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:
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 TrustChoosing 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 modelAll servers and workstations belong to one domain. There are no trust relationships to any other domain. Advantages of this model include:
Disadvantages of this model include:
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 modelThis 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:
Disadvantages of this model include:
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 modelThe master domains have trust relationships between each other and can each authenticate for the resource domains. Advantages of this model include:
Disadvantages of this model include:
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 modelDomains 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:
Disadvantages of this model include:
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.
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
A DB2 for Windows NT Scenario with Client Authentication and a Windows NT Client Machine
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
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:
Using a Backup Domain Controller with DB2If 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. |