| authors | state |
|---|---|
Andrew Lytvynov (andrew@goteleport.com) |
implemented |
RFD 33 defines the high-level goals and architecture for Teleport Desktop Access. RFD 34 defines the integration details for Windows hosts.
Desktop Access for Windows supports:
- certificate-based authentication, by emulating smart cards
- username/password authentication, as a fallback when certificates fail
This RFD describes the details of the former, certificate-based approach.
While Windows does not support generic mTLS or similar PKI-based authentication, it does support smart cards. Smart cards are similar to HSMs or U2F/WebAuthn tokens - they store private keys in and expose certificates and basic asymmetric crypto operations.
The server side (Windows host or domain controller) validate the credentials against a trusted Certificate Authority. More information at https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/enabling-smart-card-logon-third-party-certification-authorities
Smart cards are typically hardware devices, but a driver can be implemented to emulate them in software (example). Since this is the only known way for us to support cert-based authn, Teleport will implement a smart card emulator to authenticate over RDP. This emulator will use Teleport TLS certs and expose the User TLS CA for import into the Windows trust store.
Note that RDP implements smart card authentication by proxying low-level driver
commands to the client (windows_desktop_service in our case) over the RDP
connection:
+---------+ +---------+ +---------+
| driver | (installed in client) | client | | server |
+---------+ +---------+ +---------+
| | |
| | init RDP connection |
| |--------------------------------------->|
| | |
| | authn challenge |
| |<---------------------------------------|
| | |
| | smart card info (name, slot, PIN) |
| |--------------------------------------->|
| | |
| | smart card RDP virtual channel |
| |<---------------------------------------|
| | |
| smart card RDP virtual channel | |
|<------------------------------------| |
| | |
| | smart card info (name, slot, PIN) |
|<-----------------------------------------------------------------------------|
| | |
| | low-level hardware messages |
|<-----------------------------------------------------------------------------|
| | |
| low-level hardware messages | |
|----------------------------------------------------------------------------->|
| | |
| | authn OK |
| |<---------------------------------------|
More information:
- CredSSP - authentication part of RDP
- Smart Card virtual channel
Yubico implements the same authentication flows, using an actual hardware device. https://www.yubico.com/products/computer-login-tools/ and linked docs can be used for inspiration.
Smart cards are only supported for logins into domain accounts - only in Active Directory environments. There is no builtin support for standalone Windows hosts, however it's possible to implement similar to Yubico Login for Windows in the future.
When windows_desktop_service receives a client mTLS connection, it needs to
issue an ephemeral smart card certificate to present to RDP server. This
certificate will be largely based on the received client certificate, with some
tweaks.
Subject Alternative Name = Other Name: Principal Name= (UPN). For example: UPN = user1@name.com The UPN OtherName OID is: "1.3.6.1.4.1.311.20.2.3" The UPN OtherName value: Must be ASN1-encoded UTF8 string
UPN looks like an email address. But note that the user part is the target Windows user (not the Teleport username) and the domain part is the name of AD domain that we're connecting to (not the email domain in Teleport SSO login).
In theory, RDP server should keep forwarding any smart card hardware commands
to the client (windows_desktop_service in this case). If a user opens another
RDP client within their remote desktop, they should just be able to log into
any host in the same domain without a password.
This is a nice-to-have and not a strict requirement. If it does not work right away, we can try emulating a local smart card using an agent on the remote host.