In one sentence: Okta asks your own directory to check the password, instead of keeping and checking the password itself.

Let us start with the word authentication. It means proving that you are who you claim to be. When you type a username and a password, you are authenticating. When a phone app asks you to approve a sign-in, that is also authentication. The system that checks the proof is called the authenticator, and the proof is called a credential.

In a simple Okta setup, Okta stores a protected form of each person’s password and checks it directly. In a delegated setup, Okta does not hold the password it checks. It passes what the person typed, safely and over an encrypted connection, to a small program running inside the company network. That program asks the company’s directory whether the password is right and tells Okta the result.

Why anyone would want this

Many companies already have a directory with years of accounts, password rules, and security habits built around it. Employees already know their passwords. Auditors already know how to inspect the system. Rather than copy all of that into a new place, the company says, “Keep the passwords where they are. Let Okta consult them.”

Where the word shows up

In Okta’s own documentation, delegated authentication most often means the connection between Okta and an on-premises Active Directory (AD) or LDAP directory through a small helper called an agent. People also use the phrase loosely for related ideas, such as sending someone to another company’s sign-in page, or letting a network device check passwords through Okta. We will compare those neighbours in Chapter 3 so that you never mix them up.

A handful of ideas from the world of company sign-in systems will make the rest of this guide easy.

On-premises and cloud

On-premises (often shortened to on-prem) means computers that your company owns and keeps in its own buildings or private data centers. The cloud means computers owned by someone else, such as Okta, that you reach over the internet. Delegated authentication is a bridge between these two worlds, which is why it is so common in companies that are halfway through a move to the cloud. We call that mixed situation a hybrid environment.

Two flavors of Okta

You may see references to the Okta Classic Engine and the newer Okta Identity Engine. They are two generations of the sign-in brain inside Okta. Delegated authentication to AD and LDAP is available in the world of agents on both, but menu names, policy screens, and some behaviors differ. Always confirm which engine your org uses, and read the matching page of Okta’s current documentation before you change anything.

Several ideas sound alike. Separating them now will save you hours of confusion later.

When a company wants people to sign in through Okta, it has to decide where the password is checked. There are a few common choices, and each one answers that question differently.

Three lookalikes to keep apart

How to choose

Pick delegated authentication when your directory must remain the only place passwords exist, perhaps because of company policy or regulation, and when you can run and protect the agents. Pick an Okta-mastered password when you are ready to let Okta own the credential and you want the fewest moving parts. Add Desktop SSO when most people work on domain-joined office machines and you want sign-in to feel invisible.

There are only a few moving parts. Once you can name them, you can reason about almost any problem.

The picture below shows a simplified setup. On the left is the person with a browser. In the middle is Okta in the cloud. On the right, inside the company network, are the agents, the domain controllers, and the directory itself. The most important detail is the direction of the arrows between the cloud and the agents: the agents reach out to Okta. Okta never reaches in to your network.

flowchart LR
  U["Employee with Browser"] --> OK["Okta Cloud - Sign-in Page, Policies, MFA"]
  subgraph Cloud["Okta Cloud"]
    OK
    Q["Secure Agent Channel"]
  end
  OK --> Q
  subgraph Net["Company Network"]
    A1["AD Agent One"]
    A2["AD Agent Two"]
    DC1["Domain Controller One"]
    DC2["Domain Controller Two"]
    AD[("Active Directory")]
  end
  A1 -- "Outbound HTTPS" --> Q
  A2 -- "Outbound HTTPS" --> Q
  A1 --> DC1
  A2 --> DC2
  DC1 --> AD
  DC2 --> AD
    

The parts, one at a time

Why the arrows point outward

Security teams are very careful about opening holes in their firewall, which is the wall that decides what traffic may enter the company network. If Okta had to call into your network, you would have to open an inbound door and defend it from the whole internet. Instead, the agent makes ordinary outbound encrypted connections over the standard secure web port, which most firewalls already allow. The agent then waits for work. Think of a post office box: Okta drops a message in the box, and your agent, which keeps checking the box from inside, collects it.

