Okta AD agent permissions requirements

Loading

Skip to Navigation Skip to Main Content

Search

Search

Select Language

0D54z0000AJDuSyCQLOkta Identity EngineIdentity Security Posture ManagementAnswered2026-04-04T09:00:52.000Z2025-01-28T16:47:57.000Z2025-03-10T16:59:29.000Z

0d81x (0d81x) asked a question.

Edited January 28, 2025 at 4:54 PM

Okta AD agent permissions requirements

Our EMR provider uses OKTA currently hosted with a third party. They are migrating it in house. We currently have Okta agents on domain controllers and there is an AD account for this agent. In the current implementation we've added a custom AD attribute and they sync our AD users. We do all AD administration currently and OKTA just syncs. With the migration they are requesting to add the additional permissions shown in this document: https://help.okta.com/en-us/content/topics/directory/ad-agent-about-service-account.htm

I question if they need anything more than read permissions as that's what it is currently. The EMR provider has no need to create, delete or modify our AD users. Is there any other reason the Okta agent would need these additional permissions shown in the document linked above if they are just syncing with our AD for authentication?

This content is a preview of a link.

https://help.okta.com/en-us/content/topics/directory/ad-agent-about-service-account.htm

Top Rated Answers

Mihai Negoita - Okta (Okta, Inc.)
a year ago
@0d81x (0d81x) As far as I can see the write permissions are required for password management purposes not authentication and if you do not intend to manage passwords through Okta or allow self-service, then read-only should be enough.

Regards.
--
Join the discussion for Ask Me Anything on February 4, 2025: Advancements in Okta’s On-Prem Directory Integrations
Expand Post
Selected as Best

All Answers

Mihai Negoita - Okta (Okta, Inc.)
a year ago
Hi @0d81x (0d81x) , Thank you for reaching out to the Okta Community!

If you are not using Delegated Authentication, Sync password or any kind of information write-back to the AD, then read only permissions (with "logon as a service") should suffice for the service account running the Okta Agent after the install.
For the install itself, you will need to leverage account with elevated permissions.
-AD Admin to run the installer on the server.
-Okta Admin account with dedicated permissions to be referenced during the install.
More details here.

If my answer helped, remember to mark it as best to increase its visibility for other members of the Okta Community who might have the same questions as you.

Hope my answer helps!

--
Join the discussion for Ask Me Anything on February 4, 2025: Advancements in Okta’s On-Prem Directory Integrations
Expand Post
- 0d81x (0d81x)
  a year ago
  @Mihai Negoita - Okta (Okta, Inc.) I'm not familiar with "Delegated Authentication". I don't think that's what they are implementing but can you give a brief explanation?
  Expand Post
  - Mihai Negoita - Okta (Okta, Inc.)
    a year ago
    Hi @0d81x (0d81x) ,
    Delegated Authentication is covered in this article. I mentioned it due to its involvement in password use and management, for example in situation when a user wants to change their password from the Okta UI and needs to push it back to AD.
    
    Regards.
    --
    Join the discussion for Ask Me Anything on February 4, 2025: Advancements in Okta’s On-Prem Directory Integrations
    Expand Post
  - 0d81x (0d81x)
    a year ago
    @Mihai Negoita - Okta (Okta, Inc.) I think that's the basics of how they're using it but currently no ability for users to change passwords. For the migration, can they still use the basic functionality of "Delegated Authentication" but without the ability for users to change passwords? Basically we don't want to give a third party agent any permissions to modify our AD but we want to maintain the ability for Okta to authenticate/sync with our AD.
    Expand Post
  - Mihai Negoita - Okta (Okta, Inc.)
    a year ago
    @0d81x (0d81x) As far as I can see the write permissions are required for password management purposes not authentication and if you do not intend to manage passwords through Okta or allow self-service, then read-only should be enough.
    
    Regards.
    --
    Join the discussion for Ask Me Anything on February 4, 2025: Advancements in Okta’s On-Prem Directory Integrations
    Expand Post
    Selected as Best
  - 0d81x (0d81x)
    a year ago
    @Mihai Negoita - Okta (Okta, Inc.)
    
    We just performed the pre-migration steps the other day. We installed the “OktaPasswordSyncSetup” file on out domain cotnrollers. We then installed the AD agents on a seperate domain server. To confirm, since we're not doing any password resets etc. through Okta, the account that these programs/service runs under still will not need administrative permissions correct?
    Expand Post
  - Mihai Negoita - Okta (Okta, Inc.)
    a year ago
    Hi @0d81x (0d81x) , Sorry for the late reply, I was out of office.
    At this point I would strongly recommend opening a case to work with the Okta Support team who can set up a meeting and go over your implementation and clarify your requirements. I would hate for my information to be misleading due to lack of context.
    Based on all the information you've provided before, I would wager that "Okta Password Sync" is not something that you need. Its use cases are outlined here.
    
    Regards.
    --
    The new Okta Help Center YouTube channel is your go-to resource for tips, troubleshooting, and best practice videos. Subscribe today.
    Join the Online Discussion for Ask me Anything on March 25, 2025: Identity Threat Protection with Okta AI
    Expand Post

This question is closed.

Recommended content

Forum

Okta AD Agent requirements and usage

Forum

AD Agent Service Account

Forum

AD: Okta service account permissions

Forum

Okta AD agent

Loading

Okta AD agent permissions requirements