Help CenterGet A DemoTry It Free

Identity Aliases

Overview

Identity Aliases enable your organization’s users to authenticate to RDP, SSH, or Kubernetes resources using their own individual username(s) rather than a leased credential.

An Identity Alias is a username (string) or email that is unique to an individual user or service account, that the user can use to authenticate to an Identity Alias-enabled resource. When logging in to a server via an SSH client, for example, users typically log in with a username and password that are not shared with anyone else. Their individual activities are written to the resource’s native logs under their username.

Identity Aliases are different than leased credentials, which are shared across multiple users and service accounts. In a StrongDM organization that uses the leased credential method of authentication, all users authenticate with the same leased credential in order to access the resources that have been granted to their assigned role(s), and individual activities are written to the organization’s logs.

Users may have multiple Identity Aliases, and each Identity Alias is mapped to an Identity Set. Users may have only one Identity Alias per Identity Set.

Identity Sets

An Identity Set is a set of Identity Aliases that are allowed to be used to connect to specific resources.

Your organization may define multiple Identity Sets, and each user may have their own Identity Alias for each Identity Set. For example, your organization might have an Identity Set called “RDP Users” defined for connecting to all RDP resources, plus another Identity Set called “SSH Users” for connecting to all SSH resources. In this example, each Identity Set includes different Identity Aliases for the users connecting to those resources.

Another type of Identity Set is the Email Identity Set. This set is automatically created to contain Email Identity Aliases, which are the Identity Aliases automatically created or updated when a user or service account is created or updated. For users, the Email Identity Alias is the user's email address. For service accounts, the Email Identity Alias username is the name of the service account. The Email Identity Alias is automatically deleted when the user or service account is deleted.

Because the Email Identity Aliases within the Email Identity Set are automatically created, updated, and deleted when the users or service accounts are, this type of Identity Set is useful for those who want to use Identity Aliases without having to configure or maintain them. The Email Identity Set is also useful in instances where the usernames on the resource are the same email addresses of the users within StrongDM.

Resources That Support Identity Alias Authentication

The option to authenticate with Identity Alias usernames is available for the following resource types only:

  • AKS cluster

  • AKS (Service Account) cluster

  • AWS Management Console

  • AWS Management Console (Static key pair)

  • Elastic Kubernetes Service cluster

  • Elastic Kubernetes Service (instance profile) cluster

  • Google Kubernetes Engine cluster

  • Kubernetes cluster

  • Kubernetes (Service Account) cluster

  • RDP server

  • RDP (Certificate Based) server

  • SSH (Certificate Based) server

  • SSH (Customer Managed Key) server

Management of Identity Sets

Identity Sets may be created, updated, and deleted using the Admin UI, CLI, and SDKs (unless they are read-only Identity Sets). Note that deletion may only happen if the Identity Set is not in use by a resource.

In addition, Identity Sets may be created via SCIM (but not deleted or updated). Identity Aliases, however, may be created, updated, and deleted via SCIM.

An activity is generated every time an Identity Set is created, updated, or deleted.

Admin UI

In the Admin UI, you can create Identity Sets by going to Principals > Identity Sets and clicking Add set.

Every Identity Set has three tabs:

  • Users: Displays all users who have Identity Aliases in the Identity Set; clicking a user's name opens the user's profile and shows their Identity Aliases

  • Resources: Displays all resources that are configured to use the Identity Set for authentication; clicking a resource name opens the resource's configuration form

  • Settings: Shows the name of the Identity Set; for all Identity Sets except read-only Email Identity Sets, also lets you rename and delete the set if it isn't assigned to any resources

You can add a user's Identity Alias by going to their profile in Principals > Users. See Principals to learn how to add Identity Aliases.

Usage example: use Identity Aliases with RDP servers

Identity Aliases can be used to authenticate users to RDP servers with password-based authentication. In this setup, each user’s alias corresponds to a secret in your external secret store that contains their RDP credentials (username and password).

The RDP server resource uses the $SDM_USERNAME variable in its username and password paths to look up the correct secret for the connecting user. For example, for managed secrets in the Active Directory secrets engine, the secret paths are formatted in the following way:

  • path/to/user/$SDM_USERNAME?key=username

  • path/to/user/$SDM_USERNAME?key=password

For full configuration steps, see RDP Server Authentication. To learn more about storing user credentials, see Secrets Management.

CLI

Identity Sets and Identity Aliases are managed in the CLI using sdm admin identities. The subcommands of sdm admin identities allow you to create, update, delete, and list Identity Sets and Identity Aliases.

The following example provides a general idea of how to set up Identity Sets and Identity Aliases.

Please see the CLI Reference for a copy of the help text for sdm admin identities.

SDKs

To manage Identity Sets with the StrongDM SDKs, please see the SDKs on GitHub:

SCIM provisioning

If your users are managed by an identity provider, such as Entra ID, Okta, or OneLogin, you can set up the provider's application to pass Identity Set and Identity Alias values for users when they are provisioned.

Please note that Identity Sets may be created via SCIM (but not deleted or updated). Identity Aliases may be created, updated, and deleted via SCIM. Email Identity Aliases are ignored by SCIM because they are read-only.

To learn how to set up Identity Sets and Identity Aliases, please see the provisioning guides for each provider:

Last updated

Was this helpful?