Understanding the Role of the Enterprise Administrator
by Kate Follis, MCT
Windows 2000 brought us Active Directory, a dynamic directory service made possible through two-way transitive trusts and Kerberos authentication. Along with this Windows revolution came the Enterprise Admin – able to cross domain boundaries with a single account, more powerful than the domain admin, the ultimate authority in the forest. The presence of an account with unequalled power has brought fear and loathing to many system administrators as they find themselves managing a smaller piece of the Active Directory pie.
It’s a matter of trust. Suppose the administrator of our enterprise has Captain Kirk like tendencies and falls prey to the social engineering of a Klingon hacker? It could happen. Windows NT veterans were accustomed to being the ultimate authority within their domain boundaries. And those were very tight boundaries – no one could cross them without an explicit trust agreement. It gave domain admins a sense of control, but it also imposed some limitations on the interoperability of a full-blown enterprise level organization. Sure, the Enterprise Admin (EA) can reverse any restrictions you impose upon the account to maintain ultimate authority, but before we condemn this power, we need to understand the purpose of the role.
The EA security group is created automatically when a Win2k server is promoted to the first domain controller role for the forest. This group has forest-wide control of the configuration container, and user and computer accounts in this group are automatically granted logon rights to any domain controller in the forest. You will need to use an account that is a member of this group anytime that you make a configuration change that will have a forest-wide impact. If the potential exists for crossing a domain boundary, you’ll have to be running as an EA. Common tasks include Win2k site configuration, authorization of DHCP and RIS servers, application of group policy at the site level, installation of a Terminal Services Enterprise License Server, and management of the Domain Naming Master FSMO role. EA rights are also required when establishing an Exchange 2000 server organization – a single Exchange organization serves the entire forest. These are important tasks, but they are obviously not daily tasks.
The best strategy for alleviating any uneasiness caused by the existence of this super-power, is not to attempt to create barriers to be circumvented, but to control the usage of the account’s privileges. First of all, let’s consider who would most likely be granted access to the EA account. It’s probably someone pretty high in the food chain of your organization. Perhaps a Chief Information/Technology Officer or a corporate network administrator will be given the responsibility for wise usage of the account – whoever it may be, they have a responsibility toward the corporation and the network that is not to be taken lightly.
One common Active Directory design is creation of a dedicated forest root. This strategy is designed to eliminate conflict of interest when it comes to domain configuration. A forest root is established that contains high-level security accounts and single master operations roles, but no other resources. This works well in a forest whose domain boundaries are geographically based and very little site configuration is required. The forest root acts as a placeholder for all other domains and a consensus must be reached by domain administrators to gain access to the EA account. There are several strategies that can be employed to assure that the dual consent requirement is met. A procedure should be implemented that authorizes usage of the account. The EA account can be disabled and only enabled upon security approval. Smart card logon can be required, with one party maintaining control of the physical card and another control of the PIN. Create a security policy that implements Restricted Groups tracking and an audit policy that tracks privilege use.
Enacting controls over usage of the account is an important step, but protecting the account while in use is also vital. No matter how diligent our security efforts, the greatest hazard is human error. Only use the EA account when lesser administrative privileges are not sufficient. If possible, delegate enterprise level tasks to trusted administrators who specialize in configuration of sites and services. Create group policies that password protect screen savers and apply them to administrative accounts. Create dual accounts for network administrators and educate them in proper usage and sign-on procedures – admin accounts should only be logged at a workstation via the “RunAs” command. If network administrators are delegated sufficient privileges to fully control their areas of responsibilities, “enterprise envy” should subside – remember, excessive security measures can result in poor adherence to standards. We not only want to be sure this account is used wisely within our organization, but we want to make sure it is not susceptible to hacking attempts. With more and more of our company’s assets being entrusted to the care of the IT department, careless in-house practices cannot be tolerated.
The Enterprise Administrator holds the position of highest trust within the network, he can subvert virtually any protective measure in the operating system, because he controls it. And, he can cover his tracks. Create security measures that enhance accountability and you will be less likely to have security problems. Strong, effective communication will be the key to finding satisfaction with your configuration. And, if you find yourself no longer the master of your own domain and flying under the authority of a tribble-infected enterprise commander, take heart from the fact that he’s also the one that will take the heat created by poor decision making.