Thursday, 18 July 2013

How password policy works in Active Directory

In this article, I am going to explain about how password policy is working in Active Directory based environment. Before proceed I have listed important points about Password Policy here.
  1. By default, the Default Domain Policy defines the password policies for every user in Active Directory and every user located in the local Security Account Manager (SAM) on every server and desktop that joins Active Directory.
  2. There can be only one Password Policy for domain users in a Windows 2000 and Windows Server 2003 Active Directory domain.
  3. It's not possible to configure the Password Policy for an Organizational Unit (OU) of users to be different than that of other users in the domain or in a different OU.
  4. The Password Policy settings can't be extended to include additional settings without using a third-party tool or developing a custom password policy solution.
  5. It's not possible to configure a password policy for the root domain and have it "funnel" down to the other domains in the Active Directory tree.

Possible Settings in the password Policy

     When you edit the GPO Default Domain Policy through Group Policy Management Console (GPMC), you'll find the Password Policy settings under the Account Policies category,

Go to the node Account Policies: Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies.

The default settings of Default Domain Policy are shown in figure.

default password policy settings

Limitations of the Password Policy for Domain Users

To ensure you understand what I mean by domain users, let's scope out where these users reside. Domain users are those users that are created and stored in the Active Directory database. This means all users stored on your domain controllers (DCs) fall under this definition. One easy way to see whom this entails would be to open up the Active Directory Users and Computers (ADUC) and do a search on all users for that domain. Every user that shows up on that search falls into this scope.

The only way to control the password policy for domain users is to configure the aforementioned Password Policy in a GPO that linked to the domain. That is the only way by default! Yes, it's true the GPO that contains the default password policy settings is the Default Domain Policy, but this is just the default. You can easily create a new GPO, configure the Password Policy settings as per your wish and ensure this GPO has the highest precedence in the GPMC. The result will be that this new GPO will control the Password Policy settings for all domain users.

Default Password Polices

When you install a new Active Directory domain within Windows Server 2008 or Windows Server 2008 R2, or upgrade a Windows 2000 or Windows Server 2003 domain to have Windows Server 2008 or Windows Server 2008 R2 DCs, you can configure the domain to be at the Windows Server 2008 Domain Functional Level. At this functional level, you have more capabilities for configurations within the domain, but that doesn't mean that the default behavior changes. This is the case with the Account Policies for domain users.

When you have a basic Active Directory domain that's running at the Windows Server 2008 Domain Functional Level, the Password Policy for all domain users behave the exact same way they always have. A Windows Server 2008 or Windows Server 2008 R2 Active Directory domain, without FGPPs implemented

Fine Grained Password Policies (FGPPs)

The previous section was clear in stating that the default behavior of the Account Policies in a Windows Server 2008 and Windows Server 2008 R2 domain is exactly the same as it is in any other Active Directory domain before it. The difference comes when the Active Directory domain contains only Windows Server 2008 or Windows Server 2008 R2 DCs, and is moved to Windows Server 2008 Domain Functionality Level. When this occurs, it opens the door for FGPPs. Again, just to reiterate, without FGPPs configured, any Windows domain (including Windows Server 2008 R2 domains) acts the same as it always has.

The reason you'd want to configure FGPPs is to allow multiple password policies in the same Active Directory domain. Yes, that's correct. The same Active Directory domain can have multiple password policies. The result could be the following:
  • IT employees have a minimum character limit of 20
  • HR and finance employees have a minimum character limit of 15
  • Standard employees have a minimum character limit of 10
In order to configure FGPPs, you won't be using Group Policy -- FGPPs don't use Group Policy. Instead, the implementation of FGPPs is done by modifying the Active Directory database. The database is altered by adding one or more additional Active Directory objects, referred to as Password Settings Objects (PSOs). This might sound odd, and I must agree it is. If you decide to implement FGPPs, you'll have a mixture of Account Policy settings, via GPOs and FGPPs, in your environment.

How to create Fine Grained Password Policy ?

   Follow the below steps to create fine grained password policy
  1. Launch ADSI Edit management console on your DC by the command ADSIEdit.msc through command line or Run window.   
  2. Select the View toolbar menu option, then click on the Connect to option.
  3. In the Connection Settings dialog box click the OK button.
  4. Within ADSIEdit, expand the view of your domain down to the CN=System, so you can see the contents available under this node.
  5. Right-click on the CN=Password Settings Container.
  6. Select the option to Create | Object.
Refer the below screenshot:

create fine grained password policy

Fill the following values in subsequent windows and create new fine grained password policy

CN :  DevPasswordPolicy






msDS-MinimumPasswordAge-864000000000 (Minimum password age -one day)

msDS-MaximumPasswordAge-36288000000000 (Maximum password age -42 days)

msDS-LockoutThreshold : 30

msDS-LockoutObservationWindow :  -18000000000 (Elapsed time to reset password lockout counter to maximum - 30 minutes)

msDS-LockoutDuration-18000000000 (If the number of bad passwords is met in observation window time, this defines how long the account should remain locked out - 30 minutes)

Software Developer


No comments:

Post a Comment