Secure Channel/Expired Machine Account Password Concerns – Revisited

Published Apr 23 2020 03:01 PM 23.2K Views

Greetings! – I hope you and yours are as safe and as healthy as possible. 


Due to the huge up-tick in remote workers, there has been a surge in questions/concerns around ‘stale’ device passwords/secure channel issues.  Many people were simply told “Take your PC and go home, right now.”  So, they unplugged their work laptop (or even PC) and left their office building in February or March - and haven’t been back to the office since.  In many cases, there wasn’t any time for thorough (or any) planning of a remote access design/implementation.  Some have VPN or some form of remote access but many more do not.  This is the scenario we’re seeing concerns about – “My users have their PCs at home, without VPN/connectivity, for well-beyond the machine password lifetime in AD.  Will there be issues when people come back in to work?


Several of us chatted internally and decided it was a good idea to publish a post about this “no connectivity” scenario, clarifying the situation, as well as sharing a link to a thorough technical blog that has some recent updates.  We also include some guidance, in case you do run into machine password issues – a nice PowerShell command to reset it, as well as a way to do this within the client UI (without needing to be a Domain Administrator).


Special thanks to Ned Pyle, Ryan Ries, Justin Turner, Sagi Vahabi, Daniel Carroll and Chunlin Xu for “helping the masses” on this one. 



“Users have their PCs at home and are without VPN/connectivity.  Many are disconnected for longer than the machine password age setting in my AD.  Will there be secure channel/device password issues when people come back into the office and plug back into the LAN?  Will users see this at sign-in?”


The answer is No- and here’s why:

  • The password change process on your remote worker’s PCs will kick-off at some point after the MaximumPasswordAge interval is exceeded on the PC.  However, in the ‘no AD connectivity’ situation, a DC won’t be discovered/reachable.  The machine password change process ‘logic’ is such that if the client can’t connect to a DC, “the process” will shut itself down before the PC’s local registry is updated with a new password - nothing changes on the client. 
  • When these PCs come back to the office in xxx days (or get full VPN connectivity to a DC or whatever), the password change process on the PC will “wake up” again and re-attempt the domain password change process.  This time, assuming the PC will be able to find a DC, the process will complete its machine password change (and its corresponding registry update) - and then communicate that new value to the DC it found.  This DC updates the password attribute of the computer object in its copy of AD, and then AD replication takes that new value out to other DCs.  All will be well.
    • The netlogon process on the client has been trying this, every so often, while offline - but the process always bailed-out because it couldn’t find/reach a DC. 

NOTE: There is one more BIG assumption here – that there aren’t any scripts/processes that run to delete/disable “stale” computer accounts in AD while these client devices are offline.


NOTE: The above scenario is “no connectivity to AD/DCs.”  However, we have seen some issues in the past if there was ‘intermittent’ connectivity, and a DC is resolved/found, but something blocks unfettered communications to the DC (such as a firewall rule or some other connectivity issue).  In that case, the client password change process may not bail-out.  The local device’s registry may get updated with a new password - but the DC won’t be updated.  This is rare, and not normal, but if it happens, you may be on the road to secure channel issues.


Bottom line:  The device password change process (which is performed by the netlogon service on the client) – is smart enough to bail-out if it can’t find/talk to a DC and it won't change the local password.


“Ok, but what if my user’s PC lost the secure channel and the device password is out of sync with AD?”

If there are issues with PCs losing the secure channel/trust (per the screen shot above), it can be reset several ways.  NETDOM.EXE (a shout-out to the ‘good ol’ days’ of NT Resource Kit tools and those books!), NLTEST.EXE and of course, PowerShell (was there any doubt?).  GUI-wise, you can reset the computer account in AD then leave/re-join the domain or simply use a wizard in the Windows GUI that will reset the machine password.


Two examples:


  • Windows GUI – from AD and the endpoint:
    1. AD Users and Computers - ADUC (for the AD old-schoolers) 
      • To short-cut any AD replication latency/delays, you might connect this console to on a hub DC or the DC with the PDC-Emulator role (PDC-E in the image below).
      • Find the device
      • Right-click the computer account and select ‘Reset Account’



1. AD Admin Center - ADAC




  1. Now, from the client, use the “Network ID Wizard” and follow the screen shots:  
    1. You need to be signed-in to the endpoint with a local admin ID (cached creds or a local account)





  • NOTE: The account you enter here in the wizard here does NOT need to be a Domain Admin - but it DOES need the AD permissions/rights to ‘join a computer to the domain’ (one aspect of which is change/reset passwords for computer objects)
    • Many customers don’t have those permissions set for typical users in AD, so you might need to use some other creds than the ‘normal’ domain user
    • Some customers have a service account that is used to join computers to AD – if so, this would be a good use of such a service account
    • Sometimes, depending on how the computer account object was created/PC joined, the permissions on the client computer account may be restrictive. 
      • In that case, you may need to manually edit the ACL(s) on the existing computer account(s)   






