Troubleshooting Desktop Access

Common issues and resolution steps.

Auto-login does not work

Smart card service not running

You connect to a Windows host from the Teleport UI, land on the Windows login screen and nothing happens.

You can click on the username, click Sign-in options and click on the smart card icon. The error message is: "No Valid Certificates Were Found on This Smart Card".

Solution: Enable the Smart Card Service

Usually, this means that the Smart Card service is not running on the target host.

First, make sure that you enable the Smart Card service in Group Policy.

If that doesn't help, log into the target host directly, open the "Services" program from the "Start" menu and check that the "Smart Card" service is in the "Running" state.

If the "Smart Card" service is not running, open PowerShell and run gpupdate.exe /force. This forces a Group Policy sync and should pick up the service changes.

Smart card not supported for Account

You connect to a Windows host and get the error message: "Signing in with a smart card isn't supported for your account." or similar.

Solution: Review the Security-Kerberos Log on the Windows host for causes.

The Security-Kerberos Windows Event Log provides information on smart card-based authentication attempts. This Event Log is not enabled by default. Open the Windows Event Log and navigate to Event Viewer, Application and Services Logs, Microsoft, Windows, Security-Kerberos, Operational. Enable this Event Log and attempt to connect with Teleport Web UI to review log entries.

Smart card certificate not trusted

You connect to a Windows host from the Teleport UI, land on the Windows login screen and see an error message: "The smartcard certificate used for authentication was not trusted" (or similar).

Solution: Import the Teleport CA

This means that the host does not trust the Teleport CA.

First, make sure that you import the Teleport CA into Group Policy. Note that if you have rotated the Teleport CA since the last import, you need to fetch the new CA using the following command, replacing teleport.example.com with the address of your Teleport cluster:

curl.exe -fo user-ca.cer https://teleport.example.com/webapi/auth/export?type=windows

If that doesn't help, log into the target host directly, open PowerShell and run gpupdate.exe /force. This forces a Group Policy update and should pick up the new CA.

Smart card PIN not detected

Teleport uses a cryptographically secure random number generator to generate a smart card PIN for each new desktop session. In order to prevent the smart card certificate from being used for any purpose other than the initial login, this PIN is never shared with the Teleport user.

Teleport provides this PIN to the desktop during the RDP connection phase. If your group policy prevents the desktop from seeing this PIN, the user will remain at the login screen even though the smart card was detected.

Solution: Ensure that group policy allows specifying credentials during RDP connection establishment.

Expand Computer Configuration, Administrative Templates, Windows Components, Remote Desktop Services, and Remote Desktop Session Host.

Under Remote Desktop Session Host, select Security.

Right-click Always prompt for password upon connection, select Edit, select Disabled, then click OK.

Note: despite mention of passwords in the name of this policy, no passwords are sent on the wire. This mechanism is used only to send the smart card PIN.

New session "hangs"

Host unreachable

You click Connect on a Windows host from the Teleport Web UI, and a new tab opens, but nothing is displayed other than the top bar. After a while, an error is displayed about a failed connection. In most case, this error occurs when the windows_desktop_service can't reach the target Windows host.

Solution: Modify firewall rules to allow inbound RDP traffic

First, make sure that you open the RDP port and allow remote desktop connections in the group policy object you have configured for Teleport connections.

If that does not help, check if the target host is online and try to ping it from the Linux server that runs windows_desktop_service. If the host is online but not reachable, there is some other networking barrier in the way, specific to your infrastructure.

Hostname does not resolve

Connections to Windows Desktops hang during connection establishment, or the Teleport debug logs show errors of the form couldn't resolve winserver.example.com.

Solution: Ensure Firewall Permits DNS Traffic

For desktops that are automatically discovered via LDAP, Teleport makes DNS queries against the LDAP server in order to resolve the hostname to an IP address.

Ensure that your firewalls allow inbound DNS traffic on port 53 from the instance(s) running Teleport's Windows Desktop Service to the LDAP server (Active Directory Domain Controller).

Teleport fails to start

Incorrect domain

Teleport fails to start with an error similar to:

LDAP Result Code 10 "Referral": 0000202B: RefErr: DSID-0310082F, data 0, 1 access points
"\tref 1: 'xample.com'"
"\x00"

Solution: Correct Domain

This means that your domain name is likely wrong. Double-check the domain field in the ldap section of windows_desktop_service.

Domain controller unreachable

Teleport fails to start with an error similar to:

LDAP Result Code 200 "Network Error": dial tcp ad.example.com:636: i/o timeout

Solution: Check LDAP Address

This means that your domain controller is down or unreachable. Double-check the addr field in the ldap section of windows_desktop_service. If it's correct, check that the domain controller is up and reachable from the server that runs windows_desktop_service.

