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.