Self-Service Permissions

Overview

Self-service permissions grant users the ability to modify their own LDAP entry attributes without requiring administrative intervention. This empowers users to keep their own information current while reducing help desk burden and administrative overhead.

Unlike delegation rules (which grant group members access to modify other users’ attributes) or RBAC permissions (which grant administrative access to manage multiple users), self-service permissions grant every authenticated user access to modify specific attributes of their own entry.

Self-service permissions support common user autonomy scenarios:

• Users updating their own contact information (phone, email, address)
• Users managing their own SSH public keys for server access
• Users setting their own preferred language or display name
• Users uploading their own X.509 certificates for authentication

Self-service reduces administrative bottlenecks by enabling users to handle routine updates themselves. Instead of submitting help desk tickets to change a phone number, users can update the attribute directly via the IPA WebUI, command-line tools, or LDAP clients.

Self-Service Model

Access Pattern

Self-service permissions create this access pattern:

All authenticated users can [read|write] ATTRIBUTES in their own entry

The permission applies universally to all users—there’s no targeting specific users or groups. If a self-service permission grants write access to telephoneNumber, every user can modify their own telephone number (but not other users’ telephone numbers).

Components

Every self-service permission consists of three components:

Attributes (--attrs): The specific LDAP attributes users can read or modify in their own entries. Example: telephoneNumber, mobile, sshPublicKey, preferredLanguage.

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

Name: A descriptive identifier for the self-service rule. Example: “Users manage their own contact info”.

Scope

Self-service permissions only apply to the authenticated user’s own entry:

• Users cannot modify attributes of other users (use delegation rules for that)
• Users cannot modify group, host, or service entries (use RBAC permissions for that)
• Users cannot create or delete their own accounts (administrator-only operations)

Self-Service vs Delegation vs RBAC

Self-service: Users modify their own attributes

• Example: Alice updates her own phone number
• Applies to: All authenticated users, their own entries only
• Use for: Personal information users should control

Delegation: Group members modify other users’ attributes

• Example: Managers update employee titles
• Applies to: Members of delegator group modifying members of target group
• Use for: Hierarchical or departmental attribute management

RBAC: Administrators manage any users’ attributes (and more)

• Example: User administrators create, modify, delete users
• Applies to: Role members managing any/all users
• Use for: Broad administrative tasks

These three mechanisms can coexist—a user might update their own phone number (self-service), their manager might also be able to update it (delegation), and user administrators can definitely update it (RBAC).

Read vs Write Permissions

Write Permission (Default)

Write permission (--permissions=write) grants users the ability to both view and modify the specified attributes in their own entry:

• Users can see their current attribute values
• Users can change attribute values
• Most common for self-service use cases

Example: Users need to see their current phone number to update it.

Read Permission

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

• Users can see their current attribute values
• Users cannot change attribute values
• Rarely used for self-service (users typically can already read most of their own attributes)

Example: Might be used to grant users read access to computed or automatically-managed attributes that shouldn’t be user-modifiable.

Safe vs Risky Attributes

Safe Attributes for Self-Service

These attributes are generally safe for user modification:

Contact information:

• telephoneNumber: Phone number
• mobile: Mobile phone
• mail: Email address
• street, l (locality/city), st (state), postalCode, c (country): Physical address components

Display attributes:

• displayName: Display name
• preferredLanguage: Preferred language (e.g., “en-US”)
• initials: User initials

Personal metadata:

• carLicense: Car license plate
• title: Job title (if organizational policy allows)

Authentication credentials (with caution):

• sshPublicKey: SSH public key for authentication
• userCertificate: X.509 certificate for authentication
• ipaPasskey: Passkey mapping for FIDO2 authentication

Communication:

• pager: Pager number
• fax: Fax number

Risky Attributes to Avoid

These attributes should NOT be granted for self-service:

Account control:

• nsAccountLock: Account enabled/disabled status
• krbPrincipalExpiration: Kerberos principal expiration
• passwordExpiration: Password expiration date

Authorization:

• memberOf: Group memberships (grants access/privileges)
• Role assignments, privilege assignments

System identifiers:

• uidNumber: UNIX UID (changing breaks file ownership)
• gidNumber: UNIX GID (changing breaks file ownership)
• krbPrincipalName: Kerberos principal name (changing breaks authentication)

Credentials:

• userPassword: Password (use ipa passwd command instead, which enforces policies)
• krbPrincipalKey: Kerberos keys (managed automatically)

Organizational structure:

