Which RFC defines the base schema Okta Universal Directory uses for its 31 standard attributes?

Correct: b. Okta UD's base schema follows RFC 7643 — the SCIM Core Schema — giving it interoperability with SCIM-based provisioning and a standardised set of 31 user attributes out of the box.

An admin tries to edit a user's email field in the Okta Admin Console but the field is greyed out. What is the most likely cause?

Correct: a. When AD is the profile source, Okta locks the AD-mastered fields. The email field is greyed out because AD owns it — the change must be made in AD and will sync to Okta via the AD Agent.

You want the app's username to be firstName.lastName in lowercase. Which OEL expression is correct?

Correct: c. String.toLowerCase(user.firstName + '.' + user.lastName) concatenates the two attributes with a dot separator and forces them to lowercase — a standard pattern for deriving readable, consistent usernames in OEL.

Your UD department attribute is mastered by both the AD agent and an HR app with no priority set. What symptom will you observe?

Correct: d. Without mastering priority, the last sync wins — creating a race condition. If AD syncs at 2 a.m. and HR syncs at 3 a.m., the HR value wins, then AD overwrites it at 2 a.m. the next day. The fix is to set one source as the explicit master for that attribute.

A legacy application needs to authenticate users against Okta but can only speak LDAP. Which Okta feature enables this without modifying the app?

Correct: c. The LDAP Agent can expose Okta's Universal Directory as an LDAP endpoint. The legacy app points its LDAP bind at the Okta LDAP interface and authenticates against UD — no code changes required.

What is the risk of enabling profile push for an attribute that the target app also lets users edit themselves?

Correct: b. Profile push is not merge-aware — it writes the UD value over whatever the app holds. If a user updated their title in the app, that update is lost on the next push. Exclude such attributes from push or make UD the sole master.

Okta Universal Directory — Profiles, Mastering & Attribute Mapping

Q: How many standard attributes does the Okta Universal Directory base schema include?

Correct: b. Okta UD ships with 31 base attributes (firstName, lastName, email, login, mobilePhone, etc.) following RFC 7643 SCIM Core Schema. You add custom attributes on top of these via the Profile Editor.

Q: When Active Directory is set as the profile source for a user, what happens to that user's AD-mastered fields in Okta?

Correct: a. Profile sourcing makes AD the authority. Okta locks the AD-mastered fields to prevent drift — edits must happen in AD and flow to Okta via the AD agent, not the other way.

Q: You need the Okta username to be the part of the email address before the '@'. Which OEL expression achieves this?

Correct: c. String.substringBefore(user.email, '@') splits the email at the '@' and returns the left part — exactly the local-part you want as the login. This is a classic OEL pattern for deriving usernames.

Q: An app lets users update their own job title, but profile push is also set to push the jobTitle attribute. What will happen on the next push cycle?

Correct: d. Profile push overwrites the app's value with what UD holds. If the user edited their title in the app, that edit is lost on the next push. The fix is to exclude jobTitle from push or let the app master that attribute instead.

Most engineers think…

Most people picture Okta as a login box that sits in front of apps. That framing is too narrow.

Okta Universal Directory is the identity spine of the whole platform. It consolidates user profiles from Active Directory, LDAP, HR systems and SCIM sources into one object per user, applies attribute transformations via Okta Expression Language, and then pushes the right profile to each downstream app. Understanding UD — profiles, mastering, mappings, agents and push — is what lets you design an IAM deployment that stays consistent at scale instead of drifting into a mess of conflicting values.

① User profiles & the attribute schema

Every user, group and device in Okta lives in the Universal Directory (UD) as a single profile object. That object is built on a base schema of 31 standard attributes following the SCIM Core Schema (RFC 7643). You extend the base with custom attributes — any data type your org needs — through the Profile Editor in the Admin Console or via the Schema API.

The Profile Editor is your single governance window: it shows every attribute for every integration in one place, lets you set data types, mark attributes as required or unique, and configure whether they are read-only or editable by the user. Every app integration you add gets its own app user schema that sits alongside the Okta user schema; attribute mappings bridge the two.

The interview point: one user, one UD profile, regardless of how many directories feed it. AD, LDAP, HR, SCIM — they all contribute to the same object.

Figure 1 — Universal Directory data flow

Every upstream source feeds one UD profile; every downstream app gets only the attributes it needs.

Figure 2 — Okta profile attribute layers

The UD profile is built in layers — base schema on the bottom, custom attributes on top.