Follow one employee, Priya, as she signs in on a Monday morning.

Priya opens her browser and goes to a company application. The application sends her to the Okta sign-in page, because Okta is the identity provider for that app. She types her work username and her normal work password. Here is what happens next, in order.

sequenceDiagram
  participant P as Priya
  participant O as Okta Cloud
  participant G as AD Agent
  participant D as Domain Controller
  P->>O: Username and password over HTTPS
  O->>O: Find Priya and see that her password is checked by the directory
  O->>G: Verification request left in the secure channel
  G->>D: Does this password match this account
  D-->>G: Yes or no
  G-->>O: Result over the outbound connection
  O->>O: Apply policies and ask for a second proof if required
  O-->>P: Signed in and sent to the application
    

What is different from a normal sign-in?

Only step three and step four. In a normal Okta-mastered setup, Okta would check the password itself and the trip to your network would never happen. The rest of Priya’s experience, including the sign-in page, the second proof, and the single sign-on to every other app, looks exactly the same. That is the whole point: the person sees no difference, while the company keeps passwords in the directory it trusts.

Checking passwords is only half of the story. Okta also needs to know who exists, what their details are, and which teams they belong to.

Before anyone can sign in, Okta must have a record for them. In a delegated setup, those records usually come from the directory. The agent reads the list of people and groups and sends it to Okta in a process called an import. The first import copies everyone. After that, later imports copy only the changes, which is faster and lighter. Imports can run on a schedule, and an administrator can start one by hand.

flowchart TD
  AD[("Active Directory")] --> AG["AD Agent"]
  AG -- "Full import then incremental" --> IM["Okta Import Engine"]
  IM --> MAP["Attribute Mapping"]
  MAP --> UP["Okta Universal Directory"]
  UP --> GR["Group Rules and Assignments"]
  GR --> APPS["Applications"]
  UP -. "Password check at sign-in" .-> AG
    

Attribute mapping

A directory describes a person with its own field names, such as a “given name” or a “department.” Okta has its own field names. Attribute mapping is the translation table between the two. For example, the directory’s mail field becomes Okta’s email field. You decide which fields to bring over and which direction they flow. Keep the list short: bring only what applications really need.

Profile mastering

When the same fact lives in two places, one of them must win. This is called mastering. If the directory masters a person’s department, then a change in the directory overwrites what is in Okta, and edits made in Okta do not stick. This keeps one version of the truth. Many companies choose to let the directory master the profile of everyone who signs in through delegated authentication, and allow only a few extra fields, such as a phone number for second-factor prompts, to be managed inside Okta.

Groups as the glue

The agent can also import groups, which are named collections of people, such as “Finance Team.” Okta can then give an application to a whole group instead of to individuals. When someone joins “Finance Team” in the directory, the next import adds them to the group in Okta, and the finance applications appear on their home page automatically. When they leave the group, access disappears. This is how a directory-driven company keeps access tidy without a person clicking through hundreds of assignments.

Because the directory owns the password, the directory’s rules shape what happens when a password changes, expires, or fails too many times.

Whose rules apply?

In delegated authentication, the password rules that matter are the directory’s: how long a password must be, how often it must change, and how many wrong attempts lock the account. Okta’s own password policy settings, such as complexity and age, do not control a password that Okta does not keep. This surprises many administrators who spend hours tuning an Okta password policy and see no effect.

Changing and resetting

When a person changes or resets a password through Okta, Okta cannot save it in its own vault, since the directory is the master. Instead, it passes the new password to the agent, and the agent asks the directory to apply it. For this to work, the service account used by the agent must be allowed to reset passwords for the accounts involved. Giving that permission is a serious decision, so limit it to only the groups of people who need it.

Lockouts: the hidden trap

Imagine that a stranger on the internet types random passwords into your Okta sign-in page for Priya’s account. Each wrong guess is sent to the directory. After enough guesses, the directory locks Priya’s account. Priya, who did nothing wrong, cannot sign in to anything. This is a quiet form of attack called a lockout attack, and it is a real risk for any setup where the sign-in page forwards guesses to a directory with a strict lockout rule.

