Windows domain controller
You can install the Okta Privileged Access server agent on Windows domain controllers. The server can then connect to your Active Directory (AD) environment to discover privileged accounts, and allows admins to manage access to those accounts using Okta Privileged Access policies.
Okta Privileged Access integration with AD
AD account management and access to domain controllers require specific configuration within Okta Privileged Access's AD account rules. To enable RDP access to domain controllers through Okta Privileged Access, the following configurations are required within the Okta Privileged Access AD account rules:
-
AD accounts must be managed by Okta Privileged Access.
-
Both the required AD accounts and the target domain controller servers must be explicitly configured within the rule.
To sign in with RDP, the AD accounts must have RDP permissions through group policy or some other mechanism.
Okta Privileged Access server agent scope in AD
To minimize the possibility of disruption of your AD environment, Okta prevents domain controllers and AD groups, such as admins, from being changed by the server agent.
-
Domain controller access is managed exclusively through existing domain accounts and permissions. Individual Okta user accounts are neither created nor deleted on the server. For example, your org may have a policy that grants temporary server access to users for troubleshooting. However, this policy can't be applied to a domain controller, because the server agent doesn't create individual Okta user accounts in that case.
-
The Okta Privileged Access server agent doesn't scan the domain controller to identify or manage domain account passwords.
-
Domain local groups admin and remote desktop users can't be modified, and no other groups are affected.
When Okta Privileged Access provisions a persistent account on a Windows server, it checks if there's an Active Directory (AD) user in the user's OU with a matching Windows username. If there's a match, Okta Privileged Access immediately takes control of the AD object, changes its password, and blocks direct sign-in attempts from AD. From that point, the user must access the environment through Okta Privileged Access. They can sign in as the AD user on a domain controller and as a local user on member servers.
This modified behavior prevents the Okta Privileged Access server agent from changing the domain controllers and AD groups, such as the local group admin. However, you can override these default settings using an sftd.yaml configuration file. See Configure the Okta Privileged Access server agent.