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.

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.