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.
IAMSE