Permissions - CLI Reference

Overview

Permissions are the foundational building blocks of FreeIPA’s role-based access control (RBAC) system. Each permission defines a specific LDAP operation (read, write, add, delete) on a specific set of directory objects and attributes. Permissions are human-readable wrappers around 389 Directory Server Access Control Instructions (ACIs), translating complex LDAP access control syntax into manageable administrative objects.

A permission grants atomic access rights—the ability to perform a single, well-defined operation. Unlike privileges (which aggregate permissions) or roles (which aggregate privileges), permissions cannot contain other permissions. This atomic design ensures precise control over directory access and enables administrators to grant exactly the rights needed for specific tasks without over-privileging.

Permissions become effective only when aggregated into privileges, which are then assigned to roles, which are finally granted to users, groups, hosts, or services. This three-tier hierarchy (permissions → privileges → roles) provides both granular control and simplified management at scale.

Permission Anatomy

Every permission consists of three essential components:

1. Target (What)

The target defines which LDAP directory entries the permission applies to. Targets can be specified using:

Subtree (--subtree): A Distinguished Name (DN) specifying a directory branch. The permission applies to all entries under this subtree. Example: cn=users,cn=accounts,dc=example,dc=com.

Type (--type): A convenience option specifying an IPA object type (user, group, host, service, etc.). Automatically sets the appropriate subtree and objectClass filter. Example: --type=user targets all user entries.

Filter (--filter): An LDAP filter for fine-grained targeting. Combines with other target specifications using logical AND. Example: (employeeType=contractor) to target only contractor accounts.

Target DN (--target): A specific DN, potentially with wildcards. Example: uid=*,cn=users,cn=accounts,dc=example,dc=com targets all users but not the container itself.

Member Of (--memberof): Targets entries that are members of a specific group. Sets a memberOf targetfilter. Example: --memberof="cn=contractors,cn=groups,cn=accounts,dc=example,dc=com".

Target Group (--targetgroup): Specific to group membership operations. Grants rights to modify a particular group’s membership. Example: --targetgroup="cn=all-staff,cn=groups,cn=accounts,dc=example,dc=com".

2. Rights (What Operations)

The rights component specifies which LDAP operations are permitted:

read: View attribute values. Required for search results to include the attribute. Without read rights, an attribute appears as ******** in search results even if search rights exist.

search: Search and filter on attribute values. Enables using the attribute in LDAP search filters. Typically granted together with read rights.

compare: Compare an attribute value without reading it. Rarely used in IPA; primarily for password verification scenarios where the value shouldn’t be revealed.

write: Modify attribute values on existing entries. Grants both adding new values and removing existing values for multi-valued attributes.

add: Create new directory entries. Operates at the entry level, not attribute level. Typically combined with write rights for attributes of newly created entries.

delete: Remove directory entries. Operates at the entry level. Deletion often requires additional write rights to remove membership references.

all: Grant all possible rights. Use sparingly; contradicts least-privilege security principles.

3. Attributes (What Data)

The attributes component specifies which LDAP attributes the permission applies to. This works with read, write, search, and compare rights (but not add/delete, which operate on whole entries).

Included attributes (--attrs, --includedattrs): Attributes explicitly granted access. Example: --attrs=givenName,sn,cn,mail for basic user profile attributes.

Excluded attributes (--excludedattrs): Attributes explicitly denied access, even if otherwise included. Useful for managed permissions where defaults are too broad.

Default attributes (managed permissions only): The baseline attribute set for managed permissions. Administrators can include additional attributes or exclude unwanted defaults.

All attributes (--attrs=*): Grant access to all attributes. Dangerous; use only for read-only discovery tools or comprehensive administrative roles.

Managed vs Custom Permissions

Managed Permissions

FreeIPA ships with hundreds of managed permissions covering all system operations. These permissions have a “System:” prefix (e.g., “System: Add Users”, “System: Modify Group Membership”) and provide several advantages:

Maintained by IPA: Updated automatically across IPA version upgrades to accommodate new features and attributes.

Protected targets: The target specification (subtree, type, filter) cannot be modified or deleted by administrators. This prevents accidental breakage of system functionality.

Flexible attributes: While target and rights are protected, administrators can customize which attributes the permission applies to using --includedattrs and --excludedattrs.

Default privileges: Most managed permissions are included in default privileges like “User Administrators” or “Group Administrators”, providing out-of-box delegation capabilities.

Example managed permission:

Permission name: System: Modify Users
Granted rights: write
Effective attributes: cn, displayname, gecos, givenname, homedirectory,
                      initials, loginshell, mail, sn, title, [...]
Type: user
Subtree: cn=users,cn=accounts,dc=example,dc=com

Administrators can extend this to include custom attributes:

$ ipa permission-mod "System: Modify Users" \
  --includedattrs="employeeNumber,employeeType"

Or restrict it to exclude sensitive attributes:

$ ipa permission-mod "System: Modify Users" \
  --excludedattrs="sshPublicKey"

Custom Permissions

Custom permissions provide flexibility for organization-specific access control needs:

Full control: Define target, rights, and attributes completely.

Naming freedom: Choose any name (but avoid “System:” prefix to distinguish from managed permissions).

Modification: Freely modify or delete custom permissions as requirements change.

Use cases: Granting access to custom LDAP schema attributes, implementing organization-specific delegation patterns, fine-grained access to subset of entries (via filters).

Example custom permission:

# Grant read access to custom employee attributes
$ ipa permission-add "Read Employee Data" \
  --type=user \
  --right=read \
  --right=search \
  --attrs=employeeNumber,employeeType,department,manager,costCenter

When to Use Each

Use managed permissions when:

The operation aligns with built-in IPA administrative tasks
You want automatic updates as IPA evolves
Standard delegation patterns suffice

Create custom permissions when:

Working with custom LDAP schema attributes
Implementing fine-grained access (e.g., filter-based targeting)
Granting access to LDAP objects not covered by managed permissions
Organizational security policies require attribute-level restrictions beyond managed defaults

Bind Types

The bindtype specifies who can use the permission:

permission (default): The permission is effective only when the authenticated principal has the permission through the RBAC hierarchy (role → privilege → permission). This is the standard, secure approach.

all: The permission is effective for all authenticated principals, regardless of RBAC membership. Equivalent to an “authenticated users” ACL. Use very sparingly—only for operations that truly any authenticated user should perform.

anonymous: The permission is effective for unauthenticated connections. Extremely rare in IPA; used only for specific directory metadata that must be readable before authentication (e.g., supportedSASLMechanisms).

Best practice: Always use the default permission bindtype unless you have a specific, documented reason for all or anonymous.

Target Specification Methods

Type-Based Targeting (Recommended)

The --type option provides a simple, maintainable approach for most permissions:

# Target all user entries
$ ipa permission-add "Custom User Read" --type=user --right=read --attrs=cn,uid

# Target all group entries
$ ipa permission-add "Custom Group Read" --type=group --right=read --attrs=cn,member

