This topic is resolved

Share

This topic contains 7 replies, has 3 voices, and was last updated by  Luc Fullenwarth 6 months ago.

  • Author
    Posts
  • #163522
     Yiannos 
    Participant
    • Topics: 1
    • Replies: 3
    Post count: 11
    Member Points: 131
    Rank: Level 1

    Hi all,

    I am very happy to be here. Just joined and this is my 1st post:

    A client of mine’s setup:

    2 domain ctrlrs 2012 R2, one local, one in Azure VM.

    Domain joined pc with Windows 10 Pro x64

    Here is the (freaky) story:

    In this client, users are not allowed to install anything on their pc’s. As it usually goes, the time where an installation had to be done and no admin was present to enter their credentials. At that time, we created a new domain admin account, and gave the user the credentials to allow them to make the installation. We subsequently deleted this user in order to disallow any further use.

    The problem is that the user can still use this admin’s credentials on their pc event months after deletion. The creds do not work on other user profiles. Only on the one who originally made use of this.

    We tried the following:

    1. Change the admin’s password
    2. Disable the admin on the dc
    3. Delete the admin on the dc
    4. Re-create the user and check the “Require password change” box
    5. Zero-out all cached credentials in HKLM/Security/Cached
    6. Try to find the account in Credential Manager (not there of course)
    7. Try to find the account inrundll32 KeyMgr,KRShowKeyMgr (not there either)

    Needless to say we have also ruled-out replication issues as we are sure everything is working properly there.

    In the meantime, the affected user has been fired (over other issues 😉 ) so we do not have the security problem as such but this story is really spooking me.

    Any ideas?

    TIA

    Yiannos

    • This topic was modified 6 months ago by  Yiannos.
    0
  • #164412
     Michael Pietroforte 
    Keymaster
    • Topics: 138
    • Replies: 337
    Post count: 1047
    Member Points: 7,251
    Rank: Level 1

    Can you verify that the PC is still a domain member and that is connected to the domain? For instance, you can try to access a network share on a domain controller from the PC. What you can also try is remove the PC from the domain and then add it again.

    0
    • #164786
       Yiannos 
      Participant
      • Topics: 1
      • Replies: 3
      Post count: 11
      Member Points: 131
      Rank: Level 1

      Thanks for your reply.

      The PC is always a domain member.

      I will try the removal/addition and let you know.

      0
  • #164771
     Luc Fullenwarth 
    Moderator
    • Topics: 3
    • Replies: 25
    Post count: 86
    Member Points: 6,415
    Rank: Level 1

    This is probably due to the Number of previous logons to cache policy.
    (Windows Settings \ Security Setting \ Local Policies/Security Options \ Interactive logon)

    You may have the default value of 10 which is fine for Laptops, while the recommended value for Desktops and Servers is 0 (the default Administrator account is always here in case of emergency).
    Don’t set it to 0 for Laptops because they are sometimes offline, and thus users would not be able to log on.

    I suggest to:

    1. Create a GPO with this value set to 1.
    2. Apply this GPO to your computers which have the issue.
    3. Logon to those computers with any other account.
    4. Remove the GPO.

    This method will remove the rogue account from the cache.

    As a workaround you can also use the Deny log on locally policy, but this does not fix the root cause of your issue.

    2+

    Users who have liked this topic:

    • avatar
    • avatar
    • #164783
       Michael Pietroforte 
      Keymaster
      • Topics: 138
      • Replies: 337
      Post count: 1047
      Member Points: 7,251
      Rank: Level 1

      It is just odd that the account can still be used even though it has been disabled. This indicates that the computer is no longer connected to the domain. Thus, a new GPO might not solve the problem because it never reaches the client.

      On the other hand, credential caching can sometimes cause weird issues. So changing this policy is worth a try.

      0
    • #164789
       Yiannos 
      Participant
      • Topics: 1
      • Replies: 3
      Post count: 11
      Member Points: 131
      Rank: Level 1

      Thank you for your reply.

      I will try this and report back.

      0
    • #166085
       Yiannos 
      Participant
      • Topics: 1
      • Replies: 3
      Post count: 11
      Member Points: 131
      Rank: Level 1

      I am happy to report that the GPO approach solved the problem.

      Thank  you very much for your input.

      0
      • #166099
         Luc Fullenwarth 
        Moderator
        • Topics: 3
        • Replies: 25
        Post count: 86
        Member Points: 6,415
        Rank: Level 1

        Thank you also for your feedback!
        Often people just take the information and just disapear…

        You are welcome Yiannos!

        1+

        Users who have liked this topic:

        • avatar

You must be logged in to reply to this topic.

CONTACT US

Please ask IT administration questions in the forum. Any other messages are welcome.

Sending
© 4sysops 2006 - 2017

Log in with your credentials

or    

Forgot your details?

Create Account