Okta Privileged Access Frequently Asked Questions

Oct 14, 2024

Privileged Access

Okta Classic Engine

Okta Identity Engine

Content

This article provides answers to frequently asked questions about Okta Privileged Access (OPA)

Okta Privileged Access is Okta’s new Privileged Access Management (PAM) offering. It delivers a unified approach to managing access to all your privileged resources, resulting in better visibility, compliance, and security without compromising the user experience.

Okta Privileged Access reduces an organization’s risk by bringing critical PAM capabilities — including infrastructure access, privileged access governance, credential vaulting, and compliance reporting — into your core Workforce Identity and Access Management solution.

Where can I find more information about the pricing for Okta Privileged Access?

Please talk to your account team to discuss pricing for Okta Privileged Access.

What are the certifications for Okta Privileged Access?

We are actively pursuing compliance certifications for this new product. We are first pursuing Soc 2 Type 1, with additional certifications in the future. Okta Privileged Access builds on and is an evolution to Okta’s Advanced Server Access that has achieved Soc 2 Type 1, Soc 2, Soc 3, ISO 27001+, CSA STAR Lvl 2. We anticipate these will come in time.

Is Okta Privileged Access authorized for FedRamp?

Not currently. This process is planned to begin late FY25.

How is Okta Privileged Access different from Advanced Server Access (ASA) ?

Advanced Server Access solves a critical PAM use-case which is zero trust, least-privileged access to Server Infrastructure.
Okta Privileged Access broadens and deepens the capabilities of ASA to create a comprehensive Privilege Access Management solution including many new features like:

Zero trust, least privileged access to modern Infrastructure.
Discovery, Rotation, Vaulting and Monitoring of highly privileged, shared local accounts.
Secrets Vault with controls and governance layers that satisfy security requirements and compliance regulations.
Access Requests Approval flows for privileged resources leveraging the power of Okta Identity Governance.
Conditional Access Policies and Transactional MFA protection of PAM resources
Cloud Infrastructure Entitlement Discovery and Analysis (CIEM) for AWS resources.
Easy integrations with DevOps workflows.

Does Okta Privileged Access support custom domains ?

Customers can login to their Okta orgs using custom domains. The PAM teams linked to these Okta Orgs will be hosted on *.pam.okta.com domain.

What roles are available in Okta Privileged Access ?

Okta Privileged Access includes a number of built-in Roles to help customers enforce least privilege best practices. Different admin roles are available, for example, to enforce separation between those that administrate resources and those that configure access to privileged resources. Delegated resource administration is also supported. This can be used for administering specific resources (for example, admin group for Linux administration). Non-administrators are restricted from seeing administrative views and are limited to seeing only the privileged resources they have been granted access to. See here for more details.

Is Okta Privileged Access Available Worldwide?

Unlike Okta Advanced Server Access, Okta Privileged Access is bound to the corresponding Okta org - when purchased it will be provisioned into the same Okta cell as the Okta org.

Okta Privileged Access is currently available in all non FedRamp preview and production cells in North America and EMEA.

It is not currently available in the following cells:

OP2 - The EMEA preview cell.
OK8 - The APAC production cell (Sydney/Singapore). It is expected to be available in Q4 FY25.
OK16 - The Japan production cell (Tokyo/Osaka).

Policy Engine

How does conditional access work in Okta Privileged Access?

Okta privileged Access has a robust policy engine where administrators can set up a variety of conditional access policies like Access Request approval flows or transactional MFA. This extensible feature can be leveraged in a variety of ways to afford organizations the ability to create dynamic policies, addressing their specific access governance needs.

Infrastructure Access

What are the Operating Systems supported by Okta Privileged Access ?

The supported Operating Systems can be found here.

What are Individual Accounts and what permissions do they have on the server(s) ?

Okta Privilege Access enables an Okta user to gain authorized SSH or RDP access to servers by managing an individual Principal account for every Okta user on every Linux/Windows server that they are authorized to access. It does this automatically either by creating/removing an individual account on a JIT basis OR by creating a persistent local account. See here for additional details.

Okta Privileged Access Security Administrators can configure the permissions on these individual accounts on the servers to be:

user level permissions,
sudo level permissions (on Linux system), OR
admin level permissions

Privilege Elevation allows customers to enforce the least-privilege server access model by ensuring that the Okta User only has just enough elevated permissions on the right servers in order to complete their tasks.

Does Okta Privileged Access manage SSH keys ?

Okta Privileged Access's approach to establishing SSH sessions negates the need for customers to manage SSH keys at all; instead Okta Privileged Access uses short lived SSH certificates for authentication.

Okta Privileged Access also introduces a new vault capability where secrets can be stored, managed and accessed for privileged access use cases. The initial focus on this function was on the management of shared accounts from managed servers. With the General Availability release of the product this is expected to extend to managing secrets for systems that are not connected to Okta Privileged Access.

