PAM (Incl. ASA)

This page highlights the articles on this blog that relate to Okta’s Privileged Access Management (PAM) products. Okta currently has the Okta Advanced Server Access product for managing secure access to servers via SSH and RDP. During Oktane21 Okta announced development of a Privileged Access Management (PAM) product that will build on top of the Advanced Server Access (ASA) product.

Until the PAM product is released, this page (and the articles on this site) will focus on ASA.

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.

ASA Comnponents

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

Server Access with ASA

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:

ASA Provisioning Components

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.

Okta and ASA Components

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.

PAM-Related Pages

The Okta PAM-related pages on this site are listed below.

PAM-Related Articles

The most recent PAM-related articles are:

  • Extracting Okta ASA Audit Log with Okta Workflows

    The audit logs in Okta Advanced Server Access (ASA) can be viewed in the ASA administrative interface or extracted via the ASA Audit V2 API (and this is what the integrations with SIEM tools do). But what about the situation where you just need to extract all the logs and process them somewhere? You could…

  • Managing Multiple AD Users in the AD-Joined Feature of ASA

    Okta recently released the AD-Joined feature for Okta Advanced Server Access. This feature extends ASA secured RDP access to Windows servers in an AD domain, leveraging user credentials also stored in Active Directory. The feature supports both traditional password-based access and passwordless access using AD certificates, with the flexibility of having a mix of both…

  • Can ASA Work With a Shared User Directory and Linux Servers?

    Using a shared user directory for user authentication across server farms has been a common pattern since the 1990’s. Microsoft adopted it with Active Directory, but we’ve had NIS deployments for many years. Can Okta Advanced Server Access (ASA) work where user authentication is delegated to a central shared directory? Yes. This article looks at…