Get a glimpse inside Roberta Bragg's new book "Hardening Windows systems" with this series of book excerpts. This excerpt from Chapter 1, "An immediate call to action," explains why and how to create a strong password policy. Click for the complete book excerpt series or purchase the book.
Strengthen the password policy
A strong password policy can go a long way. By a strong password policy, I mean a policy that
- Insists on frequent password changes
- Requires long passwords composed of random combinations of upper and lowercase letters, numbers and special characters
- Does not allow blank passwords
- Checks to ensure passwords are not repeated
- Prevents the use of any part of the user's name or user ID
- Does not allow the use of common dictionary words
You can provide technical controls that require most of this functionality by configuring the password policy of the default domain Group Policy Object (GPO) as shown in Figure 1-1.
A strong password policy is important because a weak policy makes it easier for intruders to guess or crack passwords. If passwords can be obtained, much of the security enforced by user rights, object permissions, and even file encryption falls by the wayside. Strengthening the password policy is probably the single most important blow you can strike for security.
Oh, I know that this may be something you cannot do for the whole organization. You can, of course, easily change the password policy of Windows domains. However, you may not have the authority to do so. Changing something that so broadly impacts every employee is never a move that can, or should, be undertaken lightly. Still, you should start work on it.
Meanwhile, you can, and do, have the authority to change the "logical" password policy. That is, the technical control of changes at the domain level may not be possible right away, but you can, depending on your authority, demand stronger passwords and password management by members of your own staff, by those who have local accounts on servers, and if nothing else, by yourself. While nothing may make you, or any other administrative staff member, use a 16-character password, or one composed entirely of symbols; while nothing will force you to change it every 10 days; there is also nothing that says you cannot impose these restrictions by policy on IT administrators, or anyone who requires special access to servers. Examples of special access involve those who do backups, or anyone who must be an administrator on a server in order to effectively administer a database or other server application.
The accounts that, if compromised, pose the greatest risk may be the ones that you can change the password policy for. Think of the damage that an attacker could do by obtaining these administrative passwords!
Changing the password policy for the organization is something you may have to work toward. Changing the policy for users with elevated privileges may be something that you can do, promote, or set in motion. Anything that you can do to impact password management for the better makes your information systems more secure. At the very least, change yours, right now!
Create logical policies
Changing the password policy for an organization may be a rather large undertaking. If users can now use blank passwords or short ones, and if they do not have to meet complexity rules, making them comply with more restrictive rules may prove to be beyond your authority. This is something that you should evaluate, and it is really of the utmost importance. No single change can have as much impact on the security of your networks. Chapter 2 details many important issues surrounding the strengthening of password policy. Chapter 14 provides help in surmounting the political problems you may encounter.
You can, however, immediately improve the security of your networks by creating a logical password policy for a select group of individuals: those who have elevated privileges in the enterprise, in the domain, or on some systems. A prime target for such a policy are system and network administrators. IT admins and their management should be receptive to changes that will improve information security.
Perhaps you can spearhead change by making the adoption of a strong password policy the result of working together to improve security. Working out ways to strengthen the policy without making it overly difficult to adhere to will make it easier to obtain and implement a stronger organization-wide password policy.
Change policy for local accounts
Local accounts on servers and workstations cannot be entirely eliminated. Windows computers that are domain members retain their local account databases. Any accounts in these databases cannot be managed by the domain password policy. A password policy for these accounts should also be in place. This policy can be a very strong policy. In many organizations, local accounts are not used, with the exception of some administrative accounts on some servers. If accounts are not used, then password policies can be very restrictive; if accounts are used, then password policies should be very restrictive, and it should not be difficult to obtain approval, since many of these computers are controlled by IT.
Local password policies for NT 4.0 computers, and for those Windows computers joined in a Windows NT 4.0 domain, must be configured on the local system, or via custom scripts. Local password policies for computers joined in a Windows 2000 or Windows Server 2003 domain can be set and managed via Group Policy. Remember, password policies set at the OU level affect only the local user accounts of the computers in the OU. To use Group Policy to manage the password policy of local user accounts:
- 1. Place the accounts of servers for which the same password policy is required, in the same OU.
2. Create a GPO and link it to the OU.
3. Open the GPO for editing and modify the password policy.
4. Close the policy.
Change policy for individual accounts
In addition to domain password policy and local password policy, changes can be made at the account level. That is, you can impact the password policy of an individual account. In many cases, changing policy at the account level is a way to prevent the weakening of password policy for the domain. Options may also strengthen policy.
For example, in some cases, it may be required to store a password using reversible encryption. This is not recommended; however, it is still better to do so for a couple of accounts, using the Store Password Using Reversible Encryption option, than it is for all accounts in the domain. Another questionable option is Password Never Expires.
Expiring passwords is a way to make sure users change their passwords. Blocking this action weakens that technical control. However, if accounts are used by services, then passwords must be manually changed—the service program will not recognize or respond to reminders to change passwords and will simply be locked out when the password expires. Using the account level option allows the domain-level password policy to require periodic password changes. Incredibly, I still find domains where no user accounts are required to change passwords, because service accounts cannot.
While both of these options can weaken individual account protection, setting account level policy can strengthen protection for an individual account. For example, the option Smart Card Is Required for Interactive Logon can be set for an individual account. Long before smart cards can be installed as the primary authentication mechanism for an organization, it may be possible to require their use by administrators, or by other privileged users.
Finally, other options are temporary controls that can do much to prevent unauthorized account usage, the goal of a password policy in the first place. These options include
- User Must Change Password at Next Logon
- Account Is Disabled
- Account Is Sensitive and Cannot Be Delegated
Modify account password policy options on the Account tab of the Active Directory Users and Computers, user account property page as displayed in Figure 1-2.
Click for the next excerpt in this series: Lock down remote administration.
Click for book details or purchase the book.
This was first published in August 2004