• manager: Manager reference (should be managed by HR/managers)
• employeeNumber: Employee ID (should be managed by HR)
• department: Department assignment (should be managed by HR/managers)

Examples

Create Basic Self-Service Rule

# Allow users to update their own phone numbers
$ ipa selfservice-add "Users manage phone numbers" \
  --permissions=write \
  --attrs=telephoneNumber,mobile

  Self-service name: Users manage phone numbers
  Permissions: write
  Attributes: telephoneNumber, mobile

Allow Users to Manage Contact Information

# Comprehensive contact information self-service
$ ipa selfservice-add "Users manage contact info" \
  --permissions=write \
  --attrs=telephoneNumber,mobile,mail,pager,fax

  Self-service name: Users manage contact info
  Permissions: write
  Attributes: telephoneNumber, mobile, mail, pager, fax

Allow Users to Manage Address

# Enable address self-management (using Bash brace expansion)
$ ipa selfservice-add "Users manage address" \
  --permissions=write \
  --attrs={street,l,st,postalCode,c}

  Self-service name: Users manage address
  Permissions: write
  Attributes: street, l, st, postalCode, c

Allow Users to Manage SSH Keys

# Enable SSH public key self-management
$ ipa selfservice-add "Users manage SSH keys" \
  --permissions=write \
  --attrs=sshPublicKey

  Self-service name: Users manage SSH keys
  Permissions: write
  Attributes: sshPublicKey

Allow Users to Set Display Preferences

# Enable display name and language preferences
$ ipa selfservice-add "Users manage display preferences" \
  --permissions=write \
  --attrs=displayName,preferredLanguage

  Self-service name: Users manage display preferences
  Permissions: write
  Attributes: displayName, preferredLanguage

Modify Self-Service Rule (Add Attributes)

# Add additional attributes to existing rule
# IMPORTANT: Must include all existing attributes when modifying
$ ipa selfservice-mod "Users manage contact info" \
  --attrs=telephoneNumber,mobile,mail,pager,fax,street,l,st,postalCode

  Self-service name: Users manage contact info
  Permissions: write
  Attributes: telephoneNumber, mobile, mail, pager, fax, street, l, st, postalCode

List All Self-Service Rules

# View all active self-service permissions
$ ipa selfservice-find
  3 self-service permissions matched
  Self-service name: Users manage contact info
  Permissions: write
  Attributes: telephoneNumber, mobile, mail
  Self-service name: Users manage SSH keys
  Permissions: write
  Attributes: sshPublicKey
  [...]

Show Self-Service Rule Details

# View specific self-service permission
$ ipa selfservice-show "Users manage contact info"
  Self-service name: Users manage contact info
  Permissions: write
  Attributes: telephoneNumber, mobile, mail, pager, fax

Delete Self-Service Rule

# Remove self-service permission
$ ipa selfservice-del "Users manage contact info"
  Deleted self-service permission "Users manage contact info"

Allow Certificate Self-Management

# Enable X.509 certificate self-management
$ ipa selfservice-add "Users manage certificates" \
  --permissions=write \
  --attrs=userCertificate

  Self-service name: Users manage certificates
  Permissions: write
  Attributes: userCertificate

Allow Job Title Self-Management

# Allow users to update their own job title (if organizational policy permits)
$ ipa selfservice-add "Users manage job title" \
  --permissions=write \
  --attrs=title

  Self-service name: Users manage job title
  Permissions: write
  Attributes: title

Comprehensive Personal Information Self-Service

# Create broad self-service permission for personal data
$ ipa selfservice-add "Users manage personal information" \
  --permissions=write \
  --attrs=telephoneNumber,mobile,mail,street,l,st,postalCode,displayName,preferredLanguage,sshPublicKey

  Self-service name: Users manage personal information
  Permissions: write
  Attributes: telephoneNumber, mobile, mail, street, l, st, postalCode, displayName, preferredLanguage, sshPublicKey

Best Practices

Design Principles

User autonomy: Grant self-service access to attributes users are responsible for maintaining (contact information, preferences, authentication credentials).

Reduce help desk burden: Self-service for routine updates (phone number changes, SSH key rotation) frees help desk staff for more complex issues.

Clear naming: Use descriptive names that explain what users can do: “Users manage contact info” rather than “selfservice1”.

Attribute list completeness: When modifying self-service rules with selfservice-mod, always include the complete attribute list. The command replaces the entire list.

Conservative approach: Start with minimal self-service permissions (just contact info) and expand based on user requests and organizational trust level.

Security Considerations

Never delegate account control: Never grant self-service write access to nsAccountLock, krbPrincipalExpiration, or other account status attributes. Users could enable disabled accounts or prevent expiration.

