<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
System Status
Announcements
Announcements
Search
Search
Select Language
Knowledge Base
Knowledge Articles
Support Videos ↗
Documentation
Product Documentation ↗
Developer Documentation ↗
Product Release Notes ↗
Community
Events & Webinars
Okta Ideas ↗
Resources
Product Hub
Customer Success Hub
Product Release Update
Learning
Okta Learning ↗
Get Support
Open a Case
HomeCommunityForum
0D5KZ000019sQVS0A2Okta Classic EngineIntegrationsAnswered2025-07-31T19:48:22.000Z2025-07-24T07:05:55.000Z2025-07-31T19:48:22.000Z

workspacest.33779 (Customer) asked a question.

July 24, 2025 at 7:05 AM
Clarifying if Okta AD Agent is required for AWS WorkSpaces SAML integration (with AWS Directory Service)

Hi team,

I’m planning to integrate AWS WorkSpaces with Okta using SAML for authentication.

Architecture:

  • AWS WorkSpaces (personal virtual desktops)
  • AWS Directory Service (Microsoft AD) as the WorkSpaces directory
  • Okta as IdP for SAML
  • No RADIUS

I need clarification on two points:

  1. When is the Okta AD Agent generally required? ( My understanding: for AD user sync and delegated authentication.)
  2. Is the Okta AD Agent needed in my case, where:
  • Users authenticate via Okta (IdP)
  • AWS WorkSpaces uses AWS Directory Service (Microsoft AD) for directory backend
  • SAML assertions must include correct attributes (e.g., userPrincipalName)

If the AD Agent is mainly for syncing users or delegated auth, and Okta handles auth, I assume it’s unnecessary. But since WorkSpaces relies on AD, is the agent still required for attribute resolution?

Any general explanation and guidance would be greatly appreciated!

Thanks!

  • 6 answers
  • 284 views
workspacest.33779 likes this.

  • Mihai N. (Okta, Inc.)

    Hi @workspacest.33779 (Customer)​ , Thank you for reaching out to the Okta Community! 

     

    Yes, the Okta AD Agent is still required in your scenario.

    It acts as the bridge between your AWS Directory Service Microsoft AD and Okta. It is responsible for:

    • Synchronizing user and group information (including attributes like userPrincipalName) from AWS Directory Service to Okta. This populates Okta's user profiles so that Okta can generate accurate SAML assertions.
    • (Optional) Handling delegated authentication if you configure Okta to authenticate against your AWS Directory Service directly instead of relying solely on Okta's Universal Directory passwords. However, even if you don't use delegated authentication, the synchronization aspect is still critical for WorkSpaces.

    You will need to install and configure the Okta AD Agent on a Windows server (an EC2 instance, for example) that has network connectivity to your AWS Directory Service Microsoft AD and outbound access to Okta.

     

    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! 

     

    --

    Help others in the community by liking or hitting Select as Best if this response helped you.

    Collect them all. Learn a new skill and earn a new Okta Learning badge.

    Expand Post
    Selected as Best

  • Mihai N. (Okta, Inc.)

    Hi @workspacest.33779 (Customer)​ , Thank you for reaching out to the Okta Community! 

     

    Yes, the Okta AD Agent is still required in your scenario.

    It acts as the bridge between your AWS Directory Service Microsoft AD and Okta. It is responsible for:

    • Synchronizing user and group information (including attributes like userPrincipalName) from AWS Directory Service to Okta. This populates Okta's user profiles so that Okta can generate accurate SAML assertions.
    • (Optional) Handling delegated authentication if you configure Okta to authenticate against your AWS Directory Service directly instead of relying solely on Okta's Universal Directory passwords. However, even if you don't use delegated authentication, the synchronization aspect is still critical for WorkSpaces.

    You will need to install and configure the Okta AD Agent on a Windows server (an EC2 instance, for example) that has network connectivity to your AWS Directory Service Microsoft AD and outbound access to Okta.

     

    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! 

     

    --

    Help others in the community by liking or hitting Select as Best if this response helped you.

    Collect them all. Learn a new skill and earn a new Okta Learning badge.

    Expand Post
    Selected as Best

    • workspacest.33779 (Customer)

      Thank you, Mihai, for the detailed and structured explanation!  

      Your breakdown of the AD Agent’s role, especially regarding attribute synchronization and delegated authentication, was very helpful.  

      I appreciate the clarity and the guidance!

  • BrandonB.06003 (Customer)

    Yes AD agent is needed since your directory store is in AD which houses your user profiles and their credentials. The only way to not be required to use it is if you use okta as your identity store exclusively and no AWS AD

    • workspacest.33779 (Customer)

      Thanks, Brandon, for sharing your perspective and confirming the key point!  

      Your note about why AD Agent is required when using AD for profiles was very useful.  

      Really appreciate your input and time!

  • workspacest.33779 (Customer)

    @Mihai N. (Okta, Inc.)​ @BrandonB.06003 (Customer)​ 

    Thank you again for the previous clarification regarding the AD Agent requirement.

     

    I have an additional question about the deployment location of the Windows Server that hosts the Okta AD Agent.

     

    In an AWS environment using AWS Managed Microsoft AD (which resides in private subnets), is it considered best practice to place the EC2 instance hosting the Okta AD Agent in:

    - The same VPC and private subnets as the AWS Managed Microsoft AD?

    or

    - A public subnet (with appropriate Security Groups and routing)?

     

    My assumption is that it should be placed in a private subnet for security and direct connectivity to the directory, but I would like to confirm the recommended approach and any rationale from Okta's perspective.

     

    Thanks again for your guidance!

    Expand Post
This question is closed.
Loading
Clarifying if Okta AD Agent is required for AWS WorkSpaces SAML integration (with AWS Directory Service)