Protected Users AD security group issue with remote server access using the IP address or alias name?

Question

After adding to the Protected Users AD group, I am unable to access the remote server using the IP address or alias name.

• Protected Users Security Group | Microsoft Learn

Guidance about how to configure protected accounts | Microsoft Learn

Now people are encountering an RDP error when they try to access the legitimate server using either the IP address or the Alias/CNAME of the remote server.

 

[Window Title] Remote Desktop Connection [Content] A user account restriction (for example, a time-of-day restriction) is preventing you from logging on. For assistance, contact your system administrator or technical support. [Expanded Information] Error code: 0xc07 Extended error code: 0x0

 

Is there a way to resolve this problem without removing the user from the Protected Users AD group?

Answer 1

The error you're encountering when trying to access the server with users in the Protected Users Active Directory group is likely related to the enhanced security restrictions placed on such accounts, particularly around NTLM authentication, Kerberos, and RDP.

Protected Users in AD have a number of restrictions, including:

• NTLM is blocked entirely.
• Kerberos ticket lifetimes are reduced.
• Older encryption types like DES and RC4 are disabled.
• Cached credentials cannot be used.

This makes RDP connections using IP addresses or alias names (CNAMEs) problematic because:

• Kerberos cannot be used when connecting via an IP address or alias/CNAME since Kerberos requires the Service Principal Name (SPN), which is typically linked to the actual server hostname. If Kerberos is not used, RDP may try to fall back on NTLM, which is blocked for Protected Users.

Possible Solutions Without Removing Users from the Group:

1. Use the FQDN of the server: Ensure that users connect using the fully qualified domain name (FQDN) of the server rather than the IP address or alias. This allows Kerberos to be used instead of falling back to NTLM.
   • Example: Instead of using 192.168.x.x or alias_name, use servername.domain.com.
2. Configure SPN for the alias (CNAME): If you need to continue using the alias, you can configure a Service Principal Name (SPN) for the alias. This allows Kerberos to authenticate using the alias or CNAME. Here’s how you can do it:
   • Run the following command from an elevated command prompt to add the SPN:

      setspn -a TERMSRV/alias_name server_name
      setspn -a TERMSRV/alias_name.domain.com server_name
   

   • Replace alias_name and server_name accordingly.
3. Ensure Kerberos Constrained Delegation (KCD) is configured correctly: If delegation is involved in the process, ensure that KCD is configured correctly between the servers involved, as Protected Users cannot use unconstrained delegation.
4. Disable Network Level Authentication (NLA): For testing purposes, you could temporarily disable NLA on the RDP server to see if it resolves the issue, though this might reduce security. This would allow the use of a password prompt in RDP without needing Kerberos or NTLM. If NLA is disabled, make sure only secure, trusted connections are allowed.

---

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin