Roles

Overview

Roles in FreeIPA are the top-level component of role-based access control (RBAC), enabling fine-grained delegation of administrative authority. Roles group privileges together and assign them to users, groups, hosts, or services, granting specific administrative capabilities without requiring full administrator access. This hierarchical RBAC model (permissions → privileges → roles) enables flexible, auditable delegation matching organizational structure and responsibilities.

The RBAC hierarchy consists of three layers: permissions (low-level LDAP operations like “add user” or “modify group”), privileges (collections of related permissions like “User Administrator”), and roles (assignments of privileges to entities). Roles serve as the assignment mechanism, connecting privileges to users, groups, hosts, or services that need administrative capabilities.

IPA includes built-in roles (User Administrator, Helpdesk, Security Architect) providing common delegation patterns. Custom roles enable organization-specific delegation, combining privileges in unique ways to match local requirements. Role membership is dynamic: when users join groups with role membership, they automatically acquire role privileges; when they leave groups, privileges are revoked.

RBAC Hierarchy

Permissions are the foundation, defining specific LDAP operations (add, delete, modify, read) on specific object types (users, groups, hosts). Permissions are granular and technical, typically not managed directly by most administrators.

Privileges collect related permissions into meaningful administrative capabilities. For example, the “User Administrator” privilege includes permissions to add users, modify users, delete users, and related operations. Privileges provide abstraction over technical permissions.

Roles assign privileges to entities (users, groups, hosts, services). Roles are the delegation mechanism: “Junior Admins” role might include “User Administrator” and “Group Administrator” privileges, granting user and group management capabilities to whoever holds the role.

This hierarchy enables separation of concerns: permission design is technical (LDAP-level), privilege design is functional (what administrative tasks are needed), and role design is organizational (who needs which administrative capabilities).

Built-in Roles

IPA ships with several built-in roles for common delegation scenarios:

User Administrator: Full user and group management capabilities. Can create, modify, delete users and groups. Suitable for HR or identity management teams.

Helpdesk: Password reset and account unlock capabilities. Can reset user passwords and unlock locked accounts without broader administrative access. Ideal for support teams.

Security Architect: Manages HBAC and sudo rules, controlling access policies. Can create and modify HBAC rules, sudo rules, and related policy objects.

Enrollment Administrator: Can enroll hosts into the IPA domain. Delegates host enrollment without granting full host management.

Built-in roles cannot be deleted but can be modified (privileges added/removed). Organizations typically use built-in roles as-is or create custom roles for specific needs.

Custom Roles

Custom roles enable organization-specific delegation patterns. Create custom roles when built-in roles don’t match requirements or when specific privilege combinations are needed frequently.

Custom role creation follows a pattern: define the role (role-add), add appropriate privileges (role-add-privilege), then assign members (role-add-member). Role names should clearly indicate purpose (database-admin, project-manager, audit-viewer).

Custom roles can combine privileges in unique ways. For example, an “Application Administrator” role might include user management, service management, and certificate issuance privileges, enabling application teams to manage their own identities and services.

Role Membership

Roles can have individual users, user groups, hosts, host groups, or services as members. Group-based membership is most common, enabling role assignment that automatically adapts to group membership changes.

User and group membership grants administrative privileges to people. When a user is a direct role member or belongs to a group that is a role member, they acquire all privileges associated with the role. These privileges enable administrative operations through ipa commands and web UI.

Host and host group membership grants administrative privileges to systems. Hosts with role membership can perform administrative operations using their host credentials, enabling automation workflows where systems manage IPA objects (e.g., provisioning systems creating users, service deployment systems managing service principals).

Service membership grants privileges to specific service principals. This specialized membership supports scenarios where services need administrative capabilities distinct from their host’s capabilities.

Privilege Assignment

Privileges are assigned to roles through role-add-privilege, creating the link between abstract capabilities (privileges) and concrete assignments (roles). A role can have multiple privileges, and a privilege can be assigned to multiple roles.

When designing role privilege assignments, consider the principle of least privilege: grant only the privileges necessary for the role’s intended function. Overly broad privilege grants increase security risk and audit complexity.

Privilege assignment is additive: all privileges assigned to a role are available to role members. There is no deny mechanism; if a user holds multiple roles, they receive the union of all roles’ privileges.

Role Evaluation and Effective Privileges

When a user performs an administrative operation, IPA evaluates their effective privileges by examining all roles they hold (directly or through group membership) and collecting all associated privileges. If any held privilege grants the required permission, the operation succeeds.