Be cautious with authentication credentials: Self-service for sshPublicKey and userCertificate allows users to authenticate. Ensure users understand security implications and organizational policies (e.g., key length requirements, certificate validity periods).

Avoid system identifiers: Never grant self-service write access to uidNumber, gidNumber, or krbPrincipalName. Changing these breaks authentication, file ownership, and access controls.

Organizational attributes: Decide whether users should self-manage attributes like title, department, manager. Some organizations prefer HR or management control over these.

Read-only preference: Prefer self-service write access (users actively manage attributes) over read access (users can already read most of their own attributes by default).

Operational Practices

Communication: Inform users about self-service capabilities. Many users won’t know they can update their own information without formal communication.

Training: Provide documentation or training on using the WebUI or CLI to modify self-service attributes. Not all users are comfortable with LDAP tools.

Policy alignment: Ensure self-service permissions align with organizational data ownership policies. If HR owns contact information, don’t grant self-service for those attributes.

Regular review: Periodically audit self-service permissions to ensure they still align with organizational needs and security posture.

Monitor usage: Track which self-service attributes are frequently modified and which are rarely used. Remove unused permissions to reduce complexity.

Attribute Selection

Start conservative: Begin with clearly personal attributes:

• First priority: telephoneNumber, mobile, mail
• Second priority: street, l, st, postalCode (address components)
• Third priority: displayName, preferredLanguage, initials

Expand cautiously: Add authentication credentials only after user education:

• sshPublicKey: After users understand key management and security
• userCertificate: After users understand certificate lifecycle
• ipaPasskey: After users understand FIDO2/WebAuthn

Organization-specific: Add custom schema attributes for self-service based on organizational needs (e.g., badgeNumber, officeLocation if users should manage these).

User Experience

WebUI preferred: Most users will manage self-service attributes via the FreeIPA WebUI, which provides a user-friendly interface. Ensure WebUI self-service pages are intuitive.

Validation: Consider implementing client-side validation (in WebUI or custom tools) to prevent users from entering malformed data (invalid phone numbers, email addresses, etc.).

Change notifications: Consider implementing notifications when self-service attributes change (email to user confirming they changed their phone number). This detects unauthorized changes.

Help text: Provide clear help text in WebUI explaining what each attribute is for and acceptable formats.

Integration Points

RBAC (Permissions, Privileges, Roles)

Self-service permissions coexist with RBAC:

Self-service: All users can modify their own attributes RBAC: Role members can modify any users’ attributes

Combined access: Administrators with both self-service permissions and RBAC roles can modify their own attributes via self-service and other users’ attributes via RBAC.

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

Delegation Rules

Self-service and delegation can overlap:

Self-service: Alice modifies her own phone number Delegation: Alice’s manager also can modify Alice’s phone number

Precedence: Both mechanisms work—users can self-modify, and delegated users can also modify. No conflict.

Use case: Enable self-service for user autonomy, enable delegation for managerial oversight (manager can update employee info if employee hasn’t).

Commands: delegation-add, delegation-mod

User Entries

Self-service permissions control what users can modify in their own LDAP entries:

Modification: Users can use ipa user-mod $(ipa whoami) to modify their own attributes WebUI: Users access Settings in WebUI to modify self-service attributes LDAP tools: Advanced users can use ldapmodify to change self-service attributes

Commands: user-mod, whoami

WebUI Self-Service

The FreeIPA WebUI provides a self-service interface:

Settings page: Users access their own profile to modify self-service attributes Automatic population: WebUI automatically shows only attributes users can modify (based on self-service permissions) User-friendly: WebUI provides form inputs, validation, and help text for self-service attributes

Password Changes

Password changes are handled separately from self-service permissions:

Separate mechanism: Users change their own passwords via ipa passwd command or WebUI password change feature, not via self-service permissions Policy enforcement: Password changes enforce password policy (strength, history, expiration) regardless of self-service permissions Why separate: Granting self-service write to userPassword bypasses policy enforcement

Commands: passwd, user-mod --password (prompts for password, enforces policy)

LDAP ACIs

Self-service permissions are implemented as LDAP Access Control Instructions:

ACI generation: IPA creates ACIs granting “self” write access to specified attributes Replication: ACIs replicate across all IPA servers Self keyword: ACIs use the LDAP “self” target to match authenticated user’s own entry

Audit and Logging

Self-service attribute changes are logged:

