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:
- The ability to turn off the initial password rotation on discovery, and
- 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.
