IAmDavid

Author: iamdavid

  • Recent Updates to Okta Privileged Access – Oct 25

    There have been a number of features released for Okta Privileged Access over the recent months, some major and some minor, but may have been lost in the excitement of Oktane 25. This article provides a summary of all the changes release.

    Introduction

    The last two quarters have been very busy for Okta Privileged Access between roadmapped items and customer feedback from early adoption of features like the Active Directory integration. This has led to a flurry of feature enhancements recenty, Some of these are focused around the Active Directory integration and some are other features for OPA.

    This article summarises the recently-released features. As always you should check the Release Notes (note that these are stored at a different location in the product documentation).

    Active Directory Integration Changes

    Earlier in 2025, Okta released the first phase of the integration with Microsoft Active Directory (AD). It added the ability to discover privielged accounts in AD, bring them under management, associate them with individuals (if they were deemed to be individual admin accounts), rotate passwords and allow the credentials to be revealed so they could be used (copy’n’paste) in AD-authenticated services.

    The next phase of the AD integration, being able to RDP to member servers with AD credentials, has been released. This release also includes some additional features based off customer feedback from the initial release.

    RDP Support (aka Click-to-Connect)

    The feature is called “Active Directory Remote Desktop Protocol (RDP) support” in the Release Notes. It makes the AD accounts available, through policy, to the sft client for direct RDP connections. More details can be found in the article RDP’ing with Microsoft Active Directory Accounts in OPA.

    AD rotate password configuration

    There are two changes under this feature:

    1. The ability to turn off the initial password rotation on discovery, and
    2. The ability for users to force a password change of AD accounts

    With the initial release of the AD integration, it was decided that when an AD account was adopted into the vault an initial password rotation would be performed so that OPA knew and owned the password.

    Some customers have asked for this initial rotation to be selectable so that some accounts wouldn’t have the password rotated initially. This is so downstream systems would not be affected and the customer could manage them over time.

    The second part of this is to allow, through policy, users to change an AD account password.

    When enabled, users subject to the policy can rotate (change) the password of the AD accounts in the policy.

    Note that the AD accounts now show detailed information about the account, its checkout status and rotation. This is another AD enhancement, although I’m not sure which new feature it falls under.

    There are plans to roll this user-initiated password rotation out to other resource types.

    AD Accounts as Okta Users and OPA Service Accounts

    In the initial release of AD support, there was a strict delineation between AD primary accounts that were connected to users in Okta (and not stored in OPA) and secondary accounts and shared accounts that were in OPA but not tied to Okta users. However a number of customers wanted secondary and shared accounts to also be Okta users.

    This new feature allows an account to be tied to an Okta user and in OPA. A user would access OPA to check out the secondary/service account and log into Okta with it.

    Enabling this setting in an Account Rule (assignment rule) will allow for accounts to be Okta Users and privileged AD accounts in OPA also.

    This can be used with the new filtering option (see next section) to manage which AD accounts are Okta users AND OPA accounts.

    The example below shows three AD accounts sourced from a domain and added as users in Okta.

    They are also AD managed accounts in OPA.

    This means the password is managed by OPA, and a user can check them out to log into Okta with them (similar to how OPA manages Okta accounts).

    Filter AD Accounts for OPA Import

    The initial release of the AD integration required any accounts to be managed by OPA to be put in a separate container (OU) in AD. Thus the OPA integration would only look at specific OUs and consume all accounts from them into OPA.

    Customers found this limiting, so work has been done to allow a filtered selection of accounts from an OU to be consumed.

    You can select all accounts in the OU to be managed by OPA, or a combination of rules. Each rule can look at the AD account name or Okta group it’s connected to, and for account name it can filter based on contains, equals, starts with and ends with. These rules are applied at the OU level so you could have different filtering rules for different OUs.

    Client Command Line tools for AD

    There are now two client commands to work with AD: sft ad list-domains and sft ad list-accounts.

    They will show the domains the client user can see and the accounts for a domain that the client user can see. These correspond with OPA AD API commands. It requires OPA client 1.98.1 or greater.

    Domain Controller Support

    Active Directory Domain Controllers present their own security challenges and normally carry a higher level of control, such as not allowing local accounts on them. This has been a limitation on the operation of the OPA server agent. This has now been resolved (It requires OPA server agent 1.98.1 or greater).

    Note that there are additional sftd.yaml configuration options that aren’t in the product documentation yet. The following shows the new settings:

    This feature is currently moving through the Okta preview environments and may be available in production by the time you read this.

    Gateway RDP Support with Session Recording

    The gateway (sft-gatewayd) now supports routing AD connection traffic through it and performing session recording.

    This feature is currently moving through the Okta preview environments and may be available in production by the time you read this.

    Other Okta Privileged Access Changes

    There have been three other feature releases in OPA over the last three months.

    Search capability for Okta Privileged Access secrets

    OPA users can now search secret folders and secrets.

    The search is dynamic – it will search as you type into the search field. It will show where the secret or folder is in the folder hierarchy (with the branches clickable) and also the Resource Group and Project, and secret/folder description.

    Exclude symbols in project password policy

    Password complexity settings for servers, SaaS app service accounts, Okta service accounts, and Active Directory accounts have been updated. You can now exclude specific symbols from OPA passwords, preventing rotation failures in systems that restrict certain symbols.

    You select the exclude characters from the presented list.

    Auto-generate passwords for SaaS apps

    Okta Privileged Access users can now use the password generator feature to update the password for their unmanaged SaaS apps. This is only for unmanaged SaaS apps at this stage (managed SaaS apps are subject to the other password rotation triggers – import, check in and schedule).

    When accessing a SaaS app and credential in OPA, the Show credentials button is selected.

    The Edit button is used to change the password.

    But now there is an option to generate a strong password (padlock icon) in addition to typing in a new password.

    Selecting the padlock icon will expand the dialog to show the password strength rules. You can generate a new password.

    The new (generated) password will not be shown, but you can reveal it as you would normally. This new password would need to be manually applied to the relevant SaaS app account.

    Conclusion

    We have seen a flurry of new features added to Okta Privileged Access over the last few months. Some of these expand the AD integration work started earlier in the year and others are affect other aspects of Okta Privileged Access. These updates may have been missed with the excitement of Oktane, so this article provides a summary. There’s a lot more coming.

  • The Okta ITP Workflows Connector

    In May 2025 Okta released a Workflows connector for Identity Threat Protection with Okta AI, called the Okta ITP connector. This article is a brief walkthrough of the connector.

    Introduction

    With the release of Identity Threat Protection with Okta AI (ITP), new capabilities have been added to the Okta Workforce Identity platform for risk evaluation/detection and remediation. This includes new events written to the Okta System Log, new APIs (such as endpoints to see/manage user risk), and new functionality such as universal logout.

    In May 2025, Okta released the Okta ITP connector for Okta Workflows. As with any Workflows connect it obfuscates API call making it simpler to build bespoke automation processes. This article provides an introduction this connector. Note that by the time you see this article, additional events/actions may have been added – as always check the product documentation.

    The Okta ITP Connector

    We will look at the connector authentication, the events and actions, and show some examples.

    Connector Authentication

    Whist this is a new Workflows connector, it is leveraging standard Okta functions. Some of the actions could be done in the standard Okta connector.

    It uses the same authentication as the standard Okta connector. This is the OpenID Connect Client ID and Client secret on the Okta Workflows OAuth app in Okta.

    Depending on what events or actions you are using you may need to grant one or more of the following Okta API Scopes on the Okta Workflows OAuth app:

    • okta.events.read

    • okta.riskProviders.manage

    • okta.riskProviders.read

    • okta.sessions.manage

    • okta.sessions.read

    • okta.userRisk.manage

    • okta.userRisk.read

    • ssf.manage

    • ssf.read

    Some of these are tied to specific events/actions, and some will be required if you use the Custom API action. You may have some already granted due to workflows you’ve built in the Okta connector.

    Connector Events and Actions

    Borrowing from the product documentation, here are the events.

    Event Description
    Policy Reevaluate Auth Failed Run a flow when an authentication policy reevaluation results in a policy violation.
    Universal Logout Run a flow when an admin or system account triggers Universal Logout against an app instance. This event identifies when apps have had Universal Logout triggered for audit or debugging purposes.
    User Risk Detected Run a flow when Okta detects that a user is associated with risk activity or context.

    Using any of the these three system log events means that you can have your workflow listen for the events rather than having your workflow use an API Endpoint and setting up an event hook. It also handles parsing out the important data fields for the event rather tham having to do it yourself in the workflow (and example of this below).

    Of course if you want to trigger a workflow off other ITP events in the system log, you will need to build the workflow with an API Endpoint and data parsing, tied to an event hook.

    There are four actions.

    Action Description
    Custom API Action Make an authenticated HTTP request to the Okta API.
    Global Token Revocation Initiate the global revocation of all tokens and sessions for a specified user. This enables external identity providers (IdPs) to trigger a comprehensive sign-out process, including executing IdP-initiated sign-out flows across all apps that are using global token revocation and requiring users to re-authenticate to access protected resources.
    Retrieve User Risk Retrieve the user risk object for a specified user ID.
    Upsert User Risk Upsert (create or update) the user risk object for a specified user ID.

    The Custom API action is the same as the one for the Okta connector so you could theoretically run any Okta API through it.

    The Global Token Revocation action is useful when you want to mix universal logout with some other bespoke action. There is an example of this below.

    The other two can be used to determine the current risk level of a user (perhaps you want to query it from some other process) and set it to Low or High.

    Some Examples

    These examples have been taken from Using Risk in Okta to Manage Privileged Access in OPA.

    In the first example, we are triggering a workflow on a user.risk.detect event (i.e. user risk change) to manage users in risk-related groups. The Okta ITP User Risk Detected event card is added to the start of the flow.

    It parses out all of the relevant information from the system log event, like the Risk object and Okta User object.

    The second example there is a need for some bespoke processing for universal logout. In response to an entity risk policy being fired, the user needs to be logged out of their active sessions that Okta can do, but also needs to perform some custom action on a specific application.

    In this case the workflow is a Delegated Flow attached to the ER policy. It will perform the Global Token Revocation action and then proceed to the bespoke steps for the specific application.

    These examples show how the different events and action cards can be used to expand user risk-related bespoke automation flows.

    Conclusion

    The new Okta ITP connection for Okta Workflows means that bespoke automation can be built to leverage the risks detected by ITP and user risk levels changed by ITP. The article has provided a summary of the authentication, events and actions, and provided some example uses of these.

  • Using Risk in Okta to Manage Privileged Access in OPA

    Identity Threat Protection with Okta AI will continuously assess user context and automatically respond to identity threats across your ecosystem. This includes managing entity (user) risk levels. Okta Privileged Access does not explicitly have user risk built in, but user risk can be applied to control how users access privileged resources.

    This article looks at two scenarios where entity risk can drive access in Okta Privileged Access. The first uses risk-related groups managed by workflow off risk changes and tied to policies in OPA to implement different controls for accessing resources. The second looks at how to drive session revocation in OPA.

    The article assumes some knowledge of both Identity Threat Protection with Okta AI and Okta Privileged Access.

    This article extends off the Boosting security with Okta Identity Threat Protection and Workflows Okta blog.

    Introduction

    Identity Threat Protection with Okta AI (ITP) will continuously assess user context and automatically respond to identity threats across your ecosystem. It takes feeds from first- and third-party systems, analyses for session and entity risk, maintains an entity risk level on user profiles and provides mechanisms to remediate those risks. Remediation can include performing universal logout across apps the user is logged into and also running Workflows with bespoke remediation processing.

    Okta Privileged Access (OPA) manages and controls access to privileged resources list servers, secrets and SaaS service accounts. It uses policies tied to groups from Okta to determine who can access what and how. Whilst it does not have risk built into the policy engine currently, there are ways that we can influence OPA based on changing risk in ITP.

    This article explores two scenarios that have been implemented primarily via Okta Workflows:

    1. Scenario 1 leverages groups managed in Okta and pushed to OPA. These groups represent different levels of user risk (Low, Medium and High) and in OPA they are mapped to policies and rules with different levels of access controls (none, MFA and Access Requests). Okta Workflows trigger off a change in entity risk (from ITP) and manage the membership of the different groups).

    2. Scenario 2 is focused on session revocation for both the Okta Dashboard and the OPA session. The latter is managed through removal from the group granting access to OPA in Okta. This is done via Okta Workflows.

    The following sections explore both scenarios.

    In this first scenario, we want to apply PAM policy controls based on user risk. The higher the risk of the user the more stringent the controls. In the example below, the user needs to access a Salesforce service account in OPA. If the user is sitting at a low risk level, they will not be prompted for any additional controls to access the credentials for the service account, but if their risk increases to medium, we want to apply MFA, and if their risk goes to high, we want to apply an access request approval.

    We will walk though the user experience, then look at how the mechanism is built.

    The User Flow

    Let’s start with a user, Ivan ITPUser, who is in-scope for ITP risk evaluation.

    He is currently sitting at a Low entity risk level, and can access OPA via the OPA Risk All group. He is also in a LOW risk group (OPA Risk LOW) because of that entity risk level.

    When Ivan goes to OPA from his Okta Dashboard, he can access the Salesforce SaaS app.

    If he goes into the app and selects the service account, he sees he can access it without any special conditions.

    But what if something occurs in his session to cause ITP to elevate his entity risk to HIGH?

    He now has an Entity risk level of High and he has been moved from the LOW risk group to the HIGH risk group (OPA Risk HIGH).

    When he goes to access the same Salesforce account in OPA, he now has an Access Request condition he must comply with before being able to access the account.

    If the ITP policy evaluation had resulted in his Entity risk level going to Medium, he would be put into the MEDIUM risk group and would have to meet the MFA condition to access the Salesforce account.

    The above is all driven by groups tied to policies in OPA. Lets have a look at how it works.

    Overview of the Mechanism

    The mechanism involves Okta ITP, Okta Workflows, Okta Privileged Access, users/groups in Universal Directory, and events written to the Okta System Log. The main components are shown in the following figure.

    ITP is constantly reevaluating risk based on the events from first- and third-party systems. When a risk is detected there is a user.risk.detect event written to the Okta System Log.

    There is a Workflow configured to trigger on the user.risk.detect event. It will evaluate what the user risk change was and move the user between the appropriate risk-related Okta groups.

    These groups are assigned to the OPA app as Push Groups, so any change in membership will be pushed to OPA.

    In OPA each group is tied to a specific policy that grants access to the Salesforce account. For LOW risk users, there are no controls applied; for MEDIUM risk users there is an MFA control applied; and for HIGH risk users there is an Access Request control applied.

    This is an example of how you can use different controls on different levels of risk. You could have different combinations of controls depending on the resource and your policy requirements. For example if accessing servers, you may want to apply session recording to higher levels of risk.

    Workflows Configuration

    The mechanism uses the (relatively new) Okta ITP connector in Workflows. It comes with a User risk detected event to trigger when a user.risk.detected event is written to the system log.

    Prior to the connector, you would have to us an API connector with webhook and strip out the relevant data from the API body. With the event card, the key fields are split out for you.

    The data passed in is used to determine the past and current risk level and re-assign risk group membership based on it.

    It has the three groups (LOW, MEDIUM and HIGH) hardcoded in a helper flow. It will also check to see if there was an actual change of risk level.

    It then uses a series of multi-level if/else statements to remove the user from the old group and add them to the new group. For example, if the user went from LOW to HIGH, they would be removed from the LOW risk group and added to the HIGH risk group.

    OPA Push Groups

    All three groups are assigned as Push Groups against the OPA app.

    Any change in group membership in Okta will flow down to the group membership in OPA.

    OPA Policies

    As per the figure above, there are three OPA policies to control how the members of the different groups can access the resource (the Salesforce service account). You can see the policies and groups (principals) assigned.

    In each policy there is one rule with the appropriate conditional applied. The three rules from the three policies are:

    This is a trivial example, but it shows how you can assign users of different levels of risk to different policies. You could potentially have three policies, one for each level of risk and have multiple rules in each for different sets of resources or different resource types. Or you could have multiple policies for each risk-level.

    Scenario 2 – ITP Drives Session Revocation in OPA

    The previous scenario showed how you could alter access (and controls applied) in OPA based off user (entity) risk changes detected by ITP. But what about if you want to close all sessions if a user’s risk goes to high?

    ITP supports a universal logout function where sessions in supported apps can be automatically killed based on policy settings, including the Okta Dashboard the user is using. However OPA does not currently support universal logout. What can we do? We can remove the user from the Okta group(s) that is granting their assignment to OPA. This is a more severe action that killing sessions, but it is a way to reduce that risk (and you could tie in a process to re-add the user to the group, perhaps with an access request and approval).

    Note that the mechanism shown below assumes the user is assigned to OPA via a group. If there was a direct assignment the workflows would need to change.

    The following shows the user flow and how it works behind the scenes.

    The User Flow

    We start with our user, Ivan ITPUser, who has logged into his Okta Dashboard and then launched his OPA session to access some credential like in the previous scenario.

    At some point during his session, ITP detects a risk and escalates the user risk level to HIGH. All of a sudden his OPA session disappears and is replaced by a Session revoked message.

    When he goes back to his Okta Dashboard and refreshes his session he gets a “Your session has expired” message and is taken back to the login prompt.

    He has been shut out of both his dashboard and OPA.

    He checks his email and sees the following telling him he has lost access to OPA.

    The risk change has revoked his Okta session and removed him from the group assigned to OPA, triggering a de-provisioning and session termination.

    What’s Going on in the Background?

    Let’s have a look at what has happened. Before the detection, the user had an Entity risk level of Low. He had access to the OPA Risk LOW group (from the first scenario) and the OPA Risk All group (which is how he is assigned to the OPA app).

    When ITP detects the issue, a series of events are written to the System Log.

    From the bottom up you can see the risk detected and (delegated) workflow initiated. There was a universal logout initiated and the user was removed from the group OPA Risk All (this was done in the workflow, we will explore this later). Removing the user from the group triggered a de-provisioning of the user from the OPA app.

    Note that the user reverts back to a LOW risk level as the remediation has run, so ITP considers the user risk is back to normal.

    Also, whilst the user loses access to OPA, any active SSH/RDP sessions to servers are not immediately impacted, but will be when the agent detects that the account can no longer access OPA.

    Okta/ITP Policy Configuration

    The ITP policy configuration is straightforward. There is a new rule in the Entity Risk Policy.

    This rule applies to all users of the OPA Risk All group. It will run for Admin Reported User Risk events where the Entity risk level is High and will Run a Workflow – OITP – Admin Reported User Risk. The rule was set to just trigger on Admin Reported User Risk as that was how we tested the mechanism. You could have other detections listed.

    The bulk of the work is done in the workflow, which we will look at next.

    Okta Workflows

    There is one main flow (the delegated flow called when ITP detects the risk) and two helper flows.

    We will focus on the main flow – OITP – Admin Reported User Risk.

    It is called like any other delegated flow, but ITP only passes the Okta User ID for the affected user. It then assigns two static values, one for the app ID of the OPA app in this environment and an administrator email for cc’ing on the email to be sent at the end of the workflow.

    Then it uses the ITP Connector Global Token Revocation action to revoke the Okta session token. This handles the Okta Dashboard session revocation.

    The remainder of the flow is focused on removing the user for any groups that assigns them to the OPA app.

    First it gets all groups assigned to the user in Okta; uses a helper flow to reduce that list down to the group ID, name and description; and then pulls out just the IDs (a list of text).

    Next it finds all the groups assigned to the OPA app and plucks out the IDs for them.

    We now have a list of IDs for the groups assigned to the user, and a list of IDs for the groups assigned to the OPA app. The intersection of these two lists are the groups that map this user to the OPA app. Note that there may be more than one groups granting access to OPA.

    A helper flow will process each of the matching groups in turn. It will remove the user from the group using the Okta connector action and then format that group into a HTML list item for the email to be sent.

    Finally it will get some user properties, then build and send an email to the user informing them of the groups they have been removed from.

    This concludes the exploration of the second scenario.

    Conclusion

    This article has shown two scenarios for using entity risk derived by Identity Threat Protection with Okta AI to control access into Okta Privileged Access.

    The first scenario leveraged risk-related groups pushed from Okta to Okta Privileged Access and assigned to different policies and rules to implement different controls on accessing resources. You might say that low risk users can access a resource with no additional checks, but medium risk users will need to meet a MFA requirement or high risk users will need to get the access request approved before accessing the resource.

    The second scenario leverages extend the Identity Threat Protection with Okta AI universal logout remediation to remove a users Okta Privileged Access session by removing them from the group(s) granting them access to the app.

    Both scenarios are implemented using Okta Workflows, and the article shows how they are implemented. They could form the basis of custom implementations in your environment.

  • RDP’ing with Microsoft Active Directory Accounts in OPA

    Okta is extending it’s Okta Privileged Access capabilities with Microsoft Active Directory accounts by adding the ability to leverage them in direct RDP connections. This means it now supports two use cases with AD accounts – a reveal function where those credentials can be used (via copy’n’paste) to any AD-authenticated service, and the new direct RDP connection with AD credentials.

    This article introduces the new feature.

    Introduction

    Okta Privileged Access (OPA) has long had the ability to manage SSH and RDP sessions to standalone servers. Recently Okta introduced the first phase of the AD integration for OPA, where it would discover and store AD admin and shared credentials so they could be revealed and used to login (a copy’n’paste model). The new feature ties these two capabilities together – you can now RDP to a Windows domain-joined server using AD credentials stored in the OPA vault. The user does not need to see the AD password, the client will inject it for them and OPA can rotate the password after use.

    Bringing Servers and AD Accounts Together

    This is the first release of OPA that sees two different resource types combined to provide a single capability. The components are shown in the following figure.

    At the top is the AD integration, where the existing Okta AD Agent in the domain will consume AD users and groups and Okta will store them. The new OPA integration will pull select AD users into OPA and store them as AD Account resources in the vault.

    At the bottom is the traditional OPA server integration, where installing and enrolling the OPA Agent on a server will result in a Server resource in OPA. These server resources could be in the same project / resource group as the AD Account resources or seperate ones.

    Note that the OPA Agent must be deployed to any member server that you want to connect to. This and other requirements are listed later in this article.

    Finally a Policy Rule must be defined to allow the AD Account resource to be used for RDP and which servers the RDP can be applied to. For those familiar with OPA policy, this is effectively allowing the OPA Client to access the AD Account resource, get the password and use it to RDP to the server. We will give an example of this configuration later in the article.

    The User Experience

    The user expreience to RDP to a member server using a domain account is basically the same as RDPing to a standalone server with an account.

    In the OPA Console you select the Servers menu item (which is the default anyway) and select the member server name. It will then show the Accounts you can connect as. The following shows three DBA accounts from AD that could be used to connect to this server.

    Notice that exclusive checkout can be applied to AD accounts.

    When you connect, you are logged in as the user you selected. No password is entered anywhere in the process.

    Connecting from the command line is similar. In this example there are four servers this user can connect to, one domain-joined server (MEMBER1) and three standalone servers. Connecting to the member server will show the same three DBA accounts.

    With one of the account selected, the RDP client will launch and log the user in as that account. Again, no password is specified.

    Configuration

    Let’s explore the configuration of the feature, including AD accounts, clients, servers and agents, and the OPA configuration.

    Constraints with the Current Release

    This first release (Aug 2025) has some constraints:

    • You cannot RDP to a domain controller yet, only member servers

    • Routing via the gateway is not yet supported

    • This means there’s no session recording for RDP to member servers with AD accounts

    These will be addressed soon.

    AD Users and RDP

    This mechanism uses the AD integration that was introduced earlier this year involving the AD Agent and Okta. There is no minimum requirement for AD Agent version.

    An additional requirement that may not have been needed with the earlier “reveal” approach to AD credentials, any AD account that you plan to RDP to a member server with must be in a group that allows that account to RDP to the member server. This is in the domain configuration and is not driven by OPA.

    Clients

    The OPA Client on your workstation must be at 1.94.0 or greater.

    Servers and Agents

    To RDP to a member server, the OPA Agent must be installed (v 1.94.0 0r higher). It is a standard agent install on Windows, the same as would be done for a standalone Windows server. The agent must be enrolled into a Resource Group / Project (see below).

    As with all OPA Agents, it listens on port 4421. This port must be open to where the Clients are running. This port is unlikely to be open by default.

    Resource Groups and Settings

    Both the AD account and server resources are managed in Resource Groups and Projects within them. There is no change to this. You could manage the AD accounts and servers in separate RG / Project, the same RG and different projects or in the same project.

    We will assume that the AD integration has been done and you already have AD accounts sitting in another RG / Project. For the new AD domain-joined (member) servers we will create a new RG and Project.

    The new servers will go under the Servers Resource Type in the Project. In this case one server has been enrolled into the Project.

    The Settings tab for this Project is the same as for any other Project.

    Some thoughts on the settings in the context of a member server:

    • Enrollment Tokens – you will need an enrollment token to enroll the agent

    • Account Discovery – as we are using domain accounts not local accounts, you do not want to enable this (unless you are also managing local accounts, but we will ignore them for this article)

    • Password Settings – as the password rotation is done via the AD integration, this setting is irrelevant

    • SSH Configuration – as normal

    • Gateway Selector – for this phase of the rollout (Aug 25) gateway integration is not supported, so should not be enabled.

    • Account Lifecycle – as we are using domain accounts not JIT creating local accounts, you do not want to enable this (unless you are also allowing JIT local accounts, but we will ignore them for this article)

    • Checkout Settings – as normal

    It’s worth noting that you will not see any AD accounts show up in the Checked Out Accounts view. This is only for discovered/imported local accounts.

    Nor will you see Local Accounts (unless you are also discovering/importing local accounts).

    Next we’ll look at the policies and rules to use the AD accounts and servers.

    Policy and Rules

    The Policy definition is the same as for any other polices, with name and description, resource group assignment and principals.

    It is worth noting that you might have your AD accounts in a different resource group to your member servers. In this case you need to make sure the policy can see both.

    The Rule to allow RDP must a an Active Directory Account Rule, not a Server Rule. This is because you are allowing that Active Directory account to be used in a new way – to RDP to some servers.

    As with other AD account rules, you specify which AD accounts are in scope of the rule.

    There is a new permission for RDP access – RDP Session (note that the Rotate Password is another new feature not covered here).

    Selecting RDP Session opens another section on the form to allow you to specify which servers you can use the account(s) on.

    In the example above there is a member server (MEMBER1) and a local server (opa-demo-windows). Obviously you wouldn’t select a server where you can’t use that domain account (like a local server or an account from a different domain). This may dictate how you separate resources into Resource Groups.

    The remainder of the rule is the same as for every other rule.

    With that rule and policy saved and enabled, any user in the groups defined as a principal to the policy (PAM Windows Sysadmins) can RDP to the member server (MEMBER1) and select any of the three AD accounts to connect with (the three DBA accounts).

    Conclusion

    Combining the new AD integration of OPA with the long-standing server access RDP mechanism significantly extends the usefulness of OPA for organisations that have large AD implementations but need to reduce the risk of administration of the member servers. This new feature means users can authenticate to Okta as they do for their SaaS SSO, be prompted for MFA as required, and can connect to domain-joined servers with AD credentials without needing to know the passwords. Combined with the existing AD integration, where credentials can be revealed to those allowed and rotate after use, it significantly reduces the attack surface for AD server administration.

  • New Access Certification Auditor Reporting Package in OIG

    Okta has just released a new Early Access feature for Okta Identity Governance Access Certifications – the Auditor Reporting Package. This new feature significantly expands the usefulness of OIG Access Certification campaign reporting.

    Introduction

    When Okta Identity Governance (OIG) was released with Access Requests and Access Certification, there was reporting included. It was available under the Reports menu on the Okta Admin Console. For access certification there were two reports, a Past Campaign Summary (listing a summary of all closed reports) and Past Campaign Details (details, including all the review line items, for a specific report).

    There reports supported extensive filtering and export to CSV. However customer feedback was that it wasn’t enough to address auditors needs (often there was a lot of back-and-forth between the Okta admins and the auditors to get the data needed) and timeliness of report availability could be improved.

    To respond to these concerns, Okta has developed the Access Certifications – Auditor Reporting Package. It has more data fields, more granular reports and improved timeliness.

    Enabling the Feature – Globally and in Campaigns

    This new feature is currently in self-service Early Access. This means it needs to be enabled under the Settings > Feature menu items in the Okta Admin Console.

    This will enable the feature across OIG. However it needs to be enabled for any access certification campaign you want it to apply to.

    Note that this means the campaign will contribute to the new reporting package. It will not affect it appearing in the standard access certification reports.

    The New Reporting Interface

    The reporting in the new feature is now part of the Identity Governance > Access Certifications part of the Admin Console.

    Finding the Reports

    When you go into Access Certifications you will see a new tab called Reporting.

    Selecting this will show all campaigns that have the Create auditor reporting package checkbox selected.

    Report Status

    The reporting view has a table with the campaigns, listing the name, id, start and end dates, report status and a column of Generate reports buttons.

    The Report status shows where the campaign is in its lifecycle and the reporting status:

    • Campaign created with the auditor reporting checkbox selected

    • Campaign launched

    • PENDING CAMPAIGN CLOSE status – campaign is still open

    • Campaign closed

    • Complete manual remediation

    • PENDING REPORT GENERATION status – waiting for “Generate reports” to be clicked

    • PENDING MANUAL REMEDIATION status – waiting for “Generate reports” to be clicked + confirm manual remediation completed

    • GENERATING REPORTS status – reports being generated, one or more may be available

    • READY FOR DOWNLOAD status – all reports are ready for download

    As with the standard campaign reports, you cannot generate/download reports whilst the campaign is running, only when it has completed (i.e. reached the end date or was manually ended).

    There is a background process that needs to run to generate reports, and this can only occur once the campaign has ended (showing one of the PENDING status’).

    Generating reports

    You click the Generate reports button to start the background (asynchronous) generation process.

    A popup dialog box will remind you of the constraints around the generation process.

    Downloading reports

    When you expand the campaign (down arrow) you will see there are five different reports, each with a Download button. When a specific report is available it’s Download button is enabled.

    The reports are based on different phases of a campaign:

    1. Campaign scope. To confirm complete campaign scope. Allows auditors to determine what was being certified.

    2. Resource access – Campaign launch. To capture application access at start of campaign. Allows auditors to confirm is what was being certified (1) match application access (2).

    3. Resource access – Campaign complete. To verify campaign decisions (users approved/revoked). Allows auditors to determine what decisions were made – especially who was revoked.

    4. Campaign actions. To verify application access (post remediation). Allows auditors to determine if the individuals/access marked for removal actually get removed. It is comparing the pre-campaign access (2) to post campaign access (3).

    5. Resource access changes – Campaign launch to campaign complete. To verify access changes between launch and campaign close by looking at syslog entries. Allows auditors to account for any discrepancies in reports.

    Clicking the Download button will download the specific report to your local machine as a CSV file.

    Conclusion

    Whilst there has been access certification reporting available in OIG since the product was released, customers wanted more. This new feature is geared towards the auditors. It’s not meant as a tool for managing in-flight campaigns, but rather a means to provide more targeted information for preparing for audits in a more timely manner.

  • Role Analysis with Okta ISPM – Are My Groups and Roles Being Used Effectively

    Okta Identity Security Posture Management (ISPM) performs analysis on groups and roles which can be used to tune access via groups/roles and reduce risk. This article explores how to use ISPM for role analysis.

    Background

    Roles and a role-based identity system have been the Holy Grail for identity governance and administration (IGA) practitioners and products for a quarter of a century. We’ve been taught that if we can just put everyone into roles and those roles dictate what access you have, life will be simple. Many IGA vendors offer tools for role management, role mining and role certification. Auditors constantly focus on roles for reducing risk.

    But the reality is that most organisations cannot spent the time and money to do a full role mining exercise, and often after many dollars and months, the roles have changed as the business has changed, so the role exercise was pointless. In my 25 years of working in identity, I’ve only seen one major organisation get to 100% of access controlled through roles. The reality for everyone else is that there will be a mix of common high-level roles with the remaining access managed through access requests and access certification.

    Can we reduce access-related risk without doing a full-blown role mining and definition exercise? Yes. You can look at the user groupings for access (groups/roles in identity management systems and other apps) and see where they are over permissioned or don’t need to have all those users in them. This is where ISPM comes in.

    Using ISPM for Group and Role Analysis

    Okta Identity Security Posture Management (ISPM) helps you take control of identity and access sprawl in your organisation by uncovering hidden risks, prioritising critical threats, and guiding remediation. It uses a graph engine to correlate users, their groups, the apps they are connected to and resources in those apps. It also looks at usage. Combined, this gives a view of the groups and how well they are being utilised.

    The Inventory View for Groups and Roles

    A key view in ISPM is the Inventory view which presents risk-related information for the different objects known to ISPM, including groups and roles.

    It shows all the groups and roles discovered on the connected systems, such as identity providers (like Okta and Entra ID), apps and cloud services.

    It has summary widgets to show the Groups by sources, Groups least privilege and Types.

    The main section of the view is a filterable table of the groups.

    In addition to the name, type (group or role) and source, it lists:

    • Members – the number of members in the group

    • Apps – icons showing the apps attached to the group (hover for more details)

    • Utilization information – see the next section

    Clicking a row will open up a view for that group.

    This would be used when deciding what users or apps to remove from the group. You can also click on an account to see more information about that account.

    As with all views in ISPM, there is the ability to export the data to a CSV or PDF for offline analysis.

    Understanding Group and Role Utilization

    The Groups least privilege widget shown above provides a summary of the “underutilization” of the groups. There are three items:

    • Underutilized – this represents the number of groups that are connected to one or more applications, but that the users in that group have not connected to any of those apps in the last three months. This means these groups are potentially pointless. In the examples above there are 30 groups/roles out of a total 0f 330 (9%) that fit this category.

    • Underutilized app assignments – this represents the number of groups where one or more of the connected apps haven’t been accessed by the users in the group in three months. This means that these groups potentially don’t need to be connected to the identified apps.

    • Underutilized memberships – this represents the number of groups where one or more members in the groups have not accessed any app the group is connected to in the last three months. This means those users potentially don’t need to be in the group.

    Clicking any of these will apply filters to the groups view. We will use this for some examples below. These will use Okta apps, groups and accounts and show working in the Okta Admin Console, but a similar approach could be used for other apps admin consoles.

    An Example – Managing Underutilized App Assignments

    Lets walk through an example of using the underutilized app assignments widget to manage a group. In our system there are 34 groups in this category (>10%) and worthwhile investigating.

    We start by selecting (clicking on) the Underutilitized app assignments item in the widget.

    This applies a filter of Unutilized Apps: More than 0. If we hover over the app name in the , it shows the relevant app that has not been accessed by any of the users in that group in three months (in this case the Okta OPA – Entitlement app).

    How do we resolve this risk? We can remove the group from the app (or the app from the group) in Okta.

    Opening the app in the Okta Admin Console, you can see the group assignments. In this case there is the PAM All Users group and two groups sourced from AD. You can select the “Kebab menu” icon and click the Unassign option.

    This will remove the group from the application but not touch the group or its members.

    You may notice an Access Certification box to the right of the group list if you have Okta Identity Governance (OIG). OIG also performs some usage analysis on users and apps. In this case it has detected there are 17 users who have not accessed the app in 90 days.

    It allows creation of an access certification campaign to allow the users manager to decide if they should retain access to the app. This might be useful if you want to look at specific users assigned to the app rather than removing the whole group (we will look at underutilized group membership next). Note that this access certification function is only available for apps in Okta where OIG is used. cFor more information see Preconfigured Access Certification Campaigns in Okta Identity Governance.

    With that group unassigned from the app, the next time the ISPM load and analysis runs, you will not see the app show up as an underutilized app for that group.

    An Example – Managing Underutilized Memberships

    Underutilized memberships represent group (or role) members who have not accessed any of the apps the group is mapped to in the last three months, meaning perhaps they shouldn’t be in the group. Lets use a similar example to above.

    As before we can start by clicking on the Underutilized memberships item in the widget.

    This will apply a filter of Unutilized Memberships: More than 0 to the group list view.

    We can see there are 17 users and 9 of them are unitilized. We could click on the group name or member count to see the full list of accounts in the group with their app utilization. Or we could click on the count in the Unutilized Memberships column. This will show the low (<10%) utilization members in a slide-out panel.

    You could then go into the Okta Admin Console and open up the group.`

    Then using the ISPM list, you can manually remove the users from the group.

    Some additional thoughts on approaching the cleanup:

    • What about if you have a large list? You could potentially export the list to CSV then use a workflow to go through the list and automatically (API/Okta Connector cards) remove the users from the group.

    • You could also drill into each user in that slide-out list (or the group drilldown) in ISPM. If there are issues on the account (e.g. unused account or no MFA) you may be able to go directly to the app admin console page via the Remediate button beside the issue. But otherwise you need to go to the app admin console (like Okta) manually.

    This concludes the two examples on how to use the inventory view to explore underutilized groups. You could use different filters to slice and dice how you attack the problem, but the goal is to reduce the number of groups containing underutuilized app assignments and users, so that only the people that need access have access, and only the access they need.

    Using the Graph View to Identify Unneeded Group Memberships

    Up to this point we have looked at the Inventory view of groups (and roles) and how you could use that to work through the groups and remove unutilized app assignments or membership.

    There is another tool within ISPM that can also be used to identify redundant group app assignments – the Access graph. The access graph shows the relationships between users, their IdPs and accounts, groups, apps and resources. This includes the ability to drill into a set of app assignments and see what group (or individual) assignment applies.

    The following figure shows the Access graph for a user Ali Lesch and we have expanded the app assignments for one of Ali’s accounts. It shows a spiderweb view of the connections between the groups that account is in and the apps.

    In many cases there are two groups granting access to an application. This means there is redundant unneeded access via groups. It may be that those groups don’t need access to apps, or that the user does not need to be in all of those groups.

    Clicking on any of the groups in this view will take you to the Group view for that group, similar to below.

    From here you can perform utilization analysis as before.

    This is more of an issue driven approach – looking at users with issues and drilling into specific group mappings. Whereas the approaches described earlier in this article are a more systematic approach to analysing the groups.

    Conclusion

    Analysis of roles continues to be a challenge for many organisations. The mantra of everything managed through roles isn’t practical for most organisations. Role mining and definition tools provided by many of the IGA vendors can be overwhelming and ineffective with real world data.

    A better approach is to balance role-based assignment with request-based assignment. Where roles (and groups) are used to assign applications and rights, Okta Identity Security Posture Management (ISPM) provides effective tools to identify groups and roles where there are underutilized membership and underutilized app assignment which can be removed to reduce the risks associated with group (or role) based assignment.

  • New Delegate Feature in OIG

    Okta has recently released a delegate feature in Okta Idenity Governance. This feature allows all governance activity, such as reviewing access requests or access certifications, to another Okta user (optionally for a set period). This article introduces the new feature.

    Introduction

    We all need to go on leave or take time off. So what happens to the work we have to do when we’re away? We delegate it to someone else. Okta has recently released a Delegate feature into Okta Identity Governance (OIG) so any governance-related functions, like reviewing an access request or access certification campaign, can be reassigned to someone else in Okta.

    This is an Early Access feature that can be enabled in the Features menu in the Okta Admin Console for OIG customers.

    Setting a Delegation

    As an Administrator

    Setting up a delegation for a user by an administrator is done through the Admin Console by going to a users profile and going to the new Delegate tab.

    You can only have one delegate assignment at a time and if none are set, you will see No delegates assigned.

    Clicking the Assign a delegate button allows you to assign a delegate, set a note to go out in the email to the delegate, and optionally a start/end date and time.

    Once it’s set, you will see it under the Delegate tab.

    The delegate will get an email with the details.

    Delegations can also be modified or deleted through the same Delegate tab.

    As a User

    A user with access to the access certification tile on their dashboard, can open it and then click the pulldown menu under their name and select the Delegate option.

    Similarly the Access Request tile, when opened has the same pulldown option to select the Delegate option.

    Both approaches will present the Delegate function in the Dashboard and a delegate can be assigned as in the admin use case above.

    Now that we’ve seen how to set it, lets look at how it appears for the delegate.

    Access Requests as the Delegate

    For the Access Request scenario, I have set an approval to a user who has delegated their OIG functions to another. When a user requests access and looks at the approval step, they see that the approver is the delegate not the original approver and the original approver is shown in brackets (in this case it’s showing “You” because the user raising the request was the same user to approve, just for the sake of the screenshot).

    When the delegate goes into the Access Requests app they will see the new request.

    When they drill into the request, they will see the approval step set to themselves with the original approver shown in brackets.

    You see similar messages for the newer Conditions and Sequences as you do for the older Request Types (shown above).

    Access Certification as the Delegate

    For Access Certifications, I defined a simple campaign and set the reviewer to myself.

    When the campaign launched, you can see all the reviewers are now set to the delegate.

    When that delegate goes into Access Certifications, they see the campaign and users for them to review.

    Reviewing campaigns is the same process irrespective of whether it’s the original reviewer or delegate.

    Delegate APIs

    The APIs to see and manage delegates (aka delegate appointments) are spread across the OIG API documentation, so are summarised below.

    Set a Delegate Appointment

    There is a Principal Settings API with a Update the principal settings endpoint that is used to set a delegate appointment.

    /governance/api/v1/principal-settings/{targetPrincipalId}

    From the example, passing the following body into the endpoint

    will result in a delegate appointment.

    List all Delegate Appointments

    There is Delegates API with a List all delegate appointments endpoint to view all current delegate appointments:

    /governance/api/v1/delegates

    This will return a list of all delegations.

    Manage Personal Delegate Appointments

    There is an End user My Settings API with three endpoints:

    Use of APIs in Workflows

    Currently there are no corresponding action cards in the Okta Connector in Workflows. You need to run these API endpoints using the Custom API Action card.

    Conclusion

    The ability to delegate governance functions in OIG, such as access request and access certification reviews, has been a longtime ask for OIG customers. This feature is now in Early Access and this article has provided a brief overview of how to set up and use delegations.

  • A Set of Utilities for Secrets Management in OPA

    In a recent engagement a customer raised issues around management of secrets and folder,s and associated policies and users in their Okta Privileged Access (OPA) deployment. In the spirit of the mantra of Mr Bigweld in Robots “see a need, fill a need“, I set about writing some utilities to help manage larger, more-complex Secrets deployments. This article summarises what I’ve built.

    Background

    Secrets is a resource type in Okta Privileged Access (OPA) which has been with the product since it became Generally Available. The Secrets capability involves folders that can be applied in a hierarchy with policies applied to different levels of the folder tree and leveraging inheritance. This makes it very flexible where different folders can be used and managed by different parts of a business.

    But with flexibility comes potential complexity. Customers with large/deep folder structures face challenges in visualising the structure and where policies are applied. As an administrator there is currently no tool to visualise, nor is there a way to preview the access for a specific user or a resource (folder / secret). Whilst Okta is looking to address these as the product develops, I wrote a set of utilities based in Okta Workflows as a stopgap approach.

    The Utilities (Reports)

    This solution involves four utilities:

    1. A hierarchical (or tree) view of all folders and secrets, showing where policies and rules are attached.

    2. A user access view showing what folders and secrets a specific user can see.

    3. A secret search mechanism

    4. A resource access view showing who has access to a specific folder or secret

    These are implemented as Delegated flows that appear in the Okta Admin Console.

    They all produce reports via email.

    Report 1 – Folder Hierarchy with Policy Rules

    The first utility will produce a hierarchical (or tree) view of the folder/secret structure.

    It also shows where policies/rules are specifically attached (secret policy rules are attached to folders and/or secrets).

    Report 2 – Access for a User

    The second utility takes a OPA user and performs a search across all folders and secrets to see where they have access, and what type of access.

    It does allow for the policy inheritance model – where there is no policy rule specifically attached it will show inheritance from the next level up. It also shows the permissions from that rule and any conditions (MFA, Access Request).

    This uses a temporary table in Workflows and this table is exported and sent in the email, so it can be reviewed in a spreadsheet tool like Excel.

    Report 3 – Find a Secret

    The third utility is a search utility. Given a string it will search through the secrets to find a match.

    Note that this is somewhat redundant as Okta has released a secret search function that operates within the OPA UI and is much more usable.

    Report 4 – Access to a Resource

    The last utility will take a secret or folder name and produce a list of policy rules that apply, and thus the privileges, conditions and groups and users.

    This makes it easy to see if the folder or secret has the access configuration you are expecting.

    How It’s Built/Delivered

    The solution is implemented in Okta Workflows, with tables used to build/store all the data needed for the reports, flows to load the tables and flows to leverage the data and produce reports.

    Connectors

    There are two connectors used: the Okta Privielged Access connector and a Google mail (GMail) connector.

    Tables

    The solution requires data pulled from OPA via multiple APIs and joined together. The tables are a poor mans implementation of a RDBMS with data tables and relationship tables. It stores users, groups, folders, secrets, policies and rules and some of the relations between them.

    The most significant table (PolicyRulesAttach) shows the items (folders, secrets) with the policy rules attached and a breadcrumb showing the path to the item. Accessing the list sorting by breadcrumb is used to show the hierarchy.

    There is also a temporary user access report table (tmp_UserAccessReport) used to show the folders and secrets a specific user can access.

    LOAD*** Flows

    There are a series of flows run to load the tables using APIs into OPA:

    • LOAD1* – Get all secret folders and store in tables

    • LOAD2* – Get all secrets and store in tables

    • LOAD3* – Get all secret policies and store in tables

    • LOAD4* – Build policy to folder mapping, including pulling the secrets and folders into the table shown above

    • LOAD6* – Get all policy principals, i.e. the groups attached to policies and the users in those groups

    These are run prior to running any reports (LOAD10, LOAD20, LOAD30, LOAD40, then LOAD60).

    REPT*** Flows

    The report flows generate the four different reports. They are run as Delegated Flows from the Okta Admin Console (and thus subject to the Okta Admin model).

    • REPT1* – Produce a folder hierarchy with attached policies. This is passed the recipient email in the delegated flow, and then produces an email report with the hierarchy of folders and secrets (with indentation) and the policies attached.

    • REPT2* – Produce a user access report. This is passed an OPA username (such as wendy.winadmin) and the report recipient. It will identify the users groups, the policies the groups are attached to, the rules in those policies and the resources (folders, secrets) those rules are attached to. The results are written to a table and that table sent via an email attachment.

    • REPT3* – Product a report of secrets matching a string. This is passed a search string and a recipient email, and it searches through all secrets to find a match anywhere in the secret name. The results are emailed.

    • REPT4* – Produce a resource access report. Given a resource (folder or secret) name, find all the policies and rules than apply, including the permissions, conditions and uses/groups for that policy rule. The results are emailed.

    There is no dependency between these. Any of the reports can be run as needed (as long as the data has been loaded into the tables by the LOAD** flows).

    UTIL*** Flows

    Finally there are a set of utility flows used by multiple other flows to perform mundane functions like building the policy rule name string.

    This concludes all of the components in the solution.

    Conclusion

    As use of Secrets within Okta Privileged Access becomes more widespread and the folder structures become bigger and more complex, additional capabilities are needed to view and manage the folders, secrets, policies and rules, and users. This article has presented a set of utilities implemented in Okta Workflows that can help manage complex Secrets deployments.

  • ISPM Architecture

    This article provides a brief introduction to the architecture of Okta Identity Security Posture Management (ISPM).

    The following figure provides an overview of the architecture.

    We will break it up into the Input, Service, Console with Users/Roles and Output.

    Input

    ISPM is fed from different sources. The main source is from other customer systems, such as identity providers (currently Okta, MS Entra ID and Google), cloud platforms (AWS, GCP and Entra ID), and SaaS applications. The Integration Guides page in the product docs list the currently supported sources. These are API-based integrations.

    The other source is industry context from open-source information and threat intelligence. This provides external information, such as breached account context.

    Service

    After an initial bulkload, the ISPM cloud service will consume identity information on a daily basis. It normalizes and contextualizes that data, performs risk classification on the usage analysis, and prioritizes identity issues based on attack chains and consolidated context. Using graphical visualization and reporting capabilities, the centralized platform helps you instantly understand the biggest gaps and risks in your organization. It leverages a graph engine to maintain the object relationships.

    Console with Users/Roles

    The web-based ISPM console is part of the ISPM service. It presents multiple view of the data held in the service:

    • A dashboard – a summary view of the identities and their risks

    • The issues – a prioritised view of all identity issues

    • The inventory – view of the different objects (like users, accounts and apps)

    • The controls – issues mapped to compliance framework controls

    • Settings – for configuration of the service

    These views are used to manage the identity security posture.

    There are users defined in ISPM. They may be directly defined, or SSO in from an IdP such as Okta or Entra ID. These users are assigned different roles: Super administrator, View and dismiss issues (for all or some sources), and Integrate sources.

    Output

    Output from ISPM comes in two flavours – some actions can be performed automatically when a issue is detected (on the daily load) whereas others are human driven via the Console.

    The detection-driven integrations are:

    • Create a ticket in a ticketing system (like Jira and ServiceNow)

    • Send a message to a messaging system (like Slack)

    • Perform some bespoke automation via a webhook (like calling an Okta Workflow)

    These actions could be for all or a select set of issues.

    From within the console remediations can be performed on specific issues. These include:

    • Raising a ticket (Jira or ServiceNow)

    • Sending an email

    • Sending a message (Slack)

    There are also reports that can be downloaded (csv or pdf) from most views in ISPM. Finally there is an executive report that provides a summary of your ISPM status.

    This concludes the architectural overview of ISPM.

  • New Okta Group Push API

    If you have been working with applications in Okta for some time and occasionally use the APIs (or Workflows) you would be aware that one glaring omission in the API library was an API to manage the Push Groups on applications. This has now been addressed with the Group Push Mapping API.

    The Group Push Mapping API

    We have had APIs to manage groups and applications in Okta for a long time, including the ability to assign users and groups to apps. But missing was an API to manage the push groups assigned to an app. This is addressed with the new Group Push Mapping API, which allows programmatic access to Push Groups mapped to applications. There are five API endpoints.

    The endpoints are self-explanatory: list all push group mappings for an app, create a mapping for an app, get details of a specific mapping for an app, update a mapping for an app and delete a mapping for an app.

    For example if I wanted to see all groups mapped as push groups to an app, I would make a call like:

    /api/v1/apps/0oa7l040g0UbnhVtp1d7/group-push/mappings

    This will provide a list of objects describing each of the push groups.

    How can we use these? Let’s look at an example.

    An Example With Okta Privileged Access

    Okta Privileged Access (OPA) uses groups pushed from Okta to define administrative roles and policy membership. Thus the group membership is managed in Okta, but what users in that group can do in OPA is defined by what those groups are assigned to in OPA.

    Let’s look at an end-to-end example using Okta Workflows. I have a requirement to be able to aurtomatically create a secrets folder in OPA for a new team and have that team assigned to manage secrets in that folder. This means I need a new group in Okta for that team, that new group assigned as a push group to OPA in Okta, a new secret folder in OPA and a new policy to allow that new group to manage secrets in that new folder in OPA.

    So the steps are:

    1. Create a new Secret Folder in OPA,
    2. Create a new Group in Okta,
    3. Assign that new group as a push group on the OPA app in Okta, and
    4. Create a new Secret Policy in OPA and assign that group to it

    This is done in a series of helper flows under a single main flow. It sets some arguments (including the group name) and then calls four flows correpsonding to the steps above, passing in the arguments from the initial assignment or previous helper flow calls.

    The first helper flow (MAIN11 in the pic above) will create the new folder (based on the group name) in a standard top level folder. This is using the Create a secret folder OPA API endpoint with the OPA Connector Custom API Action card.

    The second helper flow (MAIN12) will create a new group in Okta and assign a user to it. This is using the standard Create Group and Add User to Group cards in the Okta connector.

    The third helper flow (MAIN13) is using the new API to assign the new Okta group to the OPA application. It uses the Create a Group Push Mapping API endpoint with the Okta Connector Custom API Action card.

    The last helper flow (MAIN14) creates a new Secret Policy and assigns the new pushed group as the principal for the policy. This is using the Create a Security Policy API endpoint with the OPA Connector Custom API Action card.

    Thus we have automated the entire process of adding a new group, assigning it to the OPA app, creating the new folder and assigning policy to it for the new group.

    Having an API to manage group push mapping is something that’s been asked for by customers for some time and opens up a lot of exciting automation use cases that were missing this critical piece before.

  • The New Unified Requester Experience in OIG

    This article introduces the new Access Requests – Unified Requester Experience that is currently rolling out as an Early Access feature in Okta Identity Governance (OIG).

    The Background

    As Okta was building its new Identity Governance and Administration (IGA) product, it acquired a company to provide what would become the Access Requests component of Okta Identity Governance (OIG).

    With the early Access Request capability, you built Request Types to be the approval/provisioning flow for any access request. These Request Types were accessed via the Access Request portal (SSO’d to from the Okta Dashboard).

    After going GA, Okta looked at improving the Access Requests mechanism to provide a more intuitive and user-friendly way to request access. This resulted in what was called the Resource-centric Access Requests (or RCAR). It comprises Conditions tied to applications and re-usable Sequences that are maintained in Okta but run in the Access Requests engine.

    The requester interface for these was hooked directly into the Okta Dashboard.

    It also allowed for the older Request Types to be accessed via a More items link.

    Customers adopted the new Conditions and Sequences mechanism, but also continued to use the older Requests Types mechanism to address use cases that the Conditions and Sequences could not yet address. But this resulted in two different requester interfaces and confusion.

    The Unified Requester Experience

    To address this, Okta has released a new Early Access feature called Access Requests – Unified Requester Experience.

    This new feature will consolidate all access requests, both Request Types and Conditions and Sequences, into the one UI under the Request Access function in the Dashboard.

    Note that the icons for the Request Types are based on the names of the requests and aren’t configurable like the conditions. Also management of the two different types of requests has not changed.

    This unified view provides a much better experience for requesters where organisations have a mix of the older Request Types and new Conditions and Sequences.

  • New Secrets Search Function in Okta Privileged Access

    Okta has introduced a new search function for Secrets in Okta Privileged Access (OPA).

    When an OPA user goes to the Secrets menu item, they will see a new search option.

    Typing in a search argument will show matching secrets with the secret name, Folder hierarchy (clickable breadcrumb), Resource Group / Project and Description.

    You can directly access the secret from the search result, or click any of the breadcrumb items to see the folders.

    The search uses a similarity function to catch typos (aka fuzzy search), but you need to be aware that you might get unexpected results. For example I know there’s no secret with “fred” in it’s name or description, but the search will match on parts of the search argument, like “red”.

    Also, if the secret is “hidden” behind a policy control, like MFA or Access Request, it will not show up in the search results.

    You can fix this by creating another policy rule that allows “List Item” access at the same level as the rule(s) applying MFA or Access Request. For example, I have two rules applying controls to accessing secrets in two folders (one applying MFA and another applying Access Requests). Searching for secrets will ignore those in the two folders because they are behind controls. However if you create additional rules to allow List Item to those folders (without MFA or Access Request), the search function will see the secrets in those folders.

    This feature is a welcome addition to OPA for customers managing a lot of secrets across a complex folder structure.

  • Privileged Access Management for Microsoft Active Directory with Okta

    Microsoft Active Directory is pervasive across industry, and thus a common target for hackers, particularly with the abundance of privileged accounts. In this article we look at how the Okta Workforce platform can use different approaches to managing privileged access and reducing the risk of these accessed. It includes just-in-time provisioning of access and dynamic access to admin accounts.

    We will start with an overview of the approaches and then explore each with examples, before concluding with a comparison of them.

    Overview

    Whilst there are many ways that Okta can manage AD users and groups, there are three basic approaches that we will look at, as shown in the following figure.

    The three approaches shown above are:

    A. Managing AD Group Memberships involves Okta owning the AD groups and pushing membership changes to AD. It would be combined with access requests for dynamic allocation of users to the groups and timers in the request flows to automatically remove access.

    B. Controlling Access to Individual Admin Accounts involves Okta Privileged Access taking ownership of the users individual (secondary) admin accounts and controlling the passwords, so that a user can only use their individual admin account after they’ve followed a reveal process.

    C. Controlling Access to Shared Admin Accounts is similar, except that the shared admin accounts are managed by Okta Privileged Access.

    The three approaches have different benefits and challenges, that we will explore later in the article.

    A. Managing AD Group Membership

    The first approach leverages both core Okta functionality with AD Directory Integration with the Okta Access Request mechanism. It manages group membership where those AD groups would be mapped to permissions in AD.

    The Approach

    In this approach the AD Agent is deployed to a domain tied to a Directory Integration in Okta. The groups in AD are already mapped to permissions in the domain, we are just managing the membership of those groups using Access Requests in Okta Identity Governance.

    Currently this requires Okta-mastered groups pushed to AD and mapped to permissions there. There is a new feature, called Bidirectional Group Management with Active Directory, where AD-mastered groups can be managed in Okta, but this feature is not available in Access Requests yet.

    The membership of these groups would be managed through Access Requests, which provides a Just-In-Time access approach – access granted as needed and automatically revoked after a set period of time.

    It’s worth noting that this approach supports use of the Access Certifications function in Okta Identity Governance to review/cleanup AD group memberships.

    An Example

    Let’s look at an example. We have a user, Denise DBA who has an AD-authenticated user in Okta but not additional privileges in AD. She needs to perform some changes on one of the production databases, where access is tied to a specific AD group.

    In her Okta Dashboard she clicks the Request Access button and sees the Privileged Groups tile.

    She selects this and is given the option of two AD groups, a production one and a test one. She selects the production one.

    She completes the details of duration, justification and ticket number. The duration will be used as a timer, whereas the other fields are to help the reviewers decide whether to allow the access (and this information is stored in the audit trail).

    She submits the request and the request flow routes to her manager. It could be via an email to go to the Access Requests UI or via Slack/Microsoft Teams. The manager reviews the request and approves.

    This flow is configured to go to her manager and also the service owner. Once both have approved, she is added to the prod DBA group in Okta.

    As this group is a Push Group on the Directory Integration, this membership change is pushed to AD.

    If Denise now logs into her AD-authenticated service (like her DB client) she will have the privileged rights that that group giver her.

    As the request flow has a timer built in, when the time period expires (recall she selected two hours), the flow will continue and automatically remove her from that group.

    This is a great just-in-time approach to granting privileged access in AD. It does rely on having the groups pre-defined in AD (and currently they need to be Okta-mastered groups pushed to AD, but AD-mastered groups will be available soon). The one downside of this is if you have a forest where replication of groups can be slow.

    B. Controlling Access to Individual Admin Accounts

    The next (and following) approach uses the new Okta Privileged Access AD integration feature. With this feature AD admin accounts are imported into Okta and the Okta Privileged Access (OPA) vault, where the passwords are rotated so that only OPA knows them. To access a domain service you need to reveal the credentials for the account, and after the account is used, the password is again rotated so it cannot be reused outside of OPA.

    There are two types of accounts, individual admin accounts and shared admin accounts. We are looking at the individual admin accounts (sometimes called secondary accounts) which is a standard model recommended by Microsoft – you have your ordinary AD account and an account you use for administration. The admin account would be statically assigned to groups and permissions in AD.

    The Approach

    In this approach the user in Okta checks-out their individual admin account and reveals the username and password. Depending on policy, there may need to be an Okta MFA response or an access request process similar to the above (JIT access request). The user then logs in as that account and can perform whatever functions the admin accounts’ groups allow.

    When the account is checked back in, based on a timer, manually by the user or forced by an administrator, the password for that account is rotated and pushed down to AD via Okta and the AD Agent. The password that the user last used is no longer valid.

    Note that this approach is not changing what the user’s admin account can do, it’s just controlling who can access this account and what controls are placed on the access.

    An Example

    In this case, Sally ServerAdmin needs to use her secondary account (S-sally@opademo.local). As it is managed by OPA, she doesn’t know the current password. She logs into her Okta Dashboard and goes to OPA. Under the My Privileged Access list is Active directory, where she can select from the Active Directory domains available.

    Within the domain, she has access to four accounts – three DBA shared accounts and her individual admin account, S-sally@opademo.local. She selects the latter.

    To use (reveal or show) the account credentials she will need to go through a MFA flow and then the account credentials will be checked out to her.

    She can then show the credentials, and copy and paste them into the appropriate domain login prompt for what she needs to do.

    Based on policy, she can only checkout this account for two hours. After this it will be automatically checked back in. Or she can view her checked out accounts and manually check it in (or an administrator can force the check in).

    When the account is checked in (on timer, manually or forced) the password is rotated. You can see the flow below, from revealing the password, through the check in and subsequent rotation and pushing of the new password to AD via the Agent.

    Whilst this approach provides controlled access to the individual admin account and forces users to go via OPA (as they won’t know the password otherwise) it does not dynamically manage the groups/permissions assigned to the individual admin account. Nor does it remove any standing privileges for those accounts.

    C. Controlling Access to Shared Admin Accounts

    This approach is virtually identical to the previous one, but uses shared admin accounts in AD instead of individual admin accounts.

    The Approach

    As before, this involves a user revealing the shared admin account details that are stored in the OPA vault. If required they complete an MFA flow or go through an access request process. Once revealed they can use the credentials to log into the domain and perform the functions assigned to that shared admin account.

    On check in, the password will be rotated by OPA and pushed down to AD via Okta and the AD agent.

    An Example

    Similar to the above example, Sally ServerAdmin needs to perform some work, but in this case she needs to access a production database as the production DBA account. This account is managed by OPA and she can select it from the domain in her OPA view.

    Policy for using this account has Access Request assigned. So she requests credentials.

    As we saw earlier it goes through an approval flow, with the reviewer seeing details of the request and then approving it. Again this could be in the Access Request UI or via Slack/Team if this is configured in Access Requests.

    Once the approval is done, Sally can reveal the account credentials and use them to access the database.

    As for the individual account, the account will be checked in on the timer (or manually by the user or forced by an administrator).

    This approach also involves a standing account in AD with standing privileges. It does not manage the groups/privileges assigned to the shared account. However a shared account like this is more likely to have role-specific permissions (e.g. all access needed to maintain a database) rather than whatever access is assigned to an individual admin account.

    Comparing the Approaches

    The first approach, where you are dynamically adding and removing ordinary users to/from AD groups that grant additional privileges, supports the zero standing privileges model. Users don’t have additional access until they are given that access, and it is automatically removed after a set period of time. Using an access request mechanism with approvers gives an auditable record of who was granted access and why. The downside of this is the AD-replication model where it may take time for changes to replicate between DCs. It also currently relies on using Okta-managed groups pushed to AD, so there is some set up work required. But overall it is a good approach to JIT access in AD.

    The second and third approaches are the same, but focused on different admin accounts in AD – the second is on individual admin accounts (secondary accounts) and the third is on shared admin accounts. Both require standing privileges assigned to those accounts via groups. Okta is not managing that assignment, there would need to be an additional mechanism to do this. Whilst individual admin accounts are tied to individuals, you need to assign all the admin permissions needed to that account. Whereas shared admin accounts can be role-based, such as DBA accounts or Web Admin accounts, with role-specific permissions assigned. This would be easier to manage. The concern with shared over individual admin accounts has been that you need to share the password around and don’t have line of sight to users performing actions. By applying the OPA controls, where the password for accounts is managed in OPA and rotated regularly so users don’t know them, mitigates that concern of shared over individual admin accounts. This makes using role-based shared admin accounts in OPA a viable alternative to dynamic allocation of group memberships.

    Either approach would reduce the risk of using privileged access in Active Directory.

  • Okta Privileged Access – Example Mechanisms to Export/View Session Recordings

    This article provides some example mechanisms that could be used to export and view the session recording files produced by Okta Privileged Access. There are two examples shown:

    1. A simple series of scripts that show the flow and commands to export and view logs, and

    2. An overview of a mechanism built by a former Okta employee to process Okta Privileged Access session recordings. It leverages an AWS S3 bucket and a custom web app to view the recordings. Note that this includes custom, and thus unsupported, components.

    These are provided as examples to show how you could implement a mechanism.

    Introduction

    Okta Privileged Access (OPA) and it’s predecessor Okta Advanced Server Access (Okta ASA), can capture session recordings in the Gateway (subject to policy rules). These recordings are stored, but not processed further by OPA. In many cases, session recordings are only used for later forensic analysis and are not required to be accessed often, thus storing in a compressed format is the best option, allowing customers to decide what processes to wrap around using the files.

    The recordings are stored as log files written as a base64 encoded binary file and signed to confirm that they haven’t been tampered with. The OPA client provides command options to decode (export) the files so that they can be viewed. As the OPA Gateway is a Linux server, and often without a UI, you can only view SSH recordings locally; RDP recordings need to be shipped somewhere that you can play back mkv format files.

    Session Recording in OPA

    Session Recording is a feature that’s been available in both Okta ASA and OPA for some time. It is often referred to a “Session Capture”. It stores the logs in a file on the gateway server (which could be an external drive locally mounted, like an S3 bucket) after a user session is finished. It does nothing further with the logs, but does provide commands to allow for bespoke processing on the log files.

    OPA stores the logs in a raw Base64 encoded format that must be decoded (exported) using the OPA client. Note that it does not encrypt the logs.

    OPA signs session logs to provide integrity. This prevents attackers from manipulating a log file to hide their actions. New signing keys are generated roughly every 24 hours. The OPA client can be used to verify the signature.

    To review RDP session logs, you must Install RDP Transcoder.

    Configuration of session recording involves:

    1. Mapping a gateway to the target servers in the Resource Group / Project

    2. Configuring a Policy / Rule to record sessions for a group of users connecting to a set of servers

    3. Configuring session recording on the gateway

    The gateway configuration file, /etc/sft/sft-gatewayd.yaml, has configuration options for session recording.

    This includes the LogDestinations option to tell the gateway where to write the sessions logs, which could be a local file (or mounted filesystem), AWS or GCS buckets. If extensive session recording is to be performed, you should consider where you will store the logs and how to manage them. You could easily consume a lot of local disk, particularly with RDP logs, and there’s no automatic cleanup of files. If this is a concern it would be advisable to store the logs on an external disk or cloud bucket.

    Another point to note is that exporting RDP logs can be a CPU-intensive operation. You should ensure there is ample processing capacity on the gateway if you plan to export RDP logs there (or plan to ship the RDP logs to another server to export them. Wherever you plan to run the export command, you will need the OPA client installed.

    A Simple Script-based Mechanism

    The first approach is a simple series of scripts that can be run on the gateway to export and view (some) logs. The term session logs is used to mean the files that the gateway writes to disk. This is a trivial example that shows how commands could be used to export/view logs as per the Manage session logs doc page. It may not be the most secure or efficient way of doing it.

    The scripts are:

    The sequence of scripts is:

    1. List the SSH session logs that have been written by OPA

    2. Copy a session log to the local directory

    3. Convert the SSH session log to asciinema format

    4. Play the converted session log

    5. List the RDP session logs that have been written by OPA

    6. Copy a session log to the local directory

    7. Convert the RDP session log to mkv format

    Note that the gateway is a Linux server and unless you have a UI and the relevant apps installed, you will not be able to view the graphical Windows recordings, only the text-based recordings.

    Lets walk through them in more detail.

    Exporting and Viewing SSH Session Logs

    The first step (script) will list all ssh recordings in the location where the gateway writes them. 

    sudo ls /var/log/sft/sessions | grep ^ssh

    The output is a list of all ssh recordings, like

    ssh~20241205T024708.3712~deadwoods-pam2~allServers~opa-demo-linux2~larry.linuxadmin~-1-6751142a-76d328f734c7cff842d72a1f.asa

    The file format is defined in the gateway configuration file (sft-gatewayd.yaml).

    The next step is to copy one of the files into the local directory. This is to set the permissions to work on it.

    sudo cp /var/log/sft/sessions/$1 .
sudo chmod 777 $1
ls -ltr

    The third step will use the OPA client (sft) to export the file. It’s passed the filename and writes the output in asciinema format to a file called exportedSessions.cast.

    sft session-logs export --format asciinema $1 --output exportedSession.cast

    This is the only step to require using the client. Obviously the client must be installed on to the gateway server and the user running the script needs to be able to run the session-logs command.

    Exporting RDP Session Logs

    Exporting the RDP session logs has a similar flow, to list the files, copy one into the local directory and set permissions. Then the sft session-logs export command is used.

    sft session-logs export --format mkv --output ./rdpSessionExport $1

    In this case the exported file is in mkv format and is stored in a sub-directory (./rdpSessionExport). This is because the files aren’t viewed locally, so this is where you could copy them from to a machine that can view them.

    This completes the simple script-based mechanism.

    Mechanism to Offload Logs to AWS S3 and An App to View Them

    The previous example was a bare-bones example of just using basic scripts. The following example provides a more comprehensive approach. The mechanism was written by a former Okta employee and can be found at https://github.com/mrdanielmh/opa-utils.

    Itt exports/converts the logs and stores them on a S3 bucket and provides a sample application that can be used to view the recordings as shown in the following figure.

    The github page defines the installation/configuration, including:

    • Creating an Okta application (the one to view the logs) and assigning it to users

    • Deploying the app components into AWS, including creating the IAM definitions (roles), creating the S3 bucket, creating the Elastic Beanstalk app, mapping it to the Okta app definition and setting some parameters for it.

    • Setting up the Gateway, including assigning the new IAM role to the gateway instance, deploying the provided script (or similar), installing some software, configuring the S3 bucket as a mounted drive, creating a service to monitor for new session logs and configuring the gateway to write logs to the format the script is expecting.

    The script will monitor a directory on the gateway (/var/log/sft/sessions) and when it detects a session log will run the appropriate sft session-logs export command and store the exported file onto the S3 bucket.

    #!/bin/bash -x
#Watch for new session logs and convert them to asciinema (ssh) and mkv (rdp).
WATCHPATH="/var/log/sft/sessions"
DESTPATH="/mnt/aws/{bucketname}"
process-logs-ssh(){
sudo sft session-logs export --insecure --format asciinema --output "$DESTPATH"/"$file".cast "$WATCHPATH"/"$file"
}
process-logs-rdp(){
sudo sft session-logs export --insecure --format mkv --output "$DESTPATH"/"$file".mkv "$WATCHPATH"/"$file"
}
inotifywait -m "$WATCHPATH" -e create 2>/dev/null |
while read dirpath action file; do
    if [[ $file == *ssh~* ]]; then
            echo "ssh session capture found"
            echo "starting conversion process"
            process-logs-ssh
            echo "ssh session converted"
    elif [[ $file == *rdp~* ]]; then
            echo "rdp session capture found"
            echo" starting conversion process"
            process-logs-rdp
            echo "rdp session converted"
    else
            echo "skipping unknown file type $file"
    fi
done

    With the exported session logs stored in S3, they can be accessed by the app (called OPA Utils or sometimes Advanced Server Access – Utilities).

    Selecting a recording in the app will allow playback.

    Note that this is an unsupported mechanism that was built in late 2022/early 2023. The session recording feature in Okta ASA and OPA has not changed since then, but YMMV.

    Conclusion

    Okta Privileged Access has a session recording capability for ssh and rdp sessions. The OPA Gateway will record the sessions and write them to files (locally or on AWS/GCS buckets) where the customer can access them. This article has shown two examples of how those session recording files can be stored and accessed.

  • Integrating Active Directory with Okta Privileged Access

    Okta has recently released their Microsoft Active Directory (AD) integration with Okta Privileged Access. This allows AD admin accounts to be stored in the vault and exposed via policy for use when accessing AD-authenticated services. This article provides a brief overview of the new feature.

    Note that this article is from the initial Active Directory integration with Okta Privileged Access. Later enhancements added RDP click-to-connect using the OPA Client and Agent. See http://davidedwardsphotos.com/iamdavid/index.php/2025/10/15/recent-updates-to-okta-privileged-access-oct-25/ for more details.

    What Is It?

    Put simply, the new feature allows Microsoft Active Directory (AD) accounts to be discovered, stored in the Okta Privileged Access (OPA) vault, have the account passwords rotated so OPA only knows them, and then allows reveal of the passwords according to the OPA policy applied to the user accessing them.

    The following figure shows the current set of resource types and access methods in OPA. OPA has had Windows and Linux servers, and Secrets since GA. Late last year the SaaS/Okta service accounts were added to the set. This new feature adds AD accounts as a new resource type.

    The initial phase of this feature supports a copy’n’paste model – OPA will reveal the AD credentials (username/password) and the user copies them and pastes them into the appropriate login dialog (like RDP or a database client). This is so that the feature can address the widest possible set of use cases for AD-authenticated services.

    How Does it Work?

    This new integration is based off the existing Okta and Okta AD Agent integration that many customers use today. The components and flows are shown in the following diagram.

    There is an Okta AD Agent deployed to a server within an AD domain, and it communicates with Okta for imports and provisioning. The new AD integration feature with OPA piggy-backs off this. There is a syncronisation process between OPA and Okta to consume AD accounts in specific OUs, and to apply passwords rotated in OPA.

    There are three main processes, discovery (the D* flows), rotation (C*) and checkout (C*).

    For the discovery process, Okta knows which AD OUs contain admin accounts. These accounts could be individual admin accounts (secondary accounts) or shared admin accounts. These are treated differently on an AD Directory Integration import (D1). The sync between OPA and Okta will pull these accounts into OPA and store them in the vault (D2).

    When a new account is stored in the vault, the password is rotated in OPA and pushed to Okta in the sync mechanism (R1). Okta will then apply that new password to AD via the normal Okta to AD Agent processing (R2).

    Password rotation for the vaulted AD accounts will occur in different scenarios:

    • When the account is first loaded in to the vault

    • When the checked-out account is checked back in, via the timer expiring, via the user manually checking it in, or via an admin forcing a check in.

    • On a schedule if that has been enabled

    Finally the checkout process involves an authorised user accessing the domain in the OPA UI, selecting the accounts they can see, completing any controls applied to the account (like MFA or JIT access request) and copying the username & password into the relevant login prompt (C1 & C2) which does its authentication to AD (C3). This checkout will have a timer and at the end of the time period, the account will be automatically checked back in (and password rotated).

    This is all reasonably straightforward.

    What Does it Look Like?

    Let’s walk through how this looks from the users perspective. We have a user, Sally Serveradmin, who needs to access some Windows services that are authenticated against accounts in AD.

    She SSO’s into OPA from her Okta Dashboard and sees the Active directory menu item under the PAM resources she can work with (My Privileged Access). The menu item shows all the domains she can access accounts in.

    She clicks on the domain name to see all the accounts she can access. This is all based on policies and rules set in OPA.

    The list of accounts includes three shared DBA accounts (can be accessed by multiple people, and her personal individual admin account (can only be accessed by her).

    She selects her individual admin account, S-sally, and sees that she can show the account details with exclusive checkout but will need to meet an MFA requirement before she can access the credentials.

    When she clicks the Show credentials button, she is taken through her Okta MFA flow, and can then see the credentials.

    Notice that there is a complex password. This is the password generated by OPA and pushed to AD (i.e. the rotation).

    Sally starts RDP to access a specific domain-joined server. She copies the username and password from OPA into the RDP login prompt and is given access to the relevant server.

    The account has been checked out for two hours. She can see what accounts she has checked out in the Checked out accounts menu item.

    She could let the checkout timer expire or use this view to manually check in the account. The administrator could also force a check in.

    That’s it, a very simple way of accessing AD privileged accounts.

    Conclusion

    In this article we have provided a brief overview of the new AD integration feature for Okta Privileged Access. We have looked at what the feature provides, how it’s put together and the user experience. In subsequent articles we will explore some of the configuration aspects of this new feature.

  • A Brief Intro to SoD with OIG

    Okta has just released a separation of duties feature into Okta Identity Governance. This article provides a brief introduction to the feature.

    Introduction

    Separation of Duties (or Segregation of Duties, or more commonly SoD) has been a standard control for identity governance for a quarter of a century. The concept is that a user should not have conflicting access unless there has been some governance applied to ensure it’s a valid business need and recorded.

    Whilst it may be between applications (e.g. I can access the HR app used by business unit A, but not the one used by business unit B) it comes up more in application entitlements (often application transactions). For example, if I can raise a purchase order I should not be able to approve purchase orders.

    This implies visibility into application-level access, which is what Entitlements Management in Okta Identity Governance provides. Being able to see entitlements in an app means being able to set rules around toxic combinations of those entitlements.

    We will explore this new feature across the three main use cases – access requests, access certification and reporting. For this article we will use a trivial example – a user cannot have both of a set of Microsoft Office365 licenses. The article assumes you’re familiar with Okta Identity Governance and Entitlement Management.

    Configuring SoD Rules

    SoD rules are configured within each applications’ Governance settings. At this stage the SoD rules are between entitlements within an application as that’s the most needed use case, but this may be expanded in the future.

    The rules are a simple combination of sets of conflicting entitlements – if a user has any one of (or all of) set A, they should not have any one of (or all of) set B. In the example shown below a user can have either of the MS365 E5 AAD Premium 1 or Premium 2 licenses but not both.

    There can be multiple rules defined for an application.

    The default behaviour for access requests is to block the user getting the new entitlement in conflict. However this behaviour can be set in the access request settings.

    The Allow requests with custom settings option will permit selection of a specific flow to be run in the case of a SoD violation. Perhaps you want a different process of approval for SoD violations.

    With a rule in place, we can test an Access Request.

    Requesting Access with SoD Checks

    In this environment there are multiple entitlement bundles defined, including one for each of the AAD Premium licenses.

    When a user who has one of the licenses (say P1) requests the other, (P2) they are presented with the conflict details and cannot continue.

    If we had changed the access request setting to allow the conflict, we would see the following. The user is warned, but can still request access.

    This is for user access requests. The administrator can still add conflicting entitlements to the user. For the sake of this article, the admin has added the second entitlement so the user has both AAD Premium P1 and P2 licenses.

    Recertifying Access with SoD Violations

    The SoD checking has also been added to the Access Certification mechanism.

    When running a Resource campaign with entitlements for this application, the user is highlighted with an SOD CONFLICT warning. Expanding either row with the warning will show the SoD conflict details.

    If the campaign has been set to action a Revoke decision, any of the conflicting entitlements could be removed by clicking the Revoke button.

    Reporting with SoD

    Finally some of the reporting capabilities have been extended to cover SoD. Any access request allowed with a SoD violation will indicate so on the Past Access Requests (Conditions) report. You need to add the Conflict Name column to the report.

    The report will then show any conflicts (you need to scroll right to find the column).

    This additional data will be included in the CSV Export.

    The System Log events show additional detail if SoD rules have been evaluated and violations allowed.

    Conclusion

    Separation of Duties is a fundamental IGA control for some customers. Okta has implemented SoD by leveraging the Entitlements Management capability in Okta Identity Governance. This article has provided a brief introduction to this new feature, looking at configuration of SoD rules, access request with SoD checking, access certification with SoD evaluation, and reporting.