You can reduce this risk by using Okta’s tools that recognize suspicious sign-in traffic, by limiting where sign-ins may come from, and by choosing lockout settings that slow attackers without punishing staff. We cover these protections again in the security chapter.

Delegation replaces only the password step. Everything else Okta does still works around it.

Multi-factor authentication, or MFA, means proving who you are in more than one way, such as a password plus an approval on your phone. In a delegated setup, the password is checked by the directory, but the second proof is handled entirely by Okta. The directory does not need to know anything about phone apps or security keys. This is a big advantage: you can add modern second proofs to an older directory without changing the directory at all.

What Okta’s rules can still do

Desktop single sign-on as a companion

Many companies pair delegated authentication with Desktop SSO. When a person is on an office computer that is already signed in to the Windows domain, Okta can recognize this and skip the password prompt entirely. That means the delegated password check is used mostly when people are working away from the office, on personal devices, or on the road. Together they give a smooth day for the person and a strong gate for the company.

Delegation adds a trip to your network on every sign-in. Make that trip dependable.

High availability means designing a system so that no single broken part stops the whole service. For delegated authentication, the parts that can break are the agents, the servers they run on, the domain controllers, and the network path to Okta. If any one of these fails with no backup, people may be unable to sign in.

Run more than one agent

Okta recommends running at least two agents for each directory domain, on different servers, and many large companies run more. Okta spreads requests across the agents that are online, and when one disappears, the others carry on. Place the servers in different racks or even different sites, so one power cut or network fault cannot remove them all together.

Make the directory side resilient

Each agent talks to a domain controller. A good setup has several domain controllers in every site, so if one is down for repair, the agent finds another. Keep agent servers close, in network terms, to their domain controllers. A slow link between them turns every sign-in into a slow sign-in.

flowchart TD
  S["Sign-in needs a password check"] --> A{"Any agent online?"}
  A -- No --> F1["Directory sign-in fails for everyone"]
  F1 --> F2["Use break-glass admin with an Okta-held password"]
  A -- Yes --> B{"Can the agent reach a domain controller?"}
  B -- No --> C["Agent tries another domain controller"]
  C --> D{"Another controller reachable?"}
  D -- No --> F1
  D -- Yes --> PC["Password checked"]
  B -- Yes --> PC
  PC --> R["Continue with policies and MFA"]
    

Failure scenarios and recovery

A sign-in should feel quick. Here is what makes it slower or faster, and how to grow without pain.

Every delegated sign-in contains a round trip: Okta to the channel, the channel to the agent, the agent to a domain controller, and back. Most of this takes a fraction of a second when the network is healthy. The usual causes of slow sign-ins are a far-away agent, an overloaded agent server, a struggling domain controller, or a congested internet link from the office.

The Monday morning rush

Sign-ins are not spread evenly. Thousands of people arrive between eight and ten on Monday. Think of a coffee shop at the same hour: one barista is fine at three in the afternoon, and hopeless at 8:30 in the morning. Add agents so the busiest minute stays comfortable, and watch how requests are shared among them.

Many domains and forests

Large companies, especially after mergers, may have several domains or even several separate directory forests. Each domain generally needs its own agents and its own connection in Okta. This multiplies the work: more agents, more service accounts, more imports, and more places for a rule to be inconsistent. A tidy naming scheme and a shared checklist for every domain are worth their weight in gold.

Delegation reduces some risks and creates others. A clear view of both helps you build it safely.

What delegation does well

First, the password stays in the directory. Okta does not keep a copy for people whose password check is delegated, so there is no second vault to protect and nothing in Okta’s storage that could be stolen. Second, the agents make only outbound connections, so you do not need to open a door in your firewall for the internet to knock on. Third, the connections are encrypted, so nobody listening on the network can read a password in transit.

What still needs care

The principle of least privilege

The idea of least privilege is simple: give every account only the access it needs for its job and nothing more. A lock repairer gets the key to the lock room, not the master key to the building. Apply this to the agent’s service account, to the Okta administrators who manage the integration, and to the people allowed to reset other people’s passwords.

