Koldov Posted March 20, 2019 Posted March 20, 2019 (edited) It would appear I have made a schoolboy error, which I am unable to Google my way out of and so I come cap in hand to EDUGEEK... Whilst trying to beef up security a little I decided I would gradually increase limitations on account password policies. Starting slowly, first I thought I would limit the amount of logon attempts before the account was logged out (nobody would input their password incorrectly more than 3 times, right?). The first problem arrived knocking at my door almost immediately! Some of our SEN classes have very simple class log-ins, so it only takes one of them to make a mistake 3 times, or 3 of them once and the whole group is logged out... By the second day, pretty much ALL of the groups had logged themselves out at least once. So I decided that I would take that on the chin and revise my policy at a later date, but for now I would delete the offending GPO, only I couldn't because to impact on my initial error I wanted this to apply to every OU, so where did I put it? You guessed it, I had made it part of the Default Domain Policy (ouch!). Anyway, I thought I would remove the offending part and set it all back to 'Not Defined' and peace would be restored... A swift 'gpudate /force' later NO! Still locking themselves out multiple times a day... So I thought I would put in another GPO to reverse the lockout policy... 'gpudate /force' and a reboot this time... NO! So I thought I would remove a computer from the Domain and re-add, NO! At this point I'm stuck! Secondly, I thought that it would be a good idea to have me unlock the account rather than an abritrary time out period. When I explained my clever plan to the first teacher who locked themselves out, she replied "what about in the holidays?"... Dammit! My plans for world domination ruined at the first hurdle! So I created 2 new policies, one for the on-site computers OU that still requires me to unlock them and one for the teacher laptops OU that has a timout period. Is this the best way? Is it even going to work given my experience with failing to change the policy for the other OU? What have I done?! Please don't judge... Edited March 20, 2019 by Koldov
AJB123 Posted March 20, 2019 Posted March 20, 2019 Hi, not sure this will help. https://blogs.technet.microsoft.com/canitpro/2013/05/29/step-by-step-enabling-and-using-fine-grained-password-policies-in-ad/ 1
bald_pig Posted March 20, 2019 Posted March 20, 2019 Don't you just need to change the setting to disabled instead of not configured? 1
Koldov Posted March 20, 2019 Author Posted March 20, 2019 Hi, not sure this will help. https://blogs.technet.microsoft.com/canitpro/2013/05/29/step-by-step-enabling-and-using-fine-grained-password-policies-in-ad/ Thanks, I will look at that for the future. But... Does anybody know what I need to do, or where I need to look to undo the GPO changes that still seem to be applying? I can understand that whatever changes it made (to the registry?) are still going to be there if I just revert the setting to undefined, but I'm not getting the part where I set a new policy and it seems that it isn't overwriting the original setting - i.e. still locks the account after 3 bad attempts, even when new policy should set it to zero (If you set the value to 0, the account will never be locked out)...
Koldov Posted March 20, 2019 Author Posted March 20, 2019 Don't you just need to change the setting to disabled instead of not configured? It appears that isn't an option for this particular GPO setting Looks like it's 'Not Defined' or a value - unless I'm missing something (very possible).
Koldov Posted March 20, 2019 Author Posted March 20, 2019 Well, that's annoying... Logging on to the machine and running RSoP shows that the setting was 'not defined' (but still locked me out). Tried my new 'NO LOCKOUT' policy and it has applied correctly (checked in RSoP). Logged out, logged in again with the wrong password 3 times and.... LOCKED OUT!!!!
LukeRowberry Posted March 20, 2019 Posted March 20, 2019 dcgpofix will reset the default domain policy if everything else fails. 1
Koldov Posted March 22, 2019 Author Posted March 22, 2019 (edited) Ok, so I fixed it at last.... Phew!!! Seems my Google-fu is on top form this morning (or I just worded my search terms a little better). It's still a little bit complicated to my mind, but here goes.... After a little searching I found this: https://www.experts-exchange.com/questions/24147612/Account-lockout-policy-is-still-being-enforced-after-policy-is-removed.html In that thread it mentions 'secpol.msc' - running that on an affected client machine showed the setting my new policy applied (even though it was being ignored - possibly because it was an OU level policy - see below*). However, running secpol.msc on the DC showed my old policy still being applied (on the DC) and yet looking at the 'Default Domain Policy' all settings were 'undefined'. I think I was on the right track in having to define it to change the setting, just that I needed to define it (as 0) back in the 'Default Domain Policy' and not try to override it with an OU policy. So after setting the 'Account Lockout Threshold' to '0' and setting it to defined in the 'Default Domain Policy' a quick 'gpupdate/force' later - no more lockouts! *As I also found that an 'account policy' change has to be made at the Domain level (or a policy linked to the root of the Domain), so trying to have different policies for different OUs may be slightly more complicated than I imagined, as @AJB123 mentioned I might have to look at fine-grained password policies... Edited March 22, 2019 by Koldov
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now