Role evaluation is dynamic: adding a user to a group with role membership immediately grants them the role’s privileges. Removing them from the group immediately revokes privileges. This real-time evaluation ensures authorization reflects current organizational structure without manual updates.

Effective privilege calculation considers nested group membership: if a user is in a group that’s in another group that has role membership, the user receives role privileges through the nested relationship. This enables hierarchical organizational structures.

Role Constraints and Limitations

No role nesting: Roles cannot contain other roles as members. This prevents complex delegation chains that would complicate privilege auditing and create potential security gaps.

Privilege-based only: Roles only grant privileges; they don’t restrict access. All access control is positive (grant-based). There’s no way to create roles that explicitly deny operations.

Single RBAC instance: All role definitions, privilege assignments, and memberships are part of a single RBAC system. There’s no separate RBAC per application or subsystem.

Best Practices

Use group-based role membership: Assign roles to groups rather than individual users. This enables role assignment changes through group membership management, which is often already part of organizational workflows.

Create purpose-specific roles: Design roles around organizational functions (helpdesk-role, app-team-admin) rather than individuals. This improves clarity and enables role reuse.

Document custom roles clearly: Maintain clear documentation of custom role purposes, included privileges, and intended membership. RBAC can become complex; documentation prevents confusion.

Regular role audits: Periodically review role membership and privilege assignments. Remove users who no longer need administrative access, and adjust privilege grants to match current requirements.

Start with built-in roles: Before creating custom roles, verify built-in roles don’t meet requirements. Built-in roles are well-tested and documented.

Test role privileges: After creating custom roles, test with non-production accounts to verify granted privileges work as expected and don’t grant unintended capabilities.

Minimize administrative roles: Not all power users need administrative privileges. Reserve role membership for users genuinely requiring administrative capabilities.

Combine roles judiciously: Users can hold multiple roles, but excessive role accumulation indicates poorly designed roles. If most administrators need three roles, consider whether they should be one role.

Audit role usage: Monitor which roles are actually used and which privileges within roles are exercised. Unused roles or privileges may indicate overcomplicated RBAC or privilege creep.

Integration with Other IPA Components

Privileges (privilege-*): Privileges are the components assigned to roles. Privilege management enables adjusting role capabilities by adding or removing privileges.

Permissions (permission-*): Permissions are the foundation of privileges. Understanding permission structure helps design effective privileges and roles.

User and Group Management (user-*, group-*): Users and groups are role members, receiving administrative capabilities through role membership.

Host and Host Group Management (host-*, hostgroup-*): Hosts and host groups can be role members, enabling automated administrative operations.

Service Management (service-*): Services can be role members, granting administrative capabilities to specific service principals.

Delegation Rules (delegation-*): Delegation rules provide alternative delegation mechanisms for specific scenarios. Roles are the primary delegation approach.

Audit Logging: Role-based operations are logged with actor identity, enabling audit trails of who performed which administrative actions based on which role.

EXAMPLES

Add a new role:

ipa role-add --desc="Junior-level admin" junioradmin

Add some privileges to this role:

ipa role-add-privilege --privileges=addusers junioradmin
ipa role-add-privilege --privileges=change_password junioradmin
ipa role-add-privilege --privileges=add_user_to_default_group junioradmin

Add a group of users to this role:

ipa group-add --desc="User admins" useradmins
ipa role-add-member --groups=useradmins junioradmin

Display information about a role:

ipa role-show junioradmin

The result of this is that any users in the group ‘junioradmin’ can

add users, reset passwords or add a user to the default IPA user group.

Use Cases

Delegating Password Reset to Helpdesk Team

Helpdesk teams frequently need to reset user passwords and unlock accounts without requiring full User Administrator privileges. Create a focused role granting only password management capabilities.

# Create a helpdesk role using built-in Helpdesk role
ipa role-show "Helpdesk"
  Role name: Helpdesk
  Member privileges: Modify Users and Reset passwords, Unlock user

# Create helpdesk group and add members
ipa group-add helpdesk-team --desc="IT Helpdesk staff"
ipa group-add-member helpdesk-team --users=alice,bob,charlie

# Assign helpdesk role to group
ipa role-add-member "Helpdesk" --groups=helpdesk-team

# Helpdesk team members can now reset passwords and unlock accounts
# Test as helpdesk user
kinit alice
ipa user-mod testuser --password  # Can reset password
ipa user-unlock testuser           # Can unlock account
ipa user-del testuser              # Permission denied - no delete rights

