Forum Discussion

A-CAST's avatar
A-CAST
Brass Contributor
Sep 14, 2021

SSPI handshake failed with error code 0x80090311

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!

  • The two prerequisites to introducing the first 2019 domain controller are that domain functional level needs to be 2008 or higher and older sysvol FRS replication needs to have been migrated to DFSR
    https://techcommunity.microsoft.com/t5/Storage-at-Microsoft/Streamlined-Migration-of-FRS-to-DFSR-SYSVOL/ba-p/425405

     

    I'd suggest removing the new 2019, make sure prerequisites have been met, then use dcdiag / repadmin tools to verify health correcting all errors found before starting any operations. Then stand up the new 2019, patch it fully, license it, join existing domain, add active directory domain services, promote it also making it a GC (recommended), transfer FSMO roles over (optional), transfer pdc emulator role (optional), use dcdiag / repadmin tools to again verify health, when all is good you can move on to next one
     

     

    • A-CAST's avatar
      A-CAST
      Brass Contributor
      Dave, thanks for the reply.

      I'm going to look into the FRS replication migration to DFSR to see if that's been done or not, but in regards to removing our 2019 DC. The issue with that is we already have a new 2019 DC in a remote office...that's a physical server in a different state and I don't have the option to demote it, downgrade OS license (rebuild server), then promote it to a lesser OS version.

      The new 2019 DC that I just put into another site, the one that's to replace the 2008 R2 that's part of the same site...that one I can remove as you described and redo but based on the reasoning behind your initial response I don't think it's going to matter based on what I said regarding the other 2019 DC that's been running for a while now at another site.

      I've used dcdiag /repadmin tools before but lately I've been using the AD Replication Tool from Microsoft which did not show any errors prior to me starting this project. If dcdiag gives me different info then sure I'll do both not a problem but my main focus is knowing how to test that the replacement 2019 DC is working for this site in regards to this error before I demote the 2008 R2 DC?
      • A-CAST's avatar
        A-CAST
        Brass Contributor
        One more thing...all DC's are GC enabled, but only one DC has all the FSMO roles. So, we have our HQ site, Remote Office site, and AWS site. Only physical DC is located in Remote Office, the other two are virtual DC's. The one located at our office is the 2012 R2 DC with all the FSMO roles, so my plan was to keep domain functional level at 2012 R2 until I'm ready to replace this one in the future. For now, I just needed to replace the DC on AWS due to it being EOL (2008 R2).

Resources