The agent is the most important piece of equipment in the whole design, so it is worth understanding how it behaves from the inside.

An agent is an ordinary program that runs as a background service on a server. You download it from your Okta admin area, install it on a Windows server that belongs to your domain (for the Active Directory version), and register it with your Okta org by signing in with an administrator account. Registration is like introducing a new employee to head office: from then on, Okta knows that this particular messenger is allowed to speak for your directory.

The life of an agent

What the agent needs from you

How it picks a domain controller

The agent does not usually hard-wire itself to one domain controller. It asks the domain’s own naming service which controllers are available, preferring those in the same site. A site, in directory language, is a group of well-connected servers, typically one office or data center. Preferring a nearby controller keeps sign-ins quick and keeps traffic off long, expensive network links. If the nearby controller does not answer, the agent moves on to another. For this reason, your directory team’s habit of keeping sites and subnets correctly defined has a direct effect on how healthy your Okta sign-ins feel.

Handling many requests at once

One agent can handle many people at the same time, because each check is short. But the work is not free. Each check uses a little processor time and a little network capacity, and each wait for the directory holds a request open. When a crowd arrives, requests line up. This is why the advice to run several agents is not just about surviving a failure. It is also how you share the load, so no one messenger is carrying all the mail on the busiest morning.

A calm rollout is mostly good preparation. Here is a path that avoids the surprises most teams meet.

Moving thousands of people onto a new sign-in path is as much about people as about technology. The goal is that on launch day, almost nobody notices anything except that their apps are easier to reach. That outcome comes from careful planning in four stages: understand, design, pilot, and launch.

Stage one: understand what you have

Begin with a simple inventory. List every directory domain, how many people are in each, which servers could host agents, and which applications people use daily. Ask the directory team how passwords are managed today: their strength rules, expiry time, and lockout settings. Ask the security team what second proofs they want. Ask the help desk what questions they hear most. These conversations take days, and they prevent months of rework.

Stage two: design the pieces

Decide the number and placement of agents, the shape of the service account and its permissions, the attribute mappings, the group imports, and the rules for second proofs and locations. Write all of this on a single page that both the Okta team and the directory team sign. A shared page prevents the common fight where each team assumes the other one handles lockout rules.

Stage three: pilot

Choose a friendly group of perhaps fifty people from different departments and locations. Include a few who travel and a few who work on unusual devices. Run the pilot long enough to include at least one password expiry and one lockout, since those are the moments when problems appear. Collect feedback, count the help desk calls, and fix what you find.

flowchart LR
  U1["Understand - Inventory and Policies"] --> D1["Design - Agents, Accounts, Mappings"]
  D1 --> P1["Pilot - Small Friendly Group"]
  P1 --> W1["Waves - Department by Department"]
  W1 --> L1["Launch - Everyone"]
  L1 --> R1["Review - Logs and Feedback"]
  P1 -- "Problems found" --> D1
    

Stage four: launch in waves

Roll out one department or location at a time. After each wave, look at the sign-in success rate, the slowest sign-ins, and the help desk tickets before you start the next. Announce changes in plain words, explain what will look different (usually very little), and tell people what to do if they get stuck. Schedule the largest waves for midweek mornings when the whole support team is present, not for a Friday afternoon.

A launch-day checklist

Textbook diagrams are tidy. Real companies are not. These are the awkward cases that show up sooner or later.

Name changes and renamed accounts

When someone marries, changes their name, or moves departments, their sign-in name in the directory may change. Okta identifies the person by an internal number, not by the visible name, but the username they type must still match what the directory expects. After a rename, run an import so Okta learns the new details, and tell the person which username to use. Plan this process before it happens to the first executive.

Disabled and departing accounts

When a person leaves the company, the directory team disables the account. Because the directory answers every password check, the person is immediately unable to pass the password step. But their Okta record, with its apps and any existing sessions, may still exist until the next import and cleanup. Combine the directory action with an Okta action that ends the person’s current sessions and removes assignments. The two systems should agree within minutes, not days.