Creating Custom Role for Junior Administrators

Junior administrators need user and group management capabilities but should not be able to delete accounts or modify senior administrators. Create a custom role with limited privileges.

# Create custom role for junior admins
ipa role-add "Junior Admins" \
  --desc="Limited user and group administration for junior staff"

# Add appropriate privileges
ipa role-add-privilege "Junior Admins" \
  --privileges="User Administrators"
ipa role-add-privilege "Junior Admins" \
  --privileges="Group Administrators"

# Create junior admin group
ipa group-add junior-admins --desc="Junior IT administrators"
ipa group-add-member junior-admins --users=david,emma

# Assign role to group
ipa role-add-member "Junior Admins" --groups=junior-admins

# Junior admins can add/modify users and groups
# but deletion requires senior admin approval via separate workflow

Delegating Host Enrollment to Branch Offices

Branch offices need to enroll their own workstations without granting full host management privileges. Use the built-in Enrollment Administrator role for limited host enrollment delegation.

# Create group for branch office IT staff
ipa group-add branch-it --desc="Branch office IT administrators"
ipa group-add-member branch-it --users=branch-admin1,branch-admin2

# Assign Enrollment Administrator role
ipa role-add-member "Enrollment Administrator" --groups=branch-it

# Branch IT staff can now enroll hosts
# Test as branch admin
kinit branch-admin1
ipa host-add workstation42.branch.example.com --force
  # Host enrolled successfully

# Verify limited permissions
ipa host-del server.example.com
  # Permission denied - enrollment role cannot delete hosts

Creating Read-Only Auditor Role

Compliance and security teams need read-only access to IPA configuration for auditing purposes without modification rights. Create a custom auditor role with read-only privileges.

# Create auditor role
ipa role-add "Security Auditor" \
  --desc="Read-only access for compliance and security auditing"

# Find and add read-only privileges
ipa privilege-find --name="*Read*" --pkey-only
# Add appropriate read privileges
ipa role-add-privilege "Security Auditor" \
  --privileges="Passwd Displays" \
  --privileges="Stage User Provisioners"  # Read-only aspects

# Create auditor group and assign role
ipa group-add security-auditors --desc="Security and compliance auditors"
ipa group-add-member security-auditors --users=auditor1,auditor2
ipa role-add-member "Security Auditor" --groups=security-auditors

# Auditors can view configuration but cannot modify
kinit auditor1
ipa user-show alice       # Success - can read
ipa user-mod alice --title="Manager"  # Permission denied - cannot write

Application Service Administrator Role

Application teams need to manage their own service principals and certificates without accessing other teams’ resources. Create a role enabling service and certificate management.

# Create application admin role
ipa role-add "Application Administrators" \
  --desc="Manage service principals and certificates for applications"

# Add service and certificate management privileges
ipa role-add-privilege "Application Administrators" \
  --privileges="Service Administrators" \
  --privileges="Certificate Administrators"

# Create application team group
ipa group-add app-team-db --desc="Database application team"
ipa group-add-member app-team-db --users=dbadmin1,dbadmin2

# Assign role to application team
ipa role-add-member "Application Administrators" --groups=app-team-db

# Application team can manage their service principals
kinit dbadmin1
ipa service-add postgres/db01.example.com
ipa service-allow-retrieve-keytab postgres/db01.example.com --users=dbadmin1
ipa cert-request --principal=postgres/db01.example.com cert.csr

Delegating DNS Management to Network Team

Network teams need to manage DNS records and zones without full IPA administration access. Create a DNS-focused role for network administrators.

# Create DNS administrator role
ipa role-add "DNS Administrators" \
  --desc="Manage DNS zones and records for network team"

# Add DNS management privileges
ipa role-add-privilege "DNS Administrators" \
  --privileges="DNS Administrators"

# Create network team group
ipa group-add network-team --desc="Network operations team"
ipa group-add-member network-team --users=netadmin1,netadmin2,netadmin3

# Assign DNS role to network team
ipa role-add-member "DNS Administrators" --groups=network-team

# Network team can manage DNS
kinit netadmin1
ipa dnszone-add newdomain.example.com
ipa dnsrecord-add newdomain.example.com server01 --a-rec=192.168.1.10

# But cannot manage users or other IPA objects
ipa user-add testuser
  # Permission denied

