I can’t imagine that this will make the front page of People Magazine, but if you are a Network or Security Admin, I have great news for you. With Windows Server Longhorn, you will be able to implement Password Policies on a Per User and Per Group level, as opposed to the current Windows 2003 (and prior) limitation of one password policy per domain.
This new changes to Password Policy in Longhorn are covered in detail by Microsoft MVP Ulf B. Simon-Weidner here: http://msmvps.com/blogs/ulfbsimonweidner/archive/2007/03/12/windows-server-quot-longhorn-quot-granular-password-settings.aspx
Before I get too far into this post, I need to point to the definitive article(s) on password policies from former Microsoft Senior Security Strategist Jesper Johansson:
- The Great Debates: Pass Phrases vs. Passwords. Part 1 of 3
- The Great Debates: Pass Phrases vs. Passwords. Part 2 of 3
- The Great Debates: Pass Phrases vs. Passwords. Part 3 of 3
- Frequently Asked Questions About Passwords
You’re back? Feel smarter now? Alright… let’s continue.
With Windows 2000 and 2003, you can only apply password policies on two levels. Local and Domain. I know of very few folks that have password policies applied to individual computers, so we’ll keep our discussion to Active Directory Forests/Domain Password Policies. To make sure we’re on the same page, feel free to familiarize yourself with the following:
- Step-by-Step Guide to Enforcing Strong Password Policies
- Windows Server 2003 Security Guide Chapter 3: The Domain Policy
I’ll bet you didn’t think you were going to have this much homework when you clicked on the post! The practical aspect of the way password policies were architected in Windows 2000/2003 was that your password policy had to be a one-size-fits-all policy. Think about the different types of users you may have on an enterprise domain, and the ramifications of a one-size-fits-all policy:
Standard Users – If you implement a password policy requiring 24 characters, uppercase,lowercase, numbers, special characters, and non-printable characters (Alt+whatever)… guess what? They’re not going to remember their password, and it ends up on a sticky note on the side of their monitor. Or under their keyboard. Or in their pencil drawer. Or as their desktop background.
Network Administrators – Couple of problems here… Network Admins often have the keys to the kingdom, so it is critical that their accounts are not compromised. If your password policy is too lenient (to address those forgetful standard users) you end up with passwords that can be brute forced by any number of freely available or commercial password crackers. As well, it is a Best Practice for Network Admins to be issued separate accounts. One for their standard user activities (browsing the web, checking their webmail, posting to Digg); and a separate account that is ONLY to be used for administrative activities (adding users, installing Exchange, etc.). I’ll let you in on a secret… while network administrators may be Idiot Savants in regards to remembering arcane computing knowledge and acronyms… we can’t remember passwords any better than anyone else.
Guess who writes their passwords down? Cryptographer Bruce Schneier does (http://www.schneier.com/blog/archives/2005/06/write_down_your.html). Jesper Johanssen does (you did read his articles at the beginning, right?). From News.com: http://news.com.com/Microsoft+security+guru+Jot+down+your+passwords/2100-7355_3-5716590.html
“How many have (a) password policy that says under penalty of death you shall not write down your password?” asked Johansson, to which the majority of attendees raised their hands in agreement. “I claim that is absolutely wrong. I claim that password policy should say you should write down your password. I have 68 different passwords. If I am not allowed to write any of them down, guess what I am going to do? I am going to use the same password on every one of them.”
According to Johansson, use of the same password reduces overall security.
“Since not all systems allow good passwords, I am going to pick a really crappy one, use it everywhere and never change it,” Johansson said. “If I write them down and then protect the piece of paper–or whatever it is I wrote them down on–there is nothing wrong with that. That allows us to remember more passwords and better passwords.”
Johansson said the security industry had been giving out the wrong advice about passwords for 20 years.
Windows Vista and Longhorn make great strides towards allowing folks to run as Standard Users through User Account Control (even if they are administrators on their box), but too many organizations just take the easy route, and give godlike privileges to network admins on a single account. This is just asking for trouble.
- Understanding and Configuring User Account Control in Windows Vista
- MSDN: Managing User Account Control and Security Issues
- Getting Started with User Account Control on Windows Vista
- Mark Russinovich: PsExec, User Account Control, and Security Boundaries
Developers – This 3rd class of user has an entirely unique set of issues relating to password policy. For one thing, they have access to the source code and intellectual property that your entire company may run off of. If their network account is comprimised, could you stay in business if your trade secrets/code/IP made their way onto the internet, or into a competitor’s product? Compound this problem by the fact that Developers often need “test” accounts. They need to be able to test their application as test users, test admins, test service accounts… These accounts often have the same priveleges as real users, but none of the accountability. Who will notice if these accounts are misused?
The only solution do having different users with different password policies in the past was to create separate domains. You could assign one password policy to the “Development” tomain, a different password policy to the production domain… This raises administrative efforts fairly significantly, with very minor benefits. The Best Practice from Microsoft is to run with as few domains as possible. Ideally (unless you have business justification for having multiple domains), you should run a single Domain within a single Active Directory Forest. Before I get killed in the comments, I will stipulate that your particular Active Directory design requirements may be very different from everyone else. You may be a large Fortune 500 company with wholly-owned subsidiaries, or with regional presences that require different domains. That’s fine… I’m speaking in generalities 😉
What does this all mean? Long story short, the ability (with Windows Longhorn Server) to assign different password policies to different groups or users (depending on their specific security requirements) is a much-requested and much-anticipated feature. I will point you to the blog I linked to at the beginning, which discusses the technical details behind this change, as well as why this change affects Users and Groups, and Not Group Policy.