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
- Network/Network Connections/Windows Defender Firewall/Domain Profile:
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
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.
Edit the Remote Desktop Connection file (.rdp on Windows) with a text editor and add this line:
enablecredsspsupport:i:0I 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.There are a couple things going on here:
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.