Multi-Role Assignment for Senior Administrators

Senior administrators often need multiple capabilities (user management, policy configuration, infrastructure management). Assign multiple roles to provide comprehensive administrative access.

# Create senior admin group
ipa group-add senior-admins --desc="Senior IT administrators"
ipa group-add-member senior-admins --users=senioradmin1,senioradmin2

# Assign multiple built-in roles for broad administrative capability
ipa role-add-member "User Administrator" --groups=senior-admins
ipa role-add-member "Security Architect" --groups=senior-admins
ipa role-add-member "IT Security Specialist" --groups=senior-admins
ipa role-add-member "Host Administrators" --groups=senior-admins

# Senior admins now have comprehensive privileges
# They can manage users, configure policies, manage hosts, and handle security
kinit senioradmin1
ipa user-add newuser               # User Administrator
ipa hbacrule-add new-rule          # Security Architect
ipa host-add newhost.example.com   # Host Administrators

Temporary Role Assignment for Project Work

Contractors or temporary staff need administrative access for specific project duration. Assign roles temporarily with planned removal after project completion.

# Create contractor account
ipa user-add contractor1 --first=Jane --last=Contractor

# Create project-specific group
ipa group-add migration-project --desc="AD to IPA migration project team"
ipa group-add-member migration-project --users=contractor1

# Assign necessary roles for migration project
ipa role-add-member "User Administrator" --groups=migration-project
ipa role-add-member "Group Administrators" --groups=migration-project

# After project completion (3 months later)
# Remove role assignment by removing group membership
ipa group-remove-member migration-project --users=contractor1

# Or delete the project group entirely
ipa group-del migration-project

# Contractor1 immediately loses all administrative privileges

Host-Based Automation Role

Provisioning systems need to create and manage user accounts programmatically. Grant administrative privileges to host principals for automation workflows.

# Create provisioning service principal
ipa service-add provisioning/automation01.example.com

# Create automation role for provisioning system
ipa role-add "Provisioning Automation" \
  --desc="Automated user provisioning for HR integration"

# Add user management privileges
ipa role-add-privilege "Provisioning Automation" \
  --privileges="User Administrators" \
  --privileges="Stage User Provisioners"

# Assign role to host (not user group)
ipa role-add-member "Provisioning Automation" \
  --hosts=automation01.example.com

# Automation system authenticates with host credentials
# and can create/modify users programmatically
# On automation01.example.com:
kinit -k automation01.example.com
ipa user-add autouser1 --first=Auto --last=User1
ipa user-mod autouser1 --email=autouser1@example.com

Least-Privilege Certificate Operations Role

Certificate renewal automation requires certificate issuance rights without broader administrative access. Create a minimal role for certificate operations only.

# Create certificate operations role
ipa role-add "Certificate Operators" \
  --desc="Issue and renew certificates without full CA administration"

# Add only certificate issuance privilege (not full CA admin)
ipa privilege-add "Certificate Issuance Only" \
  --desc="Issue and view certificates without CA configuration access"
ipa privilege-add-permission "Certificate Issuance Only" \
  --permissions="System: Request Certificate" \
  --permissions="System: Read Certificates"

# Assign privilege to role
ipa role-add-privilege "Certificate Operators" \
  --privileges="Certificate Issuance Only"

# Create cert operations group and assign role
ipa group-add cert-operators --desc="Certificate renewal automation"
ipa group-add-member cert-operators --users=certrenew-automation
ipa role-add-member "Certificate Operators" --groups=cert-operators

# Cert operators can issue certificates but cannot configure CA
kinit certrenew-automation
ipa cert-request --principal=HTTP/web01.example.com cert.csr  # Success
ipa cert-show 1234                                             # Success
ipa certprofile-mod default --desc="Modified"                  # Permission denied

Security Considerations

Privilege escalation through role assignment: Users with the ability to modify role membership can grant themselves or others arbitrary administrative privileges. Restrict role membership modification to a small, trusted admin group. The “User Administrator” role can modify group membership, and if that group has administrative role membership, this enables privilege escalation.

Group-based role membership risks: Using groups for role membership (recommended pattern) means that anyone who can modify group membership can indirectly grant administrative privileges. Ensure group management privileges are carefully controlled and audited.

Nested group implications: Roles grant privileges to nested group members. If Group A has role membership and Group B is a member of Group A, all members of Group B receive the role’s privileges. Deep nesting can obscure effective privilege grants and complicate auditing.

