In-Depth

Top Five Errors Enterprise Windows Administrators Make

Keep an eye out for these five common mistakes

I don’t want to come down hard on Administrators, but I must admit that they can make some bonehead mistakes. I can say this because I was once one. Over the last 10 years, I have trained and consulted with IT professionals and Windows security auditors. I have designed entire Active Directory enterprises, as well as helped develop an audit plan for large Windows enterprises. Along the way, I have seen some horrible implementations by administrators. Not to pick on the administrators only, I have seen auditors blow right over these settings, leaving the obvious insecure settings out of their reports.

The mistakes I describe here that administrators make don't all occur by accident. Some are blatant, breaking rules in the company's written security policy. As the internal or external auditor, your goal is to ensure that you check each of these control points to ensure proper security is in place.

Mistake #1: Removing Domain Administrators from Local Administrators Group

This mistake focuses on the local computer administrators use 99 percent of the time to perform their job function. Local administrators remove the Domain Admins group to remove the capability of the other administrators who have membership in the Domain Admins group from controlling the local machine. What administrators forget is that this is not their machine! Administrators need to allow all administrators access to the box for security and administrative access reasons. Otherwise, local administrators can have too much control over their computer without receiving the correct patches, updates, and supervision required by the Domain Admins group.

As auditors, you need to need ensure that the Domain Admins group has membership in the local Administrators group on all client computers and member servers.

Mistake #2: Creating a Local User Account in the Local SAM

This mistake also focuses on the local administrator's computer. The administrator will create a user account in the local SAM that has the same logon name and password as their domain user account. Why do they go to the trouble? Because when the administrators log on locally, instead of the domain, they will bypass the user-based Group Policy Objects configured in Active Directory. The problem with this is that an administrator now has an insecure computer. Bypassing the GPOs fails to configure the proper security and environment settings, leaving potential security holes on the administrator's computer every time the administrator logs in.

As an auditor, you need to ensure that there are no local user accounts on client computers and member servers. If local user accounts exist, then they need to be accounted for and purpose provided for their existence.

Mistake #3: Configuring Only One Account Policy for the Forest of Domains

Here, we turn our attention to the Active Directory configuration. If a company has more than one domain, then there will be more than one Account Policy configuration. (Remember the Account Policy dictates the password restrictions and account lockout criteria for all domain users.) The problem is that many administrators feel that if they configure the Account Policy at the root domain (first domain in the forest) that the settings will affect all other domains. This isn't so. Each domain has a unique Account Policy configured. There is no possible way to have these settings flow to other domains in the forest. If all domains are not configured properly, there is no possible way to secure the passwords properly and consistently across all domains.

In your audit, check the Account Policy on every domain in the organization: those in the Active Directory forest and those outside the Active Directory forest.

Mistake #4: Logging On Using the Administrator Account

The Administrator account, whether at the domain or local computer level, is special. The privileges this account has can’t be revoked, the account can’t be deleted (except in Windows Server 2003), and the account has “all powerful” capabilities. Instead of using this account, all administrators need to have a special user account that is placed in the appropriate admin group (Domain Admins, DNS Admins, Administrators, and so on) to give them their power. This protects the all-powerful Administrator account. A good rule of thumb is to not use this account, and configure a password that has more than 20 characters. The password should also have each type of character included, to make it harder to crack.

Check the “last time logged in” value for the Administrator account. Also, verify that the Administrator account is not being used as a service account anywhere in the enterprise.

Mistake #5: Failure to Correct Security on Upgraded Domain Controllers and Servers

When you upgrade a server or domain controller from Windows NT 4.0, the security is not as strong as if the computer is freshly installed with Windows 2000 or Server 2003. There is a special security template, dcup.inf and dsup.inf, which configure upgraded domain controllers and servers, respectively. If a server must be upgraded (which does happen often), the security should be modified after the upgrade by using one of the higher level security templates. Examples include: setup security.inf; hisec*.inf; secure*.inf, or deflt*.inf. If the security is not upgraded, the servers have security vulnerabilities built in, which can’t be patched, only reconfigured.

During an audit, inquire about the process of installing the servers and domain controllers. You also need to check for the common security settings that are left behind after an upgrade.

Conclusion

I am sure that if you walk into 100 companies that have a large staff of IT administrators you will find one or more of these errors in every company. Knowing what to check for can go a long way to protecting the network, even from the administrators' mistakes.

Additional articles by Derek Melber

About the Author

Derek Melber (MCSE, MVP, CISM) is president of BrainCore.Net AZ, Inc., as well as an independent consultant and speaker, as well as author of many IT books. Derek educates and evangelizes Microsoft technology, focusing on Active Directory, Group Policy, security and desktop management. As one of only 8 MVPs in the world on Group Policy, Derek’s company is often called upon to develop end-to-end solutions regarding Group Policy for companies. Derek is the author of the The Group Policy Resource Kit by MSPress, which is the defacto book on the subject.

Must Read Articles