The very first step you need to take is to document your Active Directory configuration. A good place to start is with the high-level structures like forest and domain configuration, organizational unit (OU) structure, top-level directory security, and existing trust relationships. Document your site topology by listing the sites, configuration settings for each site, site links and their settings, the list of subnets and their settings, and any manually created connection objects and their settings. Document your Group Policy Objects (GPOs) with a Group Policy utility like the Group Policy Management Console (GPMC), available from Microsoft downloads and included in Windows Server™ 2003 R2. The documentation you create should include password and audit policies, and don’t forget to include what the GPOs are linked to and who has rights on them. Be sure you have a list of all changes you’ve made to the Active Directory schema, preferably in the form of a Lightweight Directory Interchange Format (LDIF) file. There’s even a GPMC script included in the download to help you get started. It is located in the %programfiles%\gpmc\scripts directory and is called GetReportsForAllGPOs.wsf.
While you’re at it, also list your domain controllers and their names, their OS versions, and virus scanning software and their versions. Record the backup methods you’re using and how often they run, along with how long you keep the backups. If you use disk-based backups, record where you securely keep the backup files. If you use Windows® DNS, use DNSCMD and DNSLINT to document its configuration. Note whether it’s integrated with Active Directory, whether you use application partitions, and how they are configured.
2. Controlling your administration is the single most important step in securing your forest and it’s also probably the hardest. Everyone wants to own a piece of Active Directory, but a well-secured forest model can’t allow this. If your company’s installation is like most, your logical Active Directory design is already set, so you have to work within its constraints. If not, you have the opportunity to build Active Directory from the start.
The forest is the only true security boundary within Active Directory. Domains should be used to facilitate your company’s IT support infrastructure and replication, and OUs should be used to delegate administration within a domain. If you have hard security constraints between two parts of your company, consider implementing another forest. See “Multiple Forest Considerations in Windows 2000 and Windows Server 2003″ for recommendations. If necessary, add a security-filtered forest trust to communicate with your first forest (see “Planning and Implementing Federated Forests in Windows Server 2003″ for more information). If your domains are already administered by different groups, realize that administrative access to any domain controller in the forest can jeopardize the entire forest. As a result, you need to work closely with the administrative teams of the other domains to ensure you have a uniform domain controller (DC) administration model across the forest. For more detail on this topic, read “Design Considerations for Delegation of Administration in Active Directory”.
3. Limit the Number of Administrators
Within your forest, you need to do everything you can to limit the number of administrators. Though the Active Directory security model is much better than it was in Windows NT® 4.0, it still has a weakness: you can’t fully administer a domain controller without being an administrator of the domain. This means that in a basic Active Directory implementation, computer operators in locations that contain DCs are usually members of Domain Admins so they can perform all maintenance functions on these servers. Don’t do this! You’ve handed the keys to your Active Directory forest to a potentially large number of employees with unknown backgrounds and security qualifications. Instead, follow the time-honored practice of determining requirements first and then creating a solution based on these requirements. Meet with operations management to figure out exactly what tasks they need to perform on DCs. Then, design a solution using a combination of Group Policy and third-party tools to grant them as many rights as possible without elevating them to Domain Admins.
Finally, your administration team must assume the tasks you can’t securely delegate to operations. This is a very touchy area because you’re taking away responsibilities from operations, but you’ll have the big stick of information security on your side.
4. Test Group Policy Settings
This is a good opportunity to say a few words about Group Policy. It’s the single most powerful tool for controlling your forest’s security. Precisely because it’s so powerful, however, you need to make sure you test these settings in a controlled environment before rolling them out. You can use a duplicate test-bed environment, be it physical or virtual (through the use of virtualization software such as Virtual Server 2006). You can implement these policies in stages by first linking new security-focused GPOs to individual OUs, then to the entire domain.
5. Use Separate Administrative Accounts
Once you’ve limited the number of administrators, make sure all employees who perform operations with elevated privileges use separate administrative accounts. These accounts should have a naming convention that’s different from standard accounts and should reside in their own OU so you can apply unique GPOs to them. You can group these accounts by the roles they perform and assign rights to these groups rather than to individuals. For example, helpdesk members responsible for account management should have their administrative accounts in a group named ” Account Admins”, and this group should be added to the Account Operators built-in group.
6. Restrict Elevated Built-In Groups
If your security model follows the recommendations I just outlined, it’s relatively easy to put all elevated built-in groups into Group Policy’s Restricted Groups feature. This will ensure that the group’s membership is enforced every five minutes, limiting the chance that a rogue administrator will inject their account into it. Use Restricted Groups to keep groups like Schema Admins empty and to keep Enterprise Admins very small.
7. Use a Dedicated Terminal Server for Administration
Service administrators (responsible for running core Active Directory services like DCs, sites, and the schema) should perform all their tasks from dedicated terminal server administration points (TSAPs) rather than from their desktops. This is a much more secure practice that minimizes any leaking of desktop malware, makes working with a separate administrative account much less cumbersome and provides a locked-down, customized administration point. Keep these TSAPs in their own OU, and use GPOs to prevent Internet access, restrict logon locally to administrative accounts only, increase auditing procedures, and implement a password-protected screen saver. Upgrading your TSAP to Windows Server 2003 will cause its Active Directory administration tools to sign and encrypt Lightweight Directory Access Protocol (LDAP) traffic between itself and your Windows Server 2003 DCs.
8. Disable Guest and Rename Administrator
Basic account security measures are to disable the guest account and rename the administrator account. You may have already done this. Either way, don’t forget to also remove the default description of these accounts, since that’s easy for bad guys to search for. Most programmatic attacks use the administrator account’s well-known Security Identifier (SID) rather than its name, so renaming Administrator is really of limited use. It does show that you’re using due diligence for security audits, however. The rename policy also can be useful for creating a honeypot Administrator account. This is an account named Administrator (after you’ve renamed the real account) that has a high level of auditing enabled. If anyone attempts to log onto this account by guessing the password, the attempt will be logged. If you have an event log monitoring utility, you can also trigger an alert.
9. Limit Access to the Administrator Account
You should severely limit the number of people who have access to the real Administrator account and password. For the highest level of security, consider the nuclear password option: two (or more) administrators generate two (or more) eight-digit, random, strong passwords separate from each other; then each admin enters his password into the password field. The account now has a password that is 16-digits or longer and that requires at least two administrators to log on; one administrator can’t do it alone.
10. Watch the DSRM Password
An often overlooked but important password is the Directory Service Restore Mode (DSRM) password on domain controllers. The DSRM password, unique to each DC, is used to log onto a DC that has been rebooted into DSRM mode to take its copy of Active Directory offline. You need to update the DSRM password regularly because with this password a local operator can copy NTDS.DIT (the Active Directory database) off the server and reboot before anyone noticed. In early builds of Windows 2000, the only way to change the password was to log on and change it manually—impractical if you have more than two DCs. Windows 2000 Service Pack 2 introduced the SETPWD command (see the Knowledge Base article “Configure Your Server Wizard sets a blank recovery mode password”) to remotely update the DSRM password. The NTDSUTIL command in Windows 2003 has the ability to change it remotely (see “How To Reset the Directory Services Restore Mode Administrator Account Password in Windows Server 2003″). Create a script to run this operation against your DCs, and run it regularly.
(From: http://blog.csdn.net/yjz0065/archive/2006/08/02/1011224.aspx)
Share This
