Okta Certified Administrator: Least-Privilege Helpdesk Admin and an Over-Privileged API Token

Least-Privilege Helpdesk Admin and an Over-Privileged API Token

An 8,000-user Okta org has 12 EMEA help-desk agents holding the built-in Help Desk Administrator role. That role lets them reset passwords and unlock accounts for all 8,000 users and also edit profile attributes. An audit found three of them changed the primaryEmail of five Finance users. The requirement now is narrow: EMEA agents may reset passwords and unlock accounts for the 3,100 EMEA users only, and must not view or edit profile data. Separately, a nightly PowerShell synchronisation uses an API token minted by a Super Administrator and hard-coded in a scheduled task on a shared server. It performs roughly 12,000 user updates in 20 minutes and intermittently receives HTTP 429 responses with an X-Rate-Limit-Reset header. The sync's failures cause partial updates that nobody notices until the next morning.

1. Design the least-privilege admin model, including what you would verify before rollout.

Read the worked answer

Role design. Create a custom role, for example EMEA-Helpdesk-Password-Reset, containing only the permissions the agents actually need: reset password and unlock account. Do not include profile edit, MFA reset, or group management unless each is separately justified. If the edition does not support the specific permission combination, say so and escalate to the Okta account team rather than silently falling back to the built-in role.

Resource set. Create a resource set scoped to a rule-driven group, EMEA-Users, containing the 3,100 users. Scope by group membership, not by a list of user IDs, because the population changes daily.

Assignment. Assign the custom role to a group, EMEA-Helpdesk, not to twelve individuals. Adding a new agent then becomes a group membership change with an audit trail.

Cutover. Remove the built-in Help Desk Administrator role in the same change window. Running both in parallel defeats the purpose, because the broader role still grants org-wide scope.

Verify before rollout, and write down the results:

Positive test: an agent resets an EMEA user's password and unlocks the account.
Negative test by scope: the same agent attempts an action on a US user and receives a 403, not a silent success.
Negative test by permission: the agent attempts to edit a profile attribute and is denied, and also cannot read the attribute.
Confirm the custom role cannot be used to modify group membership, which would let an agent re-scope their own resource set.

If any negative test passes when it should fail, stop: the scoping is not working and the change has not achieved the audit requirement.

2. Remediate the Super Administrator API token and explain why your approach is durable.

Read the worked answer

Current state. The token inherits the full permissions of the Super Administrator who created it, so the scheduled task can do anything in the org. It is stored on a shared server in plaintext, which means the number of people with effective super-admin access is unknown.

Remediation steps:

Identify every token and its creator from the System Log (system.api_token.create events) so you know what else may be lurking.
Create a dedicated service identity, for example svc-hr-sync, and give it a custom role scoped only to the user lifecycle operations and the groups the sync genuinely touches. Never run an integration as a human super admin.
Generate the replacement token as that service identity, so the token's effective permissions equal the narrow role rather than the creator's.
Store the token in a secrets manager and have the scheduled task retrieve it at runtime. Remove it from the script and from the server's file system, and check the server's shell history and backups for the old value.
Revoke the old Super Administrator token, confirm the sync still runs, and rotate the replacement on a defined schedule.
Alert on any new system.api_token.create event and on any token used from an unexpected source.

Why this is durable: the previous design coupled an integration's blast radius to whichever human created the token. Scoping to a service identity decouples those, so the next person who rotates the token cannot accidentally grant super-admin rights, and a leaked token is limited to HR sync operations rather than the whole org.

3. Diagnose the 429 responses and describe how you would change the sync so partial updates stop happening.

Read the worked answer

Diagnosis. 12,000 updates in 20 minutes averages around 600 requests per minute, which is right at the ceiling for many Okta endpoints and will not be evenly distributed: the sync likely bursts at the start. When the limit is hit, Okta returns 429 with X-Rate-Limit-Reset, and the script presumably retries immediately or abandons the user. Either behaviour produces partial updates.

Fixes, in order of impact:

Honour the reset header. On a 429, wait until the epoch time in X-Rate-Limit-Reset (plus jitter) before retrying. Do not retry immediately; that deepens the burst.
Reduce request volume rather than optimising the retry. Use pagination with a large page size, use search with a lastUpdated filter so only changed users are processed instead of all 12,000, and cache lookups within a run instead of re-reading each user after each write.
Move to event-driven where possible: subscribe to System Log streaming or lifecycle events and act on deltas instead of polling nightly.
Spread the load across a wider window, or split the sync into shards with independent backoff.
Make the job idempotent and idempotency-checked: record per-user success in a run table so a retry resumes rather than restarting, and a failed run is visible the same night, not the next morning.
Alert on any run that ends with users in an unprocessed state.

Do not treat a rate-limit increase as the fix. Higher limits only move the ceiling; the bursty design and lack of resumability will fail again at the next growth in user count.