نمایش نتایج: از شماره 1 تا 3 از مجموع 3
سپاس ها 2سپاس

موضوع: مشکل با check the minimum password length password complexity and password history requirements

  
  1. #1


    عضو عادی
    تاریخ عضویت
    Jul 2006
    نوشته
    146
    سپاسگزاری شده
    7
    سپاسگزاری کرده
    15

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

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



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





  2. #2
    نام حقيقي: مهدی ه

    عضو عادی شناسه تصویری Mehdi-H
    تاریخ عضویت
    Nov 2011
    محل سکونت
    تهران
    نوشته
    50
    سپاسگزاری شده
    45
    سپاسگزاری کرده
    0
    با سلام ...
    تا اونجایی که در حیطه اطلاعات بنده هست، به طور کلی چنین امکانی در سرور وجود نداره. شما نمیتونی همزمان برای ساخت چند کاربر Password Complexity رو رعایت کنید و برای چند کاربر دیگر رعایت نکنید ...



  3. #3
    نام حقيقي: صادق نجاتی زاده

    مدیر بازنشسته شناسه تصویری SADEGH65
    تاریخ عضویت
    Nov 2003
    محل سکونت
    تهران
    نوشته
    2,264
    سپاسگزاری شده
    3410
    سپاسگزاری کرده
    3620
    نوشته های وبلاگ
    12
    نقل قول نوشته اصلی توسط hadi576 نمایش پست ها
    سلام خدمت دوستان
    من ویندوز سرور 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





    Reza.D و th95 سپاسگزاری کرده‌اند.

کلمات کلیدی در جستجوها:

قبول نکردن پسورد کوتاه در اکتیو دایرکتوری

مشکل با check the minimum password length password ...

تغییر نوع پسورد در سرور2008

مشكل پسورد در ويندوز 2008R2

complexity requirements active directoryغیر فعال بودن 2008

غیر فعال کردن پسورد سخت در 2008 سرور

پیچیدگی پسورد اکتیو 2008

چرا در اکتیوداریرکتوری تعریق یوزر و پسورد از پسورد ایراد میگیرد

پالیسی fine grained در ویندوز2008

مشکل با password policy در سرور2008

هنگام نصب ویندوز سرور 2008 پسورد یوزر چیست؟

complexity اکتیو 2008

مشکل انتخاب پسورد در ویندوز 2003

مشكل مينيمم پسورد در ايجاد يوزر در اكتيو دايركتوري

پسوردپالیسی در ویندوز سرور2008 r2

غیرفعال بودن account policies در ویندوز سرور 2008

complexity چیست پسورد

غیر فعال کردن complex در r2 2008

مشکل تعریف پسورد user ها در سرور 2008

group policy windows server 2008 password complexity اموزش

غیر فعال نمودن password complexity در سرور

مشکل غیر فعال بودن minimum password length در ویندوز 7

چگونه در ویندوز سرور2008 همزمان چند کاربر را تعریف کنیم

اعمال پسورد پیچیده در ویندوز 2008 سرور

تغییر ویژگیهای پسورد در پالیسی و اعمال به یوزرها در دامین

برچسب برای این موضوع

مجوز های ارسال و ویرایش

  • شما نمی توانید موضوع جدید ارسال کنید
  • شما نمی توانید به پست ها پاسخ دهید
  • شما نمی توانید فایل پیوست ضمیمه کنید
  • شما نمی توانید پست های خود را ویرایش کنید
  •