مشکل با check the minimum password length password complexity and password history requirements

[hadi576]

سلام خدمت دوستان
من ویندوز سرور 2008 r2 را نصب کردم و اکتیو داریکتوری را هم نصب کردم. حالا داخل OUها میخواهم یوزر تعریف کنم ولی پیغام
check the minimum password length password complexity and password history requirements را میدهد
البته پالیسی پسورد را داخل OU مربوطه اعمال میکنم ولی باز هم قبول نمیکند.
اگر پالیسی پسورد را داخل default domain policy اعمال کنم بر روی همه OUها اعمال میشود! و من نمیخواهم
لطفا راهنمایی کنید

---

موضوعات مشابه:

• history password on domain
• minimum hardware requirements برای ESX
• چگونگی RESET کردن ACTIVE DIRECTORY PASSWORD بدون دونستن PASSWORD
• SYSKEY password
• مشکل با Password ذخیره شده

---

[Mehdi-H]

با سلام ...
تا اونجایی که در حیطه اطلاعات بنده هست، به طور کلی چنین امکانی در سرور وجود نداره. شما نمیتونی همزمان برای ساخت چند کاربر Password Complexity رو رعایت کنید و برای چند کاربر دیگر رعایت نکنید ...

[SADEGH65]

سلام خدمت دوستان
من ویندوز سرور 2008 r2 را نصب کردم و اکتیو داریکتوری را هم نصب کردم. حالا داخل OUها میخواهم یوزر تعریف کنم ولی پیغام
check the minimum password length password complexity and password history requirements را میدهد
البته پالیسی پسورد را داخل OU مربوطه اعمال میکنم ولی باز هم قبول نمیکند.
اگر پالیسی پسورد را داخل default domain policy اعمال کنم بر روی همه OUها اعمال میشود! و من نمیخواهم
لطفا راهنمایی کنید

داشتن پالیسی های منفاوت در موردپسورد از ویندوز 2008 به بعد امکان پذیر شده و برای این مورد باید Granular Password Settings تعریف نمایید.
Configuring Granular Password Settings in Windows Server 2008, Part 1

Introduction

In previous versions of Active Directory (AD) we had only one password and account lockout policy for the entire domain. Some companies had to use multiple domains to place different password policies on different users; others had to develop their own password filters or buy third party solutions. With Windows Server 2008 we have the option to specify different password policies for different users and groups “out-of-the-box”.
This first of two articles is a “walkthrough” on creating a password policy in addition to the usual one we have in the “Default Domain Policy” Group Policy placed on the domain level.
New in class

In short the new functionality, referred to as “Granular Password Settings” or “Fine-Grained Password Policy“, is based on the introduction of two new object classes in the AD schema: the “Password Settings Container” and “Password Setting” objects. These objects basically provide us the option to introduce multiple password policies into a single AD domain. But let us take a look at what else we need…
The tools and prerequisites

This is a quick view on the tools and prerequisites needed for creating additional password policies.
ADUC
First of all the Active Directory domain functional level must be “Windows Server 2008”. This can be checked using Active Directory Users and Computers (ADUC) – Right click the domain > choose “Raise domain functional level” – the current domain functional level should read “Windows Server 2008” (below is a screenshot from the beta 3 version of Windows Server 2008 build 6001):

Figure 1
GPMC
We will still have to use the Group Policy Management Console (GPMC) to set the default password policy for the entire domain (the “fallback” policy you could say). If you have forgotten how to set the default domain password and lockout settings, they can be found in GPMC on the domain level under “Default Domain Policy” > Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy/Account Lockout Policy.
By the way, the GPMC is included with Windows Server 2008 (like with Windows Vista), but must be added as a “Feature” – choose “Add Feature” in Server Manager, select ‘Group Policy Management’ and after a few moments you are ‘Group Policy Ready’
ADSI Edit
The most important tool for this ‘exercise’ is actually a tool that most administrators have feared through the years – because whenever you have to use it it is normally when something bad has happened – well, I am referring to the ADSI Edit utility (adsiedit.msc). Most of the granular password policy settings are created and configured from within this tool. ADSI Edit is part of the standard Windows Server 2008 installation so you do not have to add it afterwards.
The steps

This is a quick view on the steps required to configure ‘Granular Password Settings’ in Windows Server 2008:

1. Create a Password Settings Object (PSO) in the Password Settings Container (PSC) using ADSI Edit
2. Configure the PSO options by completing the ‘primitive’ wizard within ADSI Edit
3. Assign the PSO to a user account or a global security group
4. Confirm that the settings actually applied

Now that we know what steps we have to take, let’s get going!
Let’s get started

First, let us fire up ADSI Edit by clicking Start > Run… > “adsiedit.msc” and click OK (or press Enter).
Right click the “ADSI Edit” root and select “Connect to…”

Figure 2
Select OK to choose the default options in the “Connection Settings” dialog:

Figure 3
In ADSI Edit you should now be able to expand the domain, expand the ‘System’ container and finally right click the new ‘Password Settings Container’ (PSC) and choose New > “Object...”.

Figure 4
You will now have to select a class for the new object, but you are given one choice only (sometimes it is nice not to have too many options, right?). Select msDS-PasswordSettings and click Next:

