One of the worst problems with Windows NT security and one of the best enhancements with Windows 2000 (Win2K) involves how each OS handles administrative authority. Once you understand how NT handled administrative authority and the changes Microsoft made in Win2K, you'll begin to see the opportunities you have for improving security in your network. I’ll introduce you to Win2K’s ability to delegate authority at the forest, domain, organizational unit (OU), and computer levels and even down to individual user accounts. I’ll also explain why I recommend you don’t use Win2K’s built-in administrative groups.
Windows NT Administrative Authority
In NT, administrative authority sorely lacks granularity. That is, you can’t delegate administrative privileges over a subset of the domain’s accounts to another user—in effect making that user a sub-administrator. NT has two domain groups for controlling administrative privileges. The domain local Administrators group gives you authority over the domain controllers, which includes administration of domain users, groups, rights, audit policy, trusts, shares, and services on all domain controllers. The
Domain Admins global group doesn’t have any direct authority of its own; instead, it
is a member of the domain local Administrators group, giving it administrator authority
over domain controllers. But members of the Domain Admins global group also have
authority over each member server and workstation in the domain. This is because NT also
makes Domain Admins a member of the local Administrators group on each these systems. If
you need to isolate a member server from the administrators in a domain, you can remove
Domain Admins from that system’s local Administrators group and designate another
user as administrator of that system. (For more information on this process and situations
where it is useful, see my article "NT
Security: Establishing Custom Administrative Control," March 1999\].
NT includes one other domain group known as Account Operators that gives you authority over domain users and groups, excluding of course the more powerful administrator groups. This group is useful because it doesn’t have any of the other administrative privileges that I described eariler. In multidomain environments, the Domain Admins group in one domain has no authority in any other domain regardless of trust relationships unless an administrator specifically grants that authority. To wrap up administrative authority in NT, you can grant administrative authority over computers at the domain or individual server level. Administrative authority over domain accounts must be granted over all users or not at all.
Windows 2000 Administrative Authority
In Win2K, you still have these same groups, and all the rules from NT still apply, but you gain a new group known as Enterprise Admins. Win2K automatically creates the Enterprise Admins group in the first domain of any forest and then makes it a member of every domain’s local Administrator’s group. As a result, every forest has one Enterprise Admins group whose members have administrative authority over that forest’s entire Active Directory (AD) and every domain controller. By default, members of the Enterprise Admins group don’t have authority over workstations and member servers, but this isn’t a constant because members of the Enterprise Admins group can add themselves to any Domain Admins group in the forest. So, effectively, Enterprise Admins, as the name suggests, has authority over everything in the entire forest.
As you can see, in Win2K you have pre-built groups to assign administrative authority at the system, domain, and forest levels. You only need to use these pre-built administrative groups for tasks such as adjusting system audit policy, creating shares, creating domains, and assigning rights. However, for medium and large domains, these groups provide much more authority than most administrators need. In a typical environment, most administrators specialize in a certain technology or handle a subset of the users or computers in a domain. Combine that fact with the proven concept of "least privilege," and you see why I recommend that you avoid using Account Operators, Domain Admins, Enterprise Admins, and the Administrators groups. Instead, for each administrative role, I suggest you create your own group with just the permissions you need to fulfill that role. This practice improves your security in a number of ways. First, you are at risk to the maliciousness and honest mistakes of fewer privileged users. Second, you have increased separation of duty—another proven security concept. Third, you can now delegate authority to other users to handle routine tasks, freeing you up for important security tasks such as monitoring logs and user activity.
Let me give you an example. I recently helped a client company plan its Win2K domain. In the process, we encountered a department that required the ability to administer its user accounts. In NT, we would have been forced to either give this department its own domain or add its department administrator to the current domain’s Account Operators group, which would have given the department authority over all the other user accounts outside this department. With Win2K, we plan to simply delegate authority to the administrators for that department’s OU. Thus, we keep one domain without giving out too much authority. You can delegate authority this way using AD's delegation wizard. To access the wizard, open Active Directory Users and Computers, select the OU, right click it, and select Delegate Control. The wizard will walk you through delegating authority over that OU. Screen 1 shows the final step of the wizard, which indicates that I’ve delegated user and group management for the Marketing OU to the MarketingAdmins group.
In future articles, I’ll show you how to delegate even more granular levels of authority roles, including Help desk staff and database administrators. Until then, follow the best practice of least privilege and avoid using Win2K’s built-in administrative groups.
