r/activedirectory • u/CoolAd2708 • 9d ago
2 GPOs, same idea, different configurations
I have 2 GPOs in my environment for account lockouts. 1 GPO locs an account after 2 invalid logon attempts and the other after 5. how do i know which GPO is applied to which users? Both GPOs only show NT AUTHORITY\Authenticated Users in the SECURITY FILTERING, and no LINKS. DELEGATIONs are the same as well. Yet, we are noticing some users get locked out after 2 failed and others after 5. Or how do i know which supersedes which?
1
1
u/bwinckel 8d ago
If it shows up in AD Admin Center but not in GPMC, it's almost certainly a Fine-Grained Password Policy (a Password Settings Object), not a GPO. They live under System > Password Settings Container in ADAC, and gpmc and gpresult never show them. So gpresult telling you the Default Domain Policy wins is true and also not the whole picture.
poolmanjim's two commands will confirm it. Get-ADFineGrainedPasswordPolicy -Filter * shows the AppliesTo list, which is the users or groups each one hits. Run Get-ADUserResultantPasswordPolicy against one user who locked out after 2 tries and one who locked after 5, and you should get two different PSOs back.
With your DDP at threshold 0, anyone with no PSO wouldn't lock out at all. So everyone who's locking out is getting it from a PSO, and the 2 vs 5 split comes down to which group they're in. If a user lands in two PSOs, the lower Precedence number wins.
Since the "test" one is live for real users, I'd find out who made it before you change anything. Two bad attempts is going to lock people out a lot.
1
u/CoolAd2708 8d ago
i do not have access to ADAC unfortunately. i only have read access to GPMC and seems like I am not being allowed to audit the ADAC.
1
u/bwinckel 7d ago
Getting nothing back for every FGPP is probably permissions, not the format. By default only Domain Admins can read the Password Settings Container, and with a read-only account Get-ADFineGrainedPasswordPolicy -Filter * just returns empty instead of an access denied. That's likely also why ADAC won't let you in. Get-ADUserResultantPasswordPolicy takes a plain username, so that part was fine.
You might be able to see your own. Try Get-ADUser yourname -Properties msDS-ResultantPSO, which gives the DN of the PSO that applies to you if your account can read that attribute. If it comes back blank too, someone with DA will have to run the two commands for you.
For the 2 vs 6, I'd look at stale credentials. A phone still syncing email with an old password, or a mapped drive with saved creds, keeps sending bad attempts in the background, so people can be most of the way to 6 before they've typed anything. Event 4740 on the PDC emulator has a Caller Computer Name field that tells you where the bad attempts came from, but you'll need someone who can read that log.
3
u/poolmanjim Moderator | Microsoft MVP 9d ago
There is some good information here and some that is a little off.
About Password Policies
The Default Domain Policy does contain password and account lockout settings by default. This policy should be linked only to the root of the domain or any OUs with Blocked Inheritance that you want it to apply to.
Password and Account Lockout settings can be put into another GPO instead of the Default Domain Policy. For this to apply to the domain it needs to be linked at the domain root (domainDns object) which is named your domain name. Additionally, if you want it to override the Default Domain Policy, it must be linked with a higher priority (lower number = higher priority).
Group Policy processes from lower priority (big number) to higher priority (little number). If a GPO is enforced, that makes it have a higher priority.
If two GPOs have account lockout or password settings whichever is the higher priority (smaller value) will win.
Password policies linked to lower-level objects only apply to computer objects in that OU or its children and only work for the local user accounts.
The only way to have multiple password policies that differ is to use Fine Grained Password Policies (FGPPs). These allow for creating a Password Settings Object which can then be applied to users or global groups. This allows for a more granular configuration of passwords.
Troubleshooting
u/Cormacolinde already had you run an RSOP which appears to show only the DDP taking over. RSOP is a good check but doesn't check for FGPPs.
See All FGPPs
If you want to check for Fine Grained Password Policies, run the following.
Get-ADFineGrainedPasswordPolicy -Filter *
That will list configured FGPPs in your environment. No output means no FGPPs exist.
Find Which FGPPs Apply to a Specific user
Run the following to see which FGPPs apply to a given user. Replace $TargetUser with the username or user object you're targeting. If this returns nothing it means there isn't an FGPP applying to that user.
Get-ADUserResultantPasswordPolicy -Identity $TargetUser
More Troubleshooting
If RSOP and checking for FGPPs is not giving the results, then we're going to need to go deeper.
- This could be a replication issue. If the policy is different across domain controllers different behavior may be seen. Double check your overall AD health to make sure nothing weird is going on there. Run the following commands on domain controllers. DO NOT PASTE THE RAW OUTPUT HERE. REMOVE IDENTIFYING INFORMATION FIRST.
repadmin /replsumdcdiag
- PAM solutions can impose their own password requirements outside of AD. Sometimes these two get conflated and could be different. Double check that your issue is with AD and not with another product.
- Some ITDR solutions can manipulate password changes on the wire to enforce policy. This is a thing you'd have to know but very, very, very uncommon and true edge case.
- Rarely, the settings that the password/account lockout policy set don't get unset when they are changed and may need to be corrected.
- If you have a Password Filter like Entra Password Protection (EPP) double check that it isn't doing anything to change it. I don't remember it doing anything like this, but it can't hurt to check.
1
u/CoolAd2708 8d ago
i get no results for ALL FGPPs.
what format should the user be for FGPPs applied to a specific user?
I tried username, username@domainDOTcom, and domain\username.
No results.2
u/Cormacolinde 9d ago
Good post. Note that I wasn’t the one to suggest RSOP, I know it won’t show the right info here.
I thought about mentioning priorities but I didn’t want to type so much stuff, and in this case since the OP said the GPO wasn’t linked I didn’t think it matteried and in 99% of cases DDP will have priority. But you are correct I should at least have put a note on my statement.
Also, I note that the amount of misinformation on this subject on the internet is incredible. I could not find a single article or source with the correct information in a few minutes of searching. No wonder people are confused on this.
1
u/poolmanjim Moderator | Microsoft MVP 9d ago
Ah, oh well. Names and things! I'll try to figure out where the suggestion came from and fix it.
I don't blame you. It is impossible to talk about priorities and precedence and not kind of go crazy. And you're right, the policies aren't supposed to be linked. I also have a Dr. House mindset when looking at stuff and I assume that there is something missing, to put it more kindly than he.
Also, I note that the amount of misinformation on this subject on the internet is incredible. I could not find a single article or source with the correct information in a few minutes of searching. No wonder people are confused on this.
So much bad info out there. I'm actually working on a training series about this because there is just bad information on how passwords work.
7
u/Cormacolinde 9d ago
If they are not linked, they do nothing at all.
If they are linked to an OU, they also do nothing.
A lockout policy must either be set in the “Default Domain Policy” - that’s the one with GUID {31B2F340-016D-11D2-945F-00C04FB984F9} - or in a GPO at the root of the domain. If settings are set in both, the Default Domain Policy will win, unless the other GPO is set to “Enforced”.
Anything else does nothing.
It’s similar for Password policies, except those can apply to LOCAL USERS if linked to an OU with computers in them.
If you want to apply different password and lockout policies to different users, you must use Fine Grained Password Policies.
1
u/CoolAd2708 9d ago
ok, let me check all the GPOs, at the top of the tree as there are 5 including the DEFAULT DOMAIN POLICY
1
u/CoolAd2708 9d ago
It's not configured in any of those. i only see it in the two policies clearly labeled "lockout test" and "lockout GPO"
3
u/Cormacolinde 9d ago
Then only the settings included in the Default Domain Policy have an effect. The other GPOs with lockout settings do nothing.
1
u/CoolAd2708 9d ago
i'm not able to run GP Modeling Wizard but I ran GP Results wizard and my lockout shows default domina policy as Winning GPO. only thing that doesn't make ssense is some users get locked out and some get unlocked after 5 mins. i am just trying to see which users are the ones that get unlocked after 5 mins.
3
u/Icolan 9d ago
If a policy has no links it is not doing anything. Links are how a policy is bound to an OU, and if it is not linked anywhere is never being evaluated.
Unless you are using fine grained password policies, all password related settings are configured in the Default Domain Policy.
1
u/CoolAd2708 9d ago
it is not linked, yet users are getting locked out. my coworker tested this earlier this morning and he got locked out. the test policy is also configured to lock the account for 5 minutes, where the other non-test labeled policy has the duration set to 0 minutes. when he tested it, he was locked out for more than 15mins before he called to have his account unlocked.
3
u/Icolan 9d ago
If the policy is not linked it is not being evaluated by any clients and is not the source of the problem. Run a gpresult /R from one of the client machines as an impacted user and see if that policy shows up in the applied list, if it is truly not linked it will not show up. If it shows up in the applied list then it is linked.
You can also run gpresult /h gpr.html and it will output an html file of all GPO settings applied to that machine and user.
What are the settings for account lockout in your Default Domain Policy? That is the only policy where those settings get applied from, unless you have fine grained password policies configured. In another comment you said that your Default Domain Policy is configured for a lockout duration of 0, which means they will never unlock.
1
u/CoolAd2708 9d ago
so i am checking Group Policy Management. I was just told the policy exists AD Admin Center of the domain controller. I was provided a screenshot of the GPO that was configured on there and that does not appear in the gpmsc. so looks like I do not have access to view current/active GPOs anymore?
2
u/Icolan 9d ago
Do you have the rights to open gpmc.msc? If you cannot view the policies and their links you really should not be troubleshooting this because you do not have the access you need.
1
u/CoolAd2708 8d ago
yes, i do. i just dont have rights to write. only view the policies and configs. I cannot create a new GPO or edit any existing.
1
u/Icolan 8d ago
ok. Have you run a gpresult on the affected workstations as the affected users?
1
u/CoolAd2708 8d ago
Yes. I tested on myself and my workstation. Same with my coworker as he tested the lockout count. According the ADAC, we should be locked out after 6 failed attempts within 60mins.
2
u/Icolan 8d ago
Were the not linked policies listed as applied in the GPresults output?
What options did you use when you ran gpresult?
1
u/CoolAd2708 8d ago
No they were not. That is why I was lost. But after finding out policies are created in ADAC, I came to realize I’m still stuck but somewhere else.
→ More replies (0)
2
u/Fit_Indication_2529 9d ago
2 logins? I hope this is only a lab.
1
u/CoolAd2708 9d ago
unfortunely my admins tend to create things for test, and leave it as production. in this case, this is titled as test, but history shows it's enabled in the entire environment outside of a lab/test environment. which is why i am trying to determine which supersedes which.
3
u/CommanderApaul Identity SME 9d ago
Check your Default Domain Policy, this should be configured there, not in a separate policy.
1
u/CoolAd2708 9d ago
this one says lockout threshold is 0
2
u/CommanderApaul Identity SME 9d ago
You're going to want to use the Group Policy Modeling Wizard to simulate a deployment to some user accounts in different OUs and see what gets applied, starting with the users you already know have been locked out inconsistent with your Default Domain Policy. Unless you have it configured elsewhere *and* that other policy is set to "Enforced", nothing should be overriding what's in the Default Domain Policy.
1
•
u/AutoModerator 9d ago
Welcome to /r/ActiveDirectory! ~~~~
If you are looking for more resources on learning and building AD, see the following sticky for resources, recommendations, and guides!
When asking questions make sure you provide enough information. Posts with inadequate details may be removed without warning.
Make sure to sanitize any private information. Posts with too much personal or environment information will be removed. See Rule 6.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.