All applications require a highly-privileged administrator role to deploy and maintain that application. The monitoring and oversight (audit) of actions performed by users with these roles is a cornerstone of any well-designed security program.

A number of research projects have highlighted ways in which the most privileged administrators in Okta could, if unchecked, abuse their privilege in some way. These research efforts serve to reinforce some long-held security principles: most notably the principle of “least privilege,” that a user or application should only have the permissions required to perform a specific role or function, and the principle of governance, where those responsible for holding privileged access are held to account for their actions.

Below we’ve presented some best practice advice on limiting, securing and monitoring administrative access to Okta.

Constrain Privileged Roles

Okta HealthInsight is a tool that prompts administrators to address misconfigurations or conditions identified in their Okta tenant (“org”). One HealthInsight reminder recommends limiting the number of highly privileged roles (“SuperAdmins”) in any given org.

The SuperAdmin role grants its user full privileges to all the powerful administrative capabilities Okta makes available to its customers. A SuperAdmin can manage users, policies, applications and administrative permissions and set org-level security configurations. Every new Okta org is provisioned an account with the ‘SuperAdmin’ role, and the SuperAdmin has the ability to create other admin roles using this account.

As our colleague Gurinder Bhatti recently blogged, with great power comes great responsibility. The majority of tasks an Okta administrator needs to perform do not require SuperAdmin access. For this reason, there are eight other standard admin roles in every Okta org that can be used to constrain administrator access. Your help desk admin doesn’t need the same rights as the admin that manages API access, for example.

As customer implementations of Okta grow larger and more complex, it creates a requirement to further align administrative capabilities with an individual’s role. To support this need, Okta developed Custom Admin Roles to allow organizations to set even more granular permissions within a role. So your helpdesk admin might, for example, only be granted permissions relevant to users within a specific functional unit (organization or group), a specific set of duties or specific applications and resources.

Delegated flows, meanwhile, provides administrators the ability to run (but not modify) specified Okta Workflows, without requiring SuperAdmin access.

Secure Admin Access

Given what an attacker with unauthorized access to highly privileged roles in Okta can do, admin access should be locked down according to the level of risk associated with how that role might be abused.

SuperAdmin roles should ideally make use of Privileged Access Management solutions that securely store and rotate ephemeral credentials.

Global Session Policies should enforce shorter session durations and idle timeouts for admins versus regular users.

While the permissions and resources available to any given admin role might vary, access to the Okta Admin Console would nearly always meet the NIST criteria for an AAL2+ and AAL3 application. At minimum, the total session for an admin would expire at 12 hours, with an idle timeout of no greater than 15-30 minutes.

Authentication Policies for access to the Admin Console should at a minimum require:

• Phishing Resistant authenticators (select “Phishing Resistant” as a possession factor constraint) in a policy that requires any two factor types;

• Access from a trusted network zone (using an allowlist of trusted IPs/ASNs);

• Access from a registered or managed device (ideally a device exhibiting a strong security posture); and

• Re-authentication “at every sign-in”.

We also recommend enabling the following features in Okta to prevent abuse of stolen administrative sessions:

• Protected Actions

• ASN and IP Session Binding

Auditing and Monitoring Admin Access

As employees change roles throughout their employment, it is common that they also amass and retain privileged access to systems and data.

Organizations should perform periodic access reviews of admin role assignments and ensure that privileged access is appropriate for each individual. Okta offers an out-of-the-box report that provides a snapshot of all admin roles in use.

Outside of these pre-built reports, privileged access to Okta’s administrative functions can be monitored by security teams using Okta System Log. System Log events can be <a data-cke-saved-href=" />browsed, searched or filtered in the admin console, queried and filtered programmatically via the System Log API, and can be exported or streamed to third-party security monitoring tools.

Given there are over 700+ events emitted by System Log, it might seem exhausting to know where to begin monitoring or auditing this access.

There are a few ways to narrow it down. Keep in mind that most events in System Log follow a similar pattern:

<domain>, <resource>, <action>

So the following query returns events related to users:

eventType eq user.*

The next iteration on this query returns events related to user accounts:

eventType eq user.account*

And the following event returns user password resets:

eventType eq user.account.reset_password

With this structure in mind, below we’ve listed some search terms that could be useful when auditing administrative access.

Access to the Admin Console

All sign-ins to the Okta Admin Console create a unique system log event:

eventType eq "user.session.access_admin_app"

Sign-in events of interest might include events in which access to the Okta Admin Console is denied, especially where there are multiple failure events.

Similarly, you might be interested in access to the Okta Admin Console from a new device or IP or access that triggers a velocity condition (aka “impossible travel”).

(NB: both of the detections below assume that the displayName for the Okta Admin Console has not been modified by administrators.)

Privilege Assignment

An audit of administrator privileges should consider what privileges have been assigned to different admins or groups of admins. Any eventType that ends with “privilege.grant” will cover privileges granted to both individual admins and groups of admins.

User Lifecycle Events

Querying an event that contains the string “lifecycle” provides a fairly comprehensive view of user lifecycle events triggered by administrative actions.

At the org-wide level, this query includes lifecycle events for external IdPs and authenticators, down to devices and authenticators configured at the level of the individual user. Some more granular queries for specific categories of lifecycle events are presented below:

Policy Change Events

A search for events that contain the word “lifecycle” list include most changes made to an Okta signin policy. Changes to rules within policies aren’t necessarily captured by that query. The query below captures a range of events related to changing access policies.

Other Configuration Changes

There are a number of org-wide configuration events in Okta’s Event Catalog that are just as critical for monitoring and auditing purposes. Changes to network zones or device management platforms, for example, can result in a loss of access for large numbers of users.

You’ll find a larger set of admin-relevant event types in the Event Type Catalog.

Trusting privileged users is a necessary risk for any application, and the security best practices of least privilege, strong authentication, and activity monitoring provide you with the tools you need to verify actions and mitigate this risk. Okta provides robust solutions to address these requirements. It’s worth noting that all of the events listed above can trigger a custom Okta Workflow (either through a connector event card or an event hook), such that admins can automate responses to events of interest.

By adding the controls detailed here into your security program, you can ensure your administrators have appropriate access, and are using that access to protect your organization.

Change Log

1.1 - Mar 8, 2024

• Updated recommendations to include new features released as part of Okta Secure Identity Commitment: Protected Actions, ASN/IP Session Binding.

• Updated detections section to include System Log event for for an authentication failure arising from session binding.

1.0 - Oct 25, 2022

• Original Published