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/.
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.
The Okta PAM-related pages on this site are listed below.
- Create Your Own ASA Trial (locked)
The most recent PAM-related articles are:
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 … Continue reading Can ASA Work With a Shared User Directory and Linux Servers?