Results 1 to 7 of 7

Thread: If you can expand on a tip.....

  1. #1
    romath is offline 100+ Helpful Posts! 50+ Helpful Posts
    Join Date
    Dec 1969
    Posts
    103

    Default

    If you discover new or have additional information about a tip that is already posted in the Tips and Tricks Section, or even the FAQs for that matter, please post them here and I will make sure it gets updated!!!

    Thanks!

  2. #2
    AdamV is offline 100+ Helpful Posts! 50+ Helpful Posts
    Join Date
    Dec 1969
    Posts
    669

    Default

    My reply to this post:
    http://www.gpanswers.com/community/viewtopic.php?t=537&highlight=
    is really a correction / expansion of the FAQ about applying account policies only in default domain policy. You could probably extract some useful information from that, hopefully., If you want me to rewrite it up more like a tutorial / tip rather than a specific answer to a question just let me know.

  3. #3
    romath is offline 100+ Helpful Posts! 50+ Helpful Posts
    Join Date
    Dec 1969
    Posts
    103

    Default

    Hi Adam,

    Sorry I haven't replied sooner.

    I'm going over the thread now, but I'll probably have questions. I'll definately be in touch!!

    Thanks

  4. #4
    romath is offline 100+ Helpful Posts! 50+ Helpful Posts
    Join Date
    Dec 1969
    Posts
    103

    Default

    Let's see if I have this straight.

    1. I have a user that belongs to an OU.
    2. I create a password policy linked to that OU.
    3. When the user changes their password after the policy takes effect, the policy is actually applying to their local (cached) account, so the local computer is enforcing the policy, so it looks like the its coming from the domain.
    4. This would only apply if the user is logging on as domain\user and not localmachine\user??????

  5. #5
    AdamV is offline 100+ Helpful Posts! 50+ Helpful Posts
    Join Date
    Dec 1969
    Posts
    669

    Default

    No, and this is the bit which causes the confusion.

    The policy applies to local accounts, which belong to workstations/servers, so you set the policy on a computers OU. Other than that, you have it right.

    Because this is a password policy, natural tendency is to apply it to a set of users. This does not work, so people believe the "myth" it is not possible to have varied account policies across a single domain. Strictly, it is not a myth, it is correct that you can only have one policy that applies to domain acounts (as far as I can tell). But it is not true in the way that most people read and understand it.

    It works in the most transparent way if your OU structure is like this:

    DeptA
    -UsersA
    -MachinesA

    DeptB
    -usersB
    machinesB


    rather than
    Users
    -A
    -B

    Machines
    [-A]
    [-B]

    because then you apply it to the department (or whatever) OU and it is obvious which users it will apply to, although it is really doing it via the machines.

    The structure I actually used this in was:
    Servers (< link 'stronger passwords' policy here, forcing local accounts, for services etc to be set up with very high strength)

    Citrix Servers (<link normal 'user level' strength policy)

    City1 (<apply 'user level' policy here too)
    -Depts
    ---DeptA
    ------Users
    ---DeptB
    ------Users
    ---Machines

    City2 (<apply 'user level' policy here too)
    users
    machines
    etc.

    With hindsight I could probably have set a single domain policy for all users then applied an OU policy to servers which I would expect to take precedence (in a "hardest to achieve wins" kind of way, since it would have to conform to both policies)

    One bug we used to get (which may or may not have been related to how the policy was applied) was that if users tried to change to a non-compliant passord they got the usual error that it must be complex (explanation), not use part of their name, and must be at least 7 characters.
    Always 7, regardless of the actual length set by policy. In the end we gave up on trying to enforce 8 since users would not remember this and simply believed the error, so we had to go with 7!
    Never really tried too hard to fix or fathom this, I admit.

    Incidentally, just in case I did not mention it before, Account Lockout does not seem to work in this way. I guess because locking local accounts simply does not work.
    Password expiry is "semi-retrospective" when used this way the same as if applied to the domain - if you set (say) 60 days expiry and it is already later than 60 days, the password is flagged as expired as soon as the policy gets refreshed. One to people to watch out for (although this is fairly well known by now).

  6. #6
    romath is offline 100+ Helpful Posts! 50+ Helpful Posts
    Join Date
    Dec 1969
    Posts
    103

    Default

    Sorry I haven't looked at this one for awhile.

    For some reason, I still can't seem to get my head around this one.

    If you're still interested in putting something together for this, that would be great. Just keep it simple so I can follow along.

    I'd like to take whatever you create and duplicate it in my test environment so I can better understand it.

    Let me know!!!

  7. #7
    AdamV is offline 100+ Helpful Posts! 50+ Helpful Posts
    Join Date
    Dec 1969
    Posts
    669

    Default

    Will do. I'll try to put some supporting info around it too (eg screenshots)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Search Engine Friendly URLs by vBSEO