One of the more secret but possibly hottest new features of Longhorn Server is now “out of the closet”. It is something that has been in the last couple of customer preview versions of Longhorn available up on MSDN and blog entries from Microsoft and other parties are starting to pop up. Rumors have abounded for months and months. Some of us have known for many many many months and gave input on the whole thing but sworn to secrecy. What is it you ask???
Granular Password Policy Control!!!
[Author’s Note: All of the rest of this is about a feature that is still in a beta product, so all of it is subject to change at a moment’s notice, if you read this article and you don’t see what I am talking about, it is because it was beta when I wrote about it and it changed.]
Yes, Longhorn in its current form right now has the ability to allow multiple password policies in a single domain. Previously you couldn’t do this with a native configuration, you had to add additional domains. If you wanted to buy someone’s third party password filter or “roll your own”, you could also have multiple password policies for certain features like password length and history. Longhorn allows you to configure lockout, expiration, history, length, whether complexity is enabled or not, and more. Best of all, this can be manipulated at the global group or even at the user level.
Password policy for the domain is being taken out of the GPO system (though if you only want one policy for the entire domain you can keep it there, they aren’t forcing you to change) and put into AD objects called Password Settings objects. You can read more details of the implementation at Ulf’s blog
But the basics, in case Ulf’s blog isn’t available for some reason (or if I need to search my own blog to find the info again – this blog is starting to serve as part of my memory) are:
- Password Settings Objects (PSO) are created and have the various attributes (specified below) populated.
- The PSO is linked to users or global groups via a standard forward/backlink mechanism just like the membership of groups is populated. The forward link is on the PSO, the backlink is on the user/group object.
- Multiple PSO’s can be linked to a given user or group through group nesting however only one policy will be in effect for a user, it will not merge the policies as this would just cause tremendous confusion.
- You determine which PSO “wins” and is applied to a user via precedence values assigned to the PSO objects, lowest precedence wins. The precedence value is an arbitrary number that you define just like it is with site link metrics. It could be set in intervals of 1, 10, or whatever. If you have two PSO’s linked to a user object with the same precedence, lowest GUID on PSO wins (has to be something and this is consistent with several other “who wins” scenarios in AD).
- PSOs can only be applied to global groups… That is because the policies can only be applied to users in the domain where the policy exists, only users in the same domain as a global group can be members of a global group. This is a case where only having the choice of the one group scope makes perfect sense, quite unlike other arbitrary group requirements from some Microsoft and third party apps.
More nitty gritty details:
- Password Settings object objectClass: msDS-PasswordSettings
- Where are the objects kept: CN=Password Settings,CN=System,[Domain DN]
- Precedence is maintained in: msDS-PasswordSettingsPrecedence
- Reversible Encryption: msDS-PasswordReversibleEncryptionEnabled – Boolean – TRUE or FALSE
- Password History: msDS-PasswordHistoryLength – Integer – 0,1,2,3,4,5,…
- Complexity: msDS-PasswordComplexityEnabled – Boolean – TRUE or FALSE
- Length: msDS-MinimumPasswordLength – Integer – 0,1,2,3,4,5,…
- Minimum Password Age: msDS-MinimumPasswordAge – INT8 interval – this is just like it is specified on the NC Head previously
- Expiration: msDS-MaximumPasswordAge – INT8 Interval – ditto above
- Bad password count for lockout: msDS-LockoutThreshold – Integer – 0,1,2,3,4,5,…
- Reset bad password count: msDS-LockoutObservationWindow – INT8 Interval (see above)
- Lockout Duration: msDS-LockoutDuration – INT8 Interval (see above)
- Backlink on user/group object showing all linked policies: msDS-PSO-Applied
- Effective policy on a given user: msDS-Resultant-PSO (operational so you can’t query, only return)
So my personal thoughts on this???
I am elated, I think this is absolutely great. There are details that once people think about them will irk them but so what, this is functionality that companies have been clamoring for since I started working on NT4 back in the mid-90’s. The fact that they pulled the password policies out of the Group Policy system is one of the best things to happen with Group Policy ever. The domain password policy (amongst other items) being handled in GPOs was one of the most counter intuitive and confusing things about Active Directory, there are many good admins who still think you can set policy for domain users at the OU level because that is how GPOs work in general.
I would like to see more out of this. Specifically I would like to see some ability to specify some password complexity rules for instance, x number of alphanumeric characters, x number of special characters, x number of caps, can or can’t have userid in password, etc. I also requested this last week that they pass the PSO DN to the password filter DLL function (or alternately a structure with the attribute values) so that custom complexity filters could use that info easily.
I am certain this will cause heartache for some people and certainly some of my apps will need to be updated to reflect the changes, specifically FindExpAcc, OldCmp, Unlock will all need updates. However, I have no problem with this as I am so excited to see this capability in the product. I am very much applauding the efforts of MSFT and the DS teams involved to finally get this “in there”. THANK YOU!
Another good blog entry on this topic to check out is
joe
Although, this is better than nothing, it will be almost useless in large organizations unless MS decides to make dynamic group membership a reality. Then I could see the real potential. The fact that users could be a member of multiple groups makes this almost pointless unless, the group were automatically based on some other factor such as another attribute or object creation.
The idea, or at least as I see it, would be to create groups to match each policy and place the users into them directly when you set them up. Not sure why being in multiple groups would come into play here unless you were just linking the PSO’s to random groups. If you do that, then yes you will be falling back on your PSO Precedence.
I completely disagree on the being useless in large orgs comment. I do most of my work in 100k+ seats and see this as massively useful in those environments and honestly, not that difficult to manage. It isn’t something that should be changing all that much.