No expiration or time-based restrictions: Role assignments don’t have automatic expiration dates or time-based restrictions. Temporary administrative access requires manual removal or external automation. Forgotten role assignments lead to persistent unauthorized access.

Role deletion with active members: Deleting a role immediately revokes all associated privileges from all members. This can break operational workflows if the role is actively used. Verify role membership before deletion and coordinate with affected teams.

Combining incompatible privileges: Multiple roles assigned to the same entity grant the union of all privileges. This can create dangerous privilege combinations (e.g., user creation + role assignment = arbitrary privilege escalation). Review total effective privileges, not just individual roles.

Host and service role membership: Hosts and services can be role members, enabling automated administrative operations. Compromised hosts or services with role membership grant attackers administrative access. Minimize host/service role membership and monitor their usage closely.

Built-in role modification: Built-in roles can have privileges added or removed, permanently changing their behavior. Modifying built-in roles affects all existing role assignments and can break assumptions about what “User Administrator” means. Prefer creating custom roles over modifying built-ins.

Privilege visibility gaps: Users may not be aware of all privileges granted by their roles. A user assigned “Security Architect” might not realize they can modify HBAC rules affecting production systems. Provide role documentation to users explaining their capabilities and responsibilities.

Audit trail complexity: With multiple roles and nested groups, tracing why a user has specific privileges requires multi-step analysis (user → groups → group memberships → roles → privileges → permissions). This complexity can obscure unauthorized access in audit logs.

No deny mechanism: Roles only grant privileges; there’s no way to explicitly deny specific operations. If a user holds any role granting a privilege, they have that privilege regardless of other role memberships. This limits fine-grained access control flexibility.

Cross-replica consistency: Role membership changes replicate across IPA masters asynchronously. During replication lag, different masters have different role membership, creating inconsistent privilege grants. Administrative operations on different masters may succeed or fail based on replication timing.

Role membership via external groups: External groups (e.g., AD groups) can be assigned IPA roles. Changes to external group membership in the source directory (Active Directory) propagate to IPA and automatically grant/revoke administrative privileges. This creates an indirect privilege management path that may not be audited in IPA.

Service principal role abuse: Service principals with role membership authenticate using keytabs, which are files on disk. If keytab files are stolen or improperly secured, attackers can authenticate as the service and exercise administrative privileges. Keytab security is critical for service role memberships.

Troubleshooting

User Cannot Perform Administrative Operation Despite Role Membership

Symptom: User is a member of an administrative role but receives “Insufficient access” errors when attempting administrative operations.

Diagnosis: Check user’s effective privileges, role membership, and Kerberos ticket.

Resolution: Verify role membership chain and renew Kerberos ticket:

# Verify user is in expected group
ipa group-show admin-group | grep "Member users"

# Verify group is member of role
ipa role-show "User Administrator" | grep "Member groups"

# Check user's current privileges (as user)
kinit alice
ipa user-show alice --all | grep "Member of roles"

# Destroy and renew Kerberos ticket to refresh privileges
kdestroy
kinit alice

# Retry administrative operation
ipa user-add testuser

Role Membership Not Taking Effect Immediately

Symptom: User added to group with role membership but still cannot perform administrative operations.

Diagnosis: User’s Kerberos ticket was issued before role membership change; ticket doesn’t reflect new privileges.

Resolution: User must destroy and reacquire Kerberos ticket:

# Add user to admin group
ipa group-add-member admin-group --users=bob

# User must refresh Kerberos ticket
# As user bob:
kdestroy
kinit bob

# Now test administrative operation
ipa user-mod testuser --title="Manager"
  # Should succeed with new privileges

Cannot Delete Role: Role In Use

Symptom: ipa role-del custom-role fails with “role is in use” or similar error.

Diagnosis: The role has assigned members (users, groups, hosts, or services) and cannot be deleted until all members are removed.

Resolution: Remove all members before deleting the role:

# Show role members
ipa role-show custom-role --all
  Member users: alice, bob
  Member groups: project-team

# Remove all members
ipa role-remove-member custom-role --users=alice,bob
ipa role-remove-member custom-role --groups=project-team

# Now delete the role
ipa role-del custom-role

User Has Privileges from Unknown Role

Symptom: User can perform administrative operations but ipa user-show doesn’t show expected role membership.

Diagnosis: User is member of nested groups, and a parent group has role membership.

Resolution: Trace group membership hierarchy:

