Nested AD Groups RDP permission not applying to new Windows Server 2019 VM

Question

Similar Issue with no responses: Nested AD groups working in local computer groups, but certain servers fail to allow RDP?

I am only new to this environment and the person I took this over from also experienced this issue but didn't get very far with it (considered low priority due to it correcting itself eventually).

After building a fresh VM (VMWare) and installing windows 2019 on it, using a task sequence. The task sequence creates local admin global groups for each new server and then adds these to the default local admin groups. The global groups then have our teams admin group added to it with a GPO configured to allow RDP. Some servers have issues with not allowing network admins to RDP to them but domain admin works. I can see no common denominator between them other than this issue has only happened to me on Fridays (which may hint to some process/task that I don't know about being run on Fridays which causes a delay with propagation).

Server 1: Fresh VM, Task sequence deployed OS, connects to the domain without a problem and I can RDP to it without issue.

Server 2: Fresh VM, same task sequence run minutes later/at the same time, connects to the domain, can log in via console but RDP gives "not authorised for rdp".

Every server thereafter has the same issue but the ones before it do not, despite all being created at roughly the same time. The previous day I was able to do the exact same thing (have multiple servers being deployed at the same time using the same task sequence) without any issues, then about half way through Friday they start having this RDP issue. I am able to download updates for them and do other things, so I know its not a network issue.

It's also odd that I am given other permissions that this group allows (ie; admin rights) but not RDP.

I notice that if I remove our teams admin group and add my account directly to the local admin global group, RDP works straight away but as soon as I remove it and add my teams group back, it doesn't work.

This only happens on some and not all servers and I cannot find any connection between them, they all look exactly the same in regards to groups, permissions and GPOs but some will allow RDP and some won't. It's also worth noting that when this happens on Friday, if I wait until the following Monday/Tuesday it's all come good and you wouldn't even know there was an issue in the first place.

I suspect that there is some kind of bug at play, mixed with some process I'm not aware of which results in this issue. However, trying to pin-point it for remediation has proven quite difficult. Any ideas/suggestions?

Answer 1

After a quick read of your issue I suspect that it is group policy related. If you configure Group Policies correctly, they provide a stable secure reliable environment There are a number of areas that need be taken into account • Enabling Remote Desktop on the Computer • Who is allowed to do this? • Are you using firewalls I have a single GPO which applies to all computers and users which works reliably. The Domain structure is as follows: Group Policy Management Forest: Your-Domain-Name,local Domains v Your-Domain-Name.local  Company Name OU - I created my GPO here o _Users o Computers  Desktops  Laptops  Servers

1. Create a new GPO named CN_GPO-001 Add IT Support to Local Admin & RDP
2. On the Scope Tab, check Security Filtering it should contain:  Authenticated Users  Domain Computers
3. Edit the GPO Goto:

Computer Configuration  Policies  Windows Settings  Security Settings  Restricted Groups • Group = BUILTIN\Administrators • Members = YOUR-DOMAIN-NAME\ItsupportUser, YOUR-DOMAIN-NAME\G-IT Support group, YOUR-DOMAIN-NAME\Domain Admins, YOUR-DOMAIN-NAME\adobeupdate, YOUR-DOMAIN-NAME\AdministratorUser

• Group = BUILTIN\Remote Desktop Users • Members = YOUR-DOMAIN-NAME\G-IT Support group YOUR-DOMAIN-NAME\Itsupport User

 Windows Firewall with Advanced Security Windows Firewall with Advanced Security Global Settings Policy Setting Policy version 2.26 Disable stateful FTP Not Configured Disable stateful PPTP Not Configured IPsec exempt Not Configured IPsec through NAT Not Configured Preshared key encoding Not Configured SA idle time Not Configured Strong CRL check Not Configured

Inbound Rules Name Description Remote Desktop - Shadow (TCP-In) Inbound rule for the Remote Desktop service to allow shadowing of an existing Remote Desktop session. (TCP-In) This rule might contain some elements that cannot be interpreted by the current version of GPMC reporting module
Enabled True Program %SystemRoot%\system32\RdpSa.exe Action Allow Security Require authentication Authorized computers
Authorized users
Protocol 6 Local port Any Remote port Any ICMP settings Any Local scope Any Remote scope Any Profile All Network interface type All Service All programs and services Allow edge traversal True Group Remote Desktop

Remote Desktop - User Mode (UDP-In) Inbound rule for the Remote Desktop service to allow RDP traffic. [UDP 3389] This rule might contain some elements that cannot be interpreted by the current version of GPMC reporting module
Enabled True Program %SystemRoot%\system32\svchost.exe Action Allow Security Require authentication Authorized computers
Authorized users
Protocol 17 Local port 3389 Remote port Any ICMP settings Any Local scope Any Remote scope Any Profile All Network interface type All Service termservice Allow edge traversal False Group Remote Desktop

Remote Desktop - User Mode (TCP-In) Inbound rule for the Remote Desktop service to allow RDP traffic. [TCP 3389] This rule might contain some elements that cannot be interpreted by the current version of GPMC reporting module
Enabled True Program %SystemRoot%\system32\svchost.exe Action Allow Security Require authentication Authorized computers
Authorized users
Protocol 6 Local port 3389 Remote port Any ICMP settings Any Local scope Any Remote scope Any Profile All Network interface type All Service termservice Allow edge traversal False Group Remote Desktop

  Inbound Rule for RDP Port 3389 Inbound Rule for RDP Port 3389 This rule might contain some elements that cannot be interpreted by the current version of GPMC reporting module
Enabled True Program Any Action Allow Security Require authentication Authorized computers
Authorized users
Protocol 6 Local port 3389 Remote port Any ICMP settings Any Local scope Any Remote scope Any Profile Domain Network interface type All Service All programs and services Allow edge traversal False Group

Connection Security Settings None

 Administrative Templates I have added the ADMX files for the 2 versions of Windows Builds, IE 20H2 and 21H1 Administrative Templates Policy definitions (ADMX files) retrieved from the local computer.

Windows Components/Remote Desktop Services/Remote Desktop Session Host/Connections Policy Setting Comment Allow users to connect remotely by using Remote Desktop Services Enabled

User Configuration (Enabled) Policies Administrative Templates Policy definitions (ADMX files) retrieved from the local computer. Windows Components/Remote Desktop Services/Remote Desktop Session Host/Connections Policy Setting Comment Set rules for remote control of Remote Desktop Services user sessions Enabled

Hope this helps

Answer 2

Firstly, are the custom AD groups landing in the correct local group on the affected servers? If they've been added, you should see them in Computer Management on each box. You may be running into delays with replicating the new groups before your task sequence adds them.

If you can, I suggest that creating the groups be the first task in your sequence. Hopefully the rest of the build takes longer than the interval for AD changes to propagate to each DC - obviously, if replication takes an hour, that could be an issue. One workaround is to capture the group SID when you create it and use that to add to your localgroup. When AD catches up, you should see the group name update on the box.

If the groups are present on the problem servers, I'd suggest running a GPResult /H to see if it's getting all the policies it should. By the way, if your task sequence isn't doing two reboots after installing the OS, I highly recommend that it does. For example, do OS baseline install, join to domain, reboot, configure local groups, other post-build activities, reboot.

By default, local Administrators have RDP access so I don't see why there's an additional allow-RDP policy on top of it (unless it's been disabled for Administrators some other way). If Administrators has been constrained from RDP access or your group is not supposed to be in Administrators, I'd suggest nesting the AD group into the Remote Desktop Users localgroup in your task sequence as well, rather than via the GPO (although naturally that should work anyway).