Remote Session Credential Types

In the context of Secure Remote Web Sessions, Credential Types define how the system retrieves the appropriate credentials to authenticate users against remote target systems. Proper configuration of Credential Types ensures secure, context-aware access while supporting dynamic environments with varied identity management strategies.

This article outlines the supported Credential Types, their intended use cases, and how they can be configured within the software.

Supported Credential Types

The software supports several Credential Types to accommodate authentication options for secure remote sessions. Each type determines how credentials are sourced and applied when connecting to a remote host.

Main Asset Credentials

Main Asset Credentials are the most direct method of authentication used by the software. In this model, the credentials are directly stored in the asset itself, and those same credentials are used when initiating a secure remote session to the target system.

This approach is ideal when each asset has a dedicated, unique local account used for administrative access, or when a host is not part of a broader identity infrastructure such as Active Directory.

The stored credentials can be centrally managed by the platform, including full support for password rotation, request workflows, and access expiration policies. Because credentials are tied directly to the asset, administrators can define asset-specific credential policies that meet the security and operational needs of individual systems.

Example:
A standalone Linux server uses a local account named admin-ops. The credentials for admin-ops are stored on the asset in the vault and rotated automatically every week. When a user initiates an SSH session, the session launcher retrieves the current credential version from the vault and uses it to authenticate the connection.

Main Asset Credentials are also commonly used for service accounts or systems that require frequent automated access with tightly controlled credentials. Since the credentials reside with the asset, they are easy to audit, rotate, and manage independently from user identities or external directory services.

This credential type works well in environments with:

Isolated or air-gapped systems
Hosts not joined to a domain
Systems requiring per-host credential separation
Assets managed individually rather than through shared accounts

While simple in design, this method offers robust control and is often used as a fallback when more dynamic credential models (e.g., Transit or Mirror) are not applicable.

Configuration Steps for Main Asset Credentials

To configure Main Asset Credentials for remote session access, follow the steps below:

1.Navigate to the Asset
Create or View the asset that represents the target system where remote sessions will be initiated.

2.Add Credentials to the Asset
On the Create Asset or Edit Asset page, add the credentials that will be used to authenticate to the remote host:

Enter the username and password (or key, if applicable).
Optionally configure password rotation, access policies, or workflow selectors as required by your security policy.

3.Save the Asset Configuration
Ensure the credential details are saved and the asset record is updated.

4.Launch a Session Using Main Credentials
When launching a WEB Session to the asset, select the asset’s own credentials from the Credential Type dropdown. This option is labeled Main Asset Credentials.

5.Authentication Execution
During session launch, the platform retrieves the stored credentials from the asset and uses them to authenticate to the remote system.

Note: Main Asset Credentials are managed and rotated by the software if credential rotation policies are configured. This ensures ongoing compliance and reduces manual overhead.

Transit Credentials

Transit Credentials enable a session to authenticate using the credentials of the currently logged-in 12Port user, rather than retrieving credentials stored in the vault or on an asset. This approach leverages the user’s existing identity context and passes it directly through to the remote endpoint during session establishment.

This method is particularly effective in environments where identity-based access is already enforced and credential reuse or central storage is not required. It supports seamless access without exposing or handling any static credentials.

Because authentication is performed using the user’s own credentials, session activity is inherently tied to the individual user, making it ideal for environments that require accountability, traceability, or integration with Just-In-Time (JIT) access models.

Example:
A DevOps engineer logs into the software using their domain credentials. When launching an SSH session to a Linux host, the platform passes the engineer’s own credentials through the session launcher, enabling direct access to the system without retrieving any stored secrets.

Transit Credentials do not support credential rotation or vaulting, since the platform does not store or manage the credentials used. Instead, this model relies on the organization’s identity provider or authentication infrastructure (e.g., Active Directory, LDAP, Local User) to enforce security policies, MFA, and access controls.

This type of credential is best used in trusted identity environments where users already have tightly scoped permissions, and where minimizing credential exposure is a priority.

Configuration Steps for Transit Credentials

Transit Credentials do not require any asset-specific configuration. This credential type uses the credentials of the currently logged-in user at the time the session is launched. However, there are important preconditions and restrictions that must be met for this method to connect properly.

1.Direct Login Required
Users must log in to the platform using a direct username and password. Authentication methods such as SAML or other federated identity providers are not supported with Transit Credentials, as the user's password is not made available to the session launcher in those cases.

2.Sufficient Permissions on Target Host
The user account used for Transit Credential sessions must have the required native permissions on the remote host (e.g., RDP, SSH, or other protocol-specific access rights). This credential type does not elevate or modify permissions during session launch so authentication relies entirely on the existing privileges of the user's account on the target system.

If either condition is not met, session authentication will likely fail when attempting to use Transit Credentials.

Member Credentials

Member Credentials allow a remote session to authenticate using credentials stored on a separate Member asset, which is logically associated with the primary target asset. The Member asset is selected on the Session Launcher by its displayed Asset Name, as defined in the configuration of the main asset.

This credential type supports scenarios where shared accounts are centrally managed but need to be reused across multiple target systems. It enables flexible credential reuse, independent rotation schedules, and fine-grained control over how and where privileged accounts are applied.

Ideal Use Cases
Member Credentials are ideal in environments where:

Shared service accounts (e.g., domain or functional accounts) are used across multiple hosts. See our Domain Service Credentials article for how this can be used for credential rotation.
Credentials need to be centrally stored and rotated, while being logically mapped to different endpoints.
Different accounts with varying privileges are assigned to the same host for different session purposes (e.g., support, automation, administration).

Behavior and Characteristics

The Member asset is displayed by its Name, as specified in the configuration of the main asset, on the Session Launcher.
The system uses the credentials stored on the Member asset to establish the session to the remote endpoint.
Each Member credential account can be governed by an independent password rotation strategy, history, and policy.
Multiple Member accounts can be assigned to a single host, enabling session initiators to choose the appropriate credential at launch time.

Example Scenario:
A Windows server is configured with two Member accounts:
* An Active Directory (AD) service account for general administration (ad-admin1)
* A different Active Directory (AD) service account for server support (ad-supp1)

Each Member account has its own rotation policy and is defined as a separate asset in the system. When launching a session, the user selects the required Member credential based on the task context.

This approach offers flexibility in managing privileged access at scale while avoiding the need to create and rotate local credentials on every individual host.

Configuration Steps for Member Credentials

To configure Member Credentials for use in remote sessions, perform the following steps:

1.Create the Member Asset
Begin by creating an asset that contains valid credentials. This asset will serve as the Member credential source for another asset. Ensure that credentials are stored and managed correctly on this Member asset, including any rotation or policy settings.

2.Associate the Member Asset
Navigate to the asset where you want to enable Member Credentials. On the Edit Asset page, scroll to the section labeled Member Assets.

Select the Member role.
Enter the name of the previously created Member asset.
Click Add to establish the relationship.

Repeat if additional Member assets need to be associated.

3.Confirm Association
Once added, the Member asset will appear in the list of associated Member assets for the current asset. This association allows the system to reference the credentials stored in the Member asset during session initiation.

4.Select Credential Type at Session Launch
When launching a WEB Session to the target asset, the session launcher will display a list of available Credential Types. In the dropdown, select the name of the associated Member asset to use its credentials for the session.

5.Session Authentication
The session launcher will retrieve the credentials from the selected Member asset and use them to authenticate to the remote host. The selected Member account determines the level of access granted for the session.

Each Member asset can have its own credential rotation schedule and access strategy, allowing for flexible and secure credential management across multiple systems.

Mirror Credentials

Mirror Credentials are designed to support scenarios where each user accesses remote assets using their own unique privileged account, rather than a shared account model. This approach aligns with least privilege access principles and supports enhanced tracking and control of individual user activity.

This model is especially beneficial when:

The target asset must track and audit privileged access on a per-user basis.
Users require different levels of access or permissions based on their role.
The network is designed using a Microsoft Enhanced Security Admin Environment (ESAE) or similar tiered security model.

To support these use cases, the session launcher can automatically select a mirror account, uniquely associated with each user, when initiating a WEB Session to the remote asset. The mapping of users to their respective mirror accounts is based on the Mirror Account field defined on the asset. Asset owners configure search criteria (e.g., user login, name, or directory attributes) to dynamically resolve the appropriate privileged account for each session.