Cannot initialize LDAP over TLS

Teleport fails to connect to LDAP on startup. You may see errors similar to:

LDAP Result Code 52 "Unavailable": 00000000: LdapErr: DSID-0C090F78, comment: Error initializing SSL/TLS, data 0, v2580\x00

or

connecting to LDAP server: unable to read LDAP response packet: read tcp 172.18.0.5:35970->;172.18.0.4:636: read: connection reset by peer

Solution: Enable LDAPS

This means you do not have an LDAP certificate installed on your LDAP servers, or you are trying to make an insecure connection on port 389. Teleport requires secure LDAPS connections, which are typically on port 636. First, confirm that you are connecting to the correct LDAPS port. If that doesn't resolve your issue, you can install Active Directory Certificate Services (AD CS) or import your own third party certificate. Note that Active Directory is extremely picky so take care to generate your certificates correctly.

Desktops are not discovered via LDAP

LDAP not yet initialized

Teleport is running, but desktops do not show up in the Web UI. The logs contain errors similar to:

skipping desktop discovery: LDAP not yet initialized

Solution: Confirm Teleport certificate is installed

The Teleport Desktop Service uses a Teleport-issued certificate to authenticate with the LDAP server. This error occurs when Teleport is unable to authenticate, which is often due to its certificate authority not being trusted by Active Directory.

First, verify that the Teleport CA is present in the LDAP NTAuth store. Run the following command, modifying the DN for your domain (in this command we use a domain of example.com)

$ certutil -viewstore "ldap:///CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=example,DC=com?caCertificate"

You should see a popup window that shows the Teleport CA certificate. If the Teleport certificate is not present, import it with:

$ certutil -dspublish -f <path-to-cert> NTAuthCA

Once you've verified that the Teleport certificate is present in LDAP, you should check whether it has propagated to all desktops. From a desktop that you would like to connect to, run the following:

$ certutil -viewstore -enterprise NTAuth

If the popup window does not show the Teleport certificate, and it was present in LDAP, you can force the desktop to sync with the following command:

$ certutil -pulse

If you have verified that the Teleport CA certificate is properly installed and are still seeing this error, check for any security tools or addons that may be interfering with the mTLS connection. Tools such as CrowdStrike's LDAP inspection or Silverfort's AD adapter are known to terminate TLS and drop the client certificate, which prevents Teleport from authenticating.

Connection attempts fail

RDP server only uses Standard RDP Security

Attempts to connect to a desktop fail, and the logs show an error similar to:

Rdp(RdpError(RdpError { kind: ProtocolNegFailure, message: "Error during negotiation step: the server is configured to only use standard RDP security mechanisms and does not support external security protocols" }))

Solution: Enable Enhanced RDP security

Standard RDP Security is based on RC4 encryption and is the least secure way to connect to a Windows host over RDP. Teleport's RDP client requires enhanced RDP security with TLS.

Enhanced RDP Security is typically enabled by default, but your environment may be configured to require the legacy security methods.

This configuration is available via group policy at:

Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security

Look for the "Require use of a specific security layer for remote (RDP) connections" setting. The setting should be set to Negotiate or SSL, not RDP.

RDP connection failed

You click Connect on a Windows host from the Teleport Web UI, a new tab opens but nothing is displayed other than the top bar. You see an error that refers to a failed RDP connection. You may also see errors similar to:

Rdp(Io(Os { code: 54, kind: ConnectionReset, message: "Connection reset by peer" }))

Solution: Configure a certificate for RDP connections

This means that the desktop does not support secure cipher suites for TLS connections.

Make sure that you configure a certificate for RDP connections.

Expired smartcard certificate

The login screen displays an error of the form:

The smartcard certificate used for authentication has expired. Please contact your system administrator.

Solution: Check the system clock

Teleport's smartcard certificates are only valid for a short period of time (roughly 5 minutes). If the system clock on the Teleport auth server and the target Windows host disagree about the current time, the system may reject the authentication attempt.

Enhanced RDP security with CredSSP required

Attempts to connect to a desktop fail, and the logs show an error similar to:

Error during negotiation step: the server requires that the client support enhanced RDP security with CredSSP

Solution: Disable Network Level Authentication (NLA)

This means that the RDP server is requiring NLA. Teleport currently requires that NLA is disabled in order to perform its certificate-based passwordless login.

To disable NLA, follow the instructions to allow remote desktop connections in the group policy object you have configured for Teleport connections. If you are still encountering this error after disabling NLA in Active Directory, run the following command from the Windows Command prompt as an administrator to force the policy update:

gpupdate.exe /force