Quick check · Q1 of 10 · Remember

How many standard attributes does the Okta Universal Directory base schema include?

a) 10 — just the basics like name and emailb) 31 — derived from the SCIM Core Schema (RFC 7643)c) 100 — a wide attribute libraryd) It has no standard schema; everything is custom

Correct: b. Okta UD ships with 31 base attributes (firstName, lastName, email, login, mobilePhone, etc.) following RFC 7643 SCIM Core Schema. You add custom attributes on top of these via the Profile Editor.

👉 So far: Okta UD = one profile per user, 31 base SCIM attributes + custom attrs; governed in Profile Editor; every integrated app gets its own app user schema with mappings.

② Profile sourcing & mastering

Profile sourcing is the mechanism that designates one upstream directory as the authority for a user's profile attributes. When AD is the profile source, Okta cannot let you edit that user's AD-mastered fields in the Admin Console — changes must happen in AD and then sync to Okta. This prevents drift between your authoritative directory and Okta.

How mastering works in practice

An AD-mastered user has their core attributes (name, email, department) locked to whatever AD says. If you also have an HR system, you can configure attribute-level mastering: AD masters the technical attributes (samAccountName, OU), while the HR app masters HR-specific fields (costCentre, jobTitle), and Okta itself masters any remaining attributes. Priority rules decide the winner when two sources send conflicting values for the same field.

The rule of thumb: one authority per attribute, clearly documented. Ambiguous mastering is the number-one cause of profile inconsistency in real Okta deployments.

Figure 3 — Profile sourcing — one UD, many masters

UD is the central store; each upstream source masters the attributes it owns.

🗂️

Universal Directory

tap to flip

The single identity store in Okta — one profile object per user consolidating every upstream source (AD, LDAP, HR, SCIM) with a base schema of 31 SCIM attributes plus custom extensions.

👑

Profile Mastering

tap to flip

The rule that one designated source owns and controls a user's attributes. AD-mastered users cannot have their AD-owned fields edited directly in Okta — the source is the authority.

🔧

Okta Expression Language

tap to flip

A SpEL-based scripting layer inside attribute mappings. Lets you strip, concatenate, reformat or branch on attribute values before they land in UD or are pushed to an app.

📤

Profile Push

tap to flip

Okta's mechanism for writing UD attribute changes downstream to an integrated app — automatically triggered when a mapped attribute changes, using per-attribute push rules.

Document who masters what — before you build

Before connecting any source to UD, write a one-page attribute authority table: attribute name, master source, whether it is pushed downstream, and whether the app can also edit it. Skipping this step is how orgs end up with nightly title-reset bugs and conflicting department names in different apps.

Quick check · Q2 of 10 · Understand

When Active Directory is set as the profile source for a user, what happens to that user's AD-mastered fields in Okta?

a) They are locked in Okta — changes must originate in AD and sync overb) Okta admins can freely edit them in the Admin Consolec) They are deleted from Okta when AD syncsd) Only super-admins can edit them in Okta

Correct: a. Profile sourcing makes AD the authority. Okta locks the AD-mastered fields to prevent drift — edits must happen in AD and flow to Okta via the AD agent, not the other way.

👉 So far: Profile sourcing = one upstream authority per attribute; AD-mastered fields are locked in Okta; attribute-level mastering lets AD own some fields and HR own others.

③ Okta Expression Language & AD / LDAP agents

Okta Expression Language (OEL) is a subset of Spring Expression Language (SpEL) you embed inside attribute mappings. Instead of mapping a raw field one-to-one, you write an expression that transforms it: strip a domain from an email, concatenate first and last name, reformat a date, or branch on a condition. Example: String.substringBefore(user.email, '@') as a login attribute. OEL runs at import time (when a source value lands in UD) and at push time (when UD sends a value to an app).

AD Agent and LDAP Agent

On-prem directories reach Okta through lightweight agents. The Okta AD Agent installs on a Windows server in your AD domain, opens an outbound HTTPS connection to Okta (no firewall hole inbound), and handles import, provisioning and optional password sync. You deploy multiple agents per domain for HA. The LDAP Agent does the same for any RFC 4511-compliant LDAP directory (OpenLDAP, Sun DSEE, etc.) and can also expose Okta as an LDAP endpoint so legacy apps can authenticate against UD without being modified.

Figure 4 — AD Agent vs LDAP Agent

