Users from a trusted domain cannot connect to remote desktop gateway

[VincentG1816]

Hey,

Trying since few days to have an RDP gateway allowing users from a tusted domain to connect to.

The only error I can find in the error log is : 

<The user "DOMAIN\login", on client computer "172.22.2.125", did not meet connection authorization policy requirements and was therefore not authorized to access the RD Gateway server. The authentication method used was: "NTLM" and connection protocol used: "HTTP". The following error occurred: "23003".>

Another error from the NPS is : 

<"ServerName","RAS",04/07/2023,11:31:59,1,"DOMAIN\login","DOMAIN\login","UserAuthType:PW",,,,,,,,,,,,5,,,12,7,"-- RDG Marker Policy {985F7B54-FCE8-4f55-AEBF-DF8827A44068} --",0,"311 1 10.239.16.9 04/06/2023 10:04:45 50",,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,"TS GATEWAY AUTHORIZATION POLICY",1,,,,
"ServerName","RAS",04/07/2023,11:31:59,3,,"DOMAIN\login",,,,,,,,,,,,,,,,,7,"-- RDG Marker Policy {985F7B54-FCE8-4f55-AEBF-DF8827A44068} --",65,"311 1 10.239.16.9 04/06/2023 10:04:45 50",,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,"TS GATEWAY AUTHORIZATION POLICY",1,,,,>

More info about the setup:

Domain A and domain B are linked by a 2 way trust (required for RDG to work)

I have been checking really a lot of stuff but can't fix that setup.

- Users with duplicate accounts (same SAM)

- Networking

- Creating a different CAP with separated groups (to avoid mixing local domain users and remote domain users

- RDG server well in AD group "RAS and IAS Servers"

- CAP well contains groups were my user is

- ...

Anyone has an idea ? 

Regards,

Vincent

[#2]

Hey Vincent, did you manage to resolve this? We are experiencing similair problems when our users do a fresh enrollment for MFA. The users that have an old enrollment can still log in, only newly enrolled users cant.

Im guessing this is the reason:
After May 8, 2023, when number matching is enabled for all users, anyone who performs a RADIUS connection with NPS extension version 1.2.2216.1 or later will be prompted to sign in with a TOTP method instead.

Users must have a TOTP authentication method registered to see this behavior. Without a TOTP method registered, users continue to see Approve/Deny.

Prior to the release of NPS extension version 1.2.2216.1 after May 8, 2023, organizations that run earlier versions of NPS extension can modify the registry to require users to enter a TOTP. For more information, see NPS extension.

[#3]

Hey @Mattias1305,

Yes and no 🙂

The issue described above has been "fixed" by using local group on the server instead of AD groups (for gateway rules). Of course in local groups I set domain groups of the trusted domain.

In the meantime we moved to Win 2022 and I didn't had to do that, it worked like a charm directly even with trusted groups.

Good luck !

Vincent

[#4]

Im glad you fixed it. We worked it out also, it was the "StrongAuthMethods" in Entra AD that had defaulted to "PhoneAppOTP" instead of the previous "PhoneAppNotification". Obviously the OTP will never work with standard rdp-file connection since you cant input the OTP anywhere.

We found a way to change the default values in Entra through powershell. Since May 8th 2023 the PhoneAppOTP seems to be the standard when users enroll MFA.

Now we have another known problem and it is the NPS maxing out the CPU and memory due to some kind of loop when the secondary auth gets sent to Entra. I guess you didn't encounter this?