Integrating Multiple Active Directory Domains With Okta for Agentless Desktop Single Sign-On

Integrating multiple Active Directory (AD) domains with Okta for Agentless Desktop Single Sign-On (ADSSO) requires specific configurations based on the trust relationship and forest structure of the domains. Administrators must configure service accounts and Service Principal Names (SPNs) differently depending on whether the domains reside in the same forest or different forests.

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Agentless Desktop Single Sign-On (ADSSO)
• Active Directory (AD)

How are domains in the same forest configured?

When domains are part of the same forest, such as a parent domain and its child domains, Active Directory requires Service Principal Name (SPN) uniqueness across the entire forest. Administrators cannot create the same SPN (HTTP/okta.kerberos.okta.com) on two different service accounts within the same forest. Use a single service account created in one of the domains (typically the root/parent) and use its credentials for all integrated domains in that forest within Okta.

Configure the domains in the same forest by entering the same service account credentials for each domain entry in the Okta Admin Console.

1. In the Okta Admin Console, go to Security > Delegated Authentication > Agentless Desktop SSO.
2. Enter the same Service Account User Principal Name (UPN) and Password for each domain entry that resides in that forest.

How are domains in different forests configured?

When domains reside in different forests, they act as independent Kerberos realms. SPN uniqueness is only enforced within the forest boundary. Administrators must configure the SPN in each forest and create a separate service account and SPN for each forest. Each Active Directory integration in Okta requires a dedicated ADSSO service account and SPN configuration tailored to that specific forest environment.

What are the environmental prerequisites for Agentless Desktop Single Sign-On?

Regardless of the forest structure, ensure the environment meets the following prerequisites for ADSSO to function correctly.

• The AD service account must have AES 128-bit or AES 256-bit Kerberos encryption enabled on the account object. RC4 encryption is no longer supported.
• The Okta Kerberos URL (https://<org>.kerberos.okta.com) must be added to the Local Intranet Zone (not Trusted Sites) via GPO on all end-user machines.
• Computers must be domain-joined. ADSSO is not supported on mobile devices or non-domain machines; for those, Okta FastPass is the recommended alternative.
• Ensure the Routing Rules for Agentless DSSO are prioritized correctly (usually at the top) to catch the traffic from the intended network zones.