Figure 5
From now on a pretty basic “wizard” is started that guides us though the process of creating a Password Settings Object (PSO). We will have to specificy a value for each of the following 11 attributes. Type in the values as shown in the table below (be sure to type the ‘minus’ sign in front of values where it is required) or come up with your own.

Attribute	Value	Quick explanation
Cn	PassPolAdmins	This is the name of the policy. Try to come up with a naming convention for these policies if you will have lots of them.
msDS-PasswordSettingsPrecedence	10	This number is used as a ‘cost’ for priority between different policies in case a user is hit by multiple PSOs. Be sure to leave space below and above for future use. The stronger the PSO password settings are, the lower the ‘cost’ should be.
msDS-PasswordReversibleEncryptionEnabled	False	Boolean value to select if passwords should be stored with reversible encryption (usually not a good idea).
msDS-PasswordHistoryLength	32	How many previously used passwords should the system remember?
msDS-PasswordComplexityEnabled	True	Should the users use a complex password? (Boolean value)
msDS-MinimumPasswordLength	16	What should be the minimum number of characters in the user accounts password?
msDS-MinimumPasswordAge	-864000000000 (9 zeros)	What is the minimum password age? (in this case 1 day) NB! Minus sign
msDS-MaximumPasswordAge	-36288000000000 (9 zeros)	What is the maximum password age? (in this case 42 days) NB! Minus sign
msDS-LockoutTreshold	30	How many failed attempts before the user account will be locked?
msDS-LockoutObservationWindow	-18000000000 (9zeros)	After how long should the counter for failed attempts be reset? (in this case 6 minutes) NB! Minus sign
msDS-LockoutDuration	-18000000000 (9zeros)	For how long should the user account object be locked in case of too many bad passwords entered? (in this case 6 minutes) NB! Minus sign

Table 1
When all that typing is done you should see the following dialog – just click Finish.

Figure 6
Make it happen

Now the PSO is created and it should be visible below the PSC in both ADSI Edit and ADUC/Server Manager (just remember to enable “Advanced Features” in the View menu), it should look like this:

Figure 7
From this point all we have to do is to assign the new policy to a specific user, multiple users, a global security group, multiple global security groups or a combination of users and global security groups.
To do this, right click the PSO in ADUC (or ADSI Edit) and select Properties – click Filter and make sure you have the following options selected/de-selected:


Figure 8
If you cannot see the picture I can tell you that the following options are selected: “Mandatory”, “Optional”, “Constructed”, “Backlinks” and “System-only”. The “Show only attributes that have values” is NOT selected.
Now browse to msDS-PSOAppliesTo, select it and click Edit.

Figure 9
In the “Multi-valued String Editor” insert the distinguished name of a user or a global security group in the “Value to add” field and click Add. You can add multiple distinguished names in this dialog – when done just click OK.

Figure 10
In the example above I have added a global security group named “Admins” (with the distinguished name of “CN=Admins,CN=Users,DC=Contoso,DC=Local”). Every user account that is a member of this group is now hit by the new “PassPolAdmins” password policy instead of the one defined in the Default Domain Policy. Cool, right!
At this point you might wonder what happens if the user is “hit” by multiple conflicting password policies. I will get back to this in detail in the next article in this series, but let me remind you we defined a ‘precedence’ value during the PSO creation.
Did you notice the change?

When you browsed around in ADUC just before, did you then notice the new “Attribute Editor” tab we now have on most objects (View > “Advanced Features” must be enabled)?

Figure 11
This is really cool because it enables administrator to view or edit lots of stuff which should normally be done within the ADSI Edit tool. With this tab we can take properties on the PSOs in the domain and modify the msDS-PSOAppliesTo attribute to easily set the password policy on a user or group (or move a user or group from that policy). Please notice that you cannot set the password policy from properties on the user or group objects – information about what policy applies to which users or groups is in other words set on the Password Settings Object itself!
Where can I see what policy wins?

It can be hard to determine what policy ‘wins’ for a specific user object (probably the one with the lowest cost AKA precedence value) – the Resultant Set of Policy (RSoP) you could say. But I am happy to tell you that Microsoft thought about this by introducing the msDS-ResultantPSO attribute on user objects (only).


Figure 12
This value determines what policy applies to the specific user (in my example a user named “Windows Admin”). This is in other word the “active” password and lockout policy for the selected user.
Both group and user objects have another new attribute, msDS-PSOApplied, which holds (in a multi-valued string) all the policies that the group or user is hit by - either directly or through group membership. In the example below the group called “Admins” is hit by 2 different password policies.

Figure 13

NB! If you cannot see the values mentioned here, be sure to set the “Attribute Editor” tabs filtering options to the ones described in the “Make it happen” section above.

Conclusion

We have now seen how to add a password and lockout policy in addition to the existing policy which is defined on the domain level by default.
To be honest I sometimes wonder why Microsoft was not able to make the procedure for this as easy as it is with for example Specops Password Policy (with Windows 200x AD) where everything is handled within GPEDIT, but at least we have a free option built-in to Active Directory now. I guess Microsoft wants the ‘security group approach’ instead of the ‘OU approach’ – most likely based on requests from costumers out there.
It is just a matter of getting used to this new approach and I am sure we will see some easy-to-use tools and scripts within short time to make the described process even easier to complete. Despite the “nerdy” management of these policies I think it is going to be used a great deal out there – let’s hope so anyway