Active Directory account rules
Early Access release
Active Directory (AD) account rules are designed to automate the management of AD accounts in Okta Privileged Access. They're used to automatically find AD accounts in specific OUs and bring those accounts under management. To stop managing an account with Okta Privileged Access, the account rule must be modified or removed to no longer include those specific OUs.
Types of account rules
There are two types of account rules:
-
Shared account rules: Used to manage accounts that multiple people use and that don't belong to a single user. These accounts are shared among a team, such as an admin account owned by the Active Directory team or a shipping account managed by the logistics team.
-
Individual account rules: Meant for accounts that belong to specific users. In an AD environment, there are typically separate dedicated accounts used by privileged users so that their daily accounts don't have privileged access. These admin accounts are intended solely for individual use and are named with a prefix or suffix that indicates they're admin accounts. For example, they may look like adm.Jane.Doe@ad.domain.net or clark.kent-admin@ad.dailyplanet.org. Before creating an individual account rule, it's necessary to configure the individual account settings first.
Individual account rule settings determine how Okta Privileged Access maps an individual account to its primary user. Okta Privileged Access supports several options for correlating these accounts with their respective owners. A policy rule then controls whether a user can access their own individual admin account and specifies the conditions applied to that access. A user can only view their own individual account.
AD accounts as active Okta users in Okta Privileged Access
Okta Privileged Access can manage passwords for any Active Directory (AD) account. This is done by configuring an account rule that keeps discovered accounts as active Okta users. If you change this setting for an account, or if some account were previously managed by Okta Privileged Access with the setting disabled, they show a Suspended state. An Okta admin needs to activate these accounts.
Also, to relink the Okta account with AD, a re-import from AD is necessary. This can be done through a scheduled import in the Okta Admin Console or through a manual import. It's important to note that Okta Privileged Access won't rotate the AD password until this process is completed.
Prioritizing and ordering rules for Active Directory OUs
Rule ordering is crucial for achieving the desired behavior, especially in complex environments with nested organizational units (OUs).
-
First Match Wins: Okta Privileged Access processes Active Directory (AD) account rules according to their priority order. The first rule that matches an account determines how that account is managed.
-
OU-Level prioritization: The decision to use the Keep discovered accounts as existing Okta users or the Rotate passwords upon discovery flow is based solely on the OU match and rule priority. Enhanced filters (Account Name and Okta Group) are applied after determining the primary rule based on its OU and priority. They don't affect which rule takes precedence.
-
Mandatory parent/child OU ordering: If any rule enables the Keep discovered accounts as existing Okta users feature while another rule disables it, all account rules for that AD domain must be arranged so that rules for parent OUs appear before rules for their child OUs.
Correct Order
OU=parent,DC=okta,DC=com
OU=child,OU=parent,DC=okta,DC=com
Incorrect Order
OU=child,OU=parent,DC=okta,DC=com
OU=parent,DC=okta,DC=com
Failing to follow this order can lead to unexpected behavior. Specifically, a more specific rule for a child OU may be overridden by a broader parent rule if the parent rule has a higher priority. Okta prohibits such combinations of rules from being created.