Summary and recommendation
SaltStack user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
SaltStack Config - now distributed as VMware Tanzu Salt under Broadcom - is a self-hosted IT automation and configuration management platform.
It does not expose a native SCIM 2.0 endpoint, so user lifecycle management falls entirely on administrators working through the web UI or an upstream identity provider.
Licensing requires direct engagement with Broadcom sales;
no public pricing tiers are listed.
Quick facts
| Admin console path | Administration > Users (within the SaltStack Config / VMware Aria Automation Config web UI) |
| SCIM available | No |
| SCIM tier required | Enterprise |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Administrator | Full access to all features including user management, system configuration, job execution, target management, and all Salt operations. | Administrator role is a built-in role and cannot be deleted or modified. | |||
| Operator | Can execute jobs, manage minions, and view results. Cannot manage users or system-level configuration. | Cannot create or manage users, cannot modify system-level settings. | |||
| Read-Only / Viewer | Can view jobs, targets, and results but cannot execute jobs or make changes. | Cannot execute jobs, cannot modify any configuration, cannot manage users. | |||
| Custom Role | Permissions are defined by the administrator using granular permission sets across resource types (jobs, targets, minions, files, etc.). | Custom roles require careful permission scoping; overly broad permissions can grant unintended access to sensitive Salt operations. |
Permission model
- Model type: hybrid
- Description: SaltStack Config uses a role-based access control (RBAC) model with built-in roles (Administrator, Operator, etc.) and the ability to create custom roles by combining granular permission sets. Permissions can be scoped to specific resource types including jobs, targets, minions, file server, and configuration items.
- Custom roles: Yes
- Custom roles plan: Not documented
- Granularity: Resource-type level permissions (jobs, targets, minions, file server, pillars, keys, etc.) with create/read/update/delete actions per resource type.
How to add users
- Log in to the SaltStack Config / VMware Aria Automation Config web UI as an Administrator.
- Navigate to Administration > Users.
- Click 'Add User' or the equivalent create button.
- Enter the required user details (username, email, password for local users).
- Assign one or more roles to the user.
- Save the new user record.
Required fields: Username, Email address, Password (for local authentication users), Role assignment
Watch out for:
- Local user accounts are separate from LDAP/AD-sourced accounts; mixing authentication sources requires careful planning.
- If SSO/LDAP is configured, users may be provisioned automatically on first login rather than requiring manual creation.
- Role assignments must be made at creation time or updated afterward; users with no role assigned may have no effective access.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise (requires SSO/LDAP configuration, available in enterprise deployments) |
How to remove or deactivate users
- Can delete users: Yes
- Delete/deactivate behavior: SaltStack Config / VMware Aria Automation Config supports deleting local user accounts through the Administration > Users interface. LDAP/SSO-sourced users are managed at the identity provider level; disabling them in the IdP prevents login but may not remove the user record from the SaltStack Config database.
- Log in as an Administrator.
- Navigate to Administration > Users.
- Select the user to be removed.
- Use the delete or deactivate option available in the user record actions.
| Data impact | Behavior |
|---|---|
| Owned records | Job history and audit logs associated with the deleted user are retained in the system for audit purposes. |
| Shared content | Not documented |
| Integrations | Not documented |
| License freed | Removing a user frees the associated named-user license seat, subject to the terms of the Broadcom/VMware license agreement. |
Watch out for:
- Deleting an LDAP/SSO-sourced user from SaltStack Config does not disable the account in the identity provider; the IdP account must be disabled separately.
- If a deleted user is re-provisioned via LDAP/SSO on next login, a new user record may be created automatically.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Named User | Access to SaltStack Config / VMware Tanzu Salt web UI and API for one named individual user. | Contact Broadcom for current pricing. |
- Where to check usage: Administration > Users (review active user count in the web UI)
- How to identify unused seats: Review the last login date column in Administration > Users to identify accounts with no recent activity. No automated unused-seat report is documented in official sources.
- Billing notes: SaltStack is now part of Broadcom's VMware Tanzu portfolio. Pricing and licensing terms require direct engagement with Broadcom sales. Legacy VMware ELA terms may apply for existing customers.
The cost of manual management
Without automated provisioning, every app in your stack that touches SaltStack requires a manual touchpoint each time a user joins, changes roles, or leaves. Administrators must navigate to Administration > Users for every add, role change, or deletion of local accounts.
LDAP/SSO-sourced accounts reduce creation overhead but still require IdP-side disablement on offboarding - the SaltStack user record is not automatically purged, which creates orphaned entries over time.
Identifying unused seats means manually reviewing the last-login column in Administration > Users; there is no automated unused-seat report documented in official sources. For teams managing infrastructure access at scale, this gap compounds audit and compliance risk.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Every app in a modern access management program benefits from automated provisioning, and SaltStack is a notable exception - there is no native SCIM endpoint and no programmatic way to create or remove users outside the web UI or an upstream LDAP/AD backend.
Manual management is viable for small, stable teams where access changes infrequently and a well-configured LDAP backend is already in place.
For organizations with higher user churn, mixed authentication sources, or compliance requirements around access certification, the lack of SCIM and the absence of automated unused-seat reporting create meaningful operational overhead. Role assignment must be handled at creation time or corrected afterward;
users with no role assigned have no effective access, which can cause silent access failures.
Bottom line
SaltStack / VMware Tanzu Salt requires hands-on user administration unless a well-configured LDAP/AD backend is in place. Every app in a modern stack benefits from automated provisioning, and SaltStack's lack of native SCIM means it remains a manual exception.
The multi-brand documentation history adds lookup friction, and offboarding LDAP-sourced users demands a two-step process - IdP disable plus periodic SaltStack record cleanup - to avoid stale account accumulation.
Teams should factor this operational cost into their access management planning, particularly given that Broadcom licensing terms require direct sales engagement to establish seat counts.
Automate SaltStack workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