# Available types: user, group, host, hostgroup, service, hbacrule, sudorule,
#                  dnszone, dnsrecord, certprofile, ca, caacl, vault, etc.

Type-based targeting automatically sets the correct subtree and objectClass filter, reducing errors.

Filter-Based Targeting

Use LDAP filters for conditional access:

# Grant access only to contractor accounts
$ ipa permission-add "Read Contractor Profiles" \
  --type=user \
  --filter="(employeeType=contractor)" \
  --right=read --right=search \
  --attrs=cn,mail,telephoneNumber

# Grant access only to disabled users (for audit/cleanup)
$ ipa permission-add "List Disabled Users" \
  --type=user \
  --filter="(nsAccountLock=TRUE)" \
  --right=read --right=search \
  --attrs=uid,cn,nsAccountLock

Filters combine with type/subtree using logical AND.

Subtree-Based Targeting

Directly specify the LDAP subtree:

# Target a custom LDAP container
$ ipa permission-add "Manage Custom Objects" \
  --subtree="ou=applications,dc=example,dc=com" \
  --right=add --right=delete --right=write \
  --attrs=cn,description,applicationOwner

MemberOf Targeting

Grant access to members of a specific group:

# Grant permission only for users in the "remote-workers" group
$ ipa permission-add "Manage Remote Worker Laptops" \
  --type=host \
  --memberof="cn=remote-workers,cn=groups,cn=accounts,dc=example,dc=com" \
  --right=write \
  --attrs=description,macAddress

Target Group (Group Membership)

Grant rights to modify a specific group’s membership:

# Allow modification of the "developers" group membership
$ ipa permission-add "Manage Developer Group" \
  --targetgroup="developers" \
  --right=write \
  --attrs=member

This is distinct from --type=group (which targets all groups) or --memberof (which targets group members).

ACI Relationship

Permissions are stored as LDAP Access Control Instructions (ACIs) in the 389 Directory Server. Understanding this relationship helps troubleshoot access issues:

Permission → ACI translation: When you create or modify a permission, IPA generates the corresponding ACI syntax and stores it in the directory.

Replication dependency: ACI changes propagate via directory replication. In multi-master environments, there may be a brief delay before permission changes take effect on all replicas.

Direct ACI inspection: Use ipa permission-show --all --raw to see the underlying ACI syntax:

