Password reset with DNS flush

%3CLINGO-SUB%20id%3D%22lingo-sub-1174236%22%20slang%3D%22en-US%22%3EPassword%20reset%20with%20DNS%20flush%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1174236%22%20slang%3D%22en-US%22%3E%3CP%3EHello%2C%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20have%20a%20domain%20controller%20under%20which%20I%20have%20configured%20a%20few%20systems.%20The%20regular%20password%20update%20policy%20was%20imposed%20under%20which%20most%20of%20the%20users%20updated%20their%20password.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EHowever%20one%20of%20them%20updated%20his%20password%20after%20the%20password%20expiration.%20Now%20the%20catch%20is%2C%20when%20he%20updated%20his%20password%2C%20he%20was%20able%20to%20login%20with%20his%20earlier%20password%20than%20the%20new%20one%20as%20it%20said%20'access%20denied%20or%20the%20user%20is%20not%20found%20on%20the%20active%20directly'%20(when%20in-fact%20he%20was).%20Guess%20it%20was%20some%20cache%20that%20helped%20him%20login%20with%20his%20earlier%20password.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESubsequently.%20when%20we%20further%20diagnosed%20the%20issue%20we%20found%20that%20the%20DNS%20setting%20which%20was%20pointing%20towards%20to%20the%20DC%20got%20flushed%20and%20it%20was%20set%20to%20'obtain%20DNS%20settings%20automatically'.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ENeedless%20to%20say%20%2C%20once%20that%20was%20fixed%2C%20things%20were%20back%20to%20their%20pristine%20state%20(just%20like%20always).%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWhat%20I%20would%20like%20to%20know%20is%20why%20such%20a%20strange%20behavior%20occurred%20om%20the%20system%20side.%26nbsp%3B%3C%2FP%3E%3CP%3EWhy%20did%20it%20flush%20the%20DNS%20settings%20for%20a%20password%20update%3F%26nbsp%3B%3C%2FP%3E%3CP%3EAny%20specific%20authentication%20process%20like%20kerberos%20or%20so%20might%20have%20triggered%20this%3F%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EAny%20help%20would%20be%20appreciated.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ERegards.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-1174236%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EWindows%20Server%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-1222244%22%20slang%3D%22en-US%22%3ERe%3A%20Password%20reset%20with%20DNS%20flush%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1222244%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F557852%22%20target%3D%22_blank%22%3E%40swap007%3C%2FA%3E%26nbsp%3Bbased%20on%20how%20you%20described%20this%2C%20it%20sounds%20like%20his%20workstation%20was%20getting%20DNS%20info%20from%20a%20different%20system%20(maybe%20the%20router)%20instead%20of%20the%20Windows%20DC%20DNS%20server.%20As%20such%20everything%20was%20running%20with%20cached%20creds%20as%20the%20DNS%20Zone%20for%20the%20domain%20was%20likely%20not%20resolvable%20via%20the%20routers%20DNS.%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThe%20fact%20that%20they%20could%20log%20in%20with%20old%20creds%20shows%20that%20window%20was%20attempting%20to%20use%20cached%20creds%20instead%20of%20validating%20against%20a%20DC.%20I'd%20check%20the%20event%20logs%20on%20the%20machine%20and%20see%20if%20you%20have%20errors%20around%20not%20finding%20logon%20servers.%26nbsp%3B%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E
Visitor

Hello,

 

I have a domain controller under which I have configured a few systems. The regular password update policy was imposed under which most of the users updated their password.

 

However one of them updated his password after the password expiration. Now the catch is, when he updated his password, he was able to login with his earlier password than the new one as it said 'access denied or the user is not found on the active directly' (when in-fact he was). Guess it was some cache that helped him login with his earlier password.

 

Subsequently. when we further diagnosed the issue we found that the DNS setting which was pointing towards to the DC got flushed and it was set to 'obtain DNS settings automatically'.

 

Needless to say , once that was fixed, things were back to their pristine state (just like always).

 

What I would like to know is why such a strange behavior occurred om the system side. 

Why did it flush the DNS settings for a password update? 

Any specific authentication process like kerberos or so might have triggered this?

 

Any help would be appreciated.

 

Regards.

1 Reply

@swap007 based on how you described this, it sounds like his workstation was getting DNS info from a different system (maybe the router) instead of the Windows DC DNS server. As such everything was running with cached creds as the DNS Zone for the domain was likely not resolvable via the routers DNS. 

 

The fact that they could log in with old creds shows that window was attempting to use cached creds instead of validating against a DC. I'd check the event logs on the machine and see if you have errors around not finding logon servers.