User management in Linux
The following table explains how Advanced Server Access manages users on Linux servers.
By default, Advanced Server Access creates server usernames that follow the most restrictive Linux naming conventions. Usernames can contain lowercase letters (a-z), numbers (0-9), dashes (-), and underscores (_), can't be a reserved name, and have a maximum length of 32 characters. In the event a username collision occurs, an attempt is made to differentiate between users by appending a number to the server username.
|Server account permissions||
Server account permissions are managed at the group level. When a user belongs to multiple groups on a project, the user has a combination of all the permissions granted to the groups. See Team roles.
The server agent creates the sft-admin group that grants passwordless sudo to its members through a sudoers.d drop-in configuration file. If a user has admin permissions on the project, they'll be added to the sft-admin group, which in turn grants them the ability to use sudo.
Users are created and configured on Linux using standard tools, such as useradd and groupmod.
|User and group updates||
Standard tools are used to manage user and group updates, such as usermod, groupadd, and groupmod.
Users are deleted with userdel.
|Authorized principals file||
This feature is being rolled out to all Advanced Server Access customers through Q1 2023. No action is required on your part to enable this feature for your Advanced Server Access team.
Okta PolicySync uses the OpenSSH daemon (sshd) AuthorizedPrincipalsFile configuration option. See sshd_config for more information on AuthorizedPrincipalsFile.
When PolicySync is enabled, the Advanced Server Access server agent creates the file .asa_authorized_principals in the home directory of each user, on each server that they have access to. You can change where this file is created by setting the AuthorizedPrincipalsFile option in your Advanced Server Access server agent's sftd.yaml configuration file. To configure the location, you must use one of the supported per-user tokens:
For example, to configure Advanced Server Access to create the authorized principals file in the user's home directory, add the following to a server's sftd.yaml configuration file:
The Advanced Server Access server agent also updates the server's sshd_config file with the AuthorizedPrincipalsFile directive as defined in sftd.yaml.
While the Advanced Server Access server agent, sftd, modifies sshd_config, it's highly recommended that you do not modify it, either manually or through automation. Modifying the contents of sshd_config can lead to unsupported or broken configurations.