# Show user's direct group memberships
ipa user-show alice | grep "Member of groups"
  Member of groups: developers, project-team

# Check each group for role membership
ipa group-show developers --all | grep "Member of roles"
ipa group-show project-team --all | grep "Member of roles"
  Member of roles: User Administrator

# Check if user's groups are members of other groups
ipa group-show developers --all | grep "Member of groups"
  Member of groups: all-engineers

# Check parent groups for role membership
ipa group-show all-engineers --all | grep "Member of roles"
  Member of roles: Helpdesk

Role Modification Not Replicating to Other Masters

Symptom: Role membership or privilege assignment changes on one IPA master don’t appear on other replicas.

Diagnosis: Replication lag or replication failure between IPA masters.

Resolution: Check replication status and force synchronization:

# Check replication agreements
ipa-replica-manage list

# Check replication status
ipa-replica-manage list-ruv

# Force replication from master where change was made
# On replica with stale data:
ipa-replica-manage re-initialize --from=ipa01.example.com

# Verify role configuration after replication
ipa role-show "Custom Role" --all

Added Privilege to Role But Users Still Lack Access

Symptom: Privilege added to role successfully, but users holding the role cannot perform operations granted by the new privilege.

Diagnosis: Users’ Kerberos tickets were issued before privilege addition; tickets don’t reflect updated role privileges.

Resolution: All role members must refresh Kerberos tickets:

# Add privilege to role
ipa role-add-privilege "Custom Role" --privileges="New Privilege"

# Verify privilege was added
ipa role-show "Custom Role" | grep "Member privileges"

# All users with this role must refresh tickets
# As affected user:
kdestroy
kinit alice

# Test operation granted by new privilege
ipa <operation>  # Should now succeed

Role Shows Members But Members Deny Membership

Symptom: ipa role-show admin-role lists users/groups as members, but ipa user-show or ipa group-show doesn’t show role membership.

Diagnosis: Referential integrity issue or replication conflict in LDAP directory.

Resolution: Remove and re-add role membership to fix references:

# Show role members
ipa role-show admin-role
  Member users: alice
  Member groups: admin-group

# Verify from user perspective
ipa user-show alice --all | grep "Member of roles"
  (no role membership shown - inconsistency detected)

# Remove and re-add membership to fix
ipa role-remove-member admin-role --users=alice
ipa role-add-member admin-role --users=alice

# Verify consistency
ipa user-show alice --all | grep "Member of roles"
  Member of roles: admin-role

Cannot Add Host to Role Membership

Symptom: ipa role-add-member role-name --hosts=host.example.com fails with “host not found” even though host exists.

Diagnosis: Host must be enrolled in IPA before it can be added to role membership.

Resolution: Verify host enrollment or use fully qualified hostname:

# Verify host exists in IPA
ipa host-show automation.example.com
  Host name: automation.example.com

# Add to role using exact hostname from host-show
ipa role-add-member "Automation Role" --hosts=automation.example.com

# If host doesn't exist, enroll it first
ipa host-add automation.example.com --force
ipa role-add-member "Automation Role" --hosts=automation.example.com

Service Principal Cannot Exercise Role Privileges

Symptom: Service principal is a member of administrative role but receives permission denied when attempting administrative operations.

Diagnosis: Service principal may not have valid Kerberos credentials or may be using incorrect authentication method.

Resolution: Verify service authentication and credentials:

# Verify service is role member
ipa role-show "Service Admin Role" | grep "Member services"
  Member services: HTTP/service.example.com

# Verify service principal exists
ipa service-show HTTP/service.example.com

# On host running the service, verify keytab
klist -k /etc/http.keytab
  HTTP/service.example.com@EXAMPLE.COM

# Authenticate as service principal
kinit -k -t /etc/http.keytab HTTP/service.example.com

# Verify authenticated principal
klist
  Principal: HTTP/service.example.com@EXAMPLE.COM

# Test administrative operation
ipa user-add testuser
  # Should succeed if role privileges are correct

User Lost Administrative Access After Group Restructure

Symptom: After reorganizing groups, users who previously had administrative access can no longer perform administrative operations.

Diagnosis: Group restructuring removed users from groups with role membership.

Resolution: Verify new group structure and restore role membership:

# Show user's current groups
ipa user-show alice | grep "Member of groups"
  Member of groups: new-team-group

# Check if new group has role membership
ipa group-show new-team-group --all | grep "Member of roles"
  (no roles shown)

