Plan your Active Directory integration

You use the Okta Active DirectoryActive Directory (AD) is a directory service that Microsoft developed for the Windows domain networks. It is included in most Windows Server operating systems as a set of processes and services. Initially, Active Directory was only in charge of centralized domain management. (AD) agentA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations. to integrate Okta with your on-premises AD instance. AD integration provides delegated authentication supportenabling users to sign in to Okta with their AD credentials, user provisioningassigning users to apps, and de-provisioningremoving users from apps. To enable AD integration, you install the Okta AD agent, and then import your existing AD users and groupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with groups. into Okta.

AD integrations in a newly-created organization automatically have the following default settings enabled:

AD integration includes the following tasks:

After completing your initial AD integration and importing users, these optional topics might be of interest:

Integration implementation options

How you implement your Okta AD integration is dependent on the size of your organization, your business requirements, and the scopeA scope is an indication by the client that it wants to access some resource. of your deployment. In general, there are two main approaches:

  • Proof of Concept (POC) or simple deployment — If you're doing a POC or a simple AD integration, you'll probably want to install the Okta AD agent, import some users, and configure basic settings. You may not need high availability (HA) or disaster recovery (DR) options, or be concerned about the attributes you import from your AD user profiles into Okta.
  • Large scale enterprise deployment — For large enterprise deployments, it is likely that you'll want to do some planning before installing the Okta AD agent and importing user data.

You can adjust your configuration options and make changes as your implementation evolves. There are a number of topics to help you plan your implementation, including:

  • Agent performance information
  • High Availability (HA) and Disaster Recovery (DR)
  • AD Domains and Cross-forest scenarios

These diagrams illustrate the two most common AD integration scenarios.

High availability and disaster recovery

The unique requirements of your orgThe Okta container that represents a real-world organization. determine how you implement high availability (HA) and disaster recovery (DR) processes. These guidelines are intended to help you determine what options are available.

The Okta AD agent does not perform load balancing. Traffic is directed to the first available agent.

To get started, you'll need to answer the following questions:

Use case

A use case is often the best way to demonstrate how high availability and a good disaster recovery plan can help your organization get the best out of its AD integration. In this use case, Example Corp has three data centers:

  • A physical data center in Atlanta that is always available.
  • An Amazon AWS data center that is always available.
  • A cold backup data center that is used for disaster recovery if the two live data centers are unavailable.

With the integration, it does not matter whether the data centers are physical or virtual instances. They are assigned the same significance.

If the Atlanta and AWS data centers are always available, and each instance has one or more AD agents installed, then traffic is routed to the active agents, regardless of their location.

AD agents installed on the cold data center servers are listed as inactive in the Okta adminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. dashboard. After 30 days of inactivity, the assigned API tokens expires. If Example Corp needs to route traffic to their cold backup data center, they'll need to re-install the AD agents. For this reason, Okta recommends that Example Corp install the AD agents on their cold data center servers when they are needed.

To determine the number of agents Example Corp should install in each data center, they'll need to consider what their fault tolerance is and what high availability or disaster recovery scenarios they want to prepare for:

  • The Atlanta data center experiences full failure, traffic moves to the Amazon AWS data center. If Amazon AWS fails, traffic moves to the cold data center.
  • If either Atlanta or Amazon AWS fail, the cold data center is brought online.

Installing a single AD agent in each data center increases risk. Installing two or more agents allows for recovery if one agent fails. The number of active users influences recovery performance.

Answering these questions can help you determine a strategy for your AD integration:

  • What is our risk tolerance? 
  • Are you planning for individual agents, the machines they are installed on, or entire data centers to be unavailable? 
  • How do the Okta recommendations fit in with your existing high availability or disaster recovery procedures? 

Active Directory forests and domains

When planning your AD integration, review your existing AD implementation and answer these questions:

  • How many domains do you have?
  • What kind of trusts are in place?
  • What forests do you have?
  • Which OUs do you plan to import into Okta? 
  • Are there users or resources in those OUs that you do not need to import into Okta?

The Okta AD agent does support communication across domains. However, the Okta AD agent cannot communicate across forests.

An agent must be installed in each forest and each domain in a forest where there are users you intend to import into Okta. While is it possible to register multiple domains to a single agent, be aware that if the agent goes down, all domains will be impacted.

Resource forests do not need agents installed in them because there are typically no users in the forest, just network resources.

Installing the Okta AD agent requires the use of an AD service account. It is important that the service account has permissions in all domains in that forest to read and access users in all domains to which the agent connects. For details about the service accounts required to install the agent, see Accounts required for AD agent installation.

Prepare Active Directory for the integration

Before you begin your AD integration, select the AD attributes that you want to synchronize with or your downstream applications and make sure that your organization is using those attributes for their intended purpose. If you are mapping the same data from two or more domains into one, make sure the data is consistent. If your domains share an attribute and it is used for different values, it can create a problem when the attribute is merged into Okta.

For example, a custom attribute "Attribute 1" is being used in Domain A to store users' employee badge numbers and on Domain B it is being used to store the last four digits of their corporate credit card. When Domain A and Domain B users are mapped into Okta, Attribute 1 is mapped as a single attribute in Okta. However, depending on the user being referenced, the attribute value refers to two different data types. To avoid a similar issue:

  • Make sure that the attribute values are consistent across different domains.
  • Create different attribute mappings between Okta and each of your ad domains. Okta recommends that you make your attribute values consistent at a later date.
  • Take advantage of Attribute Level Mastering.

Import considerations

Bring only the attributes that you require into Okta. For example, if you have a t-shirt size attribute in AD, but you do not need the attribute in Okta or in any of your down-stream applications, do not import the attribute into the user profile. You can add more attributes later as you need them.

Removing attribute mappings is more difficult. If you remove attribute mapping, Okta retains previously imported data. To remove attribute data in Okta, you need to intentionally map a blank value to the attribute in the user profile.

Agent install and update recommendations

Installing the Okta AD agent requires the use of an AD service account. It is important that the service account has permissions in all domains in that forest to read and access users in all domains to which the agent connects.

In general, Okta recommends you use the same AD service account to install all of your agents. This simplifies maintenance on the service account itself such as password rotation, so that the agent isn't negatively impacted.

Planning for agent updates will depend on your current change management process. Treat an agent update the same as any standard server patch process. Update each agent one or two at a time, sequentially and consistently. Avoid taking all agents down at the same time.

Agent updates can be installed over existing agents. There is no need to uninstall the existing agent first. It is possible to uninstall the existing agent and install the updated agent version. However, this requires additional steps to ensure a complete and clean uninstall.

As with all updates and configuration changes, Okta recommends that you upgrade your Okta Preview environment first to ensure everything is working correctly before upgrading your Production environment.

Related topics

Disconnect users from Active Directory

Install and configure the Okta IWA Web agent for Desktop Single Sign-on

Configure a new Agentless Desktop Single Sign-on implementation

Synchronize passwords from Active Directory to Okta