Usage Example: A user logs in to the software with their regular domain account, but the system resolves and uses a corresponding red forest account to access a critical Windows server, ensuring both isolation and traceability.

What is Enhanced Security Admin Environment?
The Enhanced Security Admin Environment (ESAE), also known as a red forest, is a Microsoft-recommended architecture for securing administrative identities. It involves creating a separate, hardened Active Directory environment that mirrors regular user accounts. While Microsoft has deprecated ESAE in favor of modern PAM models to better support hybrid/cloud environments, red forest strategies are still widely used in on-premises infrastructures and across non-Microsoft applications.

ESAE allows organizations to keep regular accounts at least-privileged, while granting elevated permissions only to mirrored admin accounts within the secure forest.

Configuration Steps for Mirror Credentials

To configure Mirror Credentials for remote session access, follow the steps below:

1.Add the Mirror Account Field
Begin by adding a String field named Mirror Account to the Asset Type that will support the Mirror Account functionality. This field will contain the dynamic search criteria used to resolve the appropriate mirror credential asset for the user.

2.Define Search Criteria
In the Mirror Account field of the asset, define a search query that dynamically resolves to a unique mirror asset based on the currently logged-in user's identity.

Design the search query so that each user resolves to a unique mirror asset based on their profile attributes.

The following user-based placeholders can be used within the query:

Placeholder	Description
`${user.name}`	Account name of the currently logged-in user
`${user.firstName}`	First name of the user
`${user.lastName}`	Last name of the user
`${user.directory}`	Directory name associated with the user
`${user.mail}`	Email address of the user

Example:
If the Mirror Account field in the asset is configured with the value:

${user.name}-ADM

And the current 12Port user is bwilliams, the session launcher will resolve the mirror account search condition as:

bwilliams-ADM

The software will search for an asset whose display name or description matches the evaluated query. Ensure that the vault contains corresponding mirror assets that can be discovered via this logic.

In this example, a matching mirror asset exists in the vault and will be located using the evaluated query.

3.Start a WEB Session
When a user initiates a WEB Session to an asset with a defined Mirror Account search query:

The session launcher will execute the search using the criteria specified in the Mirror Account field.
Any mirror assets that match the evaluated query will be displayed in the Credential Type dropdown, by its Asset Name, alongside any other Credential Type options such as Member credentials.

If the search query resolves to multiple mirror assets, the first ten results will be displayed in the session launcher's Credential Type selection list.

4.Session Launch Behavior
Once a mirror asset is selected and the session is launched:

The credentials stored on the mirror asset are used to authenticate the session against the remote asset endpoint.
This enables user-specific privilege elevation without modifying the original user’s account permissions.

Because the resolved mirror account is based on the user's identity, each user may see different mirror account options, resulting in different privilege levels within the session.

Credential Type Comparison

Credential Type	Source of Credentials	Use Case	Rotation Support	Notes
Main Asset	Stored on the asset	Unique local accounts	Yes	Best for asset-local credential management
Transit	Logged-in user	User-forwarded credentials	No	Requires authenticated user session
Member	Defined Member asset	Shared accounts, e.g. AD accounts	Yes	Supports per-account rotation strategy
Mirror	Resolved via Mirror Account	Dynamic or abstracted credential logic	Yes	Based on dynamic asset relationships

Session Report Logging

All remote sessions initiated using the software are captured in the Session Report. One of the key fields in this report is the Account field, which identifies the credential used during the session.

To provide clarity on how the session was authenticated, the platform includes a prefix in the Account field that corresponds to the Credential Type used.

The format is as follows:

<credentialType>: <accountName>

Credential Type	Prefix Example	Description
Main Asset	`Main: localadm`	Indicates the credentials were taken directly from the asset.
Transit	`Transit: bwilliams`	Indicates the session used the logged-in user's own credentials.
Member	`Member: ad-admin1`	Indicates credentials were retrieved from a Member asset.
Mirror	`Mirror: contoso\bwilliamsADM`	Indicates credentials were resolved from a Mirror account asset.

This prefixing allows auditors, administrators, and support teams to quickly identify how access was granted and which identity was used during the session. It also helps differentiate between sessions that may use the same username but were sourced from different credential types.

Example:
Two sessions may both show admin-user, but one will be labeled Main: admin-user while the other could be Member: admin-user, clearly showing the source of the credentials.