# Add role membership to new group structure
ipa role-add-member "User Administrator" --groups=new-team-group

# Or add user back to original admin group
ipa group-add-member old-admin-group --users=alice

Role Privilege Assignment Shows Success But Privilege Not Listed

Symptom: ipa role-add-privilege reports success but privilege doesn’t appear in ipa role-show output.

Diagnosis: Privilege name may be incorrect or privilege doesn’t exist.

Resolution: Verify privilege exists and use exact name:

# List available privileges
ipa privilege-find

# Show specific privilege to verify name
ipa privilege-show "User Administrators"
  Privilege name: User Administrators

# Add privilege using exact name
ipa role-add-privilege "Custom Role" --privileges="User Administrators"

# Verify addition
ipa role-show "Custom Role" | grep "Member privileges"
  Member privileges: User Administrators

Effective Privileges Don’t Match Expected Permissions

Symptom: User holds role with specific privilege, but cannot perform operations that privilege should grant.

Diagnosis: Privilege may not contain the expected permissions, or permissions may not grant required LDAP operations.

Resolution: Inspect privilege composition and permissions:

# Show role's privileges
ipa role-show "Custom Role"
  Member privileges: Custom Privilege

# Show privilege's permissions
ipa privilege-show "Custom Privilege" --all
  Member permissions: System: Add Users, System: Modify Users

# Show detailed permission to verify granted operations
ipa permission-show "System: Add Users" --all
  Granted rights: add
  Type: user
  Effective attributes: [list of attributes]

# If permission is insufficient, add missing permissions to privilege
ipa privilege-add-permission "Custom Privilege" \
  --permissions="System: Additional Permission Needed"

External Group Role Membership Not Working

Symptom: External group (Active Directory group) assigned to role, but AD users cannot exercise administrative privileges.

Diagnosis: External group mapping not configured correctly or AD users not authenticated properly.

Resolution: Verify external group configuration and trust:

# Verify trust is active
ipa trust-show ad.corp.example.com
  Domain: ad.corp.example.com
  Trust status: Established and verified

# Verify external group exists
ipa group-show ad-admins --external
  Group name: ad-admins
  External member: S-1-5-21-...-512  # AD Domain Admins SID

# Verify role membership
ipa role-show "User Administrator" | grep "ad-admins"
  Member groups: ad-admins

# AD user must authenticate with full realm
kinit aduser@AD.CORP.EXAMPLE.COM

# Test administrative operation
ipa user-add testuser
  # Should succeed if trust and group mapping correct

Role Rename Breaking Automation

Symptom: After renaming role, automation scripts fail with “role not found” errors.

Diagnosis: Scripts reference old role name; rename operation changed the role’s name attribute.

Resolution: Update automation scripts or rename role back:

# Role was renamed
ipa role-show "New Role Name"
  Role name: New Role Name

# Option 1: Update scripts to use new name
# Update scripts from "Old Role Name" to "New Role Name"

# Option 2: Rename back to old name
ipa role-mod "New Role Name" --rename="Old Role Name"

# Verify restoration
ipa role-show "Old Role Name"
  Role name: Old Role Name

Too Many Roles Making Audit Difficult

Symptom: Organization has dozens of roles with overlapping privileges, making it difficult to determine effective permissions.

Diagnosis: Role proliferation without consolidation; many similar roles exist with slight variations.

Resolution: Audit and consolidate roles:

# List all roles
ipa role-find --pkey-only
  Role name: Custom Role 1
  Role name: Custom Role 2
  [... dozens more ...]

# For each role, examine privileges
ipa role-show "Custom Role 1" --all | grep "Member privileges"
ipa role-show "Custom Role 2" --all | grep "Member privileges"

# Identify roles with identical or very similar privileges
# Consolidate by migrating members to single canonical role
ipa role-add-member "Canonical Role" --groups=group1,group2,group3
ipa role-remove-member "Deprecated Role 1" --groups=group1
ipa role-remove-member "Deprecated Role 2" --groups=group2

# Delete deprecated roles
ipa role-del "Deprecated Role 1"
ipa role-del "Deprecated Role 2"

Commands

role-add

Usage: ipa [global-options] role-add NAME [options]

Add a new role.

Arguments

Argument	Required	Description
NAME	yes	Role name

Options

