Most environments these days use some sort of enterprise-wide policy management. Group Policy has a lot of settings that can make or break security in an Active Directory environment. I omitted some that I would normally have put in this list, but Microsoft, it seems, has gotten a little smarter over the years and made some of these settings most secure by default. This is not a complete list by any means, but a basic list of some of the more essential account and password settings that can be applied with Group Policy.
Account and Logon Security
Quite a few settings need to be considered in: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
Guest account status. This should be set to Disabled to prevent Guest accounts from being active on member machines.
Rename administrator account. It’s a good idea to enable and rename the built-in administrator as an added “security through obscurity” measure. When you can move away from using defaults, it’s always best.
Do not display last user name. This should be set to Enabled. There really should be no information about the previous user available at a logon prompt, especially on machines that could be easily accessed by outsiders.
Machine inactivity limit. This should be set to Enabled and set to a time frame that makes sense. This comes in handy as a fail safe method for users who forget to log out at the end of the day or lock their screen before leaving their workstation for an extended amount of time. Obviously, the shorter duration, the more secure. It’s important to find a time that helps secure the desktops without unnecessarily continually locking out the user while they are working at their desk. I think anywhere from 10 to 30 minutes is appropriate depending on the environment.
Number of previous logons to cache. Ideally, it’s best not to cache any logons except when explicitly needed. For example, laptops. Permanent workstations should not cache logons unless the organization has frequent connectivity problems. Laptops that roam on and off the network should have a limited amount of cached logons. 1 can suffice, but it is important to remember that if the setting is “1″, then the cached logon on the machine will be the last account that logged onto the domain from that machine.
Do not allow storage of passwords and credentials for network authentication. This setting can be frustrating, but is needed for an environment that is serious about security. Most applications and functions do not need to store credentials. Every now and then a server app or scheduled task will require this. In my experience, the best practice is to explicitly enforce a separate GPO on these servers. For example, in a “Application Servers” OU, have a sub-OU named “Application Servers CS”. In this separate OU you can enforce (override) with a policy that allows this sort of storage.
LAN Manager authentication level. This should already be enforced by default in most environments, but I included it here because it’s so important. It is very important that this is set to NTLMv2 only. While far from perfect, using any older hashing methods is much less secure.
Some other settings to consider in Computer Configuration > Windows Settings > Security Settings > Account Policies > Account Lockout Policy:
Account Lockout Threshold. The amount of times an account can fail at authentication before becoming locked. Typically set anywhere from 3 to 6 depending on the environment.
Account Lockout Duration. For maximum security, leave this to indefinite by setting it to “0″. This will require an administrator to unlock the account before it can be used again.
If your organization has a formal Password Policy, or another policy which states password requirements, make sure that Active Directory is enforcing this policy to the best of its ability. Microsoft has fairly weak enforcement when it comes to complex passwords, but nonetheless these settings should always be applied at the domain level via Group Policy. These settings are located in: Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy
Passwords must meet complexity requirements. When this setting is set to Enabled, it enforces semi-complex passwords for user accounts. What I mean by “semi” is that Microsoft decided to let users choose a required 3 out of 5 attributes for complexity (Uppercase, Lowercase, Digit, Special Character, Unicode), and only requires a minimum length of 6 characters. This means a user could have a password with no special character, or no uppercase characters, etc. Since a minimum of 6 characters is too low, you must rely on another setting to compensate for this, which I will touch on next. Due to the limited pool of complexity requirements to choose from, it’s important to focus on employee training that stresses the the company policy requirements despite the lack of technical enforcement.
Minimum password length. If your policy dictates a minimum password length, this is where to enforce it. This will override the 6 character minimum of the complexity requirement. The current standard for secure environments should dictate a minimum of 10 to 12 characters. Not only does this make the hash more secure, but has an added effect of putting the hashes out of the default ranges of tools such as John the Ripper, who by default work on 8 characters or less (without re-compiling).
Enforce password history. Enable this and set a value to determine the interval in which a user could attempt to use the same password again. Microsoft recommends leaving this to 24 for most organizations, though depending on your password age, you could go lower if needed. If you do the math, at a history of 24, with a 90 day maximum age, that means users wouldn’t be able to use the same password again until 6 years later! It’s hard to find a reason why you would want users to ever use the same password again though.
Maximum password age. This should be set to a maximum of 90 days or less depending on your password complexity. The idea behind this setting, is that the user will be forced to change their password after the age expires. Using a setting too low can frustrate users (and your helpdesk), and using a setting too high increases the risk of exposure too much. A formula for this, is to set an age that works harmoniously with your policy based on how long it would take someone to crack one of your password hashes. If you have determined that your password hash can be easily brute force cracked in 45 days time, then you want a password age of less than that; say 30 days.
Minimum password age. Setting a minimum password age prevents a user from quickly changing their password over and over to reach the history maximum in order to use the same password again. This is typically set to something that would prevent this sort of activity, such as 2 to 5 days.