Okta Advanced Server Access (ASA)

This page highlights the articles on this blog that relate to Okta Advanced Server Access (commonly known as ASA). ASA has been with Okta for many years now and is used my many customers – large and small.

With the introduction of the Okta Privileged Access (OPA) product, focus has moved on from ASA. Bit the product is currently still available and supported. Many of the infrastructure components of OPA are shared with ASA, so much of this content is still relevant for OPA.

A Technical Overview of Advanced Server Access

Okta Advanced Server Access (ASA) provides secured server access via SSH and RDP, and it is a key component of Okta’s Zero Trust strategy. More information on the product can be found on the product website: https://www.okta.com/au/products/advanced-server-access/.

ASA Components

A high level overview of ASA and its components is shown below.

There are some additional components not shown:

• Bastions – Bastion servers are servers with the ASA Agent installed and used for network routing. Where you don’t want to expose all servers outside the network zone, you can deploy bastions as a network control point.

• Gateways – Gateways can also server as network control points, but also implement additional ASA functionality. For example SSH session capture is implemented in the Gateway. Also the upcoming AD-Joined feature is implemented in a Gateway.

There are two main ASA use cases – server access via SSH/RDP and provisioning to support that.

Server Access with SSH/RDP Use Case

The server access flow is shown below

In a Linux/SSH scenario, the user will initiate a SSH session via the ASA client. The client will connect with the ASA cloud service to request a user certificate. If the user does not have an authenticated session, Okta will be used to authenticate the user (optionally with MFA). Once authenticated ASA will validate the user is entitled to access the server (i.e. in the right project) and prompt the user to approve the certificate issuance. The client certificate is passed back to the ASA client, which passes the certificate as the authentication to the server via a local ssh client (like ssh or putty). On the server, the native sshd receives the request and validates the certificate against the signing key (that is specific to the project). The signing key is managed by the ASA Agent, but the agent doesn’t have any inline role in the flow.

For a Windows/RDP scenario, the flow is basically the same up to the point of connecting to the server. On a Windows server, the sshd function is provided by the ASA Agent not the OS. The agent is listening on a specific port and the ASA Client will setup a SSH tunnel with the ASA Agent. The RDP session is then run through the tunnel (showing up as a localhost connection and allowing RDP access to be turned off for the server).

There is also auditing of the access, but this will be the topic of a specific article.

Provisioning Use Case

When it comes to provisioning users and groups, ASA can work in two ways:

• Synchronise users/groups between Okta and ASA AND provision them to Linux/Windows servers. This is more likely to apply to standalone servers.

• Synchronise users/groups between Okta and ASA but NOT provision them to Linux/Windows servers. This will be the situation where a centralised user directory is used. For example, a set of Linux servers may be using a LDAP directory via SSSD. Also, if Windows servers are domain-joined, there is no need to provision users.

The following figure shows the components in the first scenario:

There are two parts of the user/group flow:

• Okta has the ASA cloud service as an application with users/groups assigned (and groups as Push Groups). Those users and groups are provisioned to the ASA Cloud Service using SCIM provisioning. Within ASA, the groups are assigned to projects to map them (and their users) to servers.

• The ASA Agents will periodically reach out the the ASA Cloud Service and if there are changes to users/groups to be applied, it will pull them down and apply them.

Also, for Linux servers ASA can centrally manage sudo rules and apply them to different groups in projects. If this is done, the same download mechanism is used to apply them to sudo files on the server.

The following figure shows the relationship between the components and obects.

There is a lot of other capabilities and functions in ASA that are too detailed for this introduction, many that will be covered in specific articles.

---

ASA-Related Articles

The most recent PAM-related articles are: