Delegation Rules

Overview

Delegation rules provide attribute-level access control outside the standard RBAC (Role-Based Access Control) framework. While permissions, privileges, and roles grant access based on administrative roles, delegation rules grant access based on group relationships—members of one group can modify specific attributes of members of another group.

This group-to-group delegation model supports common organizational patterns:

• Managers editing attributes of their direct reports
• Department administrators managing department members
• Project leads updating project team member information
• HR staff modifying employee data without full administrative privileges

Delegation rules are simpler and more targeted than full RBAC:

• RBAC: Complex three-tier hierarchy (permissions → privileges → roles) suitable for broad administrative access
• Delegation: Simple two-group relationship suitable for narrow, attribute-specific access

Delegation rules implement LDAP Access Control Instructions (ACIs) that grant the “group” (delegators) read or write access to specific attributes of the “membergroup” (targets). This provides least-privilege access without requiring full administrative roles.

Delegation Model

Components

Every delegation rule consists of four components:

Group (--group): The group whose members receive delegated access. Members of this group can modify the specified attributes. Example: managers, hr-staff, department-admins.

Member Group (--membergroup): The group whose members’ attributes can be modified. These are the target users. Example: employees, contractors, project-team.

Attributes (--attrs): The specific LDAP attributes that can be read or modified. Example: street, postalCode, telephoneNumber, title.

Permissions (--permissions): The access level granted—read (view only) or write (modify). Default is write. Write permission implicitly includes read.

Access Pattern

The delegation rule creates this access pattern:

Members of GROUP can [read|write] ATTRIBUTES of members of MEMBERGROUP

Examples:

• Members of managers can write title, department, manager attributes of members of employees
• Members of hr-staff can write employeeNumber, employeeType attributes of members of all-users
• Members of project-leads can read sshPublicKey, userCertificate attributes of members of project-members

Scope Limitations

Delegation rules only apply to user entries:

• Cannot delegate access to groups, hosts, or services (use RBAC permissions instead)
• Cannot delegate user creation or deletion (use roles with appropriate privileges)
• Cannot delegate group membership management (use RBAC or selfservice rules)

Delegation rules are evaluated in addition to RBAC permissions, not instead of. A user’s effective access is the union of all delegation rules and RBAC permissions they possess.

Read vs Write Permissions

Write Permission (Default)

Write permission (--permissions=write) grants both read and write access to the specified attributes:

• Members of the delegator group can view the attribute values
• Members of the delegator group can modify the attribute values
• Useful for most delegation scenarios where visibility and modification both make sense

Example: Managers need to see employee phone numbers before updating them.

Read Permission

Read permission (--permissions=read) grants view-only access:

• Members of the delegator group can view the attribute values
• Members of the delegator group cannot modify the attribute values
• Useful for reporting, auditing, or information access without modification rights

Example: Department leads need to view employee IDs for reporting but shouldn’t change them.

Combining Read and Write

You cannot create a single delegation rule with both read-only and read-write attributes. Instead, create two rules:

# Read-only access to employee numbers
$ ipa delegation-add "leads-read-employee-data" \
  --group=department-leads \
  --membergroup=department-members \
  --attrs=employeeNumber \
  --permissions=read

# Read-write access to contact information
$ ipa delegation-add "leads-write-contact-info" \
  --group=department-leads \
  --membergroup=department-members \
  --attrs=telephoneNumber,mobile,mail \
  --permissions=write

Use Cases

Manager-Employee Delegation

Managers need to update contact information and job details for their direct reports without full administrative access:

$ ipa delegation-add "managers-edit-employee-info" \
  --group=managers \
  --membergroup=employees \
  --attrs=telephoneNumber,mobile,street,city,state,postalCode,title,department \
  --permissions=write

This allows managers to keep employee records current without granting broader user administration privileges.

HR Department Delegation

HR staff need comprehensive access to employee data across the organization:

$ ipa delegation-add "hr-manage-employee-data" \
  --group=hr-staff \
  --membergroup=all-employees \
  --attrs=employeeNumber,employeeType,department,manager,title,street,city,state,postalCode \
  --permissions=write

HR can manage organizational attributes without the ability to reset passwords, modify group memberships, or other administrative tasks.

Department Administrator Delegation

Department admins manage users within their department:

$ ipa delegation-add "dept-admins-edit-dept-users" \
  --group=engineering-admins \
  --membergroup=engineering-staff \
  --attrs=title,telephoneNumber,mobile,sshPublicKey \
  --permissions=write

This enables distributed administration without central IT involvement for routine updates.

Project Lead Delegation

Project leads need read access to team member authentication details for troubleshooting:

$ ipa delegation-add "project-leads-view-auth-details" \
  --group=project-leads \
  --membergroup=project-members \
  --attrs=sshPublicKey,userCertificate,krbPrincipalName \
  --permissions=read

Leads can view authentication configurations without the ability to modify them.

Helpdesk Delegation

Helpdesk staff need to update specific user attributes without full access:

$ ipa delegation-add "helpdesk-update-contact-info" \
  --group=helpdesk \
  --membergroup=all-users \
  --attrs=telephoneNumber,mobile,mail \
  --permissions=write

Helpdesk can assist users with contact information updates without password reset or account management privileges.

Examples

Create Basic Delegation Rule

# Allow managers to edit employee street addresses
$ ipa delegation-add "managers-edit-addresses" \
  --group=managers \
  --membergroup=employees \
  --attrs=street \
  --permissions=write

  Delegation name: managers-edit-addresses
  Permissions: write
  Attributes: street
  Member user group: employees
  User group: managers

Add Additional Attributes

# Extend delegation to include postal code and city
# IMPORTANT: Must include existing attributes when modifying
$ ipa delegation-mod "managers-edit-addresses" \
  --attrs=street,postalCode,city,state

  Delegation name: managers-edit-addresses
  Permissions: write
  Attributes: street, postalCode, city, state
  Member user group: employees
  User group: managers

Create Read-Only Delegation

# Allow auditors to view employee data without modification
$ ipa delegation-add "auditors-view-employee-data" \
  --group=auditors \
  --membergroup=employees \
  --attrs=employeeNumber,employeeType,department,manager \
  --permissions=read

Delegate Contact Information Management

# Allow department admins to manage contact information
$ ipa delegation-add "dept-admins-manage-contacts" \
  --group=department-admins \
  --membergroup=department-members \
  --attrs=telephoneNumber,mobile,mail,street,city,state,postalCode \
  --permissions=write

Delegate SSH Key Management

# Allow team leads to update team member SSH keys
$ ipa delegation-add "leads-manage-ssh-keys" \
  --group=team-leads \
  --membergroup=team-members \
  --attrs=sshPublicKey \
  --permissions=write

Delegate Job Title Updates

# Allow HR to update employee titles and departments
$ ipa delegation-add "hr-update-positions" \
  --group=hr-staff \
  --membergroup=all-employees \
  --attrs=title,department,manager,employeeType \
  --permissions=write

List All Delegation Rules

# View all active delegation rules
$ ipa delegation-find
  3 delegations matched
  Delegation name: managers-edit-addresses
  Permissions: write
  Attributes: street, postalCode, city, state
  Delegation name: hr-update-positions
  Permissions: write
  Attributes: title, department, manager, employeeType
  [...]

Show Delegation Rule Details

# View specific delegation configuration
$ ipa delegation-show "managers-edit-addresses"
  Delegation name: managers-edit-addresses
  Permissions: write
  Attributes: street, postalCode, city, state
  Member user group: employees
  User group: managers

Search Delegations by Group

# Find all delegations where managers are delegators
$ ipa delegation-find --group=managers

# Find all delegations affecting employees
$ ipa delegation-find --membergroup=employees

Delete Delegation Rule

# Remove delegation when no longer needed
$ ipa delegation-del "managers-edit-addresses"
  Deleted delegation "managers-edit-addresses"

Create Multiple Related Delegations

# HR needs read-write on some attributes, read-only on others
$ ipa delegation-add "hr-write-employment-data" \
  --group=hr-staff \
  --membergroup=all-employees \
  --attrs=employeeNumber,employeeType,title,department \
  --permissions=write

$ ipa delegation-add "hr-read-sensitive-data" \
  --group=hr-staff \
  --membergroup=all-employees \
  --attrs=krbPrincipalName,userCertificate \
  --permissions=read

Delegate Custom Schema Attributes

# Allow managers to update custom organizational attributes
$ ipa delegation-add "managers-update-org-data" \
  --group=managers \
  --membergroup=employees \
  --attrs=costCenter,officeLocation,badgeNumber \
  --permissions=write

Best Practices

Design Principles

Least privilege: Grant access only to attributes required for the delegated task. Don’t delegate entire attribute sets when only a few are needed.

Clear naming: Use descriptive delegation names that indicate who can do what: “managers-edit-employee-contacts” rather than “delegation1”.

Group organization: Structure groups to align with delegation needs. Create purpose-specific groups (e.g., “engineering-admins”) rather than overloading general groups.

Attribute list completeness: When modifying delegation rules with delegation-mod, always include the complete attribute list. The command replaces the entire list, not appends to it.

Read vs write clarity: Use read-only delegations for audit and reporting purposes. Use write delegations only when modification is truly needed.

Security Considerations

Sensitive attributes: Never delegate write access to security-critical attributes like userPassword, krbPrincipalKey, nsAccountLock, or memberOf (group membership). Use RBAC roles with appropriate privileges instead.

Privilege escalation risk: Be cautious delegating attributes that could enable privilege escalation. For example, delegating write access to sshPublicKey allows the delegator to potentially gain shell access as target users.

Group membership control: Ensure delegator groups (—group) have controlled membership. Adding a user to the delegator group grants them access to modify target users.

Cross-department delegation: Avoid delegating across organizational boundaries unless there’s clear business justification. Department A’s managers shouldn’t typically manage Department B’s employees.

Audit delegations: Regularly review active delegations to ensure they still align with organizational needs and haven’t become outdated.

Operational Practices

Test before production: Create test delegations in a non-production environment to verify they grant intended access and nothing more.

Documentation: Maintain documentation explaining why each delegation exists, which business process it supports, and who requested it.

Review cycles: Periodically audit delegation rules (quarterly or annually) to remove obsolete delegations and adjust scopes as organizational needs change.

Change management: Treat delegation rule changes like other access control modifications—require approval and log changes for audit trails.

Combine with RBAC: Use delegations for attribute-level group-to-group access. Use RBAC (permissions, privileges, roles) for broader administrative tasks like user creation, group management, or policy configuration.

Attribute Selection

Common safe attributes for delegation:

• Contact information: telephoneNumber, mobile, mail, street, city, state, postalCode
• Job information: title, department, manager (reference only), employeeNumber (if not used as authentication)
• Display attributes: displayName, givenName, sn, initials

Risky attributes to avoid delegating:

• Authentication: userPassword, krbPrincipalKey, sshPublicKey (allows access as user)
• Account control: nsAccountLock, krbPrincipalExpiration, passwordExpiration
• Authorization: memberOf, role assignments, privilege grants
• System attributes: uidNumber, gidNumber (changing can break file ownership)

Group Structure

Delegator groups: Should have well-defined membership policies. Members of delegator groups gain access to modify target users.

Target groups: Can be broad (e.g., “all-employees”) for organization-wide delegations or narrow (e.g., “engineering-contractors”) for department-specific delegations.

Nested groups: Delegation rules work with nested group memberships—if “managers” contains “senior-managers” as a nested group, senior managers also receive the delegated access.

Integration Points

RBAC (Permissions, Privileges, Roles)

Delegation rules and RBAC are complementary:

Use delegation for: Attribute-level access based on group relationships (manager-employee, department-member)

Use RBAC for: Broader administrative tasks (user creation, group management, policy configuration)

Combined access: A user’s effective access is the union of delegation rules and RBAC permissions they possess. For example, a user in both “managers” (delegation) and “User Administrator” (role) has access from both sources.

Commands: permission-add, privilege-add, role-add, role-add-member

Self-Service Rules

Self-service rules allow users to modify their own attributes, while delegation rules allow users to modify other users’ attributes:

Use selfservice for: Attributes users should control themselves (personal phone, SSH keys for their own account)

Use delegation for: Attributes that should be managed by others (manager updating employee title, HR updating department)

Overlap: Can coexist—users can update their own contact info (selfservice) while managers can also update it (delegation)

Commands: selfservice-add, selfservice-mod, selfservice-find

Group Management

Delegation rules depend on group membership:

Delegator groups: Membership in the --group determines who receives delegated access

Target groups: Membership in the --membergroup determines whose attributes can be modified

Dynamic membership: Works with automember rules—as users are automatically added to groups, delegation rules automatically apply

Commands: group-add, group-add-member, automember-add

User Entries

Delegation rules control access to user LDAP attributes:

Attribute modification: Delegated users can use ipa user-mod to change allowed attributes of target users

Attribute visibility: Read delegations allow viewing attributes in ipa user-show output

Self-modification prevention: Delegation rules don’t grant users access to modify their own entries unless they’re members of both delegator and target groups

Commands: user-mod, user-show, user-find

LDAP ACIs

Delegation rules are implemented as LDAP Access Control Instructions:

ACI generation: IPA automatically creates ACIs in the LDAP directory to enforce delegation rules

Replication: ACIs replicate across all IPA servers via LDAP replication

Manual ACIs: Avoid creating manual ACIs that overlap with delegation rules—this can cause conflicts or unexpected behavior

Audit and Logging

Delegation rule usage is logged:

Modification tracking: User attribute changes are logged with the user who made the change

Delegation auditing: Review logs to see which delegated users are modifying which attributes

Compliance: Delegation change logs support compliance requirements for access control auditing

Security Considerations

1. Delegation Enables Privilege Escalation Paths

Users with delegation rights can modify attributes that may grant additional privileges.

• Delegated write access to group membership enables adding users to privileged groups
• Delegated write to user authentication types enables disabling 2FA requirements
• Delegated write to user shells or home directories enables command injection vectors
• Carefully review which attributes are included in delegation rules
• Sensitive attributes (group membership, authentication settings, sudo rules) require extra scrutiny
• Use separate delegation rules for sensitive vs non-sensitive attributes

2. Broad Delegation Target Groups

Delegation rules with overly broad target groups (--membergroup) grant excessive access scope.

• Delegation targeting “all users” group provides organization-wide attribute modification
• Attackers compromising delegated user gain access to modify many accounts
• Principle of least privilege: limit target groups to specific teams or departments
• Review delegation target groups regularly; narrow scope when possible
• Consider multiple narrower delegation rules instead of one broad rule

3. Read Delegation Information Disclosure

Read-only delegation exposes attribute values that may be sensitive.

• Employee salaries, SSNs, or personal data may be exposed via read delegation
• Even “harmless” attributes like email or phone can enable social engineering
• Read delegation bypasses normal attribute visibility restrictions
• Grant read delegation only for attributes truly needed for delegator’s role
• Consider data classification when designing delegation rules

4. Delegation Rule Modification by Privileged Users

Users with delegation management privileges can modify delegation rules to grant themselves access.

• Delegation administrators can expand --attrs to include sensitive attributes
• Delegation administrators can add themselves to delegator groups
• Separation of duties: different users manage delegations vs belong to delegator groups
• Audit delegation rule modifications in IPA logs
• Implement organizational approval process for delegation changes

5. Self-Delegation via Group Membership

Users who are members of both delegator and target groups can modify their own attributes.

• Intended for some use cases (managers managing their own team including themselves)
• Unintended for others (users shouldn’t modify their own privileged attributes)
• Review group membership overlap when creating delegation rules
• Use --filter to exclude self-modification if needed (advanced, requires manual ACI)
• Document whether self-modification is intentional for each delegation rule

6. Attribute Injection Attacks

Delegated write access to certain attributes enables injection of malicious content.

• Delegated write to gecos field: users can inject shell metacharacters
• Delegated write to email: users can inject addresses for phishing
• Delegated write to display name: users can impersonate other users in email
• Sanitize and validate attribute values even with delegation
• Application-level validation cannot rely solely on IPA delegation restrictions
• Consider attribute content restrictions in delegation documentation

7. Delegation Rule Naming Collisions

Delegation rule names must be unique but overlap can cause confusion.

• Similar rule names (“HR Updates” vs “HR Update”) create audit confusion
• Deleted and recreated rules with same name may have different settings
• Use descriptive, specific naming conventions (e.g., “HR-Updates-Employee-Titles”)
• Include date or version in rule name if rules change frequently
• Document each delegation rule’s purpose and scope

8. Missing Audit Trail for Delegated Changes

While changes are logged, correlating changes to delegation rules requires analysis.

• User attribute change logged but which delegation rule allowed it may not be obvious
• Bulk changes by delegated users harder to attribute to specific delegation
• Implement external auditing if detailed delegation usage tracking required
• Periodic access reviews to ensure delegation still appropriate
• Consider additional logging in applications using delegated access

9. Delegation Persistence After User Departure

Delegation rules persist even when delegator or target users leave organization.

• Former employee removed from delegator group; delegation rule remains but unused
• Orphaned delegation rules complicate security audits
• Review delegation rules when group membership changes significantly
• Periodic (quarterly/annual) delegation rule audit to remove obsolete rules
• Consider delegation rule expiration policies for temporary access

10. Write Without Read Delegation

Granting write permission without read permission creates “blind write” scenarios.

• Users can modify attributes they cannot view current values
• May cause accidental overwrites or incorrect modifications
• Generally grant both read and write for same attributes
• Exception: password resets don’t require reading current password
• Document intentional write-only delegations with rationale

11. LDAP ACI Conflict with Delegation Rules

Manual LDAP ACIs conflicting with delegation-generated ACIs cause unpredictable behavior.

• IPA generates ACIs automatically for delegation rules
• Manually created ACIs may grant or deny access in ways that conflict
• Prefer IPA delegation commands over manual LDAP ACIs
• If manual ACIs required, carefully review for conflicts with existing delegations
• Test access after manual ACI changes to ensure expected behavior

12. Delegation Across Organizational Boundaries

Delegation rules don’t enforce organizational separation; group membership determines access.

• HR delegation targeting “employees” group includes all employees across all divisions
• May violate data residency or organizational privacy requirements
• Use multiple delegation rules with division-specific groups if needed
• Document organizational boundaries in delegation design
• Consider separate IPA instances for organizations requiring strict separation

13. Privilege Creep Through Group Membership

Users added to delegator groups gradually accumulate delegation privileges.

• User added to “team leads” group inherits all delegation rules for team leads
• Over time, users may accumulate more delegations than role requires
• Regular access reviews to verify users still need delegation privileges
• Remove users from delegator groups when role changes
• Principle of least privilege: minimal delegation for each role

14. Delegation Rule Overlap and Redundancy

Multiple delegation rules granting same access create confusion and audit complexity.

• Rule A and Rule B both grant write access to same attributes for same groups
• Unclear which rule is actually being used for access
• Difficult to revoke access without understanding all overlapping rules
• Consolidate overlapping rules where possible
• Document intentional overlaps with clear rationale
• Regular delegation rule review to identify and merge redundant rules

15. No Built-in Delegation Approval Workflow

Delegation rules take effect immediately upon creation with no approval process.

• No multi-person authorization for delegation rule creation
• Mistakes or malicious delegation rules active immediately
• Implement organizational workflow outside IPA if approval required
• Use IPA staging environment to test delegation rules before production
• Require peer review of delegation rule changes via change management process

Troubleshooting

1. User Cannot Modify Delegated Attributes - Permission Denied

Symptom: User in delegator group receives “Insufficient access” error when modifying user attributes.

Diagnosis:

# Verify user is member of delegator group
ipa group-show delegator-group | grep "Member users"

# Verify delegation rule exists
ipa delegation-find

# Show specific delegation rule
ipa delegation-show "Delegation Rule Name"

# Verify target user is member of target group
ipa group-show target-group | grep "Member users"

Resolution:

• Ensure user is member of delegator group:

  ipa group-add-member delegator-group --users=username

• Verify delegation rule includes required attributes:

  ipa delegation-show "Rule Name" | grep "Attributes"

• Check target user is member of --membergroup specified in delegation

2. Delegation Rule Not Taking Effect After Creation

Symptom: Created delegation rule but users still cannot modify attributes.

Diagnosis:

# Show delegation rule
ipa delegation-show "New Rule"

# Check LDAP ACI creation
ldapsearch -x -D "cn=Directory Manager" -W \
  -b "cn=users,cn=accounts,dc=example,dc=com" \
  "(aci=*)" aci | grep "delegation"

# Wait for replication if multi-master

Resolution:

• Wait 30-60 seconds for LDAP replication across servers
• Verify delegation rule parameters correct (group, membergroup, attrs)
• User may need to re-authenticate to pick up new access:

  kdestroy
  kinit username

• Check IPA logs for errors during rule creation

3. Cannot Create Delegation - Group Not Found

Symptom: delegation-add fails with “group not found” error.

Diagnosis:

# Verify delegator group exists
ipa group-show delegator-group

# Verify target group exists
ipa group-show target-group

# Check exact group name spelling
ipa group-find delegator

Resolution:

• Create missing groups first:

  ipa group-add delegator-group --desc="Users who can delegate"
  ipa group-add target-group --desc="Users whose attributes can be modified"

• Use exact group names (case-sensitive) in delegation rule
• Verify group type is user group (not POSIX, external, or service group)

4. Delegated User Can Modify Own Attributes Unexpectedly

Symptom: User with delegation can modify their own attributes when this wasn’t intended.

Diagnosis:

# Check if user is member of both delegator and target groups
ipa user-show username --all | grep "memberof group"

# Check delegation rule groups
ipa delegation-show "Rule Name"

Resolution:

• User is member of both --group (delegator) and --membergroup (target)
• This allows self-modification (may be intentional)
• If unintended, remove user from one of the groups
• Or create separate groups ensuring no overlap
• Document whether self-modification is allowed for each delegation

5. Cannot Delete Delegation Rule

Symptom: delegation-del command fails or has no effect.

Diagnosis:

# Verify delegation rule exists
ipa delegation-show "Rule Name"

# Check for exact rule name
ipa delegation-find | grep "Delegation name"

# Try deletion with exact name
ipa delegation-del "Exact Rule Name"

Resolution:

• Use exact delegation rule name (case-sensitive, spaces matter)
• Check for special characters in rule name
• If still failing, check IPA logs:

  journalctl -u ipa -n 50 | grep delegation

• Verify user has permission to delete delegations

6. Delegation Works for Some Users But Not Others

Symptom: Some users in delegator group can modify attributes, others cannot.

Diagnosis:

# Check if all users are actually in delegator group
ipa group-show delegator-group --all

# Check if failing users have necessary Kerberos tickets
klist

# Verify users authenticating to correct IPA server
ipa env | grep server

Resolution:

• Ensure all users are direct members of delegator group

  ipa group-add-member delegator-group --users=user1,user2,user3

• Group nesting may not work for delegations; use direct membership
• Users need valid Kerberos tickets:

  kinit username

• Check LDAP replication if different servers have different states

7. Cannot Specify Certain Attributes in Delegation

Symptom: Delegation rule creation or modification fails when specifying certain attributes.

Diagnosis:

# Attempt to create delegation with attribute
ipa delegation-add "Test" \
  --group=delegator \
  --membergroup=target \
  --attrs=problematicattr

# Check attribute name spelling
ipa user-show testuser --all | grep -i attr

Resolution:

• Verify attribute name exists and is spelled correctly (case-sensitive)
• Some system attributes may be restricted from delegation
• Use LDAP attribute names (e.g., givenname not first)
• List multiple attributes with commas: --attrs=attr1,attr2,attr3
• Check attribute is valid for user entries (not for other object types)

8. Read Delegation Shows Attributes as Asterisks

Symptom: Users with read delegation see ******** instead of attribute values.

Diagnosis:

# Check delegation includes read permission
ipa delegation-show "Rule Name" | grep "Permissions"

# Should show: read (or both read and write)

# Test attribute visibility
ipa user-show targetuser --all | grep attributename

Resolution:

• Delegation must grant read permission for attributes to be visible
• Modify delegation to include read:

  ipa delegation-mod "Rule Name" --permissions=read,write

• Some attributes always protected (passwords, Kerberos keys)
• User needs valid Kerberos ticket to query attributes

9. Delegation Rule Name Already Exists

Symptom: Cannot create delegation rule; error indicates name already in use.

Diagnosis:

# List all delegation rules
ipa delegation-find

# Show existing rule with same name
ipa delegation-show "Conflicting Name"

Resolution:

• Choose different delegation rule name
• Or delete existing rule if no longer needed:

  ipa delegation-del "Conflicting Name"

• Use descriptive, specific names to avoid conflicts
• Include scope in name (e.g., “HR-Employee-Updates-2024”)

10. Delegated Modifications Not Appearing in Audit Logs

Symptom: User attribute changes made via delegation don’t appear in expected logs.

Diagnosis:

# Check IPA audit logs
journalctl -u ipa | grep "user-mod"

# Check LDAP modification logs
grep "MOD" /var/log/dirsrv/slapd-EXAMPLE-COM/access

# Verify logging configuration
ipa-advise config-server-for-smart-card-auth | grep log

Resolution:

• IPA logs should capture all attribute modifications
• Check log level configuration in /etc/ipa/server.conf
• LDAP access logs show all modifications with bind DN
• Correlate LDAP changes with IPA user operations
• Consider external SIEM integration for comprehensive audit trail

11. Cannot Modify Group Membership via Delegation

Symptom: Delegation rule includes member attribute but group membership modification fails.

Diagnosis:

# Check delegation rule
ipa delegation-show "Rule Name" | grep "Attributes"

# Should include: member

# Attempt group modification
ipa group-add-member groupname --users=username

Resolution:

• Group membership modification requires different approach
• Delegation of group membership modification is complex
• May need to use direct LDAP ACIs for group membership delegation
• Consider using RBAC roles for group management delegation instead
• Contact IPA support for advanced group membership delegation

12. Delegation Permissions Shows Empty

Symptom: delegation-show displays empty or missing permissions.

Diagnosis:

# Show delegation with all attributes
ipa delegation-show "Rule Name" --all

# Check if permissions explicitly set
ipa delegation-show "Rule Name" | grep -i permission

Resolution:

• Default permission is write if not specified
• Explicitly set permissions:

  ipa delegation-mod "Rule Name" --permissions=read,write

• Valid permissions: read, write (or both)
• Empty permissions means rule may not be functional

13. Delegation Works via CLI But Not Web UI

Symptom: Users can modify delegated attributes with ipa user-mod but not through Web UI.

Diagnosis:

# Test via CLI
ipa user-mod targetuser --title="New Title"
# Works

# Check Web UI error messages in browser console
# Check IPA server logs during Web UI attempt
journalctl -u httpd -f

Resolution:

• Web UI may have additional permission checks
• Ensure user has valid Kerberos ticket for Web UI session
• Clear browser cache and cookies
• Web UI delegation support may differ from CLI
• Some attributes may not be editable via Web UI regardless of delegation
• Use CLI for delegated operations if Web UI has limitations

14. Delegation Target Group Membership Changes Don’t Reflect

Symptom: Added users to target group but delegation doesn’t apply to them.

Diagnosis:

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

# Check delegation rule target group
ipa delegation-show "Rule Name" | grep "Member of group"

# Wait for replication
sleep 60

Resolution:

• Wait for LDAP replication (30-60 seconds)
• Verify exact group name matches in delegation rule
• User may need to re-authenticate:

  kdestroy
  kinit username

• Check group is correct type (user group, not external or POSIX)
• Force group membership cache refresh on client

15. Delegation Rule Modification Has No Effect

Symptom: Modified delegation rule but changes don’t apply.

Diagnosis:

# Show delegation rule
ipa delegation-show "Rule Name" --all

# Verify modification succeeded
# Check modification timestamp if available

# Test with user account
ipa user-mod targetuser --attributename=value

Resolution:

• Wait for LDAP ACI regeneration and replication
• Changes may take 30-60 seconds to propagate
• Restart IPA service if changes still not effective:

  systemctl restart ipa

• Verify modification command succeeded (check output)
• Re-apply modification if needed:

  ipa delegation-mod "Rule Name" --attrs=attr1,attr2,attr3

Commands

delegation-add

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

Add a new delegation.

Arguments

Argument	Required	Description
NAME	yes	Delegation name

Options

Option	Description
--permissions PERMISSIONS	Permissions to grant (read, write). Default is write.
--attrs ATTRS	Attributes to which the delegation applies
--membergroup MEMBERGROUP	User group to apply delegation to
--group GROUP	User group ACI grants access to
--all	Retrieve and print all attributes from the server. Affects command output.
--raw	Print entries as stored on the server. Only affects output format.

delegation-del

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

Delete a delegation.

Arguments

Argument	Required	Description
NAME	yes	Delegation name

delegation-find

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

Search for delegations.

Arguments

Argument Required Description

---

CRITERIA no A string searched in all relevant object attributes

Options

Option	Description
--name NAME	Delegation name
--permissions PERMISSIONS	Permissions to grant (read, write). Default is write.
--attrs ATTRS	Attributes to which the delegation applies
--membergroup MEMBERGROUP	User group to apply delegation to
--group GROUP	User group ACI grants access to
--pkey-only	Results should contain primary key attribute only (“name”)
--all	Retrieve and print all attributes from the server. Affects command output.
--raw	Print entries as stored on the server. Only affects output format.

delegation-mod

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

Modify a delegation.

Arguments

Argument	Required	Description
NAME	yes	Delegation name

Options

Option	Description
--permissions PERMISSIONS	Permissions to grant (read, write). Default is write.
--attrs ATTRS	Attributes to which the delegation applies
--membergroup MEMBERGROUP	User group to apply delegation to
--group GROUP	User group ACI grants access to
--all	Retrieve and print all attributes from the server. Affects command output.
--raw	Print entries as stored on the server. Only affects output format.

delegation-show

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

Display information about a delegation.

Arguments

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