Your network consists of a single Active Directory domain. User accounts for engineering
department are located in an OU named Engineering.
You need to create a password policy for the engineering department that is different from
your domain password policy.
What should you do?
A.
Create a new GPO. Link the GPO to the Engineering OU.
B.
Create a new GPO. Link the GPO to the domain. Block policy inheritance on all OUs
except for the Engineering OU.
C.
Create a global security group and add all the user accounts for the engineering
department to the group. Create a new Password Policy Object (PSO) and apply it to the
group.
D.
Create a domain local security group and add all the user accounts for the engineering
department to the group. From the Active Directory Users and Computer console, select the
group and run the Delegation of Control Wizard.
Explanation:
http://social.technet.microsoft.com/Forums/en-US/winserverGP/thread/b3d11cd4-897b-
4da1-bae1-
f1b69441175b
Complex Password Policy on an OU
Q) Is it possible to apply a complex password policy to an OU instead of entire domain
(Windows 2008 R2). I’m
under the impression it can only be applied to either a security group or an individual user.
A1)
I beleive you are referering to PSC and PSO.
The Password Settings Container (PSC) object class is created by default under the System
container in the
domain. It stores the Password Settings objects (PSOs) for that domain. You cannot
rename, move, or delete
this container.
PSOs cannot be applied to organizational units (OUs) directly. If your users are organized
into OUs,
consider creating global security groups that contain the users from these OUs and then
applying the
newly defined fine-grained password and account lockout policies to them. If you move a
user from
one OU to another, you must update user memberships in the corresponding global security
groups.
Groups offer better flexibility for managing various sets of users than OUs.
For the fine-grained password and account lockout policies to function properly in a given
domain, the domain
functional level of that domain must be set to Windows Server 2008.
Fine-grained password policies apply only to user objects and global security groups. They
cannot be applied
to Computer objects.
For more info, please see below article:
http://technet.microsoft.com/en-us/library/cc770842(WS.10).aspx
AD DS Fine-Grained Password and Account Lockout Policy Step-by-Step Guide
A2)
Here is a link to how you setup find grain password policy… However you can only apply it to
a Security Group.
http://www.grouppolicy.biz/2011/08/tutorial-how-to-setup-default-and-fine-grain-passwordpolicy/ A3:
In addition, for fine grated password policy ; you need DLF 2008 and you can apply that
policy on a single user and only global security group.
Find the step by step info.
http://social.technet.microsoft.com/wiki/contents/articles/4627.aspx
http://www.grouppolicy.biz/2011/08/tutorial-how-to-setup-default-and-fine-grain-passwordpolicy/
Tutorial: How to setup Default and Fine Grain Password Policy
One strange thing that still seems to catch a lot of people out is that you can only have one
password policy for your user per domain. This catches a lot of people out as they apply a
password policy to an OU in their AD thinking that it will apply to all the users in that OU….
but it doesn’t. Microsoft did introduce Fine Grain Password Policies with Windows Server
2008 however this can only be set based on a security group membership and you still need
to use the very un-user-friendly ADSI edit tool to make the changes to the policy.
Below I will go through how you change the default domain password policy and how you
then apply a fine grain password policy to your environment. The Good news is setting the
default password policy for a domain is really easy. The Bad news is that setting a fine grain
password policy is really hard.
How to set a Default Domain Password Policy
Step 1
Create a new Group Policy Object at the top level of the domain (e.g. “Domain Password
Policy”).
Note: I have elected to create a new GPO at the top of the domain in this case as I always
try to avoid modifying the “Default Domain Policy”, see references below.
Reference)
http://technet.microsoft.com/en-us/library/cc736813(WS.10).aspx
TechNet: Linking GPOs
If you need to modify some of the settings contained in the Default Domain Policy GPO, it is
recommended that you create a new GPO for this purpose, link it to the domain, and set the
Enforce option.
http://technet.microsoft.com/en-us/library/cc779159(WS.10).aspx
TechNet: Establishing Group Policy Operational Guidelines
Do not modify the default domain policy or default domain controller policy unless necessary.
Instead, create a new GPO at the domain level and set it to override the default settings in
the default policies.
Step 2
Edit the “Domain Password Policy” GPO and go to Computer
Configurations>Policies>Windows
Settings>Security Settings>Account Policy>Password Policy and configured the password
policies settings to the configuration you desire.
Step 3
Once you have configured the password policy settings make the “Domain Password Policy”
GPO the highest in the Linked GPO processing order.
TIP: Make sure you inform all your users when you are going to do this as it may trigger
them to change their password the next time they logon.
Done… told you it was easy….
Note: Even if you apply the password policies to the “Domain Controllers” OU it will not
modify the domain’s password policy. As far as I know this is the only exception to the rule
as to how GPO’s apply to objects. As you can see in the image below the “Minimum
password length” in the “Domain Password Policy” GPO is still applied to the domain
controller even though I have another GPO linking to the “Domain Controllers” OU
configuration the same setting.
For a better explanation as to why the GPO that is linked to the Domain and not the Domain
Controllers is used for the password policy for all users check out Jorge’s Quest for
Knowledge! – Why GPOs with Password and Account Lockout Policy Settings must be
linked to the AD domain object to be affective on AD domain user accounts
(http://blogs.dirteam.com/blogs/jorge/archive/2008/12/16/why-gpos-with-password-andaccountlockout- policy-settings-must-be-linked-to-the-ad-domain-object-to-be-affective-onad-domain-useraccounts.aspx)
How to set a Fine Grain Password Policy
Fine Grain Password Policies (FGPP) were introduced as a new feature of Windows Server
2008. Before this the only way to have different password polices for the users in your
environment was to have separate domains… OUCH!
Pre-Requisites/Restrictions
You domain must be Windows Server 2008 Native Mode, this means ALL of your domain
controllers must be running Windows Server 2008 or later. You can check this by selection
the “Raise domain functional level” on the top of the domain in Active Directory Users and
Computers.
http://technet.microsoft.com/en-us/library/cc770394(WS.10).aspx
AD DS: Fine-Grained Password Policies
The domain functional level must be Windows Server 2008.
The other restriction with this option is that you can only apply FGPP to users object or users
in global security groups (not computers).
Reference
http://technet.microsoft.com/en-us/library/cc770394(WS.10).aspx
AD DS: Fine-Grained Password PoliciesFine-grained password policies apply only to user objects … and global security groups.
TIP: If you setup an “Automatic Shadow Group
(http://policelli.com/blog/archive/2008/01/15/manage-shadowgroupsin-windows-server-2008/)” you can apply these password policies to users automatically to
any users located in an OU.
Creating a Password Setting Object (PSO)
Step 1
Under Administrator Tools Open ADSI Edit and connect it to a domain and domain controller
you want to setup the new password policy.
Note: If you do not see this option go to “Turn Windows Features On or Off” and make sure
the “AD DS and AD LDS Tools” are installed. (You will need RSAT also installed if you are
on Windows 7).\
Step 2
Double click on the “CN=DomainName” then double click on “CN=System” and then double
click on “CN=Password Settings Container”.
Step 3
Right click on “CN=Password Settings Container” and then click on “New” then “Object.
Step 4
Click on “Next”
Step 5
Type the name of the PSO in the “Value” field and then click “Next”
Note: With the exception of the password length the following values are all the same as the
default values in the “Default Domain Policy”.
Step 6
Type in a number that will be the Precedence for this Password Policy then click “Next”.
Note: This is used if a users has multiple Password Settings Object (PSO) applied to them.
Step 7
Type “FALSE” in the value field and click “Next”
Note: You should almost never use “TRUE” for this setting.
Step 8
Type “24” in the “Value” field and click “Next”
Step 9
Type “TRUE” in the “Value” field and click “Next”
Step 10
Type “5” in the “Value” field and click “Next”
Step 11
Type “1:00:00:00” in the “Value” field and click “Next”
Step 12
Type “42:00:00:00” in the “Value” field and click “Next”
Step 13
Type “10” in the “Value” field and click “Next”
Step 14
Type “0:00:30:00” field and click “Next”
Step 15
Type “0:00:33:00” in the “Value” field and click “Next”
Step 16
Click “Finish”
You have now created the Password Settings Object (PSO) and you can close the ADSIEdit
tool.
Now to apply the PSO to a users or group…
Step 17
Open Active Directory Users and Computers and navigate to “System > Password Settings
Container”
Note: Advanced Mode needs to be enabled.
Step 18
Double click on the PSO you created then click on the “Attribute Editor” tab and then select
the
“msDS-PSOAppliedTo” attribute and click “Edit”
Step 19
Click “Add Windows Accounts….” button.
Step 20
Select the user or group you want to apply this PSO and click “OK”
Step 21
Click “OK”
Step 22
Click “OK”
And your are done… (told you it was hard).
Fine Grain Password Policies as you can see are very difficult to setup and manage so it is
probably best you use them sparingly in your organisation… But if you really have to have a
simple password or extra complicated password then at least it give you away to do this
without having to spin up another domain.
