Get Exclusive Discounts and Free Computer Training
Signup to get our latest updates ...
Setting password policy at the domain level is like drinking moonshine from the barrel.
It gets the job done, but every once in a while, it would be nice to get a little more refinement.
With the new Server 2008 version, password policy has apparently aged enough for the boys in Redmond to smooth out a little rough spot in security administration.
Thanks to Windows Server 2008’s new fine-grain password feature, you are able to improve the enterprise security model.
No longer are you confined to only setting passwords at the domain level.
Now, you can implement password settings at a more specific and targeted level.
In fact, you’ve been implementing fine-grained passwords all over the place.
You’ve used so much fine grain that the high-end bakeries are starting to complain. What could possibly go wrong?
There are actually a lot of things that can go wrong.
Like the old-timers always say, "If it was easy, anybody could do it."
In an old Bugs Bunny cartoon, Bugs Bunny and Daffy Duck go back and forth trying to convince Elmer Fudd that it’s the season for hunting the other one. They stand in front of a sign tearing down page after page arguing, "Wabbit Season — Duck Season."
When it comes to fine-grained passwords, Elmer Fudd is the like the object in the Windows Server 2008 Active Directory. Bugs Bunny and Daffy Duck are the competing parameters trying to convince the object that it should listen to them.
A user can have many different relationships to the other objects in the enterprise. A user can be a member of multiple groups, for example. The user’s password settings are determined by these memberships and others.
The domain might have the password expiration set at 90 days (Wabbit Season). The user is also a member of the Denver Group which has had a fine-grained password setting linked to it which set the password expiration at 75 days (Duck Season).
The user is also a member of the Print Admins Group which has other fine-grained password settings and has a password expiration of 45 days (Weasel Season). Because the user has some additional admin access for a specific location, there are fine-grained password settings applied specifically on the user account to expire the password in 30 days (Llama Season).
No one likes to see Elmer Fudd running around the network, so Microsoft implemented an algorithm to determine which settings to apply.
This algorithm creates a Resultant Set of Policy (RSOP) for each user object. Obviously, the algorithm applies only if there is more than one set of parameters being applied to the same object.
Although Windows Server 2008 is setup to handle the conflicts that may arise by having more than one fine-grained password policy linked directly to a user object by taking the one with the lower precedence, it still doesn’t like it.
There should really only be one policy linked directly to the user, so if there is more than one, a warning message will be logged into the event log. Depending on how many users have this problem, this can be very repetitive and fill up your logs.
Fine-Grained Password Policies cannot be added directly to an organizational unit. As a result, many administrators create a global security group that has the same members as the OU. This group is called a shadow group.
Everything works great until a user moves OUs. Moving the user from one OU to another does not move them from the shadow group. Since the shadow group has the password policy linked to it, the user will still be subject to the old password policy unless they are manually moved from the shadow group.
As a systems administrator, you’ve seen your fair share of conflict. When one group wants to go to Flingers for happy hour, and another wants to go to Chochkies, things can get ugly.
With Windows Server 2008, it doesn’t have to be that way, at least for your password policies. Microsoft has STILL not delivered a usable happy hour decision tool. I suggest checking online.
Precedence values are set in each fine-grained password policy, and help resolve any conflicts. These values can only be integers and the lower value wins the argument. A not so common mistake is to give multiple policies the same value. Just don’t do it.
What is a common mistake is to simply start at 1 and then go to 2 and then 3 and so on. Sooner or later, a re-order will be necessary, and when you have 61 fine-grained password policies carefully crafted to have the right precedence values, sticking a new one in at number five requires a lot of tedious work.
(Go into the policies that have a 5 value and change the value to 6; Go into the policies that have a 6 value and change the value to 7…)
Save yourself a lot of future trouble by making a simple structure based on 100. Make your first (most important) policy have a value of 100, your second 200 and so on.
Then, eight months from now when a security audit compels a new fine-grained policy that needs to go between the 4th and 5th ones, you just set its value at 450, and then head out to happy hour.
(I’d go with Flingers.)