Okta service account permissions

Before adjusting the permissions on your directory, make sure you understand how Active Directory (AD) permissions are set and plan how to manage permissions within your environment. For information about the account requirements needed to perform this task, see Active Directory integration prerequisites.

By default, the Okta AD agent installer creates a Okta service account if you don't choose an existing account. The newly created OktaService account inherits the permissions of the Domain Users group. OktaService is also considered to be a member of the Authenticated Users and Everyone special identity groups when the agent is running. By default, the Authenticated Users group is a member of the Pre-Windows 2000 Compatible Access group. Removing the Authenticated Users group from the Pre-Windows 2000 Compatible Access group can cause issues with incremental imports. To resolve issues with incremental imports, Okta recommends making one of the following changes:

  • Add the OktaService account to the Pre-Windows 2000 Compatible Access group.

  • Make sure the OktaService account has Read all permissions for all synchronized AD objects.

The Okta AD agent Management Utility also includes the option of adding the OktaService account to the Domain Admins group. If you require the functionality listed here but don't want to make your service account a full admin, make sure that the following permissions are set.

Provision user

  • Requires Create Child permission for user objects on the target Organizational Unit (OU).
  • Requires the Reset Password control access right for user objects within your target OU.
  • Requires write property permissions on user objects within your target OU for the following attributes:
    • mail
    • userPrincipalName
    • SAMaccountName
    • givenName
    • sn
    • userAccountControl
    • pwdLastSet
    • lockoutTime
    • cn
    • name
  • Requires write property permissions on user objects within your target OU for all other attributes mapped on the AD user profile in Okta. Mappings are listed under Directories at https://<org>/admin/universaldirectory.

Update user attributes

  • Requires write property permissions on user objects within your target OU for the following attributes:
    • mail
    • userPrincipalName
    • SAMaccountName
    • givenName
    • sn
    • userAccountControl
    • pwdLastSet
    • lockoutTime
    • cn
    • name
  • Requires write property permissions on user objects within your target OU for all other attributes mapped on the AD user profile at https://<org>/admin/universaldirectory.

Group push

  • Requires create child permissions for group objects on the target OU.
  • Requires delete child permissions for group objects on the target OU.
  • Requires write property permissions on group objects within your target OU for the following attributes:
    • sAMAccountName
    • description
    • groupType
    • member
    • cn
    • name

Reset password, forgot password, and sync password

  • Requires write property permissions on user objects within your target OU for the following attributes:
    • lockoutTime
    • pwdLastSet
  • Requires Reset Password Control Access Right permission for user objects within your target OU.

Activate and deactivate user

  • Requires write property permissions on user objects within your target OU for the following attributes:
    • userAccountControl

Use reference commands to add permissions

Use the listed commands to add permissions. Save them to a batch file and change the target OU and service account information for your environment. Remember to remove permissions you don't need and add any attributes you have mapped for provisioning within Okta. You can get the complete list of user attributes from your Directory user profile on https://<org>/admin/universaldirectory. Run dsacls commands from a PowerShell with administrative privileges. To gain these privleges, use the Run as administrator option when launching PowerShell.

# Create User dsacls "OU=targetOU,DC=domain" /G domain\agentserviceaccount:CC;user # Create or Update user # include other attributes that are mapped in your org within Okta dsacls "OU=targetOU,DC=domain" /I:S /G domain\agentserviceaccount:WP;mail;user dsacls "OU=targetOU,DC=domain" /I:S /G domain\agentserviceaccount:WP;userPrincipalName;user dsacls "OU=targetOU,DC=domain" /I:S /G domain\agentserviceaccount:WP;sAMAccountName;user dsacls "OU=targetOU,DC=domain" /I:S /G domain\agentserviceaccount:WP;givenName;user dsacls "OU=targetOU,DC=domain" /I:S /G domain\agentserviceaccount:WP;sn;user dsacls "OU=targetOU,DC=domain" /I:S /G domain\agentserviceaccount:WP;userAccountControl;user dsacls "OU=targetOU,DC=domain" /I:S /G domain\agentserviceaccount:WP;pwdLastSet;user dsacls "OU=targetOU,DC=domain" /I:S /G domain\agentserviceaccount:WP;lockoutTime;user dsacls "OU=targetOU,DC=domain" /I:S /G domain\agentserviceaccount:WP;cn;user dsacls "OU=targetOU,DC=domain" /I:S /G domain\agentserviceaccount:WP;name;user # Create user/Password Reset dsacls "OU=targetOU,DC=domain" /I:S /G "domain\agentserviceaccount:CA;Reset Password;user" dsacls "OU=targetOU,DC=domain" /I:S /G domain\agentserviceaccount:WP;pwdLastSet;user dsacls "OU=targetOU,DC=domain" /I:S /G domain\agentserviceaccount:WP;lockoutTime;user # Group Push dsacls "OU=targetOU,DC=domain" /I:T /G domain\agentserviceaccount:CCDCDT;group # If your use case requires that you grant the preceding permission only for child objects, you can replace /I:T with /I:S. dsacls "OU=targetOU,DC=domain" /I:S /G domain\agentserviceaccount:WP;sAMAccountName;group dsacls "OU=targetOU,DC=domain" /I:S /G domain\agentserviceaccount:WP;description;group dsacls "OU=targetOU,DC=domain" /I:S /G domain\agentserviceaccount:WP;groupType;group dsacls "OU=targetOU,DC=domain" /I:S /G domain\agentserviceaccount:WP;member;group dsacls "OU=targetOU,DC=domain" /I:S /G domain\agentserviceaccount:WP;cn;group dsacls "OU=targetOU,DC=domain" /I:S /G domain\agentserviceaccount:WP;name;group