Contractors, partners, and shared accounts

Not everyone belongs in your directory. A short-term contractor may have no directory account at all. For them, many companies create accounts directly in Okta with Okta-held passwords, while employees keep the delegated path. Shared accounts, where several people use the same login, are best avoided entirely, because neither the directory nor Okta can tell who did what.

Phones, tablets, and unmanaged devices

Mobile devices cannot use Windows-based convenience features such as Desktop SSO, so people on phones will typically type the delegated password or use a phone-based approval. Make sure the second-proof experience is pleasant on a small screen, and that password rules allow a reasonable way to type on a phone keyboard.

Applications that bring their own login

Some older applications cannot use Okta and still ask for a username and password of their own. If those applications check against the directory, they continue to work as before, and the delegated password remains the same one. If they use a separate password, you may want to bring them under Okta, or at least include them in your lockout and monitoring plans.

Network devices and VPNs

A virtual private network gateway often needs to check a person’s identity too. Here the arrow turns around: the device asks Okta, using a protocol called RADIUS, and Okta may in turn delegate the password to the directory. Treat this as a separate project with its own agents, since a failure in this path can stop people from working remotely.

People in several domains

In a company with multiple domains, one person might have accounts in two of them, for example after an acquisition. Decide which account is the primary identity for Okta, and avoid creating two separate Okta users for one human. Otherwise, people will see duplicate tiles and approvals will go to the wrong place.

When sign-in fails, panic helps nobody. A calm, step-by-step approach finds most problems quickly.

Troubleshooting a delegated sign-in is like tracing a leak in a pipe: you follow the water from the tap back toward its source. Start at the person, then move to Okta, then to the agent, then to the directory. At each stop, ask, “Did the request arrive here, and what did this stage say?”

Common symptoms and likely causes

Auditors do not ask only whether the system works. They ask who is in charge, who can change it, and how you know.

Governance means the habits and rules by which an organization keeps important systems under control. For delegated authentication, it covers who may change the settings, who reviews those changes, and how you show that the system behaves as promised. A system without governance may work today and still fail an audit tomorrow.

Questions an auditor is likely to ask

Separation of duties

The principle of separation of duties says that no single person should be able to carry out and approve a sensitive change alone. A common arrangement is that the directory team controls password rules, the Okta team controls the integration settings, and the security team reviews changes to both. If one person holds all three powers, a mistake or a bad decision has no second pair of eyes to catch it.

Change management

Every change to agents, the service account, attribute mappings, and policies should follow a simple routine: write what you intend to change and why, have someone else review it, make the change at a quiet time, and check the result in the logs. Keep the record. When a surprise appears three weeks later, this record is how you find the cause.

Privacy and data minimization

Directories often hold more personal information than Okta needs. Bring over only the fields that applications truly require. A phone number may be needed for a second proof, but a home address probably is not. Smaller imports reduce risk, simplify privacy reviews, and make the system easier to explain.

Technology does not run itself. A clear owner for every part keeps small issues from becoming big ones.

Delegated authentication sits between two teams who often do not talk much: the people who run the directory and the people who run Okta. Without a clear plan, each team can assume the other is watching a problem, and nobody is. A good operating model puts a name next to every responsibility.

Keeping up with change

Okta, Windows, and the directory itself all change over time. New versions of agents arrive, Windows servers reach the end of their supported life, and Okta adds and renames features. Subscribe to Okta’s release notes, plan a regular review of what has changed, and test updates in a non-production environment first. A small test org with a test agent and a handful of test accounts is a cheap way to catch problems before they reach everyone.

Thinking about cost honestly

Delegated authentication is not free to run. The cost lies not in the Okta feature itself but in the servers, the licenses for them, the time of the people who maintain them, and the hours spent on incidents. When you compare delegation with an Okta-held password, count these hidden costs. In some companies delegation is cheaper because the directory already exists and must be run anyway. In others it is more expensive because it adds servers and work that Okta would otherwise absorb.

Keep this page handy. Every term used in this guide is explained here in one or two lines.