Option	Description
--desc DESC	A description of this role-group
--setattr SETATTR	Set an attribute to a name/value pair. Format is attr=value.
--addattr ADDATTR	Add an attribute/value pair. Format is attr=value. The attribute
--all	Retrieve and print all attributes from the server. Affects command output.
--raw	Print entries as stored on the server. Only affects output format.
--no-members	Suppress processing of membership attributes.

role-add-member

Usage: ipa [global-options] role-add-member NAME [options]

Add members to a role.

Arguments

Argument	Required	Description
NAME	yes	Role name

Options

Option	Description
--all	Retrieve and print all attributes from the server. Affects command output.
--raw	Print entries as stored on the server. Only affects output format.
--no-members	Suppress processing of membership attributes.
--users USERS	users to add
--groups GROUPS	groups to add
--hosts HOSTS	hosts to add
--hostgroups HOSTGROUPS	host groups to add
--services SERVICES	services to add
--idoverrideusers IDOVERRIDEUSERS	User ID overrides to add
--sysaccounts SYSACCOUNTS	system accounts to add

role-add-privilege

Usage: ipa [global-options] role-add-privilege NAME [options]

Add privileges to a role.

Arguments

Argument	Required	Description
NAME	yes	Role name

Options

Option	Description
--all	Retrieve and print all attributes from the server. Affects command output.
--raw	Print entries as stored on the server. Only affects output format.
--no-members	Suppress processing of membership attributes.
--privileges PRIVILEGES	privileges

role-del

Usage: ipa [global-options] role-del NAME [options]

Delete a role.

Arguments

Argument	Required	Description
NAME	yes	Role name

Options

Option	Description
--continue	Continuous mode: Don’t stop on errors.

role-find

Usage: ipa [global-options] role-find [CRITERIA] [options]

Search for roles.

Arguments

Argument Required Description

---

CRITERIA no A string searched in all relevant object attributes

Options

Option	Description
--name NAME	Role name
--desc DESC	A description of this role-group
--timelimit TIMELIMIT	Time limit of search in seconds (0 is unlimited)
--sizelimit SIZELIMIT	Maximum number of entries returned (0 is unlimited)
--all	Retrieve and print all attributes from the server. Affects command output.
--raw	Print entries as stored on the server. Only affects output format.
--pkey-only	Results should contain primary key attribute only (“name”)

role-mod

Usage: ipa [global-options] role-mod NAME [options]

Modify a role.

Arguments

Argument	Required	Description
NAME	yes	Role name

Options

Option	Description
--desc DESC	A description of this role-group
--setattr SETATTR	Set an attribute to a name/value pair. Format is attr=value.
--addattr ADDATTR	Add an attribute/value pair. Format is attr=value. The attribute
--delattr DELATTR	Delete an attribute/value pair. The option will be evaluated
--rights	Display the access rights of this entry (requires —all). See ipa man page for details.
--all	Retrieve and print all attributes from the server. Affects command output.
--raw	Print entries as stored on the server. Only affects output format.
--no-members	Suppress processing of membership attributes.
--rename RENAME	Rename the role object

role-remove-member

Usage: ipa [global-options] role-remove-member NAME [options]

Remove members from a role.

Arguments

Argument	Required	Description
NAME	yes	Role name

Options

Option	Description
--all	Retrieve and print all attributes from the server. Affects command output.
--raw	Print entries as stored on the server. Only affects output format.
--no-members	Suppress processing of membership attributes.
--users USERS	users to remove
--groups GROUPS	groups to remove
--hosts HOSTS	hosts to remove
--hostgroups HOSTGROUPS	host groups to remove
--services SERVICES	services to remove
--idoverrideusers IDOVERRIDEUSERS	User ID overrides to remove
--sysaccounts SYSACCOUNTS	system accounts to remove

role-remove-privilege

Usage: ipa [global-options] role-remove-privilege NAME [options]

Remove privileges from a role.

Arguments

Argument	Required	Description
NAME	yes	Role name

Options

Option	Description
--all	Retrieve and print all attributes from the server. Affects command output.
--raw	Print entries as stored on the server. Only affects output format.
--no-members	Suppress processing of membership attributes.
--privileges PRIVILEGES	privileges

role-show

Usage: ipa [global-options] role-show NAME [options]

Display information about a role.

Arguments

Argument	Required	Description
NAME	yes	Role name

Options

Option	Description
--rights	Display the access rights of this entry (requires —all). See ipa man page for details.
--all	Retrieve and print all attributes from the server. Affects command output.
--raw	Print entries as stored on the server. Only affects output format.
--no-members	Suppress processing of membership attributes.