none
fine grained password policy

    Question

  • I'm trying to understand the impact of a domain fine grained password policy on LOCAL computers and accounts.

    Will a fine grained password policy with PSOAppliesTo not set, affect local accounts, in the same way Group Policy does?

    If you set a local account to "Password Never Expires"=true, but a fine grained password policy to "Password Never Expires"=False, which wins?

    Thanks

    Monday, March 21, 2016 11:36 AM

Answers

  • Hi
     
    Am 21.03.2016 um 12:36 schrieb tim_dk:
    > I'm trying to understand the impact of a domain fine grained password
    > policy on LOCAL computers and accounts.
     
    Thats easy: None.
     
    It´s not a POLICY! FGPP are an AD object filtered to a group/user/object
    SID from the domain. It will only life within AD, it will not be
    deployed to the client. It is just a filter, that catches the password
    change of a DomainObject and checks if a specific FGPP will apply.
     
    A local account will never change it´s password against the DCs.
     Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    • Marked as answer by tim_dk Monday, March 21, 2016 12:45 PM
    Monday, March 21, 2016 12:00 PM
  • > I am correct in saying that a group policy object, such as the default
    > domain policy, will affect the local accounts though, aren't I?
     
    Yes.
     
    • Marked as answer by tim_dk Tuesday, March 22, 2016 1:27 PM
    Monday, March 21, 2016 12:59 PM
  • Am 21.03.2016 um 13:25 schrieb tim_dk:
    > I am correct in saying that a group policy object, such as the default
    > domain policy, will affect the local accounts though, aren't I?
     
    It does. It overides/overrules the local group policy object and it´s
    password policy settings, that exist for every single computer.
    the L-GPO would be the efectiv one, when running clients in Workgroups
    like your PC at home. (if it is no a HOME edition ;-)
     
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    • Marked as answer by tim_dk Tuesday, March 22, 2016 1:28 PM
    Monday, March 21, 2016 1:33 PM
  • > say 30 days in a FGPP, Which "wins"? Will the password expire or not?
     
    The FGPP will win. To be precise, the effective FGPP will win :)
     
    • Marked as answer by tim_dk Tuesday, March 22, 2016 1:29 PM
    Tuesday, March 22, 2016 12:00 PM