Audit trail: User attribute modifications are logged with username and timestamp Self-modification tracking: Logs distinguish between user modifying own attributes (self-service) vs administrator modifying user attributes (RBAC) Compliance: Self-service logs support compliance auditing for who changed what data when

Use Cases

Enabling User Contact Information Updates

Organizations want users to keep their own contact information current without requiring help desk intervention for every phone number or email change.

# Create self-service permission for contact information
ipa selfservice-add "Users manage their own contact info" \
  --attrs=telephonenumber,mobile,mail,street,l,st,postalcode \
  --permissions=write

# Users can now update their own contact information
kinit alice
ipa user-mod alice --phone="+1-555-0123" --mobile="+1-555-0456"
ipa user-mod alice --email="alice.updated@example.com"

# No administrator intervention required
# Contact directory automatically stays current as users update info

Allowing SSH Public Key Self-Management

DevOps environments need users to manage their own SSH public keys for server access without waiting for administrators to add keys manually.

# Create self-service permission for SSH keys
ipa selfservice-add "Users manage their own SSH keys" \
  --attrs=sshpubkey \
  --permissions=write

# Users can add/remove SSH keys themselves
kinit bob
ipa user-mod bob --sshpubkey="ssh-rsa AAAAB3NzaC1yc2EA..."

# Users can manage multiple keys
ipa user-mod bob \
  --sshpubkey="ssh-rsa AAAAB3Nz...workstation" \
  --sshpubkey="ssh-ed25519 AAAAC3N...laptop"

# Users can remove keys when devices are retired
ipa user-mod bob --sshpubkey=""  # Clear all keys
ipa user-mod bob --sshpubkey="ssh-rsa AAAAB3..."  # Re-add current key

Empowering Preferred Name and Display Name Updates

Users should be able to set their preferred display name and language preferences to personalize their IPA experience.

# Create self-service permission for display preferences
ipa selfservice-add "Users set display preferences" \
  --attrs=displayname,preferredlanguage,initials \
  --permissions=write

# Users can set their preferred display name
kinit charlie
ipa user-mod charlie --displayname="Charlie (They/Them)"

# Users can set preferred language
ipa user-mod charlie --preferredlanguage="en-US"

# Users can update initials
ipa user-mod charlie --initials="CW"

# Changes reflected in IPA WebUI and applications

Certificate Self-Service for Smart Card Users

Organizations deploying smart card authentication need users to upload their own X.509 certificates without administrator assistance.

# Create self-service permission for user certificates
ipa selfservice-add "Users manage their own certificates" \
  --attrs=usercertificate \
  --permissions=write

# Users can upload certificate from smart card
kinit david
ipa user-mod david --certificate="$(cat /tmp/david-cert.pem)"

# Users can add multiple certificates for different devices
ipa user-mod david \
  --certificate="$(cat /tmp/workstation-cert.pem)" \
  --certificate="$(cat /tmp/laptop-cert.pem)"

# Users can remove certificates when cards are replaced
ipa user-mod david --certificate=""  # Clear all certificates
ipa user-mod david --certificate="$(cat /tmp/new-cert.pem)"  # Add new cert

Personal Metadata Self-Management

Users should maintain their own personal metadata like job title, office location, or employee-specific attributes without administrator bottlenecks.

# Create self-service permission for personal metadata
ipa selfservice-add "Users update personal metadata" \
  --attrs=title,physicaldeliveryofficename,roomnumber,carlicense \
  --permissions=write

# Users update job title after promotion
kinit emma
ipa user-mod emma --title="Senior Software Engineer"

# Users update office location after move
ipa user-mod emma --setattr=physicaldeliveryofficename="Building C, Floor 3"
ipa user-mod emma --setattr=roomnumber="C-321"

# Users update car license for parking access
ipa user-mod emma --carlicense="ABC-1234"

Read-Only Self-Service for Compliance Verification

Compliance requirements may mandate that users can view but not modify certain computed or automatically-managed attributes.

# Create read-only self-service permission
ipa selfservice-add "Users view their own account metadata" \
  --attrs=employeenumber,employeetype,accountexpires \
  --permissions=read

# Users can view but not modify these attributes
kinit frank
ipa user-show frank | grep "Employee number"
  Employee number: EMP-12345

# Attempt to modify fails (no write permission)
ipa user-mod frank --setattr=employeenumber=99999
  ipa: ERROR: Insufficient access: Insufficient 'write' privilege
  to the 'employeeNumber' attribute

# Read-only access enables verification without modification risk

Removing Self-Service Permissions After Pilot

After piloting self-service capabilities, organizations may need to remove permissions if users misused the capability or requirements changed.