$ ipa permission-show "System: Add Users" --all --raw
  [...]
  aci: (target = "ldap:///uid=*,cn=users,cn=accounts,dc=example,dc=com")
       (version 3.0; acl "permission:System: Add Users";
        allow (add) groupdn = "ldap:///cn=System: Add Users,cn=permissions,
                               cn=pbac,dc=example,dc=com";)

Manual ACI conflict: Never create ACIs directly in 389-ds that conflict with IPA permissions. This can cause unpredictable behavior and security vulnerabilities.

Examples

Basic Permission Creation

# Create a permission to add users
$ ipa permission-add "Add New Users" \
  --type=user \
  --right=add \
  --right=write \
  --attrs=givenname,sn,cn,uid,uidNumber,gidNumber,homeDirectory,loginShell

# Create a permission to modify user attributes
$ ipa permission-add "Modify User Profiles" \
  --type=user \
  --right=write \
  --attrs=givenname,sn,cn,displayName,mail,telephoneNumber,title

# Create a permission to delete users
$ ipa permission-add "Delete Users" \
  --type=user \
  --right=delete

Read-Only Permissions

# Read-only access to user data
$ ipa permission-add "Read User Data" \
  --type=user \
  --right=read \
  --right=search \
  --attrs=uid,givenname,sn,cn,mail,telephoneNumber

# Read-only access to all user attributes
$ ipa permission-add "Audit User Accounts" \
  --type=user \
  --right=read \
  --right=search \
  --attrs=*

Group Management Permissions

# Create groups
$ ipa permission-add "Create Groups" \
  --type=group \
  --right=add \
  --right=write \
  --attrs=cn,description,gidNumber

# Modify group membership
$ ipa permission-add "Modify Group Membership" \
  --type=group \
  --right=write \
  --attrs=member

# Modify specific group
$ ipa permission-add "Manage Developers Group" \
  --targetgroup="developers" \
  --right=write \
  --attrs=member,description

Host Management Permissions

# Enroll new hosts
$ ipa permission-add "Enroll Hosts" \
  --type=host \
  --right=add \
  --right=write \
  --attrs=fqdn,description,l,nshostlocation,nshardwareplatform,nsosversion

# Manage host attributes
$ ipa permission-add "Modify Host Attributes" \
  --type=host \
  --right=write \
  --attrs=description,l,nshostlocation,macAddress

# Delete hosts
$ ipa permission-add "Remove Hosts" \
  --type=host \
  --right=delete

Service Principal Permissions

# Create service principals
$ ipa permission-add "Add Service Principals" \
  --type=service \
  --right=add \
  --right=write \
  --attrs=krbprincipalname,managedBy

# Manage service keytabs
$ ipa permission-add "Manage Service Keytabs" \
  --type=service \
  --right=write \
  --attrs=krbPrincipalKey,krbLastPwdChange

Certificate Permissions

# Request certificates
$ ipa permission-add "Request Certificates" \
  --type=user \
  --right=write \
  --attrs=userCertificate

# Revoke certificates
$ ipa permission-add "Revoke Certificates" \
  --subtree="ou=certificateRepository,ou=ca,o=ipaca" \
  --right=write \
  --attrs=crlDistributionPoint

DNS Permissions

# Manage DNS zones
$ ipa permission-add "Manage DNS Zones" \
  --type=dnszone \
  --right=add --right=delete --right=write \
  --attrs=idnsName,idnsZoneActive,idnsSOAmName,idnsSOArName,idnsSOAserial

# Manage DNS records
$ ipa permission-add "Manage DNS Records" \
  --type=dnsrecord \
  --right=add --right=delete --right=write \
  --attrs=aRecord,aAAARecord,cNAMERecord,mXRecord,tXTRecord,sRVRecord

Sudo Rule Permissions

# Create sudo rules
$ ipa permission-add "Add Sudo Rules" \
  --type=sudorule \
  --right=add \
  --right=write \
  --attrs=cn,description,ipaEnabledFlag,memberUser,memberHost,cmdCategory

# Modify sudo rules
$ ipa permission-add "Modify Sudo Rules" \
  --type=sudorule \
  --right=write \
  --attrs=description,memberUser,memberHost,memberAllowCmd,memberDenyCmd

HBAC Rule Permissions

# Manage HBAC rules
$ ipa permission-add "Manage HBAC Rules" \
  --type=hbacrule \
  --right=add --right=delete --right=write \
  --attrs=cn,description,ipaEnabledFlag,memberUser,memberHost,memberService,accessRuleType

Password Policy Permissions

# Manage password policies
$ ipa permission-add "Manage Password Policies" \
  --type=pwpolicy \
  --right=add --right=delete --right=write \
  --attrs=krbMaxPwdLife,krbMinPwdLife,krbPwdHistoryLength,krbPwdMinLength

Filter-Based Conditional Access

# Access only to contractor accounts
$ ipa permission-add "Manage Contractor Accounts" \
  --type=user \
  --filter="(employeeType=contractor)" \
  --right=write \
  --attrs=description,manager,telephoneNumber

# Access only to staging users
$ ipa permission-add "Activate Staged Users" \
  --type=stageuser \
  --right=delete \
  --right=add

# Access only to disabled accounts
$ ipa permission-add "Re-enable Disabled Accounts" \
  --type=user \
  --filter="(nsAccountLock=TRUE)" \
  --right=write \
  --attrs=nsAccountLock

MemberOf-Based Targeting

# Manage laptops assigned to remote workers
$ ipa permission-add "Manage Remote Worker Devices" \
  --type=host \
  --memberof="cn=remote-workers,cn=groups,cn=accounts,dc=example,dc=com" \
  --right=write \
  --attrs=description,macAddress,userCertificate

Custom LDAP Schema Permissions

# Grant access to custom organizational attributes
$ ipa permission-add "Manage Employee Data" \
  --type=user \
  --right=write \
  --attrs=employeeNumber,employeeType,department,manager,costCenter,officeLocation

# Grant access to custom application attributes
$ ipa permission-add "Manage Application Metadata" \
  --subtree="ou=applications,dc=example,dc=com" \
  --right=add --right=delete --right=write \
  --attrs=cn,description,applicationOwner,applicationURL

Vault Permissions

# Create vaults
$ ipa permission-add "Create Vaults" \
  --type=vault \
  --right=add \
  --right=write \
  --attrs=cn,description,ipavaulttype,ipavaultpublickey

# Access vault metadata (not secrets)
$ ipa permission-add "List Vaults" \
  --type=vault \
  --right=read --right=search \
  --attrs=cn,description,owner

Automount Permissions

# Manage automount locations and maps
$ ipa permission-add "Manage Automount" \
  --subtree="cn=automount,dc=example,dc=com" \
  --right=add --right=delete --right=write \
  --attrs=automountMapName,automountKey,automountInformation

Modifying Managed Permissions

# Extend managed permission with custom attributes
$ ipa permission-mod "System: Modify Users" \
  --includedattrs="employeeNumber,employeeType,department"

# Restrict managed permission to exclude sensitive attributes
$ ipa permission-mod "System: Modify Users" \
  --excludedattrs="sshPublicKey,userCertificate"

# View current attribute configuration
$ ipa permission-show "System: Modify Users" --all
  Included attributes: employeeNumber, employeeType, department
  Excluded attributes: sshPublicKey, userCertificate
  Default attributes: cn, displayname, gecos, givenname, [...]
  Effective attributes: cn, displayname, department, employeeNumber, employeeType, [...]
                       (defaults + included - excluded)

Listing and Searching Permissions

# List all permissions
$ ipa permission-find

# Search by name pattern
$ ipa permission-find --name="*User*"

# Find permissions for a specific type
$ ipa permission-find --type=user

# Find permissions with specific rights
$ ipa permission-find --right=delete

# Show only permission names
$ ipa permission-find --pkey-only

# Find permissions on specific attributes
$ ipa permission-find --attrs=userCertificate

Permission Assignment to Privileges

# Add permission to a privilege
$ ipa privilege-add-permission "Custom User Managers" \
  --permissions="Add New Users" \
  --permissions="Modify User Profiles"

# Verify permission is assigned
$ ipa permission-show "Add New Users" --all | grep "Member of privileges"

Complex Multi-Component Permissions

# Comprehensive user provisioning permission
$ ipa permission-add "Complete User Provisioning" \
  --type=user \
  --right=add \
  --right=write \
  --attrs=objectClass,uid,uidNumber,gidNumber,givenname,sn,cn \
  --attrs=homeDirectory,loginShell,gecos,krbPrincipalName \
  --attrs=mail,telephoneNumber,title,description \
  --attrs=employeeNumber,employeeType,manager,department

Renaming Permissions

# Rename a custom permission
$ ipa permission-mod "Old Permission Name" \
  --rename="New Permission Name"

# Note: Managed permissions (System: *) cannot be renamed

Deleting Permissions

# Remove permission from privileges first
$ ipa permission-show "Custom Permission" --all | grep "Member of privileges"
$ ipa privilege-remove-permission "Privilege Name" \
  --permissions="Custom Permission"

# Then delete the permission
$ ipa permission-del "Custom Permission"

# Note: Managed permissions (System: *) cannot be deleted

Auditing Permission Usage

# Find which privileges contain a permission
$ ipa permission-show "System: Add Users" --all | grep "Member of privileges"

# Trace effective access for a user
$ ipa user-show alice --all | grep "memberof role"
  # Then check each role's privileges
$ ipa role-show "Role Name" --all | grep "Member privileges"
  # Then check each privilege's permissions
$ ipa privilege-show "Privilege Name" --all | grep "Member permissions"

Viewing Underlying ACIs

# Show the LDAP ACI generated by a permission
$ ipa permission-show "System: Add Users" --all --raw
  aci: (target = "ldap:///uid=*,cn=users,cn=accounts,dc=example,dc=com")
       (version 3.0; acl "permission:System: Add Users";
        allow (add) groupdn = "ldap:///cn=System: Add Users,cn=permissions,
                               cn=pbac,dc=example,dc=com";)

Batch Permission Creation

# Create multiple related permissions for a workflow
for right in add delete write; do
  ipa permission-add "Custom ${right^} Operations" \
    --type=user \
    --right=$right \
    --attrs=cn,uid,mail
done

Workflow-Based Permission Sets

# Complete employee onboarding permission set
$ ipa permission-add "Onboarding: Create User"   --type=user    --right=add --right=write --attrs=uid,givenname,sn,cn
$ ipa permission-add "Onboarding: Set Password"  --type=user    --right=write --attrs=userPassword
$ ipa permission-add "Onboarding: Add to Groups" --type=group   --right=write --attrs=member
$ ipa permission-add "Onboarding: Enroll Device" --type=host    --right=add --right=write --attrs=fqdn
$ ipa permission-add "Onboarding: Issue Cert"    --type=service --right=write --attrs=userCertificate

# Combine into a privilege
$ ipa privilege-add "Employee Onboarding Workflow"
$ ipa privilege-add-permission "Employee Onboarding Workflow" \
  --permissions="Onboarding: Create User" \
  --permissions="Onboarding: Set Password" \
  --permissions="Onboarding: Add to Groups" \
  --permissions="Onboarding: Enroll Device" \
  --permissions="Onboarding: Issue Cert"

Best Practices

Design Principles

Atomic scope: Each permission should represent a single, well-defined operation. Don’t create “Swiss army knife” permissions with excessive rights or attributes.

Descriptive naming: Use clear, unambiguous names that indicate exactly what the permission grants. “Modify User Email Addresses” is better than “User Update 3”.

Type over subtree: Prefer --type over manual --subtree specification. Type-based targeting is more maintainable and less error-prone.

Explicit attributes: List specific attributes rather than using --attrs=*. Wildcard attribute permissions grant access to future schema additions you might not intend.

Read + Search together: When granting read access, also grant search rights on the same attributes. Read without search means attributes appear in results but cannot be used in filters.

Document intent: Use descriptive names and maintain external documentation explaining the permission’s purpose, business justification, and which privilege/role assignments use it.

Security Considerations

Principle of least privilege: Grant only the minimum rights and attributes needed. A permission to reset passwords doesn’t need write access to account status or group membership.

Sensitive attribute protection: Be extremely cautious with permissions granting write access to memberOf (role assignments), nsAccountLock (account status), krbPrincipalKey (keytabs), or userPassword.

Privilege escalation risk: Avoid creating permissions that, in combination, enable unauthorized privilege escalation. For example, separate “create user” from “assign administrative roles”.

Filter validation: When using --filter, ensure the filter cannot be circumvented by attribute modification. Example: Filtering on employeeType=contractor is ineffective if users can modify their own employeeType.

Bind type discipline: Almost never use --bindtype=all or --bindtype=anonymous. The default permission bindtype with RBAC-based granting is nearly always correct.

ACI conflicts: Never create manual ACIs in 389-ds that overlap with IPA permissions. This creates unpredictable behavior and potential security holes.

Managed Permission Best Practices

Prefer managed permissions: Use existing managed permissions (System: *) whenever they align with your needs. Managed permissions receive updates and security fixes automatically.

Extend, don’t replace: Use --includedattrs to add custom schema attributes to managed permissions rather than creating duplicate custom permissions.

Restrict carefully: Use --excludedattrs sparingly and document why. Future IPA administrators may not understand why standard attributes are excluded.

Never modify targets: Don’t attempt to change the target, type, or subtree of managed permissions. These are protected for good reason—modifying them breaks system functionality.

Track customizations: Maintain a change log of any managed permission modifications (includedattrs/excludedattrs) to facilitate troubleshooting and upgrades.

Custom Permission Best Practices

Avoid “System:” prefix: Never name custom permissions starting with “System:” to distinguish them from managed permissions.

Justify existence: Before creating a custom permission, verify that no managed permission can be extended to meet your needs.

Future-proof naming: Use naming conventions that won’t become obsolete. Avoid embedding department names, temporary project names, or version numbers.

Version control: Export custom permission definitions and store in version control. This enables disaster recovery and change tracking.

Peer review: Have security or IAM teams review custom permissions before deployment, especially those granting write access.

Maintenance Practices

Regular audits: Periodically review custom permissions to ensure they’re still needed and correctly scoped. Remove obsolete permissions.

Attribute review: When extending IPA schema, review existing permissions to determine if new attributes should be added to any permissions.

Upgrade testing: After IPA upgrades, verify that custom permissions still function correctly. Schema changes may affect filters or attribute names.

Orphan detection: Find permissions not assigned to any privilege: ipa permission-find --all | grep -v "Member of privileges". Either assign to a privilege or delete.

Privilege consolidation: If you find yourself creating many similar permissions, consider whether a single comprehensive permission (assigned to multiple privileges) would be more maintainable.

Common Pitfalls

Forgetting search rights: Granting --right=read without --right=search allows reading but not filtering on the attribute. Almost always grant both together.

Entry vs attribute confusion: Rights like add and delete operate on entries (whole objects), while read and write operate on attributes. Don’t specify --attrs with add/delete.

Over-broad filters: Creating filters that match more entries than intended. Always test filters with ldapsearch before using in permissions.

Circular dependencies: Creating permission → privilege → role structures where effective access requires impossible conditions.

Missing attributes for add: When granting add rights, ensure the permission includes write access to all required attributes for the object class. Missing required attributes causes add operations to fail.

Replication delays: Changes to permissions propagate via LDAP replication. In multi-master environments, allow 30-60 seconds for changes to take effect globally.

Deleting in-use permissions: Attempting to delete permissions assigned to privileges fails. Remove from all privileges first.

Testing and Validation

Non-production first: Create and test permissions in a development environment before deploying to production.

Effective access testing: Use a test account with the permission (via privilege/role) to verify it grants intended access and nothing more.

Negative testing: Verify the permission doesn’t grant unintended access to objects, attributes, or operations outside its scope.

ACI inspection: Review the generated ACI (ipa permission-show --all --raw) to ensure it matches expectations.

Multi-master validation: In replicated environments, verify permission changes propagate correctly to all servers.

Integration Points

Privileges

Permissions become effective only when aggregated into privileges. Every permission should be a member of at least one privilege, or it has no effect.

Commands: privilege-add-permission, privilege-remove-permission, privilege-show Relationship: Permissions are members of privileges (many-to-many) Best practice: Assign permissions to privileges immediately after creation to avoid orphaned permissions

ACIs (Access Control Instructions)

Permissions are stored as LDAP Access Control Instructions in the 389 Directory Server. Each permission generates one or more ACIs.

Inspection: ipa permission-show PERMNAME --all --raw reveals the underlying ACI Propagation: ACI changes replicate via LDAP replication; allow time for multi-master convergence Warning: Never create manual ACIs that conflict with IPA-managed permissions

LDAP Schema

Permissions reference LDAP objectClasses (via --type) and attributes (via --attrs). Schema changes may require permission updates.

Custom schema: When adding custom attributes, create or extend permissions to grant access Attribute renames: If schema attributes are renamed, update permissions referencing the old names ObjectClass changes: Type-based permissions use objectClass filters; schema changes to object classes may affect targeting

Users, Groups, Hosts, Services

While permissions don’t directly reference principals, they ultimately control what these entities can do in IPA.

Effective access: Principals receive permissions through: user/group/host/service → role → privilege → permission Auditing: Trace access by checking role memberships, role privileges, and privilege permissions Self-service: Permissions can grant users rights to modify their own entries (using filters or special self-access ACIs)

Roles

Roles assign privileges (and thus their permissions) to users, groups, hosts, or services.

Commands: role-add-privilege, user-show --all, group-show --all Relationship: Roles contain privileges, which contain permissions Best practice: Design permissions for reuse across multiple privileges and roles

Delegation Rules

Delegation rules provide an alternative, more flexible access control mechanism that can reference the same LDAP objects as permissions.

Commands: delegation-add, delegation-find Relationship: Delegation rules and permissions can coexist; delegation rules can grant privileges contextually Use case: Use permissions for stable access grants; delegation for conditional or temporary access

Replication Topology

Permission changes are LDAP modifications that propagate via multi-master replication.

Timing: Allow 30-60 seconds for permission changes to take effect on all replicas Monitoring: Check replication health (ipa-replica-manage list) if permissions behave inconsistently across servers Conflicts: Simultaneous permission modifications on different masters may create replication conflicts; last-write-wins resolution applies

Use Cases

1. Delegating User Profile Management to Help Desk

Grant help desk staff ability to modify basic user profile attributes without full admin privileges.

# Create custom permission for help desk user modifications
ipa permission-add "Help Desk: Modify User Profiles" \
  --type=user \
  --right=write \
  --attrs=givenname,sn,displayname,mail,telephonenumber,mobile,title

# Create privilege aggregating help desk permissions
ipa privilege-add "Help Desk User Management"
ipa privilege-add-permission "Help Desk User Management" \
  --permissions="Help Desk: Modify User Profiles"

# Add existing System permissions for user searches
ipa privilege-add-permission "Help Desk User Management" \
  --permissions="System: Read User Standard Attributes"

# Create role for help desk
ipa role-add "Help Desk"
ipa role-add-privilege "Help Desk" \
  --privileges="Help Desk User Management"

# Assign help desk staff to role
ipa role-add-member "Help Desk" --groups=helpdesk-staff

# Help desk can now modify phone numbers, email, names but not passwords or groups

2. Read-Only Access to Contractor User Data

Grant contractors read-only access to other contractors’ contact information.

# Create permission targeting only contractor accounts
ipa permission-add "Read Contractor Profiles" \
  --type=user \
  --filter="(employeeType=contractor)" \
  --right=read \
  --right=search \
  --attrs=cn,uid,mail,telephonenumber,title,department

# Create privilege
ipa privilege-add "Contractor Directory Access"
ipa privilege-add-permission "Contractor Directory Access" \
  --permissions="Read Contractor Profiles"

# Create role
ipa role-add "Contractor Users"
ipa role-add-privilege "Contractor Users" \
  --privileges="Contractor Directory Access"

# Add contractors group to role
ipa role-add-member "Contractor Users" --groups=contractors

# Contractors can search/view other contractors but not employees
# Employees can't see contractor data unless separately granted

3. Granting Access to Custom LDAP Schema Attributes

Extend managed permission to include organization-specific custom attributes.

# Organization added custom attributes: employeeNumber, costCenter, badgeID
# Extend existing "System: Modify Users" permission

ipa permission-mod "System: Modify Users" \
  --includedattrs="employeeNumber,costCenter,badgeID"

# Now User Administrators can modify these custom attributes
# Verify change
ipa permission-show "System: Modify Users" --all | grep "Effective attributes"

# Alternative: Create separate custom permission
ipa permission-add "Modify Employee Attributes" \
  --type=user \
  --right=write \
  --attrs=employeeNumber,costCenter,badgeID,manager,department

# Add to existing privilege
ipa privilege-add-permission "User Administrators" \
  --permissions="Modify Employee Attributes"

4. Allowing Team Leads to Manage Their Own Team Groups

Grant team leads ability to modify membership of their specific team groups.

# Create permission for each team group
ipa permission-add "Manage Engineering Team Group" \
  --targetgroup="engineering-team" \
  --right=write \
  --attrs=member

ipa permission-add "Manage Sales Team Group" \
  --targetgroup="sales-team" \
  --right=write \
  --attrs=member

# Create privileges for each team
ipa privilege-add "Engineering Team Lead Privileges"
ipa privilege-add-permission "Engineering Team Lead Privileges" \
  --permissions="Manage Engineering Team Group"

ipa privilege-add "Sales Team Lead Privileges"
ipa privilege-add-permission "Sales Team Lead Privileges" \
  --permissions="Manage Sales Team Group"

# Create roles
ipa role-add "Engineering Team Lead"
ipa role-add-privilege "Engineering Team Lead" \
  --privileges="Engineering Team Lead Privileges"

# Assign team lead
ipa role-add-member "Engineering Team Lead" --users=alice

# Alice can now add/remove members from engineering-team group
# but cannot modify sales-team or other groups

5. Restricting Sensitive Attribute Access

Remove sensitive attributes from broad permissions using exclusions.

# Built-in "System: Modify Users" includes sshpublickey
# Security policy: only security team should modify SSH keys

# Exclude sshpublickey from standard user modification
ipa permission-mod "System: Modify Users" \
  --excludedattrs="sshpublickey"

# Create separate permission for SSH key management
ipa permission-add "Manage User SSH Keys" \
  --type=user \
  --right=write \
  --attrs=sshpublickey,ipasshpubkey

# Add to security team privilege
ipa privilege-add "Security Team Privileges"
ipa privilege-add-permission "Security Team Privileges" \
  --permissions="Manage User SSH Keys"

ipa role-add "Security Team"
ipa role-add-privilege "Security Team" \
  --privileges="Security Team Privileges"

# Now only security team can modify SSH keys
# User Administrators cannot

6. Creating Audit-Only Access for Compliance

Grant compliance auditors read-only access to all IPA objects for audit purposes.

# Create comprehensive read permissions
ipa permission-add "Audit: Read All Users" \
  --type=user \
  --right=read \
  --right=search \
  --attrs=*

ipa permission-add "Audit: Read All Groups" \
  --type=group \
  --right=read \
  --right=search \
  --attrs=*

ipa permission-add "Audit: Read All Hosts" \
  --type=host \
  --right=read \
  --right=search \
  --attrs=*

ipa permission-add "Audit: Read All HBAC Rules" \
  --type=hbacrule \
  --right=read \
  --right=search \
  --attrs=*

# Create privilege aggregating all audit permissions
ipa privilege-add "Compliance Auditor"
ipa privilege-add-permission "Compliance Auditor" \
  --permissions="Audit: Read All Users" \
  --permissions="Audit: Read All Groups" \
  --permissions="Audit: Read All Hosts" \
  --permissions="Audit: Read All HBAC Rules"

# Create role
ipa role-add "Auditor"
ipa role-add-privilege "Auditor" --privileges="Compliance Auditor"

# Assign auditors
ipa role-add-member "Auditor" --users=auditor1,auditor2

# Auditors have full read access but cannot modify anything

7. Self-Service User Attribute Modification

Allow users to modify their own contact information without help desk intervention.

# Built-in "System: Modify User" requires assignment
# For self-service, use selfservice permissions

ipa selfservice-add "Users manage their own contact info" \
  --attrs=mail,telephonenumber,mobile,street,l,st,postalcode \
  --permissions=write

# All authenticated users can now modify their OWN contact attributes
# Cannot modify other users' attributes

# Alternative using standard permission with filter:
ipa permission-add "Self-Service Contact Info" \
  --type=user \
  --right=write \
  --attrs=mail,telephonenumber,mobile

# Note: This grants to all users with permission; use selfservice for true self-only access

8. Granting Service Account LDAP Read Access

Create permission for application service to query LDAP directory.

# Application needs read-only LDAP access for authentication lookups
ipa permission-add "Application: Read User Directory" \
  --type=user \
  --right=read \
  --right=search \
  --attrs=uid,cn,mail,givenname,sn,memberof

# Create service principal
ipa service-add ldap-query/app.example.com

# Create privilege
ipa privilege-add "LDAP Query Service"
ipa privilege-add-permission "LDAP Query Service" \
  --permissions="Application: Read User Directory"

# Create role
ipa role-add "LDAP Query Services"
ipa role-add-privilege "LDAP Query Services" \
  --privileges="LDAP Query Service"

# Assign service to role
ipa role-add-member "LDAP Query Services" \
  --services=ldap-query/app.example.com

# Application authenticates with service keytab and can query user directory

9. Conditional Access Based on Group Membership

Grant permissions that apply only to members of specific groups.

# Grant permission to modify hosts only for servers in "production-servers" group
ipa permission-add "Manage Production Server Attributes" \
  --type=host \
  --memberof="cn=production-servers,cn=hostgroups,cn=accounts,dc=example,dc=com" \
  --right=write \
  --attrs=description,nshostlocation,nshardwareplatform,nsosversion

# Create privilege and role
ipa privilege-add "Production Server Management"
ipa privilege-add-permission "Production Server Management" \
  --permissions="Manage Production Server Attributes"

ipa role-add "Production Admins"
ipa role-add-privilege "Production Admins" \
  --privileges="Production Server Management"

# Assign production admin team
ipa role-add-member "Production Admins" --users=prodadmin1,prodadmin2

# Admins can only modify hosts in production-servers hostgroup
# Other hosts remain protected

10. Auditing and Reviewing Permission Assignments

Review which permissions grant access to sensitive operations.

# Find all permissions allowing user deletion
ipa permission-find --right=delete --type=user

# Show all permissions in a privilege
ipa privilege-show "User Administrators" | grep -A50 "Member permissions"

# Find which roles have a specific permission
ipa role-find --privileges="User Administrators"

# Trace effective permissions for a user
ipa user-show alice --all | grep "memberof role"
# Then for each role:
ipa role-show rolename
# Then for each privilege:
ipa privilege-show privilegename

# Generate permission audit report
echo "=== Permission Audit Report ===" > perm-audit.txt
for perm in $(ipa permission-find --pkey-only | grep "Permission name:" | awk '{print $3}'); do
  echo "=== $perm ===" >> perm-audit.txt
  ipa permission-show "$perm" --all >> perm-audit.txt
  echo "" >> perm-audit.txt
done

Security Considerations

1. Over-Privileged Permissions with —attrs=*

Granting access to all attributes (--attrs=*) exposes current and future attributes indiscriminately.

New attributes added to schema automatically included in permission
May grant access to sensitive attributes not yet invented
Attackers with this permission gain access to all data on targeted entries
Use specific attribute lists; update permissions when schema changes
Reserve --attrs=* for read-only auditing roles only

2. Bindtype “all” Grants Universal Access

Using --bindtype=all grants permission to every authenticated principal regardless of RBAC.

Bypasses entire role/privilege/permission hierarchy
Equivalent to “authenticated users” group permission
Attackers with any valid account gain this access
Should be extremely rare; review all --bindtype=all permissions regularly
Default permission bindtype enforces proper RBAC

3. Write Permission Without Read Permission

Granting write but not read rights creates “blind write” scenarios.

User can modify attributes they cannot see current values
May accidentally overwrite important data
Difficult to verify changes were correct
Always pair write rights with read rights for usability
Exception: Password changes (compare right) don’t require read

4. Delete Permission Without Member Cleanup Rights

Deleting entries may require cleanup of membership references in other entries.

User granted delete on users but not write on groups cannot fully delete users
Orphaned membership references remain in groups
IPA handles some cleanup automatically but not all
Grant complementary permissions: user delete + group write(member)

5. Custom Permissions on System-Managed Subtrees

Creating custom permissions in system subtrees can conflict with managed permissions.

cn=users,cn=accounts managed by System permissions
Custom permission with overlapping target may grant unintended access or create conflicts
Managed permissions updated automatically; custom permissions are not
Prefer extending managed permissions over creating overlapping custom permissions
Document clearly why custom permission needed in system subtree

6. Filter-Based Permissions Bypassable by Attribute Modification

Filters like (employeeType=contractor) can be bypassed if user can modify employeeType.

Permission targets contractors: --filter="(employeeType=contractor)"
If separate permission grants write to employeeType, user can change own type
Reclassification as employee may grant additional access
Ensure filter attributes protected from modification by filtered users
Separation of concerns: different principals manage targeting attributes

7. Replication Lag Creates Temporary Inconsistent Permissions

Multi-master replication means permission changes not instantaneous across all servers.

Permission added on server A takes 30-60 seconds to replicate to server B
User authenticating to server B won’t have new permission yet
Security implications: Denial may succeed briefly then fail
Denial removal may be effective briefly then restored
Wait for replication before testing permission changes
Critical removals: Disable user account on all servers immediately, fix permissions after

8. ACI Conflicts from Manual Edits

Manually adding ACIs via LDAP tools can conflict with IPA-managed permissions.

IPA permissions are ACIs but managed through IPA framework
Manual ACI addition bypasses IPA’s validation and tracking
Conflicts between manual ACIs and IPA permissions create unpredictable behavior
IPA upgrades may not preserve manual ACIs
Always use IPA commands for permission management
Emergency manual ACIs should be documented and converted to IPA permissions ASAP

9. Orphaned Permissions Have No Effect

Permissions not assigned to any privilege grant no access but complicate audits.

Permission created but never added to privilege is dormant
Visible in permission-find output; suggests it’s active when it’s not
Audit confusion: “Why don’t users have this access?” “Is this permission in use?”
Delete orphaned permissions or document why they exist
Immediately assign new permissions to privileges upon creation

10. Permission Names Don’t Enforce Semantics

Permission names are cosmetic; actual rights defined by attributes, not name.

Permission named “Read User Data” might grant write rights if misconfigured
Name is for human use; LDAP ACI defines actual access
Attackers may create misleadingly-named permissions
Always verify permission rights, not just name: permission-show --all
Naming convention: Include rights in name (“Read User Data” vs “Modify User Data”)

11. Search vs Read Rights Confusion

Search rights allow finding entries; read rights allow viewing attribute values.

Search without read: User can filter on attribute but sees ******** in results
Read without search: User can view if knows DN but cannot search/filter
Both typically needed together for practical use
Exception: Password attributes (compare right) should never have read

12. Excessive Use of Managed Permission Modifications

Modifying managed permissions risks conflicts during IPA upgrades.

Managed permissions maintained by IPA across versions
Custom changes (--includedattrs, --excludedattrs) may conflict with IPA updates
IPA upgrades may reset or extend managed permission attributes
Document all managed permission modifications
Review managed permissions after IPA upgrades

13. Group Membership Permissions Enable Privilege Escalation

Write permission on group membership allows adding oneself to privileged groups.

User with write(member) on admin group can add themselves
Instant privilege escalation to admin
Target group permissions carefully; ensure only trustworthy principals have write(member)
Consider targetgroup-specific permissions instead of type=group

14. Subtree-Based Permissions May Exceed Intended Scope

Subtree permissions apply to all entries under DN, including future entries.

--subtree=cn=accounts,dc=example,dc=com includes users, groups, services, etc.
New entry types added under subtree automatically included
May grant access to objects not originally intended
Use --type for object-specific targeting when possible
If subtree required, document scope clearly and audit regularly

15. Permission Effective Immediately After Privilege Assignment

Adding permission to privilege grants access instantly; no grace period.

privilege-add-permission takes effect immediately (after replication)
No approval workflow or activation delay
Mistaken privilege assignment grants unintended access immediately
Test permission/privilege assignments in non-production environment first
Have rollback plan: privilege-remove-permission reverses quickly

Troubleshooting

1. Permission Exists But User Cannot Perform Operation

Symptom: Created permission, added to privilege, assigned to role, but user still denied access.

Diagnosis:

# Verify user is member of role
ipa user-show username --all | grep "memberof role"

# Verify role contains privilege
ipa role-show rolename | grep privileges

# Verify privilege contains permission
ipa privilege-show privilegename | grep permissions

# Verify permission has correct rights and target
ipa permission-show permissionname --all

# Check for replication lag
ipa-replica-manage list
# Wait 60 seconds and retry

Resolution:

Verify full chain: user → role → privilege → permission
Check permission rights match operation (write for modify, add for create, etc.)
Verify permission target matches object type user is accessing
Wait for replication if multi-master environment
Test on specific server: kinit -S HTTP/ipa01.example.com@REALM

2. Cannot Modify Managed Permission Target

Symptom: permission-mod "System: ..." fails when trying to change target or subtree.

Diagnosis:

# Attempt to modify target
ipa permission-mod "System: Add Users" --type=group
# Fails: Cannot modify managed permission target

# Show permission
ipa permission-show "System: Add Users" --all
# Shows: Managed: TRUE

Resolution:

Managed permissions have protected targets (subtree, type, filter, rights)
Can only modify attributes: --includedattrs, --excludedattrs
Cannot change target, type, or rights
If need different target, create custom permission instead:

  ipa permission-add "Custom: Add Groups" --type=group --right=add

3. Custom Permission Not Taking Effect

Symptom: Created custom permission but access still denied.

Diagnosis:

# Check if permission assigned to any privilege
ipa privilege-find | grep -B5 -A5 "Custom Permission Name"

# If no results, permission is orphaned

Resolution:

Permissions do nothing until added to privilege:

  ipa privilege-add-permission "Privilege Name" \
    --permissions="Custom Permission Name"

Then ensure privilege assigned to role:

  ipa role-add-privilege "Role Name" \
    --privileges="Privilege Name"

Then ensure user member of role:

  ipa role-add-member "Role Name" --users=username

4. Permission Shows Effective Attributes as Empty

Symptom: permission-show displays no effective attributes.

Diagnosis:

# Show permission
ipa permission-show "My Permission"
# Effective attributes: (empty)

# Check if rights specified
ipa permission-show "My Permission" --all | grep rights

Resolution:

Attributes only apply to read, write, search, compare rights
Add/delete rights operate on whole entries; attributes not applicable
If permission has only add or delete rights, effective attributes will be empty
This is normal; not an error
For add operations, combine with write rights on attributes:

  ipa permission-mod "My Permission" --right=write \
    --attrs=cn,uid,givenname,sn

5. User Can See Attribute Values But Cannot Search on Them

Symptom: User can view attribute when object shown directly but cannot filter by it.

Diagnosis:

# Check permission rights
ipa permission-show "My Permission" --all | grep rights

# Read right present but search right missing

Resolution:

Read right allows viewing attribute values
Search right allows using attribute in filters
Grant both rights:

  ipa permission-mod "My Permission" --right=read --right=search

For full attribute access, specify both explicitly

6. Cannot Delete Permission - Still in Use by Privilege

Symptom: permission-del fails saying permission is in use.

Diagnosis:

# Find which privileges contain permission
ipa privilege-find | grep -B10 "permissionname"

# Shows privileges referencing this permission

Resolution:

Remove permission from all privileges first:

  ipa privilege-remove-permission "Privilege Name" \
    --permissions="Permission Name"

Then delete permission:

  ipa permission-del "Permission Name"

7. Permission Appears Twice in Privilege

Symptom: privilege-show lists same permission multiple times.

Diagnosis:

# Show privilege
ipa privilege-show "Privilege Name"
# Member permissions: permission1, permission1, permission2

Resolution:

This indicates duplicate addition (rare but possible)
Remove and re-add permission:

  ipa privilege-remove-permission "Privilege Name" \
    --permissions="permission1"

  ipa privilege-add-permission "Privilege Name" \
    --permissions="permission1"

Check if replication conflict caused duplication
Review IPA logs for replication issues

8. Filter-Based Permission Not Matching Expected Entries

Symptom: Permission with --filter not granting access to expected entries.

Diagnosis:

# Show permission filter
ipa permission-show "My Permission" --all | grep filter

# Verify entry has matching attribute
ldapsearch -x -D "cn=Directory Manager" -W \
  -b "dc=example,dc=com" "(uid=username)" employeeType

Resolution:

Verify LDAP filter syntax correct: (attribute=value)
Check entry actually has the attribute/value
Filter combines with type/subtree using AND; all conditions must match
Test filter directly with ldapsearch to verify matching entries
Filters case-sensitive for some attributes; check schema

9. Permission Grants Access on One Server But Not Another

Symptom: Permission works when authenticated to server A but not server B.

Diagnosis:

# Check replication status
ipa-replica-manage list

# Verify permission on both servers
ssh ipa01.example.com
ipa permission-show "Permission Name" --all

ssh ipa02.example.com
ipa permission-show "Permission Name" --all
# Compare output

Resolution:

Permission changes propagate via replication
Check replication health: ipa topologysuffix-verify domain
Wait 60-90 seconds for replication to complete
If replication broken, fix replication first
Force replication: ipa-replica-manage force-sync --from=ipa01.example.com

10. Permission Name Already Exists Error

Symptom: permission-add "My Permission" fails saying name exists.

Diagnosis:

# Check if permission exists
ipa permission-show "My Permission"

# If exists, check if it's what you need
ipa permission-show "My Permission" --all

Resolution:

Permission names must be unique
If existing permission meets needs, use it
If not, choose different name: “My Permission v2” or “My Custom Permission”
Cannot have duplicate names even with different targets
To replace, delete old permission first (if not managed):

  ipa privilege-remove-permission "Privilege Name" --permissions="My Permission"
  ipa permission-del "My Permission"
  ipa permission-add "My Permission" --type=user --right=read

11. Cannot Include Certain Attributes in Permission

Symptom: permission-mod --includedattrs=attributename fails or has no effect.

Diagnosis:

# Verify attribute exists in schema
ldapsearch -x -D "cn=Directory Manager" -W \
  -b "cn=schema" "(objectClass=*)" attributeTypes | grep attributename

# Check if attribute allowed for object type
ipa permission-show "My Permission" --all | grep "Object type"

Resolution:

Attribute must exist in LDAP schema
Attribute must be valid for object type (user, group, etc.)
Some attributes restricted by IPA (password hashes, kerberos keys)
For custom attributes, verify schema extension loaded:

  ldapsearch -x -b "cn=schema" -s base "(objectClass=*)" attributeTypes

Restart IPA after schema changes: systemctl restart ipa

12. Self-Service Permission Not Working as Expected

Symptom: Created permission for users to modify own entries but all users can modify all entries.

Diagnosis:

# Check permission bindtype
ipa permission-show "My Permission" --all | grep bindtype

# If bindtype=all, grants to all authenticated users

Resolution:

For true self-service (modify only own entry), use selfservice commands:

  ipa selfservice-add "Users manage their own info" \
    --attrs=mail,telephonenumber \
    --permissions=write

Regular permissions with --bindtype=all grant to all users for all matching entries
Selfservice has built-in “self-only” logic that permissions lack

13. Permission Appears in Find But Show Fails

Symptom: permission-find shows permission but permission-show says not found.

Diagnosis:

# List shows UUID but name may differ
ipa permission-find --pkey-only

# Try show with UUID
ipa permission-show <uuid>

# Check for special characters in name

Resolution:

Permission name may contain special characters or spaces
Use quotes: ipa permission-show "Permission Name With Spaces"
Check exact name from find output
Try tab completion if using interactive shell
If UUID works but name doesn’t, permission name may be malformed

14. Managed Permission Attributes Changed After Upgrade

Symptom: After IPA upgrade, managed permission has different attributes than configured.

Diagnosis:

# Show permission
ipa permission-show "System: Modify Users" --all

# Check included/excluded attrs
ipa permission-show "System: Modify Users" | grep attributes

Resolution:

IPA upgrades may update managed permissions
Custom modifications (includedattrs/excludedattrs) usually preserved
Review release notes for permission changes
Re-apply excluded attributes if needed:

  ipa permission-mod "System: Modify Users" \
    --excludedattrs="sensitiveAttribute"

Document all managed permission modifications for reapplication after upgrades

15. Understanding “Permission” vs “All” Bindtype Effects

Symptom: Confusion about when permission applies based on bindtype.

Diagnosis:

# Show permission bindtype
ipa permission-show "My Permission" --all | grep bindtype

# bindtype: permission (default) - requires RBAC membership
# bindtype: all - any authenticated user

Resolution:

bindtype=permission (default, recommended):
- Permission only effective for principals with permission through RBAC
- User must be: member of role → role has privilege → privilege has permission
- Secure, follows least-privilege principle
bindtype=all (use sparingly):
- Permission effective for ALL authenticated principals regardless of RBAC
- Anyone who can authenticate gets this access
- Used only for universally-needed operations (e.g., read realm info)
To secure permission, ensure bindtype=permission:

  ipa permission-mod "My Permission" --bindtype=permission

Commands

permission-add

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

Add a new permission.

Arguments

Argument	Required	Description
`NAME`	yes	Permission name

Options

Option	Description
`--right RIGHT`	Rights to grant (read, search, compare, write, add, delete, all)
`--attrs ATTRS`	All attributes to which the permission applies
`--bindtype BINDTYPE`	Bind rule type
`--subtree SUBTREE`	Subtree to apply permissions to
`--filter FILTER`	Extra target filter
`--rawfilter RAWFILTER`	All target filters, including those implied by type and memberof
`--target TARGET`	Optional DN to apply the permission to (must be in the subtree, but may not yet exist)
`--targetto TARGETTO`	Optional DN subtree where an entry can be moved to (must be in the subtree, but may not yet exist)
`--targetfrom TARGETFROM`	Optional DN subtree from where an entry can be moved (must be in the subtree, but may not yet exist)
`--memberof MEMBEROF`	Target members of a group (sets memberOf targetfilter)
`--targetgroup TARGETGROUP`	User group to apply permissions to (sets target)
`--type TYPE`	Type of IPA object (sets subtree and objectClass targetfilter)
`--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.

permission-del

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

Delete a permission.

Arguments

Argument	Required	Description
`NAME`	yes	Permission name

Options

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

permission-find

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

Search for permissions.

Arguments

Argument Required Description

CRITERIA no A string searched in all relevant object attributes

Options

Option	Description
`--name NAME`	Permission name
`--right RIGHT`	Rights to grant (read, search, compare, write, add, delete, all)
`--attrs ATTRS`	All attributes to which the permission applies
`--includedattrs INCLUDEDATTRS`	User-specified attributes to which the permission applies
`--excludedattrs EXCLUDEDATTRS`	User-specified attributes to which the permission explicitly does not apply
`--defaultattrs DEFAULTATTRS`	Attributes to which the permission applies by default
`--bindtype BINDTYPE`	Bind rule type
`--subtree SUBTREE`	Subtree to apply permissions to
`--filter FILTER`	Extra target filter
`--rawfilter RAWFILTER`	All target filters, including those implied by type and memberof
`--target TARGET`	Optional DN to apply the permission to (must be in the subtree, but may not yet exist)
`--targetto TARGETTO`	Optional DN subtree where an entry can be moved to (must be in the subtree, but may not yet exist)
`--targetfrom TARGETFROM`	Optional DN subtree from where an entry can be moved (must be in the subtree, but may not yet exist)
`--memberof MEMBEROF`	Target members of a group (sets memberOf targetfilter)
`--targetgroup TARGETGROUP`	User group to apply permissions to (sets target)
`--type TYPE`	Type of IPA object (sets subtree and objectClass targetfilter)
`--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”)

permission-mod

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

Modify a permission.

Arguments

Argument	Required	Description
`NAME`	yes	Permission name

Options

Option	Description
`--right RIGHT`	Rights to grant (read, search, compare, write, add, delete, all)
`--attrs ATTRS`	All attributes to which the permission applies
`--includedattrs INCLUDEDATTRS`	User-specified attributes to which the permission applies
`--excludedattrs EXCLUDEDATTRS`	User-specified attributes to which the permission explicitly does not apply
`--bindtype BINDTYPE`	Bind rule type
`--subtree SUBTREE`	Subtree to apply permissions to
`--filter FILTER`	Extra target filter
`--rawfilter RAWFILTER`	All target filters, including those implied by type and memberof
`--target TARGET`	Optional DN to apply the permission to (must be in the subtree, but may not yet exist)
`--targetto TARGETTO`	Optional DN subtree where an entry can be moved to (must be in the subtree, but may not yet exist)
`--targetfrom TARGETFROM`	Optional DN subtree from where an entry can be moved (must be in the subtree, but may not yet exist)
`--memberof MEMBEROF`	Target members of a group (sets memberOf targetfilter)
`--targetgroup TARGETGROUP`	User group to apply permissions to (sets target)
`--type TYPE`	Type of IPA object (sets subtree and objectClass targetfilter)
`--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 permission object

permission-show

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

Display information about a permission.

Arguments

Argument	Required	Description
`NAME`	yes	Permission 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.