Concepts stick best when you watch them move. Here are three ordinary days at a company that uses delegated authentication.

Walkthrough one: a new hire arrives

On Thursday afternoon, the people team finishes the paperwork for a new analyst named Meera, who starts on Monday. The directory team creates her account in the company directory, places her in the groups for the analytics team, and sets a temporary password that must be changed at first sign-in. Nothing has happened in Okta yet.

Walkthrough two: a forgotten password

On a rainy Tuesday, Arjun returns from a long holiday and cannot remember his password. He clicks the “need help signing in” link on the Okta page. Because the company has allowed self-service reset, Okta first asks for a strong second proof: an approval on his enrolled phone. Once he passes that check, Okta lets him choose a new password.

Okta cannot save the new password itself, since the directory is the master. It sends the new password through the agent. The agent uses the service account, which has been given permission to reset passwords for staff accounts only. The directory checks that the new password meets its rules and applies it. The whole thing takes about a minute, and the help desk never hears about it. If the directory rejects the password for being too similar to an old one, Arjun sees a clear message and tries again.

Walkthrough three: the agent outage

One Monday at 8:40, a power fault at one office takes down a server rack. One of the three agents was on that rack. The other two carry on, and the monitoring tool raises an alert: “Agent count is below target.” The on-call engineer sees that sign-ins are still succeeding and that the slowest sign-ins are a little slower than usual, because two agents now share the load.

flowchart TD
  A1["Alert - Agent count below target"] --> A2["Engineer checks sign-in success and speed"]
  A2 --> A3{"Sign-ins still healthy?"}
  A3 -- Yes --> A4["Restore the failed agent at a calm pace"]
  A3 -- No --> A5["Start an emergency agent on a spare server"]
  A5 --> A4
  A4 --> A6["Confirm all agents are connected"]
  A6 --> A7["Write a short note on cause and fix"]
    

Because the company followed the advice in this guide, the problem became a quiet repair job rather than a company-wide emergency. The engineer starts a spare agent on another server, confirms that all agents are connected again by mid-morning, and writes a short note describing the cause and the fix. By afternoon, the power fault is repaired and the original rack is restored.

What these stories teach

You cannot fix what you cannot see. Good monitoring tells you about trouble before your employees do.

Okta keeps a diary called the System Log, which records sign-ins, failures, password changes, lockouts, and administrative actions. Sign-ins checked through an AD or LDAP agent leave their own kind of entry, so you can tell them apart from sign-ins checked inside Okta. Each entry says who, what, when, from where, and with what result. When someone calls the help desk saying “I cannot sign in,” the log is the first place to look.

Three layers of visibility

Numbers worth tracking

Alerts that help

Raise alerts on symptoms people care about. Notify the on-call team if an agent is offline for more than a few minutes, if the sign-in success rate falls sharply, if many accounts lock in a short time, or if the emergency administrator account is used. Write a short guide for each alert that says what it means and what to check first.

Teams that have done this many times tend to follow the same few habits, and avoid the same few traps.

Anti-patterns to avoid

A quick checklist for a smooth project, followed by the errors that appear again and again.

Mistakes that appear again and again

Here are typical situations where delegated authentication earns its place, described as everyday scenarios.

Many companies use delegation as a stepping stone. Here is how the journey often goes.

Delegated authentication is a very good bridge, but it is a bridge, not always a destination. As more systems move to the cloud, some companies decide to retire their on-premises directory or to let Okta own the credential. Others go further and reduce passwords altogether with phone-based or hardware-key sign-in. The path below is typical, and each step can be paused for as long as needed.

flowchart LR
  P1["Phase 1 - Delegated sign-in with MFA on top"] --> P2["Phase 2 - Add Desktop SSO and stronger policies"]
  P2 --> P3["Phase 3 - Enroll people in passwordless methods"]
  P3 --> P4["Phase 4 - Move password ownership to Okta where wanted"]
  P4 --> P5["Phase 5 - Retire agents and legacy directory when ready"]
    

Every design choice trades one thing for another. Here is the honest picture.

Choosing well