Announcement

Collapse
No announcement yet.

Improving Password Policy Win2K Environment 200 WKST

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Improving Password Policy Win2K Environment 200 WKST

    Hi,

    The existing default domain policy in place appears to be left as default.

    The clients local policy is default.

    Which means:

    1) blank passwords are accepted
    2) no min password age defined
    3) no max password age defined
    4) the local policy of 42 days to change your password is running
    5) 14 day reminder kicks in

    I've created a GPO at an "OU" level and it's being applied.

    RSOP + NET ACCOUNTS show me my changes but it's not working!

    My changes included minimum password length of 6 but I can still use a blank password.

    I've been reading the posts and it does appear that I have to make these changes at default domain policy gpo but here is some thoughts:

    (keep in mind 15 win2k dc servers and 200 workstations (xp+win2ksp4)

    1 - How will this affect domain controllers ? Probably won't because only IT logs into them as admin ( who is exempt )

    2 - What about special accounts like backup operator accounts for backup software, you don't want their passwords to be changed.

    Q: Can I go into AD and adjust any user object settings to "PASSWORD DOES NOT EXPIRE" and it will override the DEFAULT domain policy?

    To conclude:

    If I do adjust the default domain policy can anyone tell me from experience what the result will be shortly there after?

    Q: Will users with blank passwords be asked immediately to change?
    A: Probably not until the existing password expires, correct?

  • #2
    Answer

    I figure the best way to do this is implement it at the default domain policy level but I'd like to know if the override works .

    The "users's password does not expire" - > will this overridge the policy?

    Anyone?

    Comment


    • #3
      Hi joejiz,

      The problem is documented in a nice way. Well done bro. The more information you provide us, the better chance we can help you. Before we go into the details of your situation, I'd like to walk you through the concept of GPO Link Level. As you know GPOs are linked and processed in the order of:

      -> Local Workstation.
      -> Site.
      -> Domain.
      -> OU.

      All GPOs contains the same settings. But these are the ones that applied at the domain level ONLY. (c2)

      1. Password Policy

      2. Account Lockout Policy

      3. Kerberos Policy

      And this one as well: (c1)

      -Force log off when log on hours expire.

      Now let's talk about your situation

      I've created a GPO at an "OU" level and it's being applied.

      RSOP + NET ACCOUNTS show me my changes but it's not working!

      My changes included minimum password length of 6 but I can still use a blank password.
      Answer: Sure it won't work because it falls into #1: Password Policy.

      1 - How will this affect domain controllers ? Probably won't because only IT logs into them as admin ( who is exempt )
      Answer: Sure it will affect domain controllers as well because it's domain wise setting. Correct me if I am wrong but I guess you are thinking of "Allow to logon locally"? If that is the case you can edit the Default Domain Controllers policy to accomplish the task.


      2 - What about special accounts like backup operator accounts for backup software, you don't want their passwords to be changed.

      Q: Can I go into AD and adjust any user object settings to "PASSWORD DOES NOT EXPIRE" and it will override the DEFAULT domain policy?
      Answer: Yes."Password does not expire" will override the domain password policy.

      If I do adjust the default domain policy can anyone tell me from experience what the result will be shortly there after?

      Q: Will users with blank passwords be asked immediately to change?
      A: Probably not until the existing password expires, correct?
      Answer: I'll get back with you later on. I haven't experienced it before.


      Best Practices:

      1. Use "normal" user account as much as you can. Please read this so you can accomplish the task easily.

      2. Have a back up of all default and important GPOs. I'll post the details later on.

      3. You should modify the "Account Policies Settings" in Default Domain Policy only. For the rest of the settings you can create another GPO and apply to domain level.

      4. How to reset user rights in default domain policies in case you mess them up
      For Windows2000 click here
      For Windows2003 click here

      Real life experience: I am managing couple of domains. There is one domain that we have clients loaded with mandatory user profiles. So password complexity is not needed. BUT it makes those lazy admins use "short" password as well. I wanted to house all admins in a OU and lock them with the password policy but it's sad when I find out that the password policy is domain wise setting. Oh well.


      Anyway, if you need further assistance please let me know.

      Regards,

      Changelog:

      12.08.04

      (c1) Remove :

      b. Rename Administrator account.

      c. Rename Guest account.

      01.02.05

      (c2) I would like to add more information to that comment. If I say the password and account log out policies ONLY apply at the domain level, it's not 100% correct. But in your situtation it won't work because you need to apply it at domain level. The reason that I say it's not 100% correct because with those two settings you still can apply them at OU level. The only thing that makes it different is those settings will apply for LOCAL accounts only. So if you have a domain and you want those settings apply to local user accounts on the workstation you can do it. I already tested them.

      Reference: Windows 2003 Help, Security, Security Configuration Manager, Concept, Using Security Configuration Manager, Security Setting Desription, Account Policy.

      Here's the quote from that help.

      For domain accounts, there can be only one account policy. The account policy must be defined in the Default Domain policy, and it is enforced by the domain controllers that make up the domain. A domain controller always obtains the account policy from the Default Domain Policy Group Policy object (GPO), even if there is a different account policy applied to the organizational unit that contains the domain controller. By default, workstations and servers that are joined to a domain (such as member computers) will also receive the same account policy for their local accounts. However, local account policies can be different from the domain account policy, such as when you define an account policy specifically for the local accounts.
      Teamwork

      Comment


      • #4
        Couple comments:

        And these special ones as well:

        a. Automatically Log Off Users When Logon Times Expires.
        b. Rename Administrator account.
        c. Rename Guest account.
        You can rename Administrator or Guest accounts at OU level. Quoting KB816109 and KB320053 (W2K and W2K3 versions):
        2. In the console tree, right-click the domain or the organizational unit where you want to create the group policy, and then click Properties.

        If I do adjust the default domain policy can anyone tell me from experience what the result will be shortly there after?

        Q: Will users with blank passwords be asked immediately to change?
        A: No. The password policies are checked/consulted when setting or changing account's password. The safest way is to expire all the passwords in AD and require all users to set new passwords on next logon.
        Local computer accounts (not AD accounts) will still function, till expired or password is changed/set.


        3. You should modify the "Account Policies Settings" in Default Domain Policy only. For the rest of the settings you can create another GPO and apply to domain level.
        Not quite correct. Though this is considered a "Best practice" you can safely disable the links of Default Domain Policy and Default Domain Controller Policy and link your own GPOs instead. Password/Kerberos/etc policies can be configured in any GPO linked at domain level (linked to domain object)
        I consider this approach a safety net: I can always revert to original GPOs by disabling the links to my custom GPOs and re-enabling the links to default GPOs.
        Guy Teverovsky
        "Smith & Wesson - the original point and click interface"

        Comment


        • #5
          Hi Guy,
          Thanks for correcting me regarding the admin and guest account renaming.
          About Default Domain Policy and Default Domain Controller Policies I agree with you that we can always disable the links and use custom ones. The reason that I keep the default settings and add more GPOs if needed because I'm not expert like you yet .

          Also, I just found out another link for domain wise Group Policy settings:

          http://www.microsoft.com/technet/sec...od49.mspx#EEAA

          Regards,
          Teamwork

          Comment


          • #6
            Policy

            Thanks for the answers and the compliment on my post.

            We have never restored or messed with the sysvol so I think it would be safe to adjust the default domain policy on the primary DC.

            I'm glad that the policy will take effect and won't automatically force people to change anything.

            I suppose if I enable" change pw every 90 days" then they'll be prompted to change [90-14] days from the day I enable the GPO.

            As well at that time when the have to change their password it'll have to be 6 characters min. So very very minor changes and hopefully should go smoothly.


            ------------------------------------------------------------------------

            Quote:
            1 - How will this affect domain controllers ? Probably won't because only IT logs into them as admin ( who is exempt )


            Answer: Sure it will affect domain controllers as well because it's domain wise setting. Correct me if I am wrong but I guess you are thinking of "Allow to logon locally"? If that is the case you can edit the Default Domain Controllers policy to accomplish the task.
            ----------------------------------------------------------------------

            Responce to above:

            Ummm all I meant is how could the change effect the way I work on servers. After a DC becomes a DC you can't log on using the local admin account in the computer name's domain.

            -> If the DC is a DC then there is no way to login locally, those local accounts are terminated As long as I can terminal services into the DC and use the domain admin account to work on the server I'm happy. I'll just leave the DC policy the default.

            I don't quite understand the whole interactive login thing but my changes to the password policy are minor enough that I can't see any impact on logging into the server's via T/S or at console using the domain administrator account which is exeompt from password policy anywaz.

            Am I missing something, did I say that correctly?

            My password policy only suggests what I mentioned in 1st post above.

            So as long as I use "password doesn't expire" for any other account (backup or whathave you ) then everything should be ok?

            This link is damn scarry:http://support.microsoft.com/?kbid=267553

            I hope to god I don't have to go through that.

            I would however like to know how to back up the default domain policy and know how to restore just in case.

            I have the new microsoft mmc tool :GPMC

            http://www.windowsitpro.com/Windows/...393/16393.html

            Except I can't find where to actually back up a GPO. ( I run the program from my pc )

            Q: Do I need to ensure I have full security rights on the GPO to back it up?

            Q : Should I install the program on a DC and thus I'll be able to back up GPO's?

            Comment


            • #7
              I found a good traning tool on the new GPMC

              http://windows.about.com/gi/dynamic/...2Fdefault.mspx

              I'm sure I'll find out how to backup in there ...

              Thanks again.

              Comment


              • #8
                I suppose if I enable" change pw every 90 days" then they'll be prompted to change [90-14] days from the day I enable the GPO.
                The bad news are that you are wrong here. Each time a user password is changed, the pwdLastSet attribute is updated. This means that if you introduce the policy, you might have some users with a deep overdraft .

                You can solve it by searching in AD for an account with earliest pwdLastSet timestamp.
                Let's say you have users with password 200 days old. What you will do it to set the GPO to change password every 210 days and gradually decrease the number. This will prevent the situation when everyone is required to change his password right after the GPO is introduced.

                Q: Do I need to ensure I have full security rights on the GPO to back it up?
                A: You need at least read permissions on the GPO

                Q : Should I install the program on a DC and thus I'll be able to back up GPO's?
                A: You can manage GPOs from your workstation as long as workstation is part of the domain you are managing (or in domain with two-way trust to domain you want to manage).


                As for "interactive logon" thing, this is exactly what it is: account that is allowed interactive logon to computer can logon to machine's console.
                And you are right: the moment server is dcpromo-ed to a DC, all the local machine account are not accessible. The only account that "survives" the dcpromo process is the local Administrator account of the server (and only if this is the first DC in the domain).
                Guy Teverovsky
                "Smith & Wesson - the original point and click interface"

                Comment


                • #9
                  Password Policy

                  Hi Guy,

                  Sorry for delay in writing back, the holliday season has been busy.
                  I appreciate your comments and they have helped me out a great deal.
                  In Feb-Mar I will be implementing this policy and will post my results.

                  Again thanks again ...

                  Comment


                  • #10
                    Good luck !
                    Let us know how it went.
                    Guy Teverovsky
                    "Smith & Wesson - the original point and click interface"

                    Comment

                    Working...
                    X