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]

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-SYS...

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
 

[#3]

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?

[#4]

If the prerequisites have not been met then there is no choice but to remove the 2019 domain controllers. Perform cleanup if needed.

https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/ad-ds-metadata-cleanup
https://techcommunity.microsoft.com/t5/itops-talk-blog/step-by-step-manually-removing-a-domain-contr...

Then check health is 100% and if so you can start again.

[#5]

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).

[#6]

2012 R2 DFL is fine and whether physical or virtual really doesn't matter.

[#7]

After looking at the links you provided, I remembered I did use this same site for my FRS to DFRS migration and it completed successfully. I had to do this prior to adding my first 2019 DC.

[#8]

Three right? Please run;

Dcdiag /v /c /d /e /s:%computername% >C:\dcdiag.log
repadmin /showrepl >C:\repl.txt
ipconfig /all > C:\dc1.txt
ipconfig /all > C:\dc2.txt
ipconfig /all > C:\dc3.txt

then put unzipped text files up on OneDrive and share a link.

[#9]

Run these commands on each DC?  Also, these results will show 4 DC's since the 2008 R2 DC is currently running but it's the one that I want to eventually remove which will leave me with the other 3...thanks.

[#10]

Run first two on any healthy DC, if there are four then include a file for the fourth as well.

[#11]

I got all the files ready to share via a copied link from OneDrive. What email address do I share it with?

[#12]

You can just post a link here, or send me a message

About Dave Patrick - Microsoft Tech Community

[#13]

Am I missing something here? wouldn't that make the link accessible to anyone? If I share it here and the link allows for edit permissions then anyone with this link can see and access the files.

[#14]

The files should be harmless but message me the link if you like.

[#15]

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

[#16 · Accepted solution]

- 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.asp...
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc...

- 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)

[#17]

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.

[#18]

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.

[#19]

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

[#20]

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.