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)
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
Thanks for posting this detail.