NT Security: Establishing Custom Administrative Control

By understanding administrative groups and server roles, you can get the most flexibility from NT

The saying, "Power corrupts, and absolute power corrupts absolutely," has certainly proven true in the political world, but does it hold true in the realm of enterprise computing? If Windows NT were a political system, the widely held belief is that an NT domain would be a totalitarian state with the administrator as its leader. Many analysts complain that no way exists to subdivide an NT domain into separate administrative units (see "NT's Top Security Problems," October 1998). Even Microsoft employees admit that administrators have total control of a domain. But is this statement really true? Before I answer that, let’s consider why it matters.

In an ideal organization, all departments would trust one group to centrally administer all resources. Most of us don’t work in an ideal organization. Commonly, one department demands administrative control over all its resources. This scenario would lead you to implement multiple domains if you followed Microsoft's domain-planning documentation.

By default, domain administrators have full control over all computers in a domain, as Figure 1 shows. But, in an organization that demands more flexibility, you can change that setup. By understanding administrative groups and server rolls, you can get the most flexibility from NT, thereby reducing costs and simplifying administration. This article describes how you can forgo NT's default domain models to create a domain better suited for your organization.

Setting Exclusive Administrator Privileges
When you install NT Server, you must configure the system to serve as a Primary Domain Controller (PDC—thus creating a new domain), a Backup Domain Controller (BDC) of an existing domain, or a standalone server. Microsoft refers to the standalone server role as a member server role, which means it is an NT server but not a domain controller. Whereas a standalone server doesn't share its Security Account Manager (SAM) database with the PDC, a BDC does. Both NT Workstation and NT Server have built-in groups (e.g., Administrators, Power Users, Backup Operators) as defined in their local SAM. Workstations and member servers trust the domain controller because they are members of the domain, but why do domain administrators have administrator privileges on these systems? Is it simply by virtue of domain membership? No. When a workstation or member server joins a domain, NT adds the global Domain Admins group from the domain controller’s SAM to the local Administrators group in the local system’s SAM. Thus, whoever is a member of Domain Administrators is indirectly a member of Administrators on the workstation or member server. However, you can change this setup. If you want exclusive administrator privileges on a member server or workstation, but you want to remain part of the domain, simply remove the Domain Admins group from the system’s local Administrator group and replace it with another account, as Figure 2 depicts. This account can be a global user account from the domain controller or a local user account defined on the system. If you use a global user account, remember that members of the Domain Admins group can gain administrator access to the system by compromising that user account. These intruders can compromise the user account by resetting the user’s password (which the user would discover when logging on next time) or by cracking the password using a password cracker. You can prevent password cracking by using Service Pack 3's (SP3's) Syskey utility. For information about Syskey, see "Protect Your Passwords," October 1998.

Global Domain Admins Versus Local Administrators
It's important to understand the difference between the global Domain Admins group and the local Administrators group on the domain controller. The local Administrators group on the domain controller is similar to the local Administrators group on a workstation or member server. As a member of Administrators on a workstation or member server, you control that system. But, because all domain controllers within a domain share the same SAM through replicated copies from the PDC, a member of Administrators in the domain SAM has administrator authority on all domain controllers. However, domain controller Administrators have no power on member servers and workstations. (From a security standpoint, NT considers all domain controllers one computer; they even share the same security ID—SID).

In the Old Days
Microsoft wrote all of the documentation for domain planning and administration before the member server roll existed. As a result, many systems administrators are unaware of various administrative configurations. Before NT 3.51, NT Server was known as Advanced Server, and you installed the software as either a PDC or BDC. Thus all servers shared in domain authentication and received replicated SAM changes from the PDC. This setup wasn't flexible enough. For performance reasons, you don’t always want an application server to share the authentication workload for a domain. This configuration also restricted your granularity of auditing control. NT's audit policy resides in the SAM, and domain controllers share the SAM. Thus, you could configure auditing only one way for all servers within the domain, which isn’t always feasible. For instance, perhaps you need the Process Tracking audit category turned on for a particular system. Process Tracking imposes a significant load on a system, which many other servers in the domain probably can’t bear. Consequently, Microsoft created a new server roll—the member server. The member server has the same capacity as a domain controller, but it has no domain controller functions. Unlike a domain controller, the member server borrows its built-in group and privilege structure from NT Workstation. Thus, a member server has Power Users, but it doesn't have Account Operators or Print Operators.

Leveraging NT 4.0's Flexibility
What if a company has several departments that require exclusive control over their resources but want centralized account management? In this scenario, Microsoft recommends the master domain model. To use this model, you designate one domain as the master, where you maintain all user accounts. Next, you create a resource domain for each department’s servers. The resource domains trust the master domain. This configuration lets you minimize trust relationships and centrally manage user accounts, but each department designates its own administrator to manage its resources. This approach sounds good, but multiple domains are undesirable because they increase the overall complexity of your system.

What if you could achieve the same results with only one domain? As Figure 3 shows, the key is member servers. Instead of creating resource domains for each department, give each department one or more member servers. Then remove Domain Admins from the local Administrators group on each member server, as I described earlier. Now each department’s administrator can administer his or her departmental servers using the local Administrator account. If a department has multiple administrators, you can create a separate local user account on the server for each administrator.

One drawback to this approach is that you might end up with multiple accounts for one departmental administrator (the whole purpose behind domains is to reduce multiple accounts). If the administrator manages only one departmental server, this won't be a problem; the administrator will have a domain account for everyday work, such as email and other applications, and another account on the server for administrative work. The administrator can log on interactively from a workstation using a domain account and then connect to the server using the administrator's local account on that system.

Simplified Administration: Win 2K
As you can see, no domain model for large networks meets all the administrative requirements without additional resources. In the future, Active Directory in Windows 2000 (Win2K—formerly NT 5.0) will address the granularity of control and hierarchical administration problems in NT 4.0. Until then, you can get the most from your resources with a deeper understanding of server roles and account types.