# Show current self-service permissions
ipa selfservice-find
  Self-service name: Users manage their own contact info
  Self-service name: Users manage their own SSH keys

# Remove SSH key self-service after security review
ipa selfservice-del "Users manage their own SSH keys"

# Verify removal
ipa selfservice-find
  Self-service name: Users manage their own contact info
  # SSH key self-service removed

# Users can no longer modify SSH keys themselves
# Administrators must now add/remove SSH keys (RBAC)

Scoped Self-Service for Sensitive Attributes

Organizations may want users to update some attributes (phone, email) but require administrator approval for sensitive changes (title, manager).

# Create self-service permission for non-sensitive attributes only
ipa selfservice-add "Users update basic contact info" \
  --attrs=telephonenumber,mobile,mail \
  --permissions=write

# Deliberately exclude sensitive attributes: title, manager, employeetype
# These require administrator modification via RBAC

# Users can update phone/email themselves
kinit george
ipa user-mod george --phone="+1-555-9999"  # Success

# Users cannot update sensitive attributes
ipa user-mod george --title="VP of Engineering"
  ipa: ERROR: Insufficient access: Insufficient 'write' privilege
  to the 'title' attribute
  # Title changes require administrator approval

Auditing Self-Service Usage

After enabling self-service permissions, administrators need to monitor usage to detect misuse or verify adoption.

# Find all self-service permissions
ipa selfservice-find --all

# For each self-service permission, show details
ipa selfservice-show "Users manage their own contact info" --all
  Self-service name: Users manage their own contact info
  Attributes: telephonenumber, mobile, mail
  Permissions: write

# Monitor audit logs for self-service modifications
# In /var/log/dirsrv/slapd-REALM/audit, look for modifications
# by users on their own entries
grep "replace: telephonenumber" /var/log/dirsrv/slapd-*/audit | \
  grep "modifiersname: uid=alice"
# Shows alice modified her own phone number (self-service)

grep "replace: telephonenumber" /var/log/dirsrv/slapd-*/audit | \
  grep "modifiersname: uid=admin"
# Shows admin modified someone's phone number (RBAC)

Multi-Attribute Self-Service with Incremental Rollout

Organizations may start with minimal self-service and gradually expand as users demonstrate responsible usage.

# Phase 1: Basic contact info only
ipa selfservice-add "Phase 1: Basic contact" \
  --attrs=telephonenumber,mobile \
  --permissions=write

# Wait 30 days, monitor for misuse
# If successful, expand to Phase 2

# Phase 2: Add email and physical address
ipa selfservice-mod "Phase 1: Basic contact" \
  --attrs=telephonenumber,mobile,mail,street,l,st,postalcode

# Rename for clarity
ipa selfservice-mod "Phase 1: Basic contact" \
  --rename="Users manage contact information"

# Phase 3: Add display preferences
ipa selfservice-add "Users manage display preferences" \
  --attrs=displayname,preferredlanguage,initials \
  --permissions=write

# Incremental rollout reduces risk of widespread misuse

Security Considerations

Attribute misuse risks: Users with self-service write permissions can set attributes to incorrect or inappropriate values. For example, users could set display names to offensive text, phone numbers to non-functional values, or email addresses to invalid formats. This pollutes the directory with bad data.

Data validation gaps: Self-service permissions grant write access without enforcing strict validation rules. Users can enter malformed phone numbers (e.g., “123” instead of “+1-555-0123”), invalid email formats, or nonsensical values for structured attributes. Applications consuming this data may fail or behave unexpectedly.

Social engineering exploitation: Attackers can modify their own contact information to impersonate other users or organizations. Changing email to “admin@example.com” or phone number to a help desk number can facilitate social engineering attacks against users who rely on contact information for verification.

Data exfiltration via attribute changes: Users with self-service write access to email attributes can change their email to an external address, then trigger password reset or notification emails to exfiltrate account information. Similarly, changing SSH keys can grant external attackers access to servers.

Compliance data integrity issues: In regulated environments, user-modifiable attributes may need to meet strict data quality standards. Self-service write access without validation can violate compliance requirements if attributes contain PII that must be formatted consistently (e.g., phone numbers for 911 systems).

Persistent attribute pollution: Once users set incorrect values, those values persist until corrected. If users make mistakes (typos, wrong values), the directory remains polluted until administrators manually fix entries. At scale, this creates significant data quality burden.

Audit trail ambiguity: While self-service modifications are logged, distinguishing between legitimate user updates and malicious changes requires manual log analysis. Automated alerting on suspicious self-service modifications (e.g., user changing email 10 times in one hour) is typically not enabled by default.