All replies

  • Hi
     
    Am 21.03.2016 um 12:36 schrieb tim_dk:
    > I'm trying to understand the impact of a domain fine grained password
    > policy on LOCAL computers and accounts.
     
    Thats easy: None.
     
    It´s not a POLICY! FGPP are an AD object filtered to a group/user/object
    SID from the domain. It will only life within AD, it will not be
    deployed to the client. It is just a filter, that catches the password
    change of a DomainObject and checks if a specific FGPP will apply.
     
    A local account will never change it´s password against the DCs.
     Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    • Marked as answer by tim_dk Monday, March 21, 2016 12:45 PM
    Monday, March 21, 2016 12:00 PM
  • Thanks Mark.

    I am correct in saying that a group policy object, such as the default domain policy, will affect the local accounts though, aren't I?

    Monday, March 21, 2016 12:25 PM
  • > I am correct in saying that a group policy object, such as the default
    > domain policy, will affect the local accounts though, aren't I?
     
    Yes.
     
    • Marked as answer by tim_dk Tuesday, March 22, 2016 1:27 PM
    Monday, March 21, 2016 12:59 PM
  • Am 21.03.2016 um 13:25 schrieb tim_dk:
    > I am correct in saying that a group policy object, such as the default
    > domain policy, will affect the local accounts though, aren't I?
     
    It does. It overides/overrules the local group policy object and it´s
    password policy settings, that exist for every single computer.
    the L-GPO would be the efectiv one, when running clients in Workgroups
    like your PC at home. (if it is no a HOME edition ;-)
     
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    • Marked as answer by tim_dk Tuesday, March 22, 2016 1:28 PM
    Monday, March 21, 2016 1:33 PM
  • So, I plan to have 2 FGPP's. One with PSOApplies to not set, that applies to everyone, and another, with different settings that apply to an exceptions group.

    Will that work? any issues/things to ba aware of?

    Thanks

    Monday, March 21, 2016 1:39 PM
  • Hi
     
    Am 21.03.2016 um 14:39 schrieb tim_dk:
    > So, I plan to have 2 FGPP's. One with PSOApplies to not set,
    > that applies to everyone, and another, with different settings that
    > apply to an exceptions group.
    > Will that work? any issues/things to ba aware of?
     
    2? makes no sense to me  ...
     
    "Applies to everyone" = Default Domain Policy or any other real GP
    linked on Domain Level with highes priority.
    "Applies to specific" = FGPP
     
    So, it´s only one FGPP.
     
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Monday, March 21, 2016 1:59 PM
  • The Default domain policy, or other policy,  will affect one or two local accounts that need to not be affected.

    Sorry, when I say everyone, I mean domain computers/accounts only.

    So the specific in the other one, is domain accounts only, not local accounts


    • Edited by tim_dk Monday, March 21, 2016 2:08 PM
    Monday, March 21, 2016 2:06 PM
  • Am 21.03.2016 um 15:06 schrieb tim_dk:
    > The Default domain policy, or other policy,  will affect one or
    > two local accounts that need to not be affected.
     
    Domain Password Policy will target EVERY LOCAL ACCOUNT, because it
    overrules the local Group policy object that target every local account.
     
    There is no exclude for local accounts. The only exclude for local
    accounts is workgroup ...
     
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Monday, March 21, 2016 2:11 PM
  • The settings, specifically Maximium age, and complexity requirements, are not set/enabled in the default policy, so do not currently apply. I want to apply complexity requirements to everyone, but a Maximum age to some users and not others, without affecting any local accounts.

    Monday, March 21, 2016 2:30 PM
  • "There is no exclude for local accounts. The only exclude for local

    accounts is workgroup".    

    Sorry, I thought we'd already established that FGPP don't affect local accounts?

    Forgive me if I'm being thick.

    Thanks

    Monday, March 21, 2016 2:39 PM
  • > Forgive me if I'm being thick.
     
    You're right - Mark is somewhat confused right now :)
     
    It is perfectly ok to create 2 FGPPs for different purposes, and your
    thoughts will work the way you described.
     
    Monday, March 21, 2016 3:18 PM
  • So now I'm thinking this:

    If the maximum age is set to 0 in the default domain policy, but set to say 30 days in a FGPP, Which "wins"? Will the password expire or not?

    Monday, March 21, 2016 3:27 PM
  • Or can I just set maximum age to "Not configured" in the default domain policy GPO, so that that setting is not being set by group policy at all, but is by the FGPP?
    Monday, March 21, 2016 3:56 PM
  • Am 21.03.2016 um 16:18 schrieb Martin Binder [MVP]:
    >> Forgive me if I'm being thick.
    > You're right - Mark is somewhat confused right now :)
     
    ok, " ... without affecting any local accounts".
    Sorry, I didn´t get the "without" part of your goal.
     
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Monday, March 21, 2016 4:44 PM
  • Any more thoughts on this?

    Thanks

    Tuesday, March 22, 2016 11:01 AM
  • > say 30 days in a FGPP, Which "wins"? Will the password expire or not?
     
    The FGPP will win. To be precise, the effective FGPP will win :)
     
    • Marked as answer by tim_dk Tuesday, March 22, 2016 1:29 PM
    Tuesday, March 22, 2016 12:00 PM
  • Thanks.

    Another question. Sorry this stuff messes with my head.(why couldn't Microsoft just make passwords user based like they should be?) Anyway that's not the question. This is:

    After the notification pops up saying "your password expires today" and consider changing it, logging off and logging on will force a user to change it at the logon. What happens if they never log off, and therefore never log on?

    Tuesday, March 22, 2016 12:09 PM
  • > change it at the logon. What happens if they never log off, and
    > therefore never log on?
     
    Don't know - simply try it out :)
     
    Tuesday, March 22, 2016 12:38 PM
  • Yeah, that's what I'm doing. God kows how long I'll have to wait. I'm guessing at least a day.

    So:

    > say 30 days in a FGPP, Which "wins"? Will the password expire or not?
     

    The FGPP will win. To be precise, the effective FGPP will win :)

    So, a user in a group that a FGPP applies to will get settings from the FGPP first, then group policy afterwards? In the case of a conflict, the FGPP will have precedence over group policy?

    If a password policy setting is not defined in either the FGPP, or group policy, where the user will get that setting from?

    Or to put it another way, if no FGPP exists, and no GPO exists, where will the settings come from for a domain user account, and how do you view those settings? I've got LDAP in front of me here, and looking at the builtin container, I can see some password settings. Is that what they would get?

    Thanks

    I guess what I'm asking is the order of precedence between FGPP,GPO, and default active directory in the case of a conflict. Highest priority to lowest


    • Edited by tim_dk Tuesday, March 22, 2016 1:14 PM
    Tuesday, March 22, 2016 12:56 PM
  • Am 22.03.2016 um 13:09 schrieb tim_dk:
    > What happens if they never log off, and therefore never log on?
     
    The password will still expire and after expiration, the user has no
    longer access. If you define account lockout policy aswell, the account
    will get lockout, because of wrong password.
     
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Tuesday, March 22, 2016 12:56 PM
  • Am 22.03.2016 um 13:56 schrieb tim_dk:
    > In the case of a conflict, the FGPP will have precedence over group policy?
     
    No,Yes.
    The FGPP is more like a 2nd layer or filter for genrating the password.
    When it comes to change or password set the SID of the object will be
    checked and if there is a applying FGPP all settings from the specific
    PSO are applied.
    Thats why PSOs/FGPP have a sort order, because it can have more than one
    matching FGPP.
     
    > If a password policy setting is not defined in either the FGPP, or group
    > policy, where the user will get that setting from?
     From the Domain Head. Default Naming Context -> dc=your,dc=dom
     
    The PDC Emulator can paste this settings from the domain head into
    Default Domain Policy, but only if it is still the {31B2 ...}
    Edit them manually and see what happens ... ;-)
     
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Tuesday, March 22, 2016 1:26 PM
  • Edit them manually and see what happens ... ;-)

    Where?

    Tuesday, March 22, 2016 2:38 PM
  • Am 22.03.2016 um 15:38 schrieb tim_dk:
    > Edit them manually and see what happens ... ;-)
    > Where?
     From the Domain Head. Default Naming Context -> dc=your,dc=dom
    right click -> properties ...
     
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Tuesday, March 22, 2016 2:43 PM
  • Sorry I don't know what or where the "Domain Head" is? How do I access it?
    Tuesday, March 22, 2016 2:50 PM
  • "..but only if it is still the {31B2 ...}"

    No idea what that means

    Tuesday, March 22, 2016 3:37 PM
  • Am 22.03.2016 um 15:50 schrieb tim_dk:
    > Sorry I don't know what or where the "Domain Head" is? How do I
    > access it?
     
    If you can not find it and if you do not know how to access the default
    naming context of your "dc=your,dc=dom" please: do not touch it.
    You will never need it or you will mess it up.
     
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Tuesday, March 22, 2016 3:49 PM
  • Am 22.03.2016 um 16:37 schrieb tim_dk:
    > "..but only if it is still the {31B2 ...}"
    > No idea what that means
     
    The GUID of the original Default Domain Policy on EVERY domain.
     
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Tuesday, March 22, 2016 3:53 PM
  • I understand and appreciate your concern there, but this is on a test lab I don't care about, and I'm only asking for educational purposes. Anyway, it's a look, don't touch exercise.
    Tuesday, March 22, 2016 3:57 PM
  • Am 22.03.2016 um 16:57 schrieb tim_dk:
    > I don't care about
     
    me either ... ADSI Editor (adsiedit.msc)
     
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Tuesday, March 22, 2016 4:04 PM
  • That's what I thought. I'm already in that. That's how I created my FGPP PSO. Anyway, I've found what I'm looking for. Thanks

    Tuesday, March 22, 2016 4:20 PM
  • Anyway, back to basics.

    If you set a maximum password age in a FGPP PSO, when does the counter start?

    Next time the password is changed?

    Next logon?

    If the password is not changed, would the counter not start until it is changed?

    Tuesday, March 22, 2016 4:47 PM
  • Am 22.03.2016 um 17:47 schrieb tim_dk:
    > If you set a maximum password age in a FGPP PSO, when does the counter
    > start?
     
    use "net user yourtestaccount" and test your scenarios.
     
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Tuesday, March 22, 2016 5:20 PM
  • And back to the issue of precedence.

    If a FGPP PSO, the default domain policy GPO, and default active directory all set the same setting to different values, the order of precedence appears to be the FGPP PSO first (if it's a user the PSO applies to they get the PSO settings), then the default domain policy GPO (if it's a user the PSO does not apply to, they get the default domain policy GPO settings), and if there was no default domain policy GPO, and the PSO didn't apply, they would get the settings from the local computers security policy, which is what the default domain policy GPO is actually writing the settings to.

    If there was no default domain policy GPO, the local computers security policy settings could be edited (by an administrator). If the computer was removed from the domain, and re-joined, and there was no default domain policy GPO, the computer's security policy would be changed to the active directory defaults? if there was a default domain policy GPO at the time of joining, the computer's security policy would be the settings defined in the default domain policy GPO

    Is that correct?

    Thanks

    I think I've finally got my head around all this. Thanks for you all your help Mark and Martin
    • Edited by tim_dk Tuesday, March 22, 2016 5:35 PM
    Tuesday, March 22, 2016 5:31 PM
  • Am 22.03.2016 um 18:31 schrieb tim_dk:
    > If a FGPP PSO, the default domain policy GPO, and default active
    > directory all set the same setting to different values, the order of
    > precedence appears to be the FGPP PSO first (if it's a user the PSO
    > applies to they get the PSO settings),
     
    Yes.
     
    > then the default domain policy
    > GPO (if it's a user the PSO does not apply to, they get the default
    > domain policy GPO settings), and if there was no default domain policy
    > GPO, and the PSO didn't apply, they would get the settings from the
    > local computers security policy,
     
    from local computers only if they are LOCAL accounts. Domain accounts
    still get the rules from DefDomPol.
     
    > If there was no default domain policy GPO,
     
    There is always a domain rule for domain accounts, because if there is
    no DefDomPol, the PDC Emulator rules the rules.
     
    > the local computers security
    > policy settings could be edited (by an administrator).
     
    Yes, but only for local accounts
     
    > If the computer
    > was removed from the domain, and re-joined, and there was no default
    > domain policy GPO, the computer's security policy would be changed to
    > the active directory defaults?
     
    No. The local security stays as it is and will apply to local accounts.
    For domain accounts, the PDC rules are valid.
     
    > if there was a default domain policy GPO
    > at the time of joining, the computer's security policy would be the
    > settings defined in the default domain policy GPO
     
    Yes and now there will be the same rules for local accounts as for the
    one of the domain
     
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Tuesday, March 22, 2016 7:37 PM
  • > use "net user yourtestaccount" and test your scenarios.
     
    net user is legacy and doesn't know about FGPP...
     
    Wednesday, March 23, 2016 9:18 AM
  • > Next time the password is changed?
     
    No - "pwdlastset" :)
     
    Wednesday, March 23, 2016 9:19 AM
  • "There is always a domain rule for domain accounts, because if there is

    no DefDomPol, the PDC Emulator rules the rules."

    Sorry I meant if no password settings were being set by group policy.

    If we forget local accounts for a minute only focus on domain accounts:

    If there was no FGPP PSO applicable, and settings were not being written by group policy, do domain users get the settings from local security policy of the domain controller (which the DefDomPol is writing to as well)?

    Or is it the PDC Emulator? In which case is there a way to view the settings coming from the PDC Emulator?

    Thanks

    Wednesday, March 23, 2016 10:39 AM
  • Am 23.03.2016 um 10:18 schrieb Martin Binder [MVP]:
    > net user is legacy and doesn't know about FGPP...
     
    take it as a synonym for the new powershell cmdlets ... :-)
     
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Wednesday, March 23, 2016 11:39 AM
  • Am 23.03.2016 um 11:39 schrieb tim_dk:
    > If there was no FGPP PSO applicable, and settings were not being
    > written by group policy, do domain users get the settings from local
    > security policy of the domain controller
     
    No. AD Accounts are managed in AD database, not in a local SAM.
    The DCs get the rules from the domain head.
     
    > In which case is there a way to view the settings coming from the PDC
    > Emulator?
     
    the domain head will show this settings, because the PDC writes its
    settings from local sec policy (view with secpol.msc) into it.
     
    And from there, if changed it will be written into DefDomPol.
     
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    • Proposed as answer by Deepak Rawat25 Wednesday, March 23, 2016 12:52 PM
    • Unproposed as answer by Deepak Rawat25 Wednesday, March 23, 2016 12:52 PM
    Wednesday, March 23, 2016 11:39 AM
  • So for a domain user, and a setting such as Maximum Password Age:

    If there was an applicable PSO, they the user would get max password age defined in the PSO

    If there was no applicable PSO, the user would get the setting defined in DefDomPol.

    If the setting was not defined in either PSO, or DefDomPol, the maxPwdAge setting defined in "dc=your,dc=domain" container of Domain head would apply, unless "Password Never expires" is enabled?

    I can't find any setting for complexity requirements though. Do I take it there isn't one in the Domain Head, and the only way to force complexity requirements for Domain users, is either group policy, or FGPP PSO?

    Wednesday, March 23, 2016 12:52 PM
  • Even if you block inheritance for fine grained policy since they are security setting they will override any policy.so local will not be effective in any way.
    Wednesday, March 23, 2016 12:54 PM
  • Only interested in domain accounts at this point, not local thanks
    Wednesday, March 23, 2016 1:07 PM
  • So DefDomPol writes to DC local Security Policy

    DC local Security Policy writes to domain head.

    Domain Head writes to DefDomPol

    I've found if I change the DC local Security Policy manually, the changes are immediately written to the Domain Head

    Therefore this statement:

    "If there was no FGPP PSO applicable, and settings were not being written by group policy, do domain users get the settings from local security policy of the domain controller" is somewhat valid. Even though the settings are coming from the Domain Head, the domain head first got them from local security policy of the domain controller. (at least for the settings that exist in the local security policy of the domain controller)
    Wednesday, March 23, 2016 2:14 PM
  • Am 23.03.2016 um 13:52 schrieb tim_dk:
    > So for a domain user, and a setting such as Maximum Password Age:
    > If there was an applicable PSO, they the user would get max password age
    > defined in the PSO
     
    Yes.
     
    > If there was no applicable PSO, the user would get the setting defined
    > in DefDomPol.
     
    Yes.
     
    > If the setting was not defined in either PSO, or DefDomPol, the
    > maxPwdAge setting defined in "dc=your,dc=domain" container of Domain
    > head would apply, unless "Password Never expires" is enabled?
     
    Yes.
     
    > I can't find any setting for complexity requirements though. Do I take
    > it there isn't one in the Domain Head, and the only way to force
    > complexity requirements for Domain users, is either group policy, or
    > FGPP PSO?
     
    Probably. I have no clue. Passwordcomplexity was introduced in 2003, so
    probably they did not update the schema for that particular attribute
     
    There is no big reason to think about, because it will literally /never/
    happen, lets say, if it would, solving this issue is easy:
    Use a Password Policy.
     
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Wednesday, March 23, 2016 3:00 PM
  • Am 23.03.2016 um 15:14 schrieb tim_dk:
    > "If there was no FGPP PSO applicable, and settings were not
    > being written by group policy, do domain users get the settings from
    > local security policy of the domain controller" is somewhat valid. Even
    > though the settings are coming from the Domain Head, the domain head
    > first got them from local security policy of the domain controller.
     
    Right, with one small thing to add: not every DC, only the FSMO Holder
    of the PDC Emulator role.
     
    I think, now we got it all :-)
     
    Mark
    --
    Mark Heitbrink - MVP Windows Server - Group Policy
     
    GPO Tool: http://www.reg2xml.com - Registry Export File Converter
     
    Wednesday, March 23, 2016 3:03 PM
  • > I can't find any setting for complexity requirements though.
     
    You didn't try hard enough... Kidding :-)) "pwdProperties" -
     
    Thursday, March 24, 2016 8:06 AM
  • > So DefDomPol writes to DC local Security Policy
     
    No - DCs have no local security policy (as well as no local accounts),
    they have the domain security policy in the domain head only. And this
    policy cannot be "undefined".
     
    You can verify that through editing one of the password attributes in
    the domain head. Then open secpol.msc - your change will be visible here.
     
    And you cannot delete those password attributes - AD DS will not allow
    to do so (although you can modify them).
     
    > Domain Head writes to DefDomPol
     
    Yes.
     
    Thursday, March 24, 2016 8:11 AM
  • "You didn't try hard enough... Kidding :-)) "pwdProperties" - "

    I did actually find that but didn't realise it had anything to do with complexity/I didn't understand it. I certainly wouldn't know how to set it.

    "DCs have no local security policy "

    Sorry for "local security policy on DC", read "secpol.msc on DC".

    "You can verify that through editing one of the password attributes in

    the domain head. Then open secpol.msc - your change will be visible here."

    True. This also works in reverse. ie. editing it in secpol.msc also changes it in domain head.

    Anyway my thinking is this:

    If you create a FGPP PSO and apply it to a group of users, what password settings will all other users, not in that group, get, if we don't set/change them in group policies such as DefDomPol.(because we don't want to affect local accounts)

    Is it necessary to create a second PSO, and second group, for these users? It certainly seems like a good idea?


    • Edited by tim_dk Thursday, March 24, 2016 1:20 PM
    Thursday, March 24, 2016 12:35 PM
  • > If you create a FGPP PSO and apply it to a group of users, what password
    > settings will all other users, not in that group, get, if we don't
    > set/change them in group policies such as DefDomPol.(because we don't
    > want to affect local accounts)
     
    It doesn't matter if you have password settings in your DDP or not. You
    will always have password settings in your domain head, you cannot
    delete them and they will NOT vanish if you delete them from the DDP.
    And these will apply.
     
    Thursday, March 24, 2016 3:47 PM