Remote Desktop Authentication without NTLM - How to Configure from non-Windows clients?

Question

Background

This has been bugging me for quite a while (and no amount of internet searching has amounted to a decent solution), so I'm hoping someone can offer some sage advice. When I try and start a Remote Desktop session from a Mac to a Windows domain-joined PC, using Microsoft's latest Remote Desktop Client (v10.3.9 currently), I'll often receive the error in the following screenshot.

We couldn't connect to the remote PC. This might be due to an expired password. If this keeps happening, contact your network administrator for assistance.

Error code: 0x207

If I try and remote into the same PC from a Windows PC, using the native Windows Remote Desktop client, I don't get this error, and can connect fine. This is specific to non-Windows clients.

TL;DR

Is there a way I can enable non-Windows clients to connect to domain-joined Windows PCs by remote desktop, without making NTLM authentication exceptions for each target PC? Kerberos doesn't seem available for the Mac RDP Client, is there another authentication mechanism that is supported?

GPO Settings and Event Logs, on the RDP Server

The domain-joined target PC (RDP server) has many GPO's applied. What I think are all the relevant settings from gpresult follow:

Computer Settings > Policies > Administrative Templates
- Network/Network Connections/Windows Defender Firewall/Domain Profile:
  - Windows Defender Firewall: Allow Local Port Exceptions: Enabled
  - Windows Defender Firewall: Defined Inbound Port Exceptions: 3389:TCP:[IP Addresses]:enabled:Remote Desktop Connections
- System/Credentials Delegation
  - Remote Host Allows delegation of non-exportable credentials: Enabled
- Windows Components/Remote Desktop Services/Remote Desktop Session Host/Connections
  - Allow users to connect remotely by using Remote Desktop Services: Enabled
- Windows Components/Remote Desktop Services/Remote Desktop Session Host/Security
  - Always prompt for password upon connection: Enabled
  - Require secure RPC communication: Enabled
  - Require user authentication for remote connections by using Network Level Authentication: Enabled
  - Set client connection encryption level: Enabled. Encryption Level: High Level

Users intended for remote access are added to the respective remote desktop PC's user group "Remote Desktop Users", using the lusrmgr.msc MMC snap-in.

If I try and login from a non-Windows client, thereby receiving the above error, the Security Log on the RDP Server shows a failed Logon Event, ID 4625:-

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          <Date> <Time>
Event ID:      4625
Task Category: Logon
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      <RDP Host>
Description:
An account failed to log on.

Subject:
    Security ID:        NULL SID
    Account Name:       -
    Account Domain:     -
    Logon ID:       0x0

Logon Type:         3

Account For Which Logon Failed:
    Security ID:        NULL SID
    Account Name:       <User Name>
    Account Domain:     <Domain Name>

Failure Information:
    Failure Reason:     An Error occured during Logon.
    Status:         0x80090302
    Sub Status:     0xC0000418

Process Information:
    Caller Process ID:  0x0
    Caller Process Name:    -

Network Information:
    Workstation Name:   <RDP PC FQDN>
    Source Network Address: <RDP PC IP Address>
    Source Port:        0

Detailed Authentication Information:
    Logon Process:      NtLmSsp 
    Authentication Package: NTLM
    Transited Services: -
    Package Name (NTLM only):   -
    Key Length:     0

GPO Settings and Event Logs, on the Domain Controller

So, looks like a failed Network login using NTLM authentication. As per various security best-practices and recommendations, I have tried to disable NTLM authentication in the domain, by applying the following group policies to Domain Controllers, using the Default Domain Controllers Policy:-

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
- Network Security: LAN Manager authentication level: Send NTLMv2 response only. Refuse LM & NTLM
- Network Security: Restrict NTLM: NTLM authentication in this domain: Deny for Domain Accounts to Domain Servers.
- Network security: Restrict NTLM: Audit Incoming NTLM Traffic: Enable auditing for all accounts

On the domain controller, I have a corresponding log event to the failed NTLM authentication request, under Applications and Services logs > Microsoft > Windows > NTLM > Operational:-

Log Name:      Microsoft-Windows-NTLM/Operational
Source:        Microsoft-Windows-Security-Netlogon
Date:          <Date> <Time>
Event ID:      4004
Task Category: Blocking NTLM
Level:         Warning
Keywords:      
User:          SYSTEM
Computer:      <DC FQDN>
Description:
Domain Controller Blocked: NTLM authentication to this domain controller is blocked.
Secure Channel name: <RDP PC FQDN>
User name: <User Name>
Domain name: <Domain>
Workstation name: <RDP PC FQDN>
Secure Channel type: 2

NTLM authentication within the domain <Domain> is blocked.

If you want to allow NTLM authentication requests in the domain <Domain>, set the security policy Network Security: Restrict NTLM: NTLM authentication in this domain to Disabled.

