-
Title
Mapped Users – Use Cases and Limitations -
Description
Safeguard Authentication Services (SAS) supports mapped users, allowing existing local UNIX accounts to authenticate using Active Directory (AD) credentials. This approach centralizes authentication and password policy enforcement while preserving existing UNIX identities.
This article explains when mapped users are appropriate, common supported use cases, and scenarios where mapped users are not recommended.
-
Cause
A mapped user is a local UNIX account that is associated with an Active Directory user account for authentication. The UNIX identity (UID, GID, home directory, shell) continues to be sourced from the local system, while authentication is performed against Active Directory using Kerberos. The local UNIX password is no longer used, and AD password policies apply.
Users authenticate using their local UNIX username and their Active Directory password.
User mappings are stored locally (for example, in mapping files or local identity sources) and are not written back to Active Directory.
-
Resolution
Use Case Scenarios Where Mapped Users Make Sense
1. Rapid Enablement of Active Directory Authentication
Mapped users provide a fast and low‑impact way to move authentication to Active Directory without re‑creating users or modifying existing UNIX account data. This is useful when immediate central authentication is required, but identity refactoring is not feasible.
2. Applications That Require Local UNIX Accounts
Some applications require a local UNIX account to exist and cannot use directory‑based identities directly. Mapped users allow these applications to continue using local accounts while authentication is centralized in Active Directory, eliminating the need for local password management.
3. Phased Migration from Local or NIS Accounts
Mapped users are commonly used during staged migrations from local files or NIS to Active Directory. Authentication can be centralized first, while UNIX identity attributes remain local. This reduces risk and allows identity consolidation to occur later.
4. Environments with Non‑Uniform UID Assignments
In environments where the same username exists across multiple systems with different UIDs, mapped users allow each local account to map to a single AD identity. This avoids the need for disruptive UID alignment while still providing centralized authentication and auditing.
5. Security and Compliance Improvements with Minimal Change
Mapped users enable enforcement of AD password policies, Kerberos authentication, and centralized logging without changing local UNIX identity data. This is useful for compliance initiatives where system changes must be minimized.
When Not to Use Mapped Users
1. New or Greenfield UNIX Deployments
For new systems, it is generally better to use fully UNIX‑enabled Active Directory users with identity attributes stored in AD. This avoids long‑term reliance on local identity sources and simplifies identity management.
2. Environments Requiring Centralized Identity Data in AD
Mapped users keep UNIX identity data local and do not store mappings in Active Directory. If centralized lifecycle management, reporting, or identity governance is required, fully UNIX‑enabled AD users are more appropriate.
3. Long‑Term Identity Standardization Projects
Mapped users are intended as a transitional or compatibility solution. For environments pursuing long‑term standardization of identities, UID/GID consistency, and directory‑centric management, mapped users may introduce unnecessary complexity.
4. Scenarios Requiring AD‑Based Authorization Decisions
Because mapped users rely on local identity sources, some authorization models that depend entirely on AD‑stored UNIX attributes may not be fully supported. In these cases, native AD UNIX identities are preferred.
Additional Notes
- Mapped user configurations are stored locally and must be maintained on each system or via centralized configuration tools (for example, VGP).
- Mixed environments are supported, where some systems use mapped users and others use fully UNIX‑enabled AD users.
- Mapped users are commonly used as a migration or compatibility mechanism, not as a permanent identity architecture.
For more information about mapping local users, please visit our admin guide