Windows 8.1 cannot change password in Windows 2003 domain level domain RRS feed

  • Question

  • 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.

    Monday, November 25, 2013 8:50 PM

All replies

  • 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.

    Enfo Zipper
    Christoffer Andersson – Principal Advisor - Directory Services Blog

    Monday, November 25, 2013 9:02 PM
  • They are made from original media.
    Monday, November 25, 2013 9:07 PM
  • I have tried this but still have the same change password issue.  Are you able to duplicate my issue?
    Tuesday, November 26, 2013 2:04 PM
  • 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.
    Tuesday, November 26, 2013 2:39 PM
  • 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.


    Wednesday, November 27, 2013 2:21 PM
  • Repadmin: running command /showrepl against full DC

            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 4, 2013 2:00 PM
    Wednesday, November 27, 2013 4:49 PM
  • logonserver=\\dccorp01

    Wednesday, November 27, 2013 5:02 PM
  • 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.


    Wednesday, December 11, 2013 5:26 PM
  • 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.
    Wednesday, December 11, 2013 7:59 PM
  • 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.

    Thursday, January 2, 2014 8:29 AM
  • 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.


    Monday, January 6, 2014 8:42 AM
  • Hey Guys,

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

    Friday, January 31, 2014 5:13 AM
  • 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)


    • Edited by Bryan Yu-MSFT Wednesday, February 5, 2014 2:49 AM add
    Wednesday, February 5, 2014 2:46 AM
  • 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 5, 2014 3:52 PM
    • Unproposed as answer by Allan Skou Wednesday, March 5, 2014 3:52 PM
    Tuesday, March 4, 2014 12:06 PM
  • Hotfix is out for this!


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

    Wednesday, March 5, 2014 3:54 PM
  • That's for 2008. Is the hotfix for 2003 coming?
    Thursday, March 6, 2014 1:20 PM
  • kb2910686 is only for DC 2008 R2. 

    There is still no hotfix for 2008 and 2003 DCs.

    Please hurry up!

    Friday, March 7, 2014 8:27 AM
  • 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

    Monday, March 10, 2014 11:35 AM
  • for Win 2003 sp2
    Friday, March 14, 2014 7:16 AM
  • It works! Thanks
    Monday, March 17, 2014 3:07 PM
  • Wednesday, May 28, 2014 6:05 AM
  • 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
    Sunday, July 20, 2014 9:40 PM
  • 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
    Monday, September 29, 2014 6:55 AM
  • Is there any solution for Windows Server 2008 (non-R2) domain controllers?

    Wednesday, March 18, 2015 7:17 AM
  • Hi All,

    We are seeing this in our environment as well:

    PDC - Server 2012

    ADC -server 2008 x 86

    Domain Functional Level - 2008

    Clients - Windows 8.1 Pro

    Unable to change password the error is following

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

    Tuesday, September 22, 2015 9:51 AM