Parallels RAS uses the Windows Negotiate security package for authentication, which attempts Kerberos first and falls back to NTLM when Kerberos is not available or not completed. Some customers, particularly those responding to security audits or hardening policies that require disabling NTLM entirely, ask whether RAS can operate with NTLM fully disabled and Kerberos as the only authentication protocol. This article explains current support for that configuration and which RAS components still depend on NTLM.
Is NTLM-only-disabled (Kerberos-only) authentication supported?
No. At this time, Parallels RAS does not support fully disabling NTLM. Several underlying Windows APIs, identity-resolution calls, and RAS gateway/broker workflows still rely on NTLM, even in environments where Kerberos is used as the primary authentication method. We recognize the value this capability would provide, particularly for organizations enforcing NTLM-restriction policies via Group Policy, and it is being evaluated for a future release. We are not currently able to commit to a timeline or estimated delivery date.
Important: Disabling NTLM entirely via Group Policy (e.g. Network security: Restrict NTLM: NTLM authentication in this domain set to Deny All) in an environment running RAS will cause session launches to fail even though initial login and application listing may continue to work.
What works and what fails when NTLM is disabled
Testing against environments with NTLM denied via GPO showed a consistent pattern across clients: authentication and application listing generally continue to work because Kerberos alone is sufficient to log the user in, but launching a session frequently fails because the credentials handed to the session host at launch time are incomplete.
| Client / Access Method | Authentication / App Listing | Session Launch |
|---|---|---|
| Windows Client - Credentials | Works | Fails in Gateway Mode. Fails in Direct Mode when the direct address is set to the RDSH's IP address; works when the direct address uses the RDSH's FQDN/hostname instead. |
| Windows Client - Smart Card | Fails (see note below) | Not reached |
| Windows Client - Web Authentication | Expected not to work | Expected not to work |
| User Portal - Credentials | Works | Fails |
| Linux, macOS, Android, iOS Clients - Credentials | Works | Fails |
| RDP Tunneling (via Gateway FQDN, same target machine) | N/A | Works |
| RDP Tunneling (via Gateway FQDN, tunneling to a different machine) | N/A | Fails, unless the client resolves the target machine's own FQDN to the gateway address (see below) |
Note: The Smart Card authentication failure observed during testing traced to GetUserNameEx() failing to resolve the fully qualified DN after an otherwise successful LsaLogonUser() call, with the domain controller reporting it could not be contacted to service the request. This is consistent with a Kerberos-dependent identity-resolution step that has an NTLM fallback which is unavailable when NTLM is denied.
Why session launch fails
RAS authenticates users through the LogonUser Windows API, which negotiates between Kerberos and NTLM and generally succeeds with Kerberos alone for the initial logon. The failure occurs at a later step: when a session is launched, the credentials passed from the RAS Gateway/Connection Broker to the session host to establish the RDP session do not carry a valid Kerberos service ticket for that host. Where NTLM is available, this step falls back to passing an NTLM-compatible credential and the session starts; where NTLM is denied, that fallback is unavailable and the session host prompts for or rejects the credential, and the connection fails.
In short: identity resolution, gateway/broker brokering, and session creation in current RAS versions have a functional dependency on NTLM being available as a fallback, even in environments configured to prefer Kerberos.
Partial workarounds observed during testing
- For Direct Mode from the Windows Client, configuring the RDSH's direct address as its FQDN/hostname (instead of its IP address) allowed the session to launch successfully. Using the IP address reproduces the failure.
- For RDP Tunneling to a different target machine through the Gateway, the tunneled connection succeeds if the client resolves the target machine's own FQDN to the external gateway's address (e.g. via a hosts file entry), so that the client's Kerberos request is made against the target machine's name rather than the gateway's.
- These are environment-level workarounds observed in testing, not supported configurations, and do not extend to Web Authentication, the User Portal, or non-Windows clients, which failed to launch sessions in all tested NTLM-disabled scenarios.
Recommendation
Until RAS removes its remaining NTLM dependencies, do not configure Group Policy (or an equivalent domain-wide setting) to deny NTLM authentication in environments running RAS. Kerberos is used preferentially wherever RAS and the underlying Windows security stack support it, but NTLM must remain available as a fallback for session brokering and launch to function reliably across all supported clients and access methods.
If a customer's security policy mandates disabling NTLM domain-wide, they can raise it as a formal feature request with Parallels so that the demand is tracked against the roadmap; let them know it is already an item under evaluation as of this writing.
Was this article helpful?
Tell us how we can improve it.