Using Advanced Server Access with Windows requires installing the Advanced Server Access Server Tools on the server, and ClientEssentially, a client is anything that talks to the Okta service. Within the traditional client-server model, Okta is the server. The client might be an agent, an Okta mobile app, or a browser plugin. Tools on the client. See below for directions.

Once the Advanced Server Access Server Tools are installed on the server and the server is enrolled, the Advanced Server Access AgentA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations. (sftd) does two things:

  1. Creates local accounts for all Advanced Server Access usersIn Okta literature, we generally refer to "users" as the people who serve as Okta administrators. When we refer to "end users" we are generally referring to the people who the administrators serve. That is, those who use Okta chiclets to access their apps, but have no administrative control. who should have access to the server, very similar to on Linux. On Windows, these accounts are initially disabled.
  2. Runs an additional Access Broker which listens on port 4421.

The Access Broker uses TLS 1.2 to authenticate all clients using client certificates that can only be issued by the Advanced Server Access platform.

Connection Establishment

In order to establish an RDP connection, the Advanced Server Access client:

  1. Communicates with Advanced Server Access platform to get short-lived credentials it can use to authenticate to the Access Broker.
  2. Optionally establishes an SSH tunnel through any intermediate bastion servers. If any bastion also uses Advanced Server Access for authentication, short-lived credentials are fetched transparently.
  3. Connects to the Advanced Server Access broker (over the SSH tunnels, if applicable) and authenticates using the short-lived certificate provided by the platform. The client also authenticates the server's host certificate against one provided by the platform to defend against man-in-the-middle attacks.
  4. The client requests access to the user account on the server. At this point the Broker requests that the Agent enable the user account.
  5. Negotiates a proxied RDP connection via the Broker. The client is then able to start a TCP server on a random port on the client, which is proxied through the broker to the RDP service on the server.
  6. The client writes an RDP connection file containing the connection info, including the random local port on which the client is now listening. It then opens the Windows Terminal Services client with this configuration.

The RDP client connects to the local TCP port and is forwarded to the RDP service on the server. The RDP server is able to automatically authenticate as the user without any further prompting.

When the user logs out, the agent will automatically disable their account.


Server Configuration

Server configuration follows the same principles as it does on Linux.

In order to enroll the server using an enrollment token, write the token to:


Alternatively if you are using AWS you can associate your AWS account with a Advanced Server Access project.

Advanced Server Access Server Tools installers are available here.

Advanced Server Access Server Tools can be automatically installed on AWS using the following userdata script. If you are using an enrollment token be sure to replace the value of $enrollment_token. If you have associated your AWS account with your Advanced Server Access project, you can omit the first half of the script which is responsible for writing the enrollment token.

# Write the Enrollment Token
$enrollment_token = "ENROLLMENT TOKEN GOES HERE"
$enrollment_token_path = "C:\windows\system32\config\systemprofile\AppData\Local\scaleft\enrollment.token"
New-Item -ItemType directory -Path (Split-Path $enrollment_token_path -Parent)
$enrollment_token | Out-File $enrollment_token_path -Encoding "ASCII"

# Install  Advanced Server Access Server Tools
$installer_url = "https://dist. Advanced Server Advanced Server Access-Server-Tools-latest.msi"
$installer_path = [System.IO.Path]::ChangeExtension([System.IO.Path]::GetTempFileName(), ".msi")
(New-Object System.Net.WebClient).DownloadFile($installer_url, $installer_path)
msiexec.exe /qb /I $installer_path

Client Configuration

Windows Client installers are available from Okta support.

Once the client is installed it must be enrolled into your team by running sft enroll.

Connecting to a Server

To RDP to a server using Advanced Server Access run:

sft rdp <server-name>

If you need to traverse one or more bastions use --via arguments, such as:

sft rdp --via <first.bastion> --via <second.bastion> <server>

Advanced Server Configuration


State Directory


Config File


Log Directory


Enrollment Token



The configuration format used by the agent is the same on Windows as it is on Linux. See the sftd reference for details.