No approval workflow: Self-service permissions grant immediate write access without approval workflows. Users can change attributes instantly, with no manager or administrator approval required. This prevents organizations from implementing separation of duties for sensitive attributes.

Attribute locking bypass: Some organizations use attribute locking or read-only flags on specific user attributes to prevent changes. Self-service permissions may bypass these controls if ACIs are not correctly ordered, allowing users to modify supposedly-locked attributes.

Cross-attribute consistency problems: Users may update one attribute but forget to update related attributes. For example, changing phone number but not updating mobile, or changing job title but not updating organizational unit. This creates directory inconsistencies that break applications expecting coordinated attribute updates.

Dangerous attribute exposure: Granting self-service write to risky attributes (uidNumber, gidNumber, krbPrincipalName) can break authentication, file ownership, and authorization. Users accidentally changing these values can lock themselves out or gain unintended access to resources.

No multi-factor authentication requirement: Self-service modifications require only Kerberos authentication (password or existing ticket). There’s no built-in option to require multi-factor authentication for sensitive self-service operations like SSH key changes or certificate updates.

Bulk modification abuse: Users can programmatically modify their own attributes rapidly (e.g., changing SSH keys hundreds of times per minute). This can be used to flood audit logs, obscure malicious activity, or test for validation weaknesses.

Certificate upload security: Allowing users to upload their own X.509 certificates via self-service creates risk if certificates are compromised, stolen, or issued by untrusted CAs. IPA may accept any certificate format without validating the certificate authority or expiration.

Passkey/FIDO2 self-enrollment risks: Self-service passkey registration allows users to enroll FIDO2 devices themselves. If not combined with user verification requirements, attackers with stolen passwords can enroll their own FIDO2 devices and establish persistent phishing-resistant authentication.

Troubleshooting

User Cannot Modify Own Attribute Despite Self-Service Permission

Symptom: User receives “Insufficient access” error when attempting to modify an attribute that should be granted by self-service permission.

Diagnosis: Self-service permission may not include the attribute, attribute name may be incorrect, or user’s Kerberos ticket may be stale.

Resolution: Verify self-service permission and refresh ticket:

# Verify self-service permission includes the attribute
ipa selfservice-show "Users manage their own contact info"
  Attributes: telephonenumber, mobile, mail

# Check if user is trying to modify attribute not in list
# If trying to modify "street" but permission doesn't include it:
ipa selfservice-mod "Users manage their own contact info" \
  --attrs=telephonenumber,mobile,mail,street

# User must refresh Kerberos ticket after permission change
# As user:
kdestroy
kinit alice
ipa user-mod alice --street="123 Main St"  # Should succeed now

Self-Service Modification Works in WebUI But Not CLI

Symptom: User can modify attributes via IPA WebUI but same modification fails from command line.

Diagnosis: WebUI and CLI may use different attribute names (friendly names vs LDAP attribute names).

Resolution: Use correct LDAP attribute names in CLI:

# WebUI allows setting "Phone Number" (friendly name)
# CLI requires LDAP attribute name "telephonenumber"

# This fails - wrong attribute name
ipa user-mod alice --phone-number="+1-555-0123"
  ipa: ERROR: Unknown option: --phone-number

# This succeeds - correct attribute name
ipa user-mod alice --phone="+1-555-0123"

# Or use setattr with exact LDAP attribute name
ipa user-mod alice --setattr=telephonenumber="+1-555-0123"

Self-Service Permission Created But Not Working

Symptom: After creating self-service permission, users still cannot modify the specified attributes.

Diagnosis: LDAP replication lag, ACI not yet applied, or user needs new Kerberos ticket.

Resolution: Wait for replication and refresh user tickets:

# Create self-service permission
ipa selfservice-add "Test permission" --attrs=displayname

# Wait for ACI replication across all IPA servers (typically 5-30 seconds)
sleep 30

# Users must get fresh Kerberos tickets to pick up new ACIs
# As user:
kdestroy
kinit alice

# Retry modification
ipa user-mod alice --displayname="Alice Updated"
  # Should succeed after replication and ticket refresh

Cannot Delete Self-Service Permission

Symptom: ipa selfservice-del fails with unexpected error.

Diagnosis: Permission name may have spaces or special characters requiring quotes.

Resolution: Use exact permission name with quotes:

# Show current self-service permissions to get exact name
ipa selfservice-find
  Self-service name: Users manage their own contact info

# Delete using exact name (with quotes if spaces present)
ipa selfservice-del "Users manage their own contact info"

