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 will provide information on Smart Card-based authentication attempts. This is available
at Event Viewer->Application and Services Logs->Microsoft->Windows->Security-Kerberos->Operational in the Windows Event Log. By default this
log is not enabled. Enable and attempt to connect with Teleport 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 the Teleport CA was rotated since the last import, you will have to fetch the new CA using the following command:
Log in to your cluster with tsh so you can use tctl from your local machine.
You can also run tctl on your Auth Service host without running "tsh login"
first.
tsh login --proxy=teleport.example.com --user=myusertctl auth export --type=windows >user-ca.cer
If that doesn't help, log into the target host directly, open PowerShell and
run gpupdate.exe /force. This forces a Group Policy sync 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. This setting can be found under:
Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security
Right click Always prompt for password upon connection and select Disabled.
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 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.
Solution: Open Firewall for RDP Traffic
This happens when the windows_desktop_service can't reach the target Windows
host.
First, make sure that you open the RDP port and allow remote RDP connections in Group Policy.
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).
RDP connection failed
You click CONNECT on a Windows host from the Teleport 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.
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:389: 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
Connection attempts fail
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 NLA
This means that the RDP server is requiring Network Level Authentication (NLA). Teleport currently requires that NLA is disabled in order to perform its certificate-based passwordless login.
To disable NLA, follow the instructions in our Desktop Access Manual Setup. If you are still encountering this error after disabling NLA in Active Directory, run the following command from the Windows Desktop command prompt as an administrator to force the policy update:
gpupdate.exe /force