SSPI handshake failed with error code 0x80090311

[A-CAST]

The full error I'm getting:

SSPI handshake failed with error code 0x80090311, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. No authority could be contacted for authentication.

I was configuring a new server as a 2019 Domain Controller to replace a 2008 R2 one. In addition I have two other DC's for a total of 3. All in different sites.

One with all FSMO roles which is what is referred to as PDC back in the day running 2012 R2. The other running Windows Server 2019 and now the new one that I mentioned above that replaced the 2008 R2 also running 2019.

The problem I ran into is that I forgot to raise the domain functional level from 2008 R2 to 2012 R2 before I demoted it. Once that happened I started to receive errors from a couple of servers regarding the SSPI handshake and after researching this, I found that it's most likely or I can honestly say it's probably close to 100% that what I did caused this error.

So, I took the same server and brought it back to 2008 R2 Domain Controller status but what's weird is that even prior to completing this task, the errors seemed to stop...but accessing some of our applications didn't work until I fully brought it back.

My goal is to raise the domain functional level to 2012 R2 then test to make sure that the new DC in that site works for authentication of the SQL and application servers running there. I was wondering if shutting down the 2008 R2 DC temporarily and monitoring to make sure no errors are thrown is a good way to make sure my environment is ready to demote the 2008 R2 DC once and for all?

I appreciate any help I can get and thanks in advance!

[#2]

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.

[#3]

No worries, you're welcome.

[#4]

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

[#5]

Thanks for posting this detail.