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:
- Delegated authentication — Allows your end usersEnd users are people in your org without administrative control. They can authenticate into apps from the icons on their My Applications home page, but they are provisioned, deprovisioned, assigned, and managed by admins. to sign in to Okta. with their AD credentials.
- The import schedule set to never — Specifies how users and groups are imported from AD into Okta.
- Profile masteringMastering is a more sophisticated version of read (import) users. Mastering defines the flow and maintenance of user-object attributes and their lifecycle state. When a profile is mastered from a given resource (application or directory), the Okta user profile’s attributes and lifecycle state are derived exclusively from that resource. In other words, an Okta user mastered by Active Directory (or HR system) has an Okta profile. However, the profile isn’t editable in Okta by the user or Okta admin, and derives its information exclusively from Active Directory. If the lifecycle state of the user in Active Directory moves to Disabled, the linked Okta user also switches to the corresponding lifecycle state of Deactivated on the next the read (import). — Identifies which application is the source of truth for user data. By default, AD is the profile masterA profile master is an application (usually a directory service such as Active Directory, or human capital management system such as Workday) that acts as a source of truth for user profile attributes. A user can only be mastered by a single application or directory at any one time. For more details, see the Profile Master page. When users are mastered by attribute, we call this attribute-level mastery (ALM). ALM delivers finer grain control over how profiles are mastered by allowing admins to specify different profile masters for individual attributes. Profile mastering only applies to Okta user profiles, not app user profiles. For more details, see Attribute Level Mastering. when the agent is installed.
AD integration includes the following tasks:
- Installing and configuring the Okta AD agent. This includes:
- Importing AD users. This includes:
- Optional tasks:
After completing your initial AD integration and importing users, these optional topics might be of interest:
- Customizing the AD user profiles and attributes. This includes:
- Understanding Okta user profile and attribute functionality. This includes:
- Learning about Profile Masters and Attribute Level Mastering. This includes:
- Learning about Okta security policies.
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.
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:
- Who owns your organization's DR or HA processes and who needs to be consulted?
- How many data centers do you have?
- How are they used? That is, which ones are live (hot) all the time and which ones are backups (cold).
- What kind of fail over do you want to plan for? You can have agent redundancy, in the event an individual agent fails. Or you can plan for the failure of an entire data center (that is, all agents in that data center).
- Are the AD domainA domain is an attribute of an Okta organization. Okta uses a fully-qualified domain name, meaning it always includes the top-level domain (.com, .eu, etc.), but does not include the protocol (https). controllers live all the time?
- Are they actively replicated to?
- Is there a significant latency in replication between the data centers? This can cause replication problems.
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?
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.
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.
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.
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.