Both agents bridge on-prem directories to UD over outbound HTTPS — but they target different directory types.

Inbound firewall rules are not needed for Okta agents

Both the AD Agent and the LDAP Agent open outbound HTTPS connections to Okta — Okta never initiates inbound connections to your network. If a firewall team asks you to open an inbound port for 'the Okta connector', that is a misconception. Deploy the agent on an internal server, allow outbound 443, and the handshake happens automatically.

▶ Watch an AD attribute update flow all the way to Salesforce

An employee's department changes in Active Directory. See how that flows through the AD Agent, UD, an OEL mapping and profile push to Salesforce. Press Play, then Break it.

① AD changeThe AD admin updates the department attribute for Priya in Active Directory from 'Operations' to 'Engineering'.

▼

② Agent syncThe Okta AD Agent detects the change (delta import) and writes the new department value to Priya's UD profile.

▼

③ OEL mappingThe attribute mapping expression capitalises and reformats the value — 'Engineering' becomes 'Engineering-IN' (country suffix) — before storing it in UD.

▼

④ Profile pushOkta's push rule fires, sending 'Engineering-IN' to the Salesforce app user schema. Priya's Salesforce record now shows the correct department.

Press Play to step through the healthy path from AD change to Salesforce update. Then press Break it.

Quick check · Q3 of 10 · Apply

You need the Okta username to be the part of the email address before the '@'. Which OEL expression achieves this?

a) user.login + '@company.com'b) user.firstName + '.' + user.lastNamec) String.substringBefore(user.email, '@')d) Arrays.toCsvString(user.groups)

Correct: c. String.substringBefore(user.email, '@') splits the email at the '@' and returns the left part — exactly the local-part you want as the login. This is a classic OEL pattern for deriving usernames.

👉 So far: OEL expressions transform raw attributes at import or push time; AD Agent = outbound HTTPS, Windows-based, HA-capable; LDAP Agent = any RFC 4511 dir, can expose Okta as an LDAP endpoint.

④ Profile push — writing changes downstream

Profile push is the downstream half of the data flow. After UD has the authoritative, possibly transformed profile, it needs to write the right subset of attributes to each integrated app. Profile push does this automatically whenever a mapped UD attribute changes — username, department, title, or a custom field — without manual intervention.

You control what gets pushed through attribute-level push rules: some attributes sync immediately on change; others are excluded. Selective Attribute Push lets you push specific attributes independently — useful when you want to update an app's department field but not override a username the app manages itself.

Push groups vs push attributes

Okta also supports Push Groups, which replicate Okta groups into an app's own group model. Combined with profile push and OEL expressions, this gives you a full write-back loop: source directory masters the data, UD consolidates and transforms it, and push propagates the right version to every downstream system. The failure mode to avoid: pushing an attribute that the app also allows users to edit — the app's own value gets overwritten on the next push cycle.

Figure 5 — Profile push cycle end-to-end

A change in the master source travels through UD transformations and arrives in the target app automatically.

Priya at a Pune fintech faces this

After a new HR system was connected to Okta, users' job titles in Salesforce started reverting to stale values every night.

Likely cause

Both the HR app and Okta's AD agent are sending jobTitle to UD, and profile push is set to immediately overwrite the Salesforce value with whatever UD holds — but UD itself is receiving conflicting masters.

Diagnosis

Check Profile Editor ▸ Mappings for jobTitle: two sources — AD and the HR app — are both mapped to jobTitle with no mastering priority set. The last sync wins, creating a race condition.

Admin Console ▸ Directory ▸ Profile Sources ▸ jobTitle priority

Fix

Set the HR app as the sole master for jobTitle (higher priority than AD). Remove the AD-to-jobTitle mapping, or set it to 'do not override'. Re-run the HR import. Profile push will now carry the HR-authoritative title to Salesforce.

Verify

Change jobTitle in the HR system, confirm UD shows the new value, confirm Salesforce reflects it within the push interval — and that a stale AD value no longer overwrites it.

Test the full push cycle in a sandbox first

Before enabling profile push on a production app, run a test: change a mapped attribute in UD and confirm the app receives the new value within the expected push interval. Also confirm that any app-side user edits to the same attribute are correctly overwritten (or excluded, if that is your intent). Never assume push is working until you have watched it end-to-end.

Quick check · Q4 of 10 · Analyze

An app lets users update their own job title, but profile push is also set to push the jobTitle attribute. What will happen on the next push cycle?