Well, there ya have it, folks … more secure channel/device password details than you can shake a stick at.





Occasional Contributor

Thanks for the Blog post!


1) A different trick that works in less steps:   Let's say your computer is joined to 'CONTOSO.COM' (DNS-style name). You can change the domain to 'CONTOSO' (NETBIOS style name). 1 reboot, and you're back in business.


2) Is the [Reset] needed if you leave/re-join a domain? Doesn't it assume ownership of the computer object when it re-joins?



Occasional Contributor

Thanks for your guidance! I would be greatly satisfied if the screenshots would use the modern Active Directory Administrative Center instead of the legacy ADUC. Can you consider this @Michael Hildebrand ?

@ Ryan – Great tip!  A typical ‘snag’ on these actions is having the proper/needed permissions - both on the computer account in AD (ordinary users often lack the needed AD permissions) and local admin rights needed to make changes on the client.  If the ID doing the dis-join/re-join has AD permissions to reset/change the password on the computer object, then the reset isn’t needed.  But many ‘users’ are local admins but don’t have those AD permissions.  This  could be due to how the computer account object was created in AD, how the PC was joined initially, or permissions in AD/the OU where the computer object lives, etc.


@ kwester – I’ve updated the post w/ the AD Admin Center visuals - I hope it helps.

Senior Member

thanks for this article. may be you could add a statement about cached credentials as well. i guess that would affect a lot of people too.

@Michael Hildebrand 

Daniel - can you elaborate on your thought there? 




But, what about this sentence?: "If the machine was unable to communicate with a domain controller, it doesn’t try to change its password - for example if it was a laptop running at home with no VPN for 4 months. If it could contact the DC but not succeed in changing its password for 60+ days, then it will have a secure channel issue."






We re-worded that line for clarity.  

Adding a note here that has been asked relating to end-user AD passwords while offline, on a domain-joined PC:  

"My AD password is going to expire ‘next Tuesday’ (based on the Password Policy of my AD and how long it’s been since I last set my password in AD).  However, I’m offline and working away from a DC, so my cached creds are getting me into my PC.  Will my cached creds expire ‘next Tuesday’ even though I’m away from a DC?  Is the cached password ‘aged’ on my PC when away from AD/DCs?"  


The answer here is no - your AD password won't expire locally (on your PC) and prevent you from signing in to your PC while offline (away from AD/DCs).

Occasional Contributor

@Michael Hildebrand I am guessing that  @Daniel Gut is probably talking about the cached user credentials on an offline domain joined machine such as described

There is a common misconception that this refers to the number of times that you can login without a domain controller. However my understanding is that it refers to the number of different cached credentials that are stored on the computer - so with the maximum of 50, you could have up to 50 users credentials cached (apart from machine and service accounts that are used.

Andy - you are right. There is often misunderstanding that the setting you mentioned limits how many times a given user can login while offline; it is NOT that. It is a limit to how many different users can login while offline (assuming there is an existing cached profile on the system for a user).

New Contributor

On the cached credentials part, if a user updates his password while being offline/away from a DC (so different user password in AD & locally)

When he comes back, how does the password get "synced" again with AD?

Regular Contributor

You can't change your domain user password if a connection to a DC cannot be established.

Occasional Contributor

@Daniel Niccoli , you can't change your password *locally* whilst not connected to a DC, however you can change your password on the Domain whilst not connected to a DC by changing your password in OWA, Self Service Password Reset (with password writeback enabled), RDS sessions all while your local laptop is not connected to the office network.

This then ends up with a situation where your offline machine has the old password and is quite happy, but your domain has a new password.

With a ton of people working from home using Office365 as their main data source for everything, this is a very real possibility and can even end up in situations where the domain account is locked due to expiry BUT the local machine is still obliviously working away with the old password. As long as that local machine does not need to vpn, rdp or otherwise access local resources, "everything is fine"

Regular Contributor

@Andy Helsby  I think  @Jan Gezels was asking what happens if the user changed the password locally. He asked "how does the password get "synced" again with AD?" Since you can't change your user password form your local computer without a reachable DC, there requirement to sync it back to AD is a moot point.


Anyway, you are right, that changing the password via OWA, SSPR or ADFS is going to create some complexity if the computer is not connected through VPN when the user logs on to their computer the next time.

Version history
Last update:
‎Apr 24 2020 05:49 AM
Updated by: