On several installations of windows 8.1 enterprise, users cannot change passwords by using <ctrl> + <al> + <del> keys and choosing change password. 

The error is: "The security database on the server does not have a computer account for this workstation trust relationship"

Fresh Windows 8.1 enterprise installs with no patches to fully patched windows 8.1 enterprise workstations have the problem.  Backed out patches one by one and tested password change without success.  Tried various dell laptops, tablets, and workstations but same issue.  Tried VMware guest workstation with windows 8.1 enterprise.  The domain functional level is 2003 with a mixture of Windows 2008 R2 DC's and Windows 2003 DC's.

The add/remove from domain did not help.  What troubleshooting steps should I take from this point?  Is this related to secure channel failures?  Note: did not find event log entries for the failures in the DC's nor on the workstation.  Perhaps I did not search  for the proper entry on the DC's.

Are the windows 8.1 enterprise installations made manually from original media, or are they running a "corporate" image? If the later it sounds like sysprep has failed or that step has been missing.

They are made from original media.

Hi,

Thanks for your posting.

Did you check this article?

http://blog.blksthl.com/2013/03/18/fix-the-trust-relationship-between-this-workstation-and-the-primary-domain-failed/

Please have a try and let us know if it helps.

Regards.

I have tried this but still have the same change password issue.  Are you able to duplicate my issue?

I just added the computer to a windows 2003 test domain and tested the password change successfully.  Not sure what to check in the problem domain.  This only affects windows 8.1 workstations.  It works fine for windows 7.  Have not tested windows 8.

Hi,

Please find below several possible cause of error The security database on the server does not have a computer account for this workstation trust relationship

• Secure channel is broken (Can fix by rejoin problematic client to domain)
• AD replication issue. The computer account exists on one domain controller but not others.
• Duplicated SPN (seems not possible)

So, to narrow down the issue, you need to make sure the AD replication is working fine. Please run command repadmin /showrepl * on a DC, then post the result here.

After that, please run set l on a problematic client, then post the result here.

Moreover, please check on system event log and check if there have any related error of the issue.

Thanks.

Repadmin: running command /showrepl against full DC neplantdc.ohdc.com

        Last attempt @ 2013-11-27 10:48:18 was successful.

All the syncs were successful. I deleted the list as it was long.

• Edited by ReyesB Wednesday, December 04, 2013 2:00 PM

logonserver=\\dccorp01

Was a resolution ever found for this? We are running into it as well on Windows 8.1 Ent. in a Server 2008R2 level domain. I also tested removing/re-adding to the domain with Surface Pro running 8.1 Enterprise and a Dell Precision desktop also 8.1 Ent.

I know the trust relationship exists as we can login to the workstation with domain credentials, it's only when attempting to change the password the error is received. The only other time I've seen this error is when the computer account for the workstation in question has been disabled or removed.

Thanks!

I do not have a fix yet.  Exploring what is different about the test domain and the production domain.  <ctrl> + <alt> + <del> change password works in the test domain but not production.

Same issue here. It looks like it is caused by an update, therefore it occurs only on updated computers. On Win8 it is caused probably by KB2883201, but perhaps on Win8.1 is the KB different. Does anyone have a clue which KB it may be?

BTW it occurs also on higher domain level than 2003.

Hi,

Yes, Ptries42 is correct. The issue is realted a bug, for windows 7 and window 8, we can remove hotfix MSKB 2845626/2883201 to workaround the issue.

Based on my research, this update (MSKB 2845626/2883201) is included in 8.1 and cannot be removed. However you may try blocking the kpasswd port (TCP 464) on the client as workaround on all machines including Windows 8.1.  

You can use the UI or the netsh command to add an outbound rule for port 464: 
netsh advfirewall firewall add rule name="BlockTCP464" protocol=TCP dir=out remoteport=464 action=block

The new hotfix for the issue is not released yet. Please try my suggestion above to check if it works, if the issue still exist, please try upgrage the windows 2003 DCs to a later OS version or uncheck the "users must change password at next logon" on the account in question if we checked to verify if it works.

Thanks.

• Edited by Bryan Yu-MSFT Monday, January 06, 2014 8:44 AM error

Hey Guys,

anyone have any information on a timeframe on the Hotfix for This.

Hi,

Thanks for the reply.

Microsoft engineer team is working on this bug and the hotfix will release at 2014-03. I appreciate your patience. (Bug ID is 490875)

Thanks.

• Edited by Bryan Yu-MSFT Wednesday, February 05, 2014 2:49 AM add

Hi, 

are there any news about this? 

We are still waiting on the hotfix for a 2003 DC.

• Proposed as answer by Allan Skou Wednesday, March 05, 2014 3:52 PM
• Unproposed as answer by Allan Skou Wednesday, March 05, 2014 3:52 PM

Hotfix is out for this!

hxxp://support.microsoft.com/kb/2910686/en-us 

Fixed the problem for me after I installed this hotfix on my DC.

That's for 2008. Is the hotfix for 2003 coming?

kb2910686 is only for DC 2008 R2. 

There is still no hotfix for 2008 and 2003 DCs.

Please hurry up!

Hi I am experiencing a similar issue, I believe it is related to the same problem as windows 8 unpatched and 7 clients do not experience the issue and the issue is affecting new builds not installed from an image.

Domain users can update passwords when they expire however if they attempt to logon to another workstation than the one the password was changed on, the logon authenticates but does not move past the welcome message with the spinning circle. It will stay on this screen forever. I should say this only happens when a user profile is already present. If they logon to a workstation without a user profile setup proceeds as expected and everything is fine until the password is updated.

Running 2k8 R2 DC's in 2k8 ffl / dfl

http://support.microsoft.com/kb/2927811 for Win 2003 sp2

• Proposed as answer by Marcin Piwowar Monday, March 17, 2014 3:07 PM

It works! Thanks

http://support.microsoft.com/kb/2910686

• Edited by Bryan Yu-MSFT Wednesday, May 28, 2014 6:12 AM 1

Hi Bryan,

We're having the same problem with our new Windows 2012 R2 domain but from what I can tell, all of the hotfixes listed here only apply to earlier Windows versions.  Is there one for Windows 2012 R2 as well?  Thanks

• Edited by Brian.Lawton Sunday, July 20, 2014 9:41 PM clarification

Is there a patch available for 2008 non r2 servers, we have a domain with 2008, 2008 r2 and 2012 server and on the sites with 2008 servers the bug is still present

Is there any solution for Windows Server 2008 (non-R2) domain controllers?