SSPI handshake failed with error code 0x80090311

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.

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.

 

 

Ok, will do and thank you for all of your help

Ok, then as long as the ip address is not changing on those two it should be Ok, but the other issues need to be cleared up specifically the system and dfs replication event logs should be clear of errors on all four. If problems persist after cleaning up event logs put up a new set of files to look at.

 

 

The DHCP on DC7 is the way servers are configured on AWS, but it still uses the same static IP assigned to it, this is how all of our servers operate as EC2 instances on AWS which we have configured using a VPC back to our on-premise domain. DC4 is the same thing...both on AWS but this is the server I'm trying to get rid of once all is clear with errors, etc.

I'll look through the rest of them and see what I can do to clear those RPC and 5012 errors. I'll definitely mark this as helpful/best response but the main question I had hasn't been answered, but I guess it can't until all is cleared and then I guess I have no choice but to demote DC4 again and see what happens...I guess deal with the errors from there if any and resolve them rather than trying to add it back as a DC.

I just sent it to you via private message, thanks.