Update: This is now fixed in the following updates:
I have spent the last few weeks looking at an issue where after a user gets prompted to change their expired password at logon Windows just hangs at either Welcome or Changing your password.
I have googled every possible permutation of the search terms to no avail. Through a lot of testing I have found that disabling the group policy that sets the default associations configuration file seems to help but couldn’t for the life of me understand why. So decided to throw in the towel and log a case with Microsoft support and then as it often happens this blog post crops up: http://blogs.technet.com/b/askpfeplat/archive/2016/01/11/does-your-win-8-1-2012-r2-win10-logon-hang-after-a-password-change.aspx .
It really nicely explains what is going and how to get around it. It also turns out it’s not just limited to changing expired passwords either.
In my case I had the Set a default associations configuration file group policy applied (Computer configuration\administrative templates Windows Components\File Explorer\ “Set a default associations configuration file”) with the file sitting in the sysvol share so the best workaround was to move the file to a non DFS share on a different server and updating the group policy.
Another viable option could be disabling the credential manager and clearing cached credentials.
Definitely have a ready through the article as you might be experiencing the same problem if you map your drives to DFS shares.
Here is what happens during the logon process (taken from the above article):
1. When the user logs on, the profile service tries to map network home folder to \\contoso.com\…
2. To do this, we need to have a call created in RDR, and this requires a SMB session setup to dcname.contoso.com
3. The SMB session setup requires a security blob created to authenticate with the target server, which is the DC.
4. To create the security blob, Kerberos will check saved credentials by calling DPAPI.
5. DPAPI cannot decode the saved credential because the master key is not available because the user’s password is reset on DC, so it will need to query the DC for a master key. This requires a named pipe call to \\dcname.contoso.com\IPC$\protected_storage
6. To connect to this named pipe, RDR found it is the same as previous call in#2 (same fqdn DC name \\dcname.contoso.com) so now session setup is queued…
7. The Kerberos thread will hang forever, and the profile service will hang forever until a reboot.
8. After reboot, the user still cannot logon with the same symptom. (note: a different user CAN log on).
Really pleased I can finally tick this one off my list after scratching my head for such a long time. I will be looking out for updates and hopefully a full fix from Microsoft soon.