# Verify deletion
ipa selfservice-find
  # Should not list deleted permission

User Modified Wrong Attribute by Mistake

Symptom: User accidentally set wrong value for self-service attribute and needs it corrected.

Diagnosis: User error, no validation prevented incorrect value.

Resolution: User can correct their own mistake, or administrator can fix:

# User accidentally set wrong display name
kinit bob
ipa user-mod bob --displayname="Wrong Name"

# User can immediately correct it
ipa user-mod bob --displayname="Correct Name"

# Or administrator can fix
kinit admin
ipa user-mod bob --displayname="Correct Name"

# For attributes requiring administrator-level validation,
# remove from self-service and require RBAC modification

Self-Service Allows Invalid Data Entry

Symptom: Users can set attributes to invalid values (e.g., phone number “abc”, email “notanemail”) via self-service.

Diagnosis: IPA self-service permissions don’t enforce attribute syntax validation by default.

Resolution: Implement validation via external systems or remove self-service:

# Option 1: Remove self-service and require administrator approval
ipa selfservice-del "Users manage their own contact info"

# Option 2: Keep self-service but add monitoring/validation
# Create validation script to check directory for invalid values
ldapsearch -Y GSSAPI -b "cn=users,cn=accounts,dc=example,dc=com" \
  "(!(telephonenumber=*))" uid mail | \
  grep -E "uid:|mail:" | \
  while read attr value; do
    # Validate value format
    if ! [[ "$value" =~ ^[0-9+-]+$ ]]; then
      echo "Invalid phone for $attr: $value"
    fi
  done

# Option 3: Implement pre-commit validation hook (advanced, requires custom code)

Multiple Self-Service Permissions Conflict

Symptom: Created multiple self-service permissions with overlapping attributes; unclear which applies.

Diagnosis: Multiple self-service permissions with same attributes create redundant ACIs but shouldn’t conflict.

Resolution: Consolidate overlapping permissions for clarity:

# Show all self-service permissions
ipa selfservice-find
  Self-service name: Users manage phones
    Attributes: telephonenumber, mobile
  Self-service name: Users manage contact info
    Attributes: telephonenumber, mobile, mail

# Permissions overlap on telephonenumber and mobile
# Delete redundant permission
ipa selfservice-del "Users manage phones"

# Keep comprehensive permission
ipa selfservice-show "Users manage contact info"
  Attributes: telephonenumber, mobile, mail

Self-Service Permission Missing After Upgrade

Symptom: After IPA upgrade, previously configured self-service permissions no longer exist.

Diagnosis: Upgrade process may have removed or modified self-service permissions; check release notes.

Resolution: Re-create missing permissions:

# List current self-service permissions
ipa selfservice-find
  # If expected permission missing:

# Re-create based on organizational requirements
ipa selfservice-add "Users manage their own contact info" \
  --attrs=telephonenumber,mobile,mail \
  --permissions=write

# Verify creation
ipa selfservice-show "Users manage their own contact info"

# Notify users they may need to refresh Kerberos tickets

User Can Modify Attribute But Changes Don’t Replicate

Symptom: User successfully modifies attribute on one IPA server but changes don’t appear on other replicas.

Diagnosis: Replication failure or replication lag between IPA servers.

Resolution: Check replication status:

# Check replication agreements
ipa-replica-manage list

# Check replication status for each agreement
ipa-replica-manage list-ruv

# Force replication if needed
ipa-replica-manage re-initialize --from=ipa01.example.com

# Verify change propagated
for server in ipa01.example.com ipa02.example.com ipa03.example.com; do
  echo "=== $server ==="
  ipa -s $server user-show alice | grep "Mobile"
done

Self-Service Shows Different Attributes Than Expected

Symptom: ipa selfservice-show displays different attribute list than what was specified during creation.

Diagnosis: May have used ipa selfservice-mod which replaces attribute list rather than adding to it.

Resolution: Verify and correct attribute list:

# Show current attributes
ipa selfservice-show "Users manage contact" --all
  Attributes: mail
  # Expected: telephonenumber, mobile, mail

# Modify to include all intended attributes
ipa selfservice-mod "Users manage contact" \
  --attrs=telephonenumber,mobile,mail

# Verify update
ipa selfservice-show "Users manage contact"
  Attributes: telephonenumber, mobile, mail

Cannot Find Self-Service Permission by Name

Symptom: Self-service permission exists but cannot be found with selfservice-show.

Diagnosis: Permission name has unusual characters, spaces, or case sensitivity issues.

