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 usersIn Okta literature, we generally refer to "users" as the people who serve as Okta administrators. When we refer to "end users" we are generally referring to the people who the administrators serve. That is, those who use Okta chiclets to access their apps, but have no administrative control. 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.
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
_, 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.
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.
Admin permissions on a project will be added to the local Administrators group on any Windows server enrolled in that project.
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
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
NetUserSetInfo, defaulting user flags
UF_DONT_EXPIRE_PASSWD UF_PASSWD_CANT_CHANGE UF_NORMAL_ACCOUNT
Users are created and configured on Linux with standard tools such as
Updates to Users
Standard local user management system calls are used, such as
Standard local user management tools are used to add, modify, and remove users and groups such as
Users are deleted with
Users are deleted with
Reading System State
Standard native calls are made to read the state of local user accounts on the system such as