Auditing a Windows Active Directory domain is rife with security control points, processes and configurations to check and double check. Most auditors focus on the domain infrastructure, which is key to the environment's security. Yet, leaving the servers' and clients' local Security Accounts Manager (SAM) untouched, unaudited and vulnerable could put the entire domain in jeopardy if attackers exploit weaknesses to gain access to...
The local SAM, a directory database that controls the domain user and group accounts, is found on each server and client computer running Windows NT 4.0, Windows 2000, Windows XP and Windows Server 2003. Each local SAM contains critical security settings that, if not set properly, can be exploited by attackers. The following discusses control points that auditors need to consider when checking local SAMs.
Use the following directory to look up specific control points and auditing techniques.
TABLE OF CONTENTS
Patch and service pack level
How to pick sample servers and clients
Check all control points to safeguard systems
Bonus: Tools for auditing groups
Each local SAM always has two user accounts: administrator and guest. The administrator account located in the local SAM is only administrator of the local computer and should not be used by a typical user for accessing the computer. This account is only used to get the computer installed, create a new administrator account, and to recover from a system disaster or failure. The administrator account has special privileges associated with it, such as creating users, groups, installing applications and updating operating system settings, which should be protected by not logging in as this account.
To administer the local computer, a user account from the domain should be used rather than the administrator account. As with all accounts, the administrator account should have a complex password that is hard to guess and crack. In Active Directory, the guest account is disabled by default, and auditors should ensure that the account is turned off on the computer being reviewed.
In general, other types of user accounts should not exist in the local SAM. Occasionally, though, they are found when an administrator adds a new user account to the local SAM to match a corresponding domain user account. This is a poor idea because it allows the user to be authenticated by the local SAM account rather than through the Active Directory-based Group Policy Objects (GPOs). If other user accounts exist, they should have a purpose, such as for System Management Services (SMS) and local services.
Like the administrator user account, the members of the administrators group on the local SAM can control the computer. Consequently, this group should have as few members as possible. Two members that should be included are the local administrator account and the domain admins group. Any other members should be audited and questioned. Another group that should be checked is the power users, which have some privileges that the administrator has, but not to the full extent.
The account policies on the local SAM control the password and password lockout for all users that logon locally using the user accounts listed in the local SAM. A quick check of the account policies should prove whether or not they match the domain account policies. If they do not meet or exceed the levels set in the domain account policies, they should be questioned.
The user rights on the local SAM determine which users and groups can have elevated privileges to the operating system and resources located on the computer. For a server or client computer, default user rights for Active Directory are very lenient. For client computers, the user rights are not highly significant, because clients do not store many resources. However, for servers, especially file and resource servers, user rights are highly important. During a review, auditors need to pay special attention to user rights such as:
- Shut down of the system.
- Log on as a batch job.
- Log on locally.
- Backup and restore files and directories.
- Generate security audits.
- Manage auditing and security log.
- Synchronize directory service data.
- Forced shutdown of remote system.
- Log on as a service.
- Act as part of the operating system.
- Enable trusted for delegation.
- Load and unload device drivers.
- Replace process-level token.
- Take ownership of files and other objects.
The audit policy determines what will be tracked within the operating system and resources. The results from an enabled audit policy will show up in the security log located in the Event Viewer. It is important to verify that the security policy standards for the organization are upheld on each server and client computer.
If the server or client computer stores files or important data, it is important to check the permissions for these resources. A common error is to check only the share permissions, which may not be sufficient to protect the data, instead of focusing on the NT File System (NTFS) permissions.
Each server and client computer runs services, typically applications or features that run at the operating system level when the computer starts up, such as Microsoft Exchange, Web publishing, telnet and file transfer protocol (FTP). These might be standard, built-in services or services that were installed after the operating system was installed and configured. When checking servers, client computers and domain controllers, services running should be audited to an authorized list, and unauthorized services should be questioned to prevent security vulnerabilities.
Because the security environment is frequently attacked, it is essential that patches and service packs are audited on each server and client computer. This is a two-fold audit point. First, the correct patches and service pack should be installed on every server and client computer, based on the organization's security policy. Second, the process of deploying patches and service packs needs to be reviewed. Ideally, the security should be controlled by SMS or Software Update Services (SUS).
Backups are primarily a server concern, but client computers that run accounting, design and drafting, or other essential business software also fit this audit control point. These servers and clients must be backed up regularly -- preferably every day -- and the storage of the backup media needs to be monitored and audited. Failure to backup or store media properly can cause days, weeks or months of lost data and money.
In reality, auditors won't be able to evaluate every server or client computer in a large network. In an organization with thousands of clients and servers, auditors will need to pick and choose wisely which computers to review, focusing on a small percentage of those machines to gather enough information to compile a report on the network's security. Rather than guessing on an appropriate sample, auditors should obtain a copy of the Active Directory structure and sample one computer from each organizational unit, because these machines are typically managed in a like manner by GPOs. If there are servers and client computers in the same organizational unit, it is ideal to sample one of each. This sampling method allows computer accounts to be placed logically in Active Directory and to be configured consistently using GPOs. GPOs can configure all of the control points mentioned above.
If auditors discover that the servers and clients are not controlled by GPOs, the computers are probably manually configured. Consequently, many may not be correctly configured, with no logical method for administration, and therefore almost no logical method to pick the sample.
The Windows servers or client computers that need special attention are listed below. It is best to sample at least one from each category, to check the security on the computer.
|Servers||Client computer categories|
|SQL servers||IT staff personal computer|
|SMS servers||Chief executive, chief information, chief technology and other senior officers|
|File servers||Help desk staff personal computer|
|Exchange servers||Power user (typically one in each department)|
Most organizations that use GPOs will already have these computer types organized in the Active Directory by organizational units. As a result, the sample based on GPOs will overlap with the one picked based on organizational unit location.
Auditing a Windows domain is not complete until auditors review all types of computers, including the servers and clients. Not checking the entire scope of control points on a server or client can leave security vulnerabilities on these computers. Making sure that these additional control points are correctly configured will help secure these computers, as well as the entire environment.
Auditors can use a variety of tools to review the critical control points of servers and client computers, many of which are either built-in to the Windows operating system or are free from the vendor. The following lists tools for each control point mentioned above.
|Control point||Tools and techniques|
|User accounts||Somarsoft Dumpsec, Windows Computer Management Console|
|Administrators group||Dumpsec, Computer Management Console|
|Account policy||Dumpsec, Windows Local Security Policy|
|User rights||Dumpsec, Local Security Policy|
|Audit policy||Dumpsec, Local Security Policy|
|Resource permissions||Dumpsec, Microsoft Showacls.exe|
|Services||Dumpsec, Computer Management Console|
|Patch and service pack level||Microsoft Baseline Security Analyzer, Windows System Properties applet|
|Backup procedures||Interview IT staff and manually evaluate backup scripts and backup procedure|
Would you like to see more auditing tips from Derek Melber? E-mail us and let us know.
Originally published in ITAudit, (July 1, 2004), published by The Institute of Internal Auditors, Inc., www.theiia.org/ITAudit.
About the Author:
Derek Melber is a SearchWindowsSecurity.com guest contributor and one of the leading solution developers, project leaders and technical instructors in the United States, with an innate understanding of how to decipher, organize and communicate complex issues. Derek is a co-founder of BrainCore.Net LLC, which focuses on exam development and certifications, and is the leading outsource company for Microsoft. Derek has worked with Microsoft Learning on over 20 projects focusing on the MCSA and MCSE tracks. He has also taken his years of experience to develop the only Web site dedicated to Windows auditing and security: www.auditingwindows.com, which showcases the auditing windows security book series, online courses and customized training that Derek provides. Finally, Derek has just finished writing books on Windows security, including the "Administrator shortcut guide to Active Directory security. He has a masters degree from the University of Kansas, Microsoft Certified Systems Engineer Certification, CISM, A+ Certification, and 10 years of solution development, training, public speaking, sales and management experience.