What is the purpose of Gateways in Okta Privileged Access ?

A gateway is a transparent proxy component that can address multiple needs:

Network routing to avoid making server agents publicly accessible to clients
Improving credential security by encrypting short lived client authentication certificates with a gateway encryption keys ensuring clients have no direct access to authentication certificates
Enabling session recording for SSH/RDP
The Gateway component will be required for future use cases for additional resource types.

Unlike with Okta Advanced Server Access, Okta Privileged Access does not support Bastions. To implement the equivalent network proxying/routing that Bastions provided, use Gateways.

Does Okta Privileged Access provide session recording ?

Okta Privileged Access leverages the gateway (requirement for this feature) that will record SSH/RDP sessions locally on the gateways.

Tamper-proof session recordings are stored on the Gateway, can be mounted on NAS storage or forwarded to AWS S3 bucket for later review. The sessions are recorded as asciinema for SSH and MKV files for RDP. After a session ends, teams can store the finalized session logs locally on the gateway or upload them to remote platforms such as Amazon Web Services (AWS) S3 or Google Cloud Storage (GCS). See Session capture options .

Does Okta Privileged Access detect out of band password changes for local accounts on the servers that it manages ?

Once an account is put under management by Okta Privileged Access it will stay under management, driven by the policy engine and backed with tamper-proof logging. Since events in Okta Privileged Access are logged in Okta any out-of-band password change is also logged, the password rotated, and that event can be leveraged by a SIEM or ticketing solution to create further actions to dig into who, what, when, and where someone changed the password.

How Does Okta Privileged Access Manage SUDO Rules?

As with Okta Advanced Server Access, Okta Privileged Access can centrally manage SUDO rules for Linux servers. But the implementation is slightly different.

First, SUDO rules are managed in a separate part of the menu system: Sudo Commands under RESOURCE ADMINISTRATION. This means it is subject to the system-wide Resource Administrator roles. They are called “command bundles” and comprise a name and description, as well as commands.

Sudo command bundles are applied to users and servers via policies. They are associated with individual access when assigned to servers. The command bundles can be reused across different policies to apply to different sets of servers.

When a policy is applied to an individual user in policy, and that user connects to an in-policy server, as the user is created just-in-time on the server, the relevant sudoers.d rule is created. This rule in the /etc/sudoers.d/ directory will be tied back to the users’ personal group. The filename will be comprised of the sudo command bundle name, the username and a unique identifier.

For example, if larry.linuxadmin connects to a server there will be a sudoers.d file that includes a mapping of the command alias to larry’s personal group (e.g. %larry_linuxadmin ALL= NOPASSWD: …). When the user disconnects from the session, this file is deleted.

For more details see Sudo Command Bundle. Also, there is an iamse.blog article exploring this in more detail - Centrally Managing SUDO Rules with Okta Privileged Access

Secrets Vault

What is the generic secrets vault within Okta Privileged Access?

Okta Privileged Access Secrets Vault feature will enable customers to protect Secrets. It provides a durable, secure place to store secrets within their organization. It will deliver ease-of-use for end users as well as provide controls and governance layers that administrators require to satisfy security requirements and compliance regulations. Policies can be applied to ensure privileged access conditions such as governance and MFA.

Can I Programmatically Access the Secrets Vault?

Yes. There is a Secrets API for programmatically working with secrets and secret folders.

Use of the APIs is explored in an iamse.blog article - Using the Secrets API with Okta Privileged Access.

Privileged Entitlements Analysis and Discovery

What is the Privileged Entitlement Discovery and Analysis feature of Okta Privileged Access ?

This feature will help customers find the set of resources in their IaaS applications that represent high risk to their organization if breached, then help them create entitlements in those applications to right size access to IaaS resources. Benefits include streamlining the process of removing standing access to privileged resources in IaaS applications and implementing a just in time access model.

Auditing and Reporting

What are the auditing capabilities of Okta Privileged Access ?

Native integration with Okta System Log provides a single location to review all Events related to Privileged Access.

Session recordings and Event data help with security detection+response as well as compliance objectives.

Are There Any PAM Reports in Okta Privileged Access?

Yes there is an Access Report that can report on all access for users or all access for resources (like servers). Reports can be generated and downloaded using the Access Reports API or by leveraging the reports cards in the Okta Privileged Access Workflows connector.

Workflows

Is there a Workflows Connector for Okta Privileged Access?

Yes. An Okta Privileged Access connector has been made available from Okta. It obfuscates the authentication needed for Okta Privileged Access APIs - you create a connection and do not need to worry about managing API keys in each flow. The connector supports actions for object management and reporting.

There are examples of using the new connector on iamse.blog, including:

Content

Table of Contents