User Management


Advanced Server Access defers identity governance and specific authentication mechanisms to the team’s identity provider.

Advanced Server Access manages individual user accounts on a server for every individual user in the team who is granted Access or 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. permission on the project. Advanced Server Access does not support shared user accounts by default. Individual server user accounts create clarity and auditability at the system level so individual actions by a user on a system are logged as being associated with the Advanced Server Access user performing the action.

User accounts managed by Advanced Server Access are configured to only be accessed via ephemeral clientEssentially, a client is anything that talks to the Okta service. Within the traditional client-server model, Okta is the server. The client might be an agent, an Okta mobile app, or a browser plugin. certificates issued by the Certificate Authority associated with the project that the server is enrolled in. Certificates issued by Advanced Server Access include among other metadata the user account name on the system being accessed so the credential cannot be reused for a different account. These certificates have a short expiration time and are associated with individual access requests so that the Advanced Server Access platform can dynamically make individual authorization decisions. After a certificate has expired, it cannot be re-used. When a user with an expired certificate make a subsequent access attempt, the Advanced Server Access Platform makes another authorization decision and, if the user is authorized, issues a new certificate with a new cryptographic key.

User accounts managed by Advanced Server Access will be removed from the systems they exist on when the configuration on the Advanced Server Access Platform which granted them permissions on the project associated with those systems is removed. This ensures that outdated user accounts are never left behind on a system.


The Advanced Server Access 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. manages users on servers only if those servers are enrolled in a project which has “Server User Management” enabled. This feature is enabled by default in new projects.

To use Advanced Server Access without this feature requires additional configuration and coordination between the team’s identity provider and deployment automation.


Server user names are derived from data in the IdPAn acronym for Identity Provider. It is a service that manages end user accounts analogous to user directories such as LDAP and Active Directory, and can send SAML responses to SPs to authenticate end users. Within this scenario, the IdP is Okta. for the team under which the server is managed. Server user names are made compatible with the target OS and are unique within a project. If a user has been federated from another team, their server user name will be prepended with a specific prefix.

On Linux

Advanced Server Access ensures that server user account names we create by default follow the most restrictive conventions for naming on Linux. They are lowercase, can not include special characters other than - and _, can not be reserved names, and are at maximum 32 characters. In the case of collisions, numbers are added to the end of the server user name to differentiate.

On Windows

Windows server user names follow the conventions outlined for Linux server user names, except they have a maximum length of 20 characters.

Server Account Permissions

Server account permissions are managed at the group level per-project. When you grant permissions on a project to a group, you will be able to choose between allowing Access or allowing Admin permissions. If a user is part of multiple 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. on a project with different levels of permission, they will receive a superset of the granted permissions.

On Windows

Users granted Admin permissions on a project will be added to the local Administrators group on any Windows server enrolled in that project.

On Linux

The agent creates an sft-admin group on the server which grants passwordless sudo to its members via a sudoers.d drop-in configuration file. If a user has been granted Admin permissions on the project, they will be added to the sft-admin group.

User Creation

On Windows

Users with access permission are added to the Remote Desktop Users group if they do not already belong to it. User accounts are created and configured with standard native calls such as NetUserAdd and NetUserSetInfo, defaulting user flags UF_SCRIPT UF_PASSWD_CANT_CHANGE UF_NORMAL_ACCOUNT UF_DONT_EXPIRE_PASSWD.

On Linux

Users are created and configured on Linux with standard tools such as useradd and groupmod.

Updates to Users

On Windows

Standard local user management system calls are used, such as NetLocalGroupDelMembers and NetLocalGroupAddMembers.

On Linux

Standard local user management tools are used to add, modify, and remove users and groups such as usermod, groupadd, and groupmod.

Deleting Users

On Windows

Users are deleted with NetUserDel.

On Linux

Users are deleted with userdel.

Reading System State

On Windows

Standard native calls are made to read the state of local user accounts on the system such as NetUserEnum, NetLocalGroupGetMembers, LookupAccountSidW, WTSEnumerateSessions, and WTSQuerySessionInformation.