a) Okta will merge both values into a combined fieldb) Okta will stop pushing and raise an alertc) The push will be skipped silentlyd) The app's user-edited job title will be overwritten by the UD value

Correct: d. Profile push overwrites the app's value with what UD holds. If the user edited their title in the app, that edit is lost on the next push. The fix is to exclude jobTitle from push or let the app master that attribute instead.

👉 So far: Profile push writes UD changes downstream automatically; use selective attribute push to control what syncs; avoid pushing attributes the app also allows users to edit.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.

🧠 In your own words

Type one line: what is the difference between profile sourcing and profile push in Okta? Then compare with the expert version.

Expert version: Profile sourcing is about the upstream flow: it designates which directory (AD, LDAP, HR) owns and masters each attribute in UD, locking those fields in Okta so the source remains authoritative. Profile push is about the downstream flow: it takes attributes from the UD profile — potentially transformed by OEL expressions — and writes them to integrated apps whenever a mapped value changes. Together they form a complete identity pipeline: source masters the data in UD, push propagates the right version to every app.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📩 Quiz me on this in 7 days. Opt in and we'll email 3 micro-questions on Okta at Day 1, Day 7 and Day 30 — spaced repetition is how this sticks. Un-tick any time.

📖 Glossary

Universal Directory (UD): Okta's central identity store — one profile object per user consolidating attributes from all upstream sources with a 31-attribute SCIM base schema.
Profile Editor: The Admin Console tool for viewing and extending the Okta user schema and per-app user schemas, including adding custom attributes and configuring their data types.
Profile Sourcing: The configuration that designates one upstream directory as the authoritative owner of a user's profile attributes; Okta locks those fields to prevent direct edits.
Profile Mastering: The state of a user attribute being owned by a specific source (e.g. AD-mastered); the source controls all updates and Okta reflects them after sync.
Okta Expression Language (OEL): A SpEL-based scripting language used in attribute mappings to transform, combine or reformat attribute values before they land in UD or are pushed to an app.
AD Agent: A Windows-based lightweight agent installed in an AD domain that connects to Okta over outbound HTTPS to sync users, groups and optionally passwords.
LDAP Agent: An agent that bridges any RFC 4511 LDAP directory to Okta UD and can also expose UD as an LDAP endpoint for legacy app authentication.
Profile Push: Okta's downstream sync mechanism that writes UD attribute changes to integrated apps automatically when a mapped attribute value changes.
Selective Attribute Push: A profile push setting that lets you push specific attributes to an app independently rather than syncing the full profile on every change.

📚 Sources

Okta Developer — Universal Directory concepts: user profiles, base schema and custom attributes. developer.okta.com/docs/concepts/universal-directory/
Okta Help — Make Active Directory the Profile Source (Identity Engine). help.okta.com/oie/en-us/content/topics/directory/directory_ad_enable_profile_source.htm
Okta Developer — Okta Expression Language overview guide. developer.okta.com/docs/reference/okta-expression-language/
Okta Help — Modify attributes with expressions (attribute mapping transformations). help.okta.com/oie/en-us/content/topics/users-groups-profiles/usgp-attribute-mappings-expressions.htm
Okta Help — Configure Active Directory import and account settings (AD Agent). help.okta.com/en-us/content/topics/directory/ad-agent-configure-import.htm
Okta Help — Set up and manage the LDAP Interface (LDAP Agent and LDAP endpoint). help.okta.com/en-us/content/topics/directory/ldap-interface-main.htm

What's next?

Understand the Universal Directory? Next, go deep on Okta Lifecycle Management — how Joiner, Mover, Leaver workflows use UD profiles to automate provisioning and deprovisioning across every integrated app.

Next · All interview lessons → Practice on exam.techclick.in →

Okta Universal Directory — Profiles, Mastering & Attribute Mapping

🎯 By the end you will be able to

Pick where you want to start

Profiles & schema

Sourcing & mastering

OEL & AD/LDAP agents

Profile push

① User profiles & the attribute schema

② Profile sourcing & mastering

How mastering works in practice

③ Okta Expression Language & AD / LDAP agents

AD Agent and LDAP Agent

▶ Watch an AD attribute update flow all the way to Salesforce

④ Profile push — writing changes downstream

Push groups vs push attributes

🤖 Ask the AI Tutor

📝 Wrap-up assessment — six more

🧠 In your own words

🗣 Teach a friend

📖 Glossary

📚 Sources

What's next?