Account lockout from a computer without a line of site to active directory VIA MECM

Rahamim Levi 366 Reputation points

Hi everyone

Here is a weird story: Since COVID, most of our domain laptops haven't arrived to the office to connect to active directory. Meaning, users who still wanted to work had to use 2 different passwords - 1 for the local computer (because there is no line of site to AD and it is the password they had last time they were connected to the LAN). 2 for accessing data (office 365, RDS via VPN etc...) which they can change remotely (Password write back)
Everything works and the users understand the need for 2 passwords. The weird part is, users get locked out from their own computers... We found that out with using AD monitoring for account lockout, Checking the user's home ISP IP address and our firewall to see what the IP address is trying to access in our network. We still use IBCM and we have a DMZ MECM server to manage those computers, and the clients send and receive data from that server. Apparently, the computer accessed the DMZ server in some way and forwarded credentials to AD.

Has anyone encountered this? If we can use this to update the cached password it would be even better.

Kind regards, Rahamim

Active Directory
Active Directory
A set of directory-based technologies included in Windows Server.
5,962 questions
Microsoft Configuration Manager
{count} votes

Accepted answer
  1. Daisy Zhou 18,956 Reputation points Microsoft Vendor

    Hello @Rahamim Levi ,

    I once again carefully reviewed the entire post information, my understanding now is this.

    1.The user PC have not connected to AD domain;
    2.But when the user's password was about to expire and the user was forced to change the password via office 365 password writeback system and without line of site to the domain controllers.
    3.The new password will be write back to AD domain.
    4.The users use old credential to logon their PCs (MECM clients) and the MECM client is using Integrated Windows Authentication to send messages to MECM DMZ server.
    5.Because there is no such user credentials on MECM DMZ server, the MECM DMZ server can not authenticate those user account and password, then MECM DMZ server will pass the credentials (there are user accounts and old passwords on DCs) to the domain controller (there are user accounts and new passwords on DCs) for authentication. At last, the authentication will fail, so the account will be locked out.

    If anything I misunderstood, please correct me.

    If my understanding is correct, here is my suggest for your reference.

    1.Prevent MECM clients from communicating with MECM server.

    2.Or make MECM clients connect to AD one time via VPN, after the user logon MECM clients using new credentials, we can stop using VPN again.

    Hope the information above is helpful.

    Best Regards,
    Daisy Zhou

6 additional answers

Sort by: Most helpful
  1. Daisy Zhou 18,956 Reputation points Microsoft Vendor

    Hello @Rahamim Levi ,

    Thank you for posting here.

    Based on the description, please confirm the following information:

    1. What does DMZ server do (I mean which services did DMZ server provide)?
    2. How did client to access the DMZ server?

    User must provide the credential when access the DMZ server, and now the user changed his/her password, maybe the old credential is rememberred automatically to access the DMZ server more time using old password, so the user account is locked out.

    We can try to find out the old credential and delete it to see if it helps.

    Best Regards,
    Daisy Zhou

  2. Daisy Zhou 18,956 Reputation points Microsoft Vendor

    Hello @Rahamim Levi ,

    1.So as I understand, there is a domain account locked on DMZ server with MECM.

    2.Can you see event 4625 on DMZ server via Event Viewer?

    For example,
    If a domain account is locked out, we can see the 4771/4776 and followed by 4740 on one Domain Controller.


    The number of 4771/4776 is the lockout threshold value.

    At the same time as 4771 (in my case, 1:48:48 PM and 1:48:52 PM ) or 4776, we will see event 4625 (in my case, 1:48:48 PM and 1:48:52 PM ) on machien that locked the account.

    3.If you cannot see event 4625 on DMZ server, maybe the audit policy setting is not configured, we can configured them through local group policy on DMZ server as below:

    Computer Configuration\Windows settings\security settings\local policies\audit policy
    Audit Logon Events – Failure (on server)

    Or use advanced audit policies (advanced audit policies will overwrite traditional audit policies by default):
    Computer Configuration\Windows settings\security settings\Advanced Audit Policy Configuration on server
    Audit Account Lockout – Failure
    Audit Logon – Failure

    4.Then update gpo on DMZ server by running gpupdate/force.

    5.If the account locked again, we can check 4771/4776 on DC and 4625 on DMZ server.

    Hope the information above is helpful. If anything is unclear, please feel free to let us know.

    Best Regards,
    Daisy Zhou

  3. Daisy Zhou 18,956 Reputation points Microsoft Vendor

    Hello @Rahamim Levi ,

    Thank you for your update.

    We can try to find out what is being authenticated using this specified user account on the DMZ server (such as App, script).

    • Check the credential management to see if there are cached user’s old credentials
    • Check if you have used the wrong password to mount the network disk
    • Check whether the user has used the wrong password to start services, run scheduled tasks, etc.
    • Are there other third-party programs that cache the user's wrong password

    Hope the information above is helpful.

    Best Regards,
    Daisy Zhou

    0 comments No comments

  4. Daisy Zhou 18,956 Reputation points Microsoft Vendor

    Hello @Rahamim Levi ,

    For account lockout, we need to know the locked user account and the device that locked this user account.

    As I understand, now you know which user account was locked and which machine (MECM server) has locked this user account, is that right?

    If so,could you please check if the event ID 4625 was generated on the MECM server (with the specific locked user account and with the same timestap as 4771/4776) before the user account was locked.


    Best Regards,
    Daisy Zhou