ScaleFT defers identity governance and specific authentication mechanisms to the team’s identity provider.
ScaleFT manages individual user accounts on a server for every individual user in the team who is granted Access or Admin permission on the project. ScaleFT 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 ScaleFT user performing the action.
User accounts managed by ScaleFT are configured to only be accessed via ephemeral client certificates issued by the Certificate Authority associated with the project that the server is enrolled in. Certificates issued by ScaleFT 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 ScaleFT 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 ScaleFT Platform makes another authorization decision and, if the user is authorized, issues a new certificate with a new cryptographic key.
User accounts managed by ScaleFT will be removed from the systems they exist on when the configuration on the ScaleFT 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 ScaleFT Agent 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 ScaleFT 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 IdP 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.
ScaleFT 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 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 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_SCRIPT | UF_PASSWD_CANT_CHANGE | UF_NORMAL_ACCOUNT | UF_DONT_EXPIRE_PASSWD.
Users are created and configured on Linux with standard tools such as
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
Standard native calls are made to read the state of local user accounts on the system such as