1. 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.
2. 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.
3. 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.
4. 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.
5. 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?
6. 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.
7. 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.
8. 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.
9. 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”.
More information you can via :http://blog.csdn.net/yjz0065/archive/2006/08/02/1011224.aspx