Help desk admin role
The help desk administrator can perform common help desk actions. This role has a reduced set of permissions and promotes good security practices by not granting unnecessary permissions to help desk personnel.
You cannot selectively assign permissions to the help desk administrator role. Instead, it has these fixed permissions:
- Reset password
- Create a temporary password for users in a Pending status using "set password and activate" button
- Reset Multifactor Authentication
- Unlock account
- Clear user session
- View user profiles in the groups to which the admin has been assigned
The help desk administrator role does not have the following permissions:
- Create and activate users
- Suspend and delete users
- Assign users to apps or groups
- Initiate Okta directory specific actions
- View or modify users outside the assigned group(s)
- Create API tokens
The help desk administrator can perform these actions on all users or on select groups of users. This provides granular administrative control. The help desk administrator cannot view or modify users outside of the selected group. Delegated administration allows you to spread administrative duties and, more importantly, segregate duties so that no administrator has too much control.
Note: While the help desk administrator can't create API tokens, you can create an API token for this role's privileges for any given help desk admin. For example, you may implement a Reset MFA button in an application using Okta APIs and API tokens. For more information about API tokens, see API tokens. For information about Okta APIs, see Getting started with the Okta API.
The help desk administrator role may be useful in these scenarios:
- You have a single help desk that does not need excessive permissions to perform the role.
- You have a Tier 1 IT that handles high volume account transactions such as password resets.
- Your organization has branches, brands, or franchises that have separate IT teams.
- You have business units that need to perform actions on just their own users.
- You have outsourced service vendors that need to perform actions on just their own users.
Only super admins may assign the help desk admin role to a user and optionally apply a group scope.
To assign the help desk administrator role to a user, do the following:
In the Admin Console, go to Security > Administrators.
Click Add Administrator. In the resulting dialog box, do the following:
- Type an administrator name into the Grant Administrator Role to field.
- Select the Help Desk Administrator role.
- Select Can administer user in specific groups (recommended).
- Type in the group name of the Okta groups the admin will control. You can also select Active Directory (AD) or LDAP groups in addition to Okta groups. This allows you to assign specific AD or LDAP groups for the Help Desk admin to handle.
If you want your Help Desk Administrator to perform operations on users that delegate authentication to AD, you’ll also have to configure the AD policy:
In the Admin Console, go to Security > Policies.
Select Active Directory Policy.
- Edit the Legacy Rule to indicate that the user can change passwords.
- Click Update Rule.
- Sign in to Okta with an account that’s been designated a help desk administrator.
- In the Admin Console, go to Directory > People.
- Select a user account
- To reset a user’s password, click Reset Password.
- To perform any of the other options, click More Actions.
Help desk admins can't activate a suspended or deactivated account. But, once that user becomes active and is in a Pending user action state, the help desk admin can create a temporary password for the end user. However, because the help desk admin can't send the activation email to the end user, they must provide the temporary password to the end user directly.
Groups have not fundamentally changed within Okta, but they are more useful and powerful when used with the help desk administrator role. Getting the most out of delegated administration requires careful selection of Okta groups. The groups you choose should reflect your organization's structure or boundaries of control.
For example, an organization shares Okta-protected resources with two business units, A and B, each with their own users and separate IT teams who manage those users. It is important for the organization to maintain strict boundaries of control within Okta. A's IT team should only be able to view and manage A's users in Okta. Similarly, B's IT team should only be able to view and manage B's users in Okta. The organization can accomplish this by:
- Giving A and B separate help desk administrators roles in Okta
- Scoping A's help desk administrator role to Group A, which consists only of A's users
- Scoping B's help desk administrator role to Group B, which consists only of B's users