Does Active Directory keep you up at night? One could easily understand why. It is most likely the largest and most critical distributed system in your enterprise. Along with
disaster recovery, Active Directory® security is at the top of the list of topics that gnaw away at an administrator’s sleep.
But there’s a lot you can do to enhance your Active Directory security, and you’ve probably already taken some steps. What follows is a list of tips you can use to help you make your Active Directory installation more secure. First I’ll cover administrative security, then passwords and group security, then wrap up with tips for domain controller security.
1. Document What You Have
The very first step you need to take is to document your Active Directory configuration. It’s not very exciting work, but you can’t tell where you need to go if you don’t know where you are right now. 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. Control Your Administration
Active Directory security begins right at the top—your administration model. 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. (For a good password generator, take a look at www.winguides.com/security/password.php.) 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.
11. Enforce Strong Password Rules
By now, you all know the benefits of strong passwords, but it’s probably too much to expect your users to use them willingly. To help them along, you really should enforce strong password rules in your domain (see "Enabling Strong Password Functionality in Windows 2000"). You can help your users by suggesting strategies such as the use of passphrases instead of confusing word/number/character combinations.
12. Protect the Service Account’s Password
As you know, service accounts are another sore subject. The nature of service accounts—used on application servers for the application’s service—makes a low-impact password change very difficult, and so the password is usually set to never expire. Because the account controls an important service (often on many servers), compromising the service account’s password is not something you want to happen.
Though it may be difficult to solve the password change problem, you can take steps to mitigate the risk of attack or accidental changes. Give the accounts a naming convention that identifies them as service accounts and suggests what they’re used for. Put all of these accounts into a group named something like "Service Accounts" and apply a policy to your application servers to deny the "Log on Locally" policy but allow "Log on as a Service". Keep them in their own OU so you can apply GPOs unique to their requirements.
13. Make Sure that Each DC is Physically Secure
Domain controllers make up the physical aspect of Active Directory. Distributed throughout your enterprise, each DC has its own copy of the Active Directory database NTDS.DIT. This means that one of your paramount security concerns is to make sure that each DC is physically secure. If one of them grows legs and walks off, the thief will have physical access to the directory information tree (DIT) and can run cracking programs against it to obtain usernames and passwords. Therefore, you must have a reaction plan in place to change all passwords in a domain if one of its DCs is stolen.
A proposed feature of the forthcoming version of Windows Server (code-named "Longhorn") aims to mitigate the risk from this scenario dramatically with the read-only domain controller (RODC), a DC whose DIT contains no user passwords. Users are logged on via a Kerberos referral from a full DC; you can configure the RODC to cache the passwords of users who use it for authentication. In a branch office scenario, only the branch office’s users will have their passwords cached on the RODC so if it’s compromised they’re the only passwords that must be changed immediately. The RODC caching configuration is very flexible; it even includes a way to determine who had their password cached on it. As with all discussion of prerelease software, though, this is subject to change.
14. Minimize Unnecessary Services and Open Ports
The Windows Server 2003 SP1 Security Configuration Wizard can quickly harden your DCs in this aspect by stepping you through a wizard to lock it down.
One attack to be wary of—a denial of service of sorts—fills the available disk space on a DC. There are two ways this attack can be executed. The first is by attempting to flood Active Directory with objects. Because Active Directory is hugely scalable, it is unlikely to crash in this scenario, but flooding Active Directory with objects will increase the size of the database until it fills the disk partition. Besides ensuring the DIT is on a partition with lots of free space, consider implementing directory quotas via DSMOD PARTITION or DSMOD QUOTA. This will prevent any one security principal from adding too many objects to the directory.
Another denial of service attack has to do with flooding the SYSVOL folder with files, causing it to fill up the boot partition, and crashing the DC. You can’t use a quota system in this case, but you can create a simple reserve file or files to take up existing free disk space. If you encounter this type of disk-filling situation, simply erase reserve files, one at a time, to maintain free disk space until you resolve the root cause. You can easily create reserve files with the FSUTIL FILE CREATENEW command.
15. Make the DC Time Source Secure
Because Active Directory depends on Kerberos, it’s very sensitive to time variations between its DCs. This is especially true in trusts between forests because they may rely on different time hierarchies. By default, the PDC operations master in the root domain is the reference to which all other DCs in the forest look for accurate time. What time source does this DC look to for accurate time? Is it secure?
16. Audit Important Events
You must enable auditing in a domain-level GPO, with no override, to ensure every system in your domain is tracking important events. You should audit failed logons, successful and failed account management, object access, and policy change. Use the same GPO to boost the security log size, because with the increased auditing you’ll need it.
17. Use IPsec
Many organizations have dragged their feet on the implementation of IPsec because of the complex rules you must build, but it’s relatively easy to implement for inter-DC communication only. For communications from DCs to clients, there are a number of options to consider. Windows Server 2003 DCs by default have SMB signing enabled, which means they sign all their communications to the client to prevent spoofing. Its policy is listed as "Microsoft network server: Digitally sign communications (always)". Be aware of this change when you upgrade, and don’t disable it if you don’t have to.
18. Don’t Store LAN Manager Hash Values
You should try to rid yourself of LM (Lan Manager) password hashes if possible; many password crackers attack the weak LM hash and then deduce the stronger NTLM hash. The policy you need is "Do Not Store LAN Manager Hash Value on Next Password Change". Also consider enabling "Send NTLM v2 response only, refuse LM and NTLM". Most down-level clients can be configured to use NTLMv2. This may not be possible for Active Directory installations in factory environments or other installations where embedded Windows is used. Test these settings carefully because they can break down-level clients. It’s important to remember that these clients not only include Windows NT 4.0 and Windows Me, but also other Server Message Block (SMB)-enabled network clients like network attached storage (NAS) devices, UNIX clients running Samba, or embedded Windows devices like factory station controllers. The Knowledge Base article "Client, service, and program incompatibilities that may occur when you modify security settings and user rights assignments" lists recommendations for most DC security settings and user rights.
19. Don’t Forget Your Business Practices
Handle emergencies and document procedures for facing situations like compromised passwords, general Active Directory attacks, and Active Directory disaster recovery. Microsoft has done much of this work for you in "Best Practice Guide for Securing Active Directory Installations", and "Best Practices: Active Directory Forest Recovery".
Prerelease info in this article is subject to change.
Nessun commento:
Posta un commento