I can't connect to RDP server ,using remote getaway, using dns name

Brass Contributor

I have an authentication problem using RDP service via remote gateway.
Randomly users fail to authenticate on terminal servers, using the dns name, passing the remote gateway.
Using the IP address instead the connection is successful.
There are two remote gateways one Windows 2012 r2 and one Windows 2019.
Remote Desktop Session Hosts are both Windows 2012 R2 and Windows 2019.
The problem seems to have arisen after having inserted 3 DC Windows 2019 in the domain.
There are currently 6 AD.
Two are windows 2012 r2,1 2016 and 3 2019.
Going to analyze the dc logs I found the following errors:

The Key Distribution Center (KDC) encountered a ticket that did not contain information about the account that requested the ticket while processing a request for another ticket. This prevented security checks from running and could open security vulnerabilities. See https://go.microsoft.com/fwlink/?linkid=2173051 to learn more.
Ticket PAC constructed by: %DC%
Client: %FQDN of Domain%\%Clientname$%
Ticket for: krbtgt


And searching the internet I found the following interesting articles:



On the DC 2019 I also found these Audit Failure events:

A Kerberos service ticket was requested.

Account Information:
Account Name:
Account Domain: domain.COM
Logon GUID: {00000000-0000-0000-0000-000000000000}

Service Information:
Service Name: TERMSRV/on-prem-pc-name
Service ID: NULL SID

Network Information:
Client Address: ::ffff:10.x.x.x
Client Port: 50281

Additional Information:
Ticket Options: 0x40810008
Ticket Encryption Type: 0xFFFFFFFF
Failure Code: 0x14
Transited Services:

And this interesting article:

The proposed solution is:
The root cause is this: KB5008380—Authentication updates (CVE-2021-42287)
So long story short:
- update all DCs in forest to 14 Nov 2021 Updates (KB5008602 for Server 2019)
- wait until all kerberos tickets have the PAC Attributes (System Event ID 35-38 should not appear on any DC anymore)
- Install October 2022 on the DCs (KB5018419 for Server 2019)
If you have October 22 Updates on any DC and an other DC does not have the November 21 Updates installed the only workaround is to remove the October 22 Update.

The patch level of the DCs is as follows:
dc01 windows 2012 patch r2 may 2022
dc02 windows 2012 r2 patch December 17, 2017
dc03 windows 2016 patch 2022 april 14
dc10 windows 2019 patch january 2023
dc11 windows 2019 patch january 2023
dc12 windows 2019 patch january 2023

So from what I have the problem is due to the auth updates and probably the old DC's failing to talk properly.
Is my analysis correct?
Are the solutions to install the patches on the old DCs or remove them from the domain leaving only the 2019?
In this infrastructure there are another 200 application servers (windows 2012,2016 and 2019) could these machines be impacted?
Would it be better to first install the patches on all the applicaton servers and then on the old DCs?


Thank you



5 Replies

@pazzoide76 Hi did you find a solution at your problem i Havre exactly same issue after first install of 2019DC on 2008R2 forest.

So i don't Know if i have to decommission all 2008R2 DC and it will be find or not.

Thanks in advanced 


I solved by patching all the dc.

@pazzoide76 So for my old 2008R2 domain controllers, i have to install all patches included in the article manually because i don't have extended support so no more updates.

I'm a little bit confused about which patch i have to install 

On 2019 they are already up to date do i need to do something ?

In my environment I simply did all the windows update on the dc but I didn't have windows 2008 r2.
I guess you will have to retire the dc 2008 r2 but I would say see if anyone else replies on the forum to confirm.
OK it was easier like that.
My idea was to decommission all 2008R2 so i think when i will have only 2019 DC up to date all will be OK.
Thank you for your answer