Resolution: Use exact name from selfservice-find:

# List all self-service permissions to get exact names
ipa selfservice-find --pkey-only
  Self-service name: Users manage their own contact info

# Use exact name (case-sensitive, including spaces)
ipa selfservice-show "Users manage their own contact info"

# If name has special characters, use quotes and escaping

User Sees “Entry Not Found” When Modifying Own Attributes

Symptom: User receives “entry not found” error when trying to modify their own attributes.

Diagnosis: User may not have discovered their own DN or DN format is incorrect.

Resolution: Use user-mod with username, not DN:

# Wrong: trying to use DN directly
kinit alice
ipa user-mod "uid=alice,cn=users,cn=accounts,dc=example,dc=com"
  ipa: ERROR: entry not found

# Correct: use username (uid)
ipa user-mod alice --phone="+1-555-0123"
  # Success

# Or use shorthand to modify current user
ipa user-mod $(ipa whoami | awk '{print $2}') --phone="+1-555-0123"

Self-Service Attribute Change Reverted Unexpectedly

Symptom: User modifies attribute via self-service, but value reverts to previous value after some time.

Diagnosis: External synchronization (AD sync, HR feed) may be overwriting user-modified values.

Resolution: Identify and adjust synchronization source:

# Check if attribute is managed by sync agreement
ipa-replica-manage list

# For AD sync, check sync configuration
ipa config-show | grep sync

# Exclude self-service attributes from synchronization
# Or disable self-service for attributes managed by external feeds

# For attributes managed by HR integration, choose:
# - HR system is authoritative: disable self-service
# - Users are authoritative: disable HR sync for those attributes

Self-Service Permission Grants Too Much Access

Symptom: After creating self-service permission, users can modify more attributes than intended.

Diagnosis: May have granted write permission to wildcard or multiple attributes unintentionally.

Resolution: Review and restrict attribute list:

# Show current permission
ipa selfservice-show "Overly broad permission" --all
  Attributes: telephonenumber, mobile, mail, title, manager, employeetype

# Modify to restrict to safe attributes only
ipa selfservice-mod "Overly broad permission" \
  --attrs=telephonenumber,mobile,mail

# Remove risky attributes (title, manager, employeetype)
# Verify restriction
ipa selfservice-show "Overly broad permission"
  Attributes: telephonenumber, mobile, mail

Read-Only Self-Service Not Working

Symptom: Created self-service permission with --permissions=read but users still cannot view attributes.

Diagnosis: Read-only self-service rarely needed; users can typically already read their own attributes via default ACIs.

Resolution: Verify default read access and check if custom permission needed:

# Test if user can already read their own attributes
kinit alice
ipa user-show alice | grep "Telephone"
  Telephone Number: +1-555-0123
  # Users can already read own attributes by default

# Read-only self-service only needed for attributes
# normally hidden from users (rare case)

# For hidden attributes, verify read-only permission
ipa selfservice-show "Read-only permission" --all
  Attributes: customhiddenattribute
  Permissions: read

# User can now view but not modify
ipa user-show alice | grep "customhiddenattribute"
  # Attribute visible

ipa user-mod alice --setattr=customhiddenattribute=newvalue
  # Permission denied - read-only

Commands

selfservice-add

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

Add a new self-service permission.

Arguments

Argument	Required	Description
NAME	yes	Self-service name

Options

Option	Description
--permissions PERMISSIONS	Permissions to grant (read, write). Default is write.
--attrs ATTRS	Attributes to which the permission applies.
--all	Retrieve and print all attributes from the server. Affects command output.
--raw	Print entries as stored on the server. Only affects output format.

selfservice-del

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

Delete a self-service permission.

Arguments

Argument	Required	Description
NAME	yes	Self-service name

selfservice-find

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

Search for a self-service permission.

Arguments

Argument Required Description

---

CRITERIA no A string searched in all relevant object attributes

Options

Option	Description
--name NAME	Self-service name
--permissions PERMISSIONS	Permissions to grant (read, write). Default is write.
--attrs ATTRS	Attributes to which the permission applies.
--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.

selfservice-mod

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

Modify a self-service permission.

Arguments

Argument	Required	Description
NAME	yes	Self-service name

Options

Option	Description
--permissions PERMISSIONS	Permissions to grant (read, write). Default is write.
--attrs ATTRS	Attributes to which the permission applies.
--all	Retrieve and print all attributes from the server. Affects command output.
--raw	Print entries as stored on the server. Only affects output format.

selfservice-show

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

Display information about a self-service permission.

Arguments

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