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

Rahamim Levi 366 Reputation points
2020-12-10T15:20:00.177+00:00

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,997 questions
Microsoft Configuration Manager
{count} votes

Accepted answer
  1. Daisy Zhou 19,276 Reputation points Microsoft Vendor
    2020-12-29T03:13:15.913+00:00

    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: Newest
  1. Rahamim Levi 366 Reputation points
    2020-12-28T17:22:22.87+00:00

    Thank you @Daisy Zhou

    I just realized That I used the wrong terminology.
    The MECM client is using Integrated Windows Authentication to send messages to the management point which is MECM DMZ server that is what I attached in my last answer. (Personal details have been removed.)
    The problem is, The user's password was about to expire and the user was forced to change the password without line of site to the domain controllers.(We are in a hybrid mode and do not use VPN for security concerns. The users are able to change their password via office 365 password writeback system). Since the user changed their password it uses 2 passwords. 1 is what was set against the domain the last time the computer had a line of site and one that was set via office 365 password change service.
    The client is using the old password as shown below:

    Post using domain\testuser security context failed due to Integrated Windows Authentication failure (CcmMessaging)
    Post to https://MECM-DMZ.Domain.com/ccm_system_windowsauth/request failed with 0x80070005. (CcmMessaging)

    I hope this clears my problem

    Rahamim.

    0 comments No comments

  2. Rahamim Levi 366 Reputation points
    2020-12-24T13:56:35.38+00:00

    Found something causing the credential attempt:

    In the file CCMMessaging.log I found the failed attempts to use the user with the cached credentials.
    I'm attaching the part of the log that showed the failed attempt. I also copied the entire CCM logs folder to have a "Snapshot" of the situation during the time of the issue

    51143-ccmmessaging.log

    Rahamim.


  3. Daisy Zhou 19,276 Reputation points Microsoft Vendor
    2020-12-21T08:32:17.147+00:00

    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.

    49963-logon1.png

    Best Regards,
    Daisy Zhou


  4. Daisy Zhou 19,276 Reputation points Microsoft Vendor
    2020-12-16T01:36:02.647+00:00

    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