If you want to allow NTLM authentication requests only to specific servers in the domain ms-rtc, set the security policy Network Security: Restrict NTLM: NTLM authentication in this domain to Deny for domain servers or Deny domain accounts to domain servers, and then set the security policy Network Security: Restrict NTLM: Add server exceptions in this domain to define a list of servers in this domain as an exception to use NTLM authentication.

The Workaround

So, the only way I know of to allow Remote Desktop access to PCs from a non-Windows client, is to add that PCs FQDN to the Default Domain Controllers Policy, under:-

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
- Network security: Restrict NTLM: Add server exceptions in this domain:

P.S. Just thought, haven't mentioned certificates. I have deployed an internal PKI and have RDP Certificates automatically deployed by GPO also. From the client, I am prompted whether or not to trust the certificate, the 0x207 occurs after I choose Accept to Trust the certificate, and then enter my domain\user name and password. As above, I can connect if an NTLM exception is listed, or login will fail if the server is not listed as an exception.

EDIT 1

As an alternative to the Microsoft RDP client on Mac, I have tried another app called freerdp, installed with brew install freerdp. This also fails to login to any PC where NTLM has not been explicitly enabled, but gives a far more informative error message than the Microsoft client, especially with the log-level set to TRACE. I'm not certain if it support Kerberos, CredSSP, or similar, but maybe this additional information may prove useful:-

$ xfreerdp /log-level:TRACE /d:<DOMAIN> /u:<User Name> /v:<RDP Host FQDN> 
[17:24:38:242] [4547:0ff48000] [DEBUG][com.freerdp.channels.cliprdr.client] - VirtualChannelEntryEx
[17:24:38:243] [4547:0ff48000] [INFO][com.freerdp.client.common.cmdline] - loading channelEx cliprdr
[17:24:38:261] [4547:0ff48000] [INFO][com.freerdp.client.x11] - Property 296 does not exist
[17:24:38:262] [4547:0ff48000] [DEBUG][com.freerdp.client.x11] - Searching for XInput pointer device
[17:24:38:263] [4547:0ff48000] [DEBUG][com.freerdp.client.x11] - Pointer device: 6
[17:24:38:270] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - Enabling security layer negotiation: TRUE
[17:24:38:270] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - Enabling restricted admin mode: FALSE
[17:24:38:270] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - Enabling RDP security: TRUE
[17:24:38:270] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - Enabling TLS security: TRUE
[17:24:38:270] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - Enabling NLA security: TRUE
[17:24:38:270] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - Enabling NLA extended security: FALSE
[17:24:38:270] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_NLA
[17:24:38:270] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - Attempting NLA security
[17:24:38:272] [4547:0ff48000] [DEBUG][com.freerdp.core] - connecting to peer <RDP Host IP>
[17:24:38:277] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - RequestedProtocols: 3
[17:24:38:394] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - RDP_NEG_RSP
[17:24:38:394] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - selected_protocol: 2
[17:24:38:394] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - state: NEGO_STATE_FINAL
[17:24:38:394] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - Negotiated NLA security
[17:24:38:394] [4547:0ff48000] [DEBUG][com.freerdp.core.nego] - nego_security_connect with PROTOCOL_NLA
[17:24:38:622] [4547:0ff48000] [DEBUG][com.winpr.utils] - Could not open SAM file!
Password: ***
[17:24:42:365] [4547:0ff48000] [DEBUG][com.winpr.sspi] - InitSecurityInterfaceExA
[17:24:42:365] [4547:0ff48000] [DEBUG][com.freerdp.core.nla] - nla_client_init 348 : packageName=Negotiate ; cbMaxToken=12256
[17:24:42:366] [4547:0ff48000] [TRACE][com.freerdp.core.nla] -  InitializeSecurityContext status SEC_I_CONTINUE_NEEDED [0x00090312]
[17:24:42:366] [4547:0ff48000] [DEBUG][com.freerdp.core.nla] - Sending Authentication Token
[17:24:42:366] [4547:0ff48000] [DEBUG][com.freerdp.core.nla] - 0000 <some hex numbers> NTLMSSP.........
[17:24:42:366] [4547:0ff48000] [DEBUG][com.freerdp.core.nla] - 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[17:24:42:366] [4547:0ff48000] [DEBUG][com.freerdp.core.nla] - 0020 06 01 b1 1d 00 00 00 0f                         ........
[17:24:42:371] [4547:0ff48000] [DEBUG][com.freerdp.core.nla] - CredSSP protocol support 6, peer supports 6
[17:24:42:371] [4547:0ff48000] [ERROR][com.freerdp.core.nla] - SPNEGO failed with NTSTATUS: 0x80090302
[17:24:42:371] [4547:0ff48000] [ERROR][com.freerdp.core] - freerdp_set_last_error ERRCONNECT_AUTHENTICATION_FAILED [0x00020009]
[17:24:42:371] [4547:0ff48000] [ERROR][com.freerdp.core.rdp] - rdp_recv_callback: CONNECTION_STATE_NLA - nla_recv_pdu() fail
[17:24:42:371] [4547:0ff48000] [ERROR][com.freerdp.core.transport] - transport_check_fds: transport->ReceiveCallback() - -1
[17:24:42:371] [4547:0ff48000] [DEBUG][com.freerdp.core.rdp] - transport_check_fds() - -1

