Wierd AD lockout issue

BigToneBigTone Member Posts: 283
All,

The last couple days one particular user has been experiencing windows authentication lockouts daily on his machine and when he tries to remote desktop. According to him, he changed his password and this problem started. Keep in mind this is a programmer and one of those users that knows enough to be dangerous but enough to help me figure out what he's got going on inside it.

I've pinpointed the problem down to something on his machine, on his profile. Reasons being:

1. When his machine is off, this doesn't happen. He can RDP to our servers on our test machine at my desk.
2. Even after trying to remove and create a new profile for the user, this occurs. No wierd programs or anything load up, its pretty clean aside from antivirus and the usual dell garbage

I haven't run process monitor yet, but thats my next thing. Does anyone have any quick tips or tricks to help me to see what is in the background authenticating?

Thanks in advance.

I'm trying to avoid the "Crush his box" answer I get from the other guy in our team. I would actually like to figure out what the problem is.

Comments

  • ClaymooreClaymoore Member Posts: 1,637
    Does he have a service running on his workstation that is set to authenticate using his (now old) credentials? If he does, I am sure he didn't change his password on the authentication tab of the service. I would think that the service would just fail to start but maybe this one is really determined or kicked off by something he is doing and it continually tries to authenticate with a bad password.

    You should see failures in the system log.
  • BigToneBigTone Member Posts: 283
    Thanks,

    After digging through the logs I've found multiple references to this. On 11/10 the user did windows update and manually changed the password. It sounds like a DNS thing, but this is the only user having the problem, which is really perplexing.

    "The Security System detected an attempted downgrade attack for server ldap/myserver.mycompany.com. The failure code from authentication protocol Kerberos was "The user account has been automatically locked because too many invalid logon attempts or password change attempts have been requested. (0xc0000234)" "
    and
    (1) "Automatic certificate enrollment for TECHEXAMS\ouruser failed to contact the active directory (0x80072095). A directory service error has occurred. Enrollment will not be performed."
    (2) "Windows cannot determine the user or computer name. (An internal error occurred. ). Group Policy processing aborted."
    in the Application log.
  • TechJunkyTechJunky Member Posts: 881
    Sounds like a classic prank to me.

    I used to fail peoples logins all the time if they made me angry so they would have to call helpdesk to get them reactivated. Talk about fun.
  • blargoeblargoe Member Posts: 4,174 ■■■■■■■■■□
    Any services running on his pc using his windows account? You said he is a developer, maybe he installed something like sql developer edition and is running the services under his user credential or something like that.
    IT guy since 12/00

    Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
    Working on: RHCE/Ansible
    Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands...
  • undomielundomiel Member Posts: 2,818
    Check where your failure audits for his account are coming from and as mentioned earlier see if there are any services set to run under his account.
    Jumping on the IT blogging band wagon -- http://www.jefferyland.com/
  • BigToneBigTone Member Posts: 283
    Under the users - advanced manage passwords the only thing he has is for exchange and for MS Live.

    I'll turn on auditing now and see if I can pinpoint where its coming from.
  • RobertKaucherRobertKaucher Member Posts: 4,299 ■■■■■■■■■■
    BigTone wrote: »
    Under the users - advanced manage passwords the only thing he has is for exchange and for MS Live.

    I'll turn on auditing now and see if I can pinpoint where its coming from.

    AD issue... I could have swore this thread was Weird Al issue. Nothing I can add to that except "It's all about the Pentiums, baby!"
  • BigToneBigTone Member Posts: 283
    Account audit on the server is giving the krbtgt service. I installed the account lockout tools from MS on his machine and going to hopefully get a better idea of whats happening in that log.
  • BigToneBigTone Member Posts: 283
    AD issue... I could have swore this thread was Weird Al issue. Nothing I can add to that except "It's all about the Pentiums, baby!"

    lol


    I'm glad you think this is funny. Maybe for christmas I'll send a russian programmer over to your cube that needs his account unlocked everytime he decides to reboot his machine.
  • RobertKaucherRobertKaucher Member Posts: 4,299 ■■■■■■■■■■
    BigTone wrote: »
    lol


    I'm glad you think this is funny. Maybe for christmas I'll send a russian programmer over to your cube that needs his account unlocked everytime he decides to reboot his machine.

    In all seriousness, if I had to place a bet on this it would be that he has set something like a local instance of SQL Server (or some other application) to run under his user name. When he set it to run under his user account he used his prvious password. Once he reset his password he forgot about it and now when the PC starts the service launches and attempts to run under the security context of his account with the old password. The domain controller says no, the service tries to restart, the domain controler says no, etc and by the time he tries to log on it has reached the lockout limit. It could actually be multiple services.
  • BigToneBigTone Member Posts: 283
    Well... The lock audit thing didn't help much.

    I did run wireshark, captured from an unlocked Account to when he got locked and I see the 5 instances of Kerberos trying to hit our domain controller from his PC and it goes from KRB Error: KRB5KDC_ERR_PREAUTH_FAILED to the 5th time KRB Error: KRB5KDC_ERR_CLIENT_REVOKED NT Status: STATUS_ACCOUNT_LOCKED_OUT

    They're all UDP packets... Maybe I'm drilling down too far. On the account lockout thing it didn't bring up any services that were causing the lockout, and on the domain controller user audit thing it gives Kerberos as the culprit as well.

    Any ideas or directions for me to look next?
  • ClaymooreClaymoore Member Posts: 1,637
    Run services.msc (or go the the services section in Computer Management), sort by the Log On As column and look for his account name. most services will use Local System or Network Service so the services using his account should be easy to spot.
  • BigToneBigTone Member Posts: 283
    Ok,

    Will do first thing monday. Thanks for the help.
  • redalertredalert Registered Users Posts: 1 ■□□□□□□□□□
    I wish this thread had a second page...I'm stuck with this issue...
    Services reveal no Log on as the user - only Local Service, Local System and Network....
  • About7NarwhalAbout7Narwhal Member Posts: 761
    I know this one is dated, but from my experience for the OP and for the new poster, check and see if the user has attached any third party hardware. Perhaps a printer, mouse, or scanner. From what I have seen, even a valid authentication will result in a lockout if your user does not have the rights to run a service. So what happens is that the device attempts to add a service when it installs and cannot run. It continues to try to install multiple times until the account locks out. This results in "resource is unavailable" and "access denied" errors when attempting to access network resources even though the user has been logged in for a while.

    I would suggest having the user attempt to use their computer without any third part HW attached for the day and see if the issues are resolved. I had a HD tech on my team who would get locked out 3 or 4 times a day for about a month. It was traced back to a mouse install that he didn't have full access to perform. The result is a successful driver install but the service didn't have the rights to run. Credential cache is another big one. Consider removing all network share drives and re-adding them. Especially if there are drives that the user almost never accesses.

    *Note that these are mostly XP issues*
  • survivor030406survivor030406 Member Posts: 18 ■□□□□□□□□□
    Well this is an interesting thread. I wish the original poster had wrote the details discovered and the solution.
    I wonder if this issue is covered in Network+ or Security+ studies?
    I'd like to see a write up, or PDF explaining this problem and solution.
    As I plan to keep advancing my studies, this is one issue I'd like to learn about.
Sign In or Register to comment.