Puppet User Management Guide

• Model type: role-based
• Description: Puppet Enterprise uses Role-Based Access Control (RBAC). Permissions are assigned to roles, and users are assigned to one or more roles. Predefined roles exist (Administrators, Operators, Viewers, Code Deployers, etc.). Administrators can create custom roles with granular permission sets drawn from a defined permissions catalog.
• Custom roles: Yes
• Custom roles plan: Puppet Enterprise
• Granularity: Permissions are object-type and action scoped (e.g., 'Nodes: view', 'Puppet agent runs: run', 'Users: edit', 'Roles: edit'). Permissions can be scoped to specific node groups or applied globally.

1. Log in to the PE console as an Administrator.
2. Navigate to Access Control > Users.
3. Click 'Add local user'.
4. Enter the user's full name and login (username).
5. Click 'Add local user' to save.
6. Click the user's name to open their profile.
7. Click 'Generate password reset' and send the link to the user so they can set their password.
8. Assign the user to one or more roles via Access Control > Roles, selecting the role and adding the user.

Required fields: Full name, Login (username)

Watch out for:

• New local users cannot log in until they set a password via the generated reset link; there is no option to set a password directly during creation.
• Users must be explicitly assigned to at least one role to have any permissions in the console.
• Users imported from an external directory (LDAP/AD) are created automatically on first login if directory integration is configured; they do not need to be manually added.
• Email address is not a required field for local users; the login field is the unique identifier.

• Can delete users: Yes
• Delete/deactivate behavior: Puppet Enterprise supports both revoking (deactivating) and deleting users. Revoking a user prevents them from logging in but retains their record. Deleting a user permanently removes them from the PE console. Both actions are available via the PE console UI and the RBAC API. The built-in 'admin' user cannot be deleted.

1. Log in to the PE console as an Administrator.
2. Navigate to Access Control > Users.
3. Click the user's name.
4. To revoke (deactivate): click 'Revoke user access'. The user's status changes to 'Revoked' and they cannot log in.
5. To delete: use the RBAC API DELETE /rbac-api/v1/users/ endpoint, or use the 'Delete' option if available in the console UI for that PE version.

Watch out for:

• The default 'admin' user cannot be revoked or deleted.
• Revoking a user from an external directory does not remove them from the directory itself; it only prevents PE console access.
• If a revoked directory user is re-imported (e.g., logs in again after revocation is lifted), their role assignments may need to be re-verified.
• Deleting a user via the API requires the user's subject ID (sid), not their username.

• Where to check usage: PE console > License (or via the pe_license fact and 'puppet license' command on the primary server)
• How to identify unused seats: Run 'puppet license' on the PE primary server to view total licensed nodes vs. active nodes. Nodes not checking in can be identified via the PE console's node list filtered by last check-in date.
• Billing notes: Puppet Enterprise is billed per managed node per year, not per user. Adding or removing console users has no direct billing impact. Volume discounts and custom pricing are available for large deployments.

Puppet Enterprise is licensed per managed node, not per console user. Adding or removing user accounts has no direct billing impact. Node licensing is priced annually per node, with Standard and Premium support tiers and volume discounts available for large deployments.

Without automation or directory integration, each onboarding and offboarding event is a manual, multi-step process: create the user, generate a password reset link, send it out-of-band, then assign roles separately. There is no built-in email notification and no bulk import path for local users.

Community evidence is not specific enough to quote or summarize yet for this app.

Every app and service account that needs PE console access must be explicitly created and role-assigned - there is no automated provisioning without directory integration or API tooling.

For any team larger than a handful of people, LDAP or Active Directory integration is the operationally sound choice: remote users are created automatically on first login and bypass the manual password reset flow entirely.

Custom roles are only available in Puppet Enterprise. If your permission requirements go beyond the four predefined roles, confirm you are on a PE license before investing time in RBAC design.

Revocation (disabling access without deleting the record) is the safest offboarding action for auditing purposes. Permanent deletion requires either the RBAC API or a PE version that exposes the delete option in the console UI - verify your version before relying on the UI alone.

Bottom line

Puppet Enterprise's RBAC system is capable and granular, but it is built for infrastructure teams comfortable with manual workflows or directory integration - not for organizations expecting automated provisioning out of the box.

Every app and service account that needs PE console access must be explicitly created and role-assigned, with no bulk import and no native email delivery for credentials. Teams that invest in LDAP/AD integration or API-driven provisioning will eliminate the most painful manual steps;

teams that do not will find user lifecycle management to be a persistent, low-level operational burden.