Forum Discussion
SSPI handshake failed with error code 0x80090311
- ACEPDC7 is DHCP assigned which is a no-no for a domain controller. After assigning a static address I'd do ipconfig /flushdns, ipconfig /registerdns, restart the netlogon service.
- ACEPDC4 is DHCP assigned which is a no-no for a domain controller. After assigning a static address I'd do ipconfig /flushdns, ipconfig /registerdns, restart the netlogon service.
- ACEPDC5 -> ACEPDC4 5012 errors
https://social.technet.microsoft.com/wiki/contents/articles/1205.dfsr-event-5012-dfs-replication.aspx
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc770728(v=ws.11)
- ACEPDC6 event logs cannot be queried because of RPC, so I'd check the logs for possible errors- ACEPDC7 event logs cannot be queried because of RPC, so I'd check the logs for possible errors
- ACEPDC4 has replication problems. I'd check the event logs for error details (may be related to DHCP assignment)(please don't forget to mark helpful replies)
You're welcome. Another tip: the system and dfs event logs prior to last boot are of no use to me so when I'm building a new one I like to clear out the logs just prior to reboot so a quick look I don't need to decide if an error was before or after last boot. Another reason to clear is dcdiag will query the last 24 hours so something that shows there may have been before last boot and no longer a problem.
Thanks for posting this detail.
- Dave, just wanted to follow-up and let you know that I was able to resolve the SSPI handshake error along with the RPC errors from two of my domain controllers.
First, did some more digging and found that these RPC errors are common when trying to query a server remotely while running the dcdiag command, so the quick fix was to temporarily disable the firewall and dcdiag ran fine with all tests passing. The articles I found said to add inbound rules for RPC, there is like 3 of them if I really wanted to but that they were harmless, just makes the dcdiag not report the errors, so being that I don't use this much and only to troubleshoot specific errors like this, I decided to just re-enable the firewall and only disable it if I need to run the tests or simply ignore them.
For the domain controller issue that caused this error to begin with...I shutdown the domain controller to see if this would happen and it did, so it was very repeatable. I then started to investigate on the application and noticed that I was getting LDAP authentication errors. This lead me to find that the entry for this in DNS was an alias CNAME record that was pointing to that same domain controller.
I then changed the entry to point to the new domain controller and forced replication, etc. waiting for DNS to update and show things correctly on all domain controllers and was then able to sign into the application even after shutting down the old domain controller that I'll be removing.
Other applications from different servers that were generating the same error also continued to work, so no SSPI handshake failed errors happened after this fix.
Now, I can demote this 2008 R2 domain controller once and for all and thanks again for all your help with this No worries, you're welcome.
- Ok, makes sense I'll do that as I work through errors today. That reminds me that I'm not sure why there were RPC related errors when RPC is available on the DC's in question. I'm going to clear out the event logs prior to rebooting them but also prior to me making corrections to make sure it truly is a problem.
Once I'm done I'll let you know how it goes even if it all works out, but if not glad to have you helping me where you can.