Without NTLM you will have to use a Key Distribution Center, or KDC. — Overmind, Apr 22 '20 at 12:28
Thanks, are ADDS servers not KDCs? One thing I have tried (on a Mac) is running `kinit @`, to obtain a valid Kerberos ticket prior to logging in. I get the ticket okay, but the Microsoft RDP client still tries authenticating over NTLM. Is that the sort of process you would have had in mind? — Alex Leach, Apr 22 '20 at 13:27
Yes, but note that NTLM is used by default. You need to change that for it to allow/try ticketing. — Overmind, Apr 23 '20 at 07:54
Ok, thanks. Do you have any tips to enforce Kerberos authentication? One thing I haven't set up is an RD Gateway server, do you know if one is required for kerberos? Thanks — Alex Leach, Apr 23 '20 at 09:05
This guide should help: https://docs.actian.com/vector/5.0/index.html#page/Security/How_to_Configure_Kerberos_to_Authenticate_agains.htm — Overmind, Apr 23 '20 at 09:36

score 1 · Answer 1 · answered Mar 07 '21 at 21:46

Policy "Network Security: Restrict NTLM: NTLM authentication in this domain: Deny for Domain Accounts to Domain Servers" is restricting NTLM connections to domain servers. If you want to connect to domain via client which does not support Kerberos you have to disable this policy or maybe try option "deny for domain accounts". Other potential problem is that you have turned on NLA (Network level authentication). Try to turn it off and try again.

score 0 · Answer 2 · answered Apr 20 '20 at 02:36

0

Edit the Remote Desktop Connection file (.rdp on Windows) with a text editor and add this line: enablecredsspsupport:i:0 I had to do this in order to login to a Windows 10 PC from Linux Mint 17. In fact I've also had to do this to login from Windows 10 that was attached to a different AD domain.

answered Apr 20 '20 at 02:36

CB_Ron

313
2
10

Thanks for the suggestion. I create my RDP connections in the GUI, just entering a hostname, so I exported a .rdp file from a pre-configured connection. There was already the line `enablecredsspsupport:i:1`, so I changed the `1` for a `0`, deleted the PC, re-imported the config and retried the connection. Unfortunately, no change in behaviour. Was really hopeful that this would be a good starting point. Ideally, I'll be able to change a setting on the target machine however, so that I can effect the change across RDP hosts in the domain, and not need to worry about client configurations. – Alex Leach Apr 20 '20 at 14:41

score 0 · Answer 3 · answered Apr 24 '20 at 08:20

0

There are a couple things going on here:

In order to use Kerberos authentication on a non-windows machine you will need to set this up specifically. There is a nice guide here ( different goal - vscode auth - but same solution): https://github.com/microsoft/vscode-mssql/wiki/How-to-enable-Integrated-Authentication-on-macOS-and-Linux-using-Kerberos
Using CredSSP this should actually allow you to use Kerberos ( or better put delegate the kerb ticket from the client to the target)
I don't have a Mac to test this on - but this method does work with Linux

But even if this does work it will shift the burden from adjusting a GPO to contain all the names of clients that are exempt from Kerberos auth to adjusting all the clients.

It does make it safer however because you are now allowing NTML auth for anything coming from these specific clients.

answered Apr 24 '20 at 08:20

discondor

139
3

Thanks for the response and apologies for the delay getting back to you. I've set up the `krb5.conf` now (although I could get a ticket prior to even having one, as I guess DNS SRV records are used to resolve the KDC), and obtained a fresh tgt. Still, no change in behaviour however :( I am left considering the impact of Credential Delegation GPOs in the domain, and whether the Mac RDP client even supports CredSSP (which it should, given `enablecredsspsupport` is present in the .rdp files). – Alex Leach May 01 '20 at 10:35
No problem and to bad that it didn't work out. Unfortunately I don't have any macs to further troubleshoot this either. – discondor May 04 '20 at 14:40
Thanks. I did try out an alternative app to the Microsoft one on Mac: `freerdp`, which being open source should be available to try on Linux as well. With this, I get a slightly more informative error. I will update my original question with the error messages. – Alex Leach May 05 '20 at 16:17

Remote Desktop Authentication without NTLM - How to Configure from non-Windows clients?

3 Answers3