advanced

Service Delegation

Manage constrained delegation rules for Kerberos services (S4U2Proxy). FreeIPA supports both general constrained delegation (administrator-controlled rules and targets) and resource-based constrained delegation (RBCD, service-controlled access lists). Features include delegation rule creation, membership management for delegating and delegated services, cross-realm delegation support, and support for constrained delegation scenarios enabling secure service-to-service authentication on behalf of end users.

14 commands
advanced

Overview

FreeIPA provides two mechanisms for constrained delegation of Kerberos credentials using S4U2Proxy extensions:

General Constrained Delegation

Available since: FreeIPA 3.0.0

General constrained delegation uses administrator-controlled rules and targets stored in cn=s4u2proxy,cn=etc,$SUFFIX. This mechanism gives administrators centralized control over which services can delegate credentials and to which target services.

Control model: Administrators define delegation rules centrally Configuration: Uses servicedelegationrule-* and servicedelegationtarget-* commands LDAP structure: Separate rule and target entries with ipaKrb5DelegationACL objectclass

A general delegation rule consists of:

  • A list of Kerberos principals (services) that can impersonate users
  • A list of targets defining which services they can delegate to

Resource-Based Constrained Delegation (RBCD)

Available since: FreeIPA with MIT Kerberos 1.19+

Resource-based constrained delegation stores access control directly in the target service’s LDAP entry using the memberPrincipal attribute with resourceDelegation objectclass. This allows service administrators to control who can delegate to their services without requiring FreeIPA administrator intervention.

Control model: Service/host administrators control delegation to their own resources Configuration: Uses service-add-delegation, host-add-delegation and related commands (see service/host command families) LDAP structure: memberPrincipal attribute in target service entry Cross-realm support: Enables delegation across forest/realm boundaries

The key difference: In RBCD, the target service defines who can delegate to it, rather than the delegating service defining where it can delegate.

S4U2Proxy and Services for User

Both delegation mechanisms rely on Kerberos S4U extensions:

S4U2Self: Allows a service to obtain a ticket to itself on behalf of a user (protocol transition). Requires ok-to-auth-as-delegate permission for forwardable tickets.

S4U2Proxy: Allows a service to obtain a ticket to another service on behalf of a user (constrained delegation). The original ticket must be forwardable.

These extensions prevent users from having to forward their TGT, making delegation more secure by limiting credential exposure.

Delegation Type Comparison

FeatureGeneral Constrained DelegationResource-Based Constrained Delegation
ManagementCentralized by FreeIPA administratorsDecentralized to service/host owners
Control locationDelegating service (proxy)Target service (resource)
LDAP storagecn=s4u2proxy,cn=etc,$SUFFIXTarget service’s own LDAP entry
Commandsservicedelegationrule-*, servicedelegationtarget-*service-add-delegation, host-add-delegation
Cross-realmSame realm onlySupports cross-realm/cross-forest
Use caseInternal IPA services, centralized controlServices in trusted domains, delegated management
AvailabilityFreeIPA 3.0.0+MIT Kerberos 1.19+ required
Required forIPA framework (HTTP→LDAP/CIFS)Cross-forest NFS, multi-realm architectures

When to Use General Constrained Delegation

  • All services are within the same FreeIPA realm
  • Centralized administrative control is desired
  • Managing core FreeIPA framework delegation (HTTP to LDAP/CIFS)
  • Limited number of delegation relationships to manage

When to Use Resource-Based Constrained Delegation

  • Services span multiple Kerberos realms or Active Directory forests
  • Service administrators need to control access to their own resources
  • Delegating to services in trusted Active Directory domains
  • Cross-forest NFS scenarios with trusted AD users
  • Reducing administrative overhead by delegating management to service owners

General Constrained Delegation

The naming convention is to append the word “target” or “targets” to a matching rule name. This is not mandatory but helps conceptually to associate rules and targets.

A rule consists of two things:

  • A list of targets the rule applies to
  • A list of memberPrincipals that are allowed to delegate for
those targets

A target consists of a list of principals that can be delegated.

In English, a rule says that this principal can delegate as this list of principals, as defined by these targets.

In both a rule and a target Kerberos principals may be specified by their name or an alias and the realm can be omitted. Additionally, hosts can be specified by their names. If Kerberos principal specified has a single component and does not end with ’$’ sign, it will be treated as a host name. Kerberos principal names ending with ’$’ are typically used as aliases for Active Directory-related services.

EXAMPLES

Add a new constrained delegation rule:

ipa servicedelegationrule-add ftp-delegation

Add a new constrained delegation target:

ipa servicedelegationtarget-add ftp-delegation-target

Add a principal to the rule:

ipa servicedelegationrule-add-member --principals=ftp/ipa.example.com       ftp-delegation

Add a host principal of the host ‘ipa.example.com’ to the rule:

ipa servicedelegationrule-add-member --principals=ipa.example.com       ftp-delegation

Add our target to the rule:

ipa servicedelegationrule-add-target       --servicedelegationtargets=ftp-delegation-target ftp-delegation

Add a principal to the target:

ipa servicedelegationtarget-add-member --principals=ldap/ipa.example.com       ftp-delegation-target

Display information about a named delegation rule and target:

ipa servicedelegationrule_show ftp-delegation
ipa servicedelegationtarget_show ftp-delegation-target

Remove a constrained delegation:

ipa servicedelegationrule-del ftp-delegation-target
ipa servicedelegationtarget-del ftp-delegation

In this example the ftp service can get a TGT for the ldap service on the bound user’s behalf.

It is strongly discouraged to modify the delegations that ship with IPA, ipa-http-delegation and its targets ipa-cifs-delegation-targets and ipa-ldap-delegation-targets. Incorrect changes can remove the ability to delegate, causing the framework to stop functioning.

Use Cases

1. Web Application Delegating to LDAP Backend

Enable web application to access LDAP directory on behalf of authenticated users.

# Create service principal for web application
ipa service-add HTTP/webapp.example.com

# Create delegation target for LDAP access
ipa servicedelegationtarget-add webapp-ldap-targets

# Add LDAP service to target (backend LDAP servers)
ipa servicedelegationtarget-add-member webapp-ldap-targets \
  --principals=ldap/ipa01.example.com

ipa servicedelegationtarget-add-member webapp-ldap-targets \
  --principals=ldap/ipa02.example.com

# Create delegation rule
ipa servicedelegationrule-add webapp-ldap-delegation

# Add web application as delegating principal
ipa servicedelegationrule-add-member webapp-ldap-delegation \
  --principals=HTTP/webapp.example.com

# Link target to rule
ipa servicedelegationrule-add-target webapp-ldap-delegation \
  --servicedelegationtargets=webapp-ldap-targets

# Verify configuration
ipa servicedelegationrule-show webapp-ldap-delegation
ipa servicedelegationtarget-show webapp-ldap-targets

# Now webapp can obtain LDAP service tickets on user's behalf via S4U2Proxy

2. Multi-Tier Application Architecture Delegation

Configure delegation chain for application with presentation, business logic, and database tiers.

# Tier 1: Web frontend (HTTP/frontend.example.com)
# Tier 2: Application server (app/appserver.example.com)
# Tier 3: Database (postgres/db.example.com)

# Create all service principals
ipa service-add HTTP/frontend.example.com
ipa service-add app/appserver.example.com
ipa service-add postgres/db.example.com

# Frontend -> App Server delegation
ipa servicedelegationtarget-add frontend-to-app-target
ipa servicedelegationtarget-add-member frontend-to-app-target \
  --principals=app/appserver.example.com

ipa servicedelegationrule-add frontend-to-app-rule
ipa servicedelegationrule-add-member frontend-to-app-rule \
  --principals=HTTP/frontend.example.com
ipa servicedelegationrule-add-target frontend-to-app-rule \
  --servicedelegationtargets=frontend-to-app-target

# App Server -> Database delegation
ipa servicedelegationtarget-add app-to-db-target
ipa servicedelegationtarget-add-member app-to-db-target \
  --principals=postgres/db.example.com

ipa servicedelegationrule-add app-to-db-rule
ipa servicedelegationrule-add-member app-to-db-rule \
  --principals=app/appserver.example.com
ipa servicedelegationrule-add-target app-to-db-rule \
  --servicedelegationtargets=app-to-db-target

# Users authenticate to frontend; credentials delegated through chain

3. Reviewing Built-in IPA Delegation Configuration

Examine pre-configured IPA framework delegations (ipa-http-delegation).

# List all delegation rules
ipa servicedelegationrule-find --sizelimit=0

# Show built-in HTTP delegation rule
ipa servicedelegationrule-show ipa-http-delegation

# Show LDAP delegation targets
ipa servicedelegationtarget-show ipa-ldap-delegation-targets

# Show CIFS delegation targets (for AD integration)
ipa servicedelegationtarget-show ipa-cifs-delegation-targets

# These built-in delegations allow IPA web UI to access LDAP and CIFS
# on behalf of authenticated users
# DO NOT MODIFY unless directed by Red Hat support

4. File Server Delegation to Kerberos KDC

Allow file server to obtain service tickets for user home directory access.

# Create NFS service principal
ipa service-add nfs/fileserver.example.com

# Create delegation target for NFS accessing user credentials
ipa servicedelegationtarget-add nfs-kerb-targets
ipa servicedelegationtarget-add-member nfs-kerb-targets \
  --principals=krbtgt/EXAMPLE.COM

# Create delegation rule
ipa servicedelegationrule-add nfs-kerb-delegation
ipa servicedelegationrule-add-member nfs-kerb-delegation \
  --principals=nfs/fileserver.example.com
ipa servicedelegationrule-add-target nfs-kerb-delegation \
  --servicedelegationtargets=nfs-kerb-targets

# NFS server can now obtain tickets on behalf of users for accessing kerberized resources

5. Using Host Principal in Delegation Rule

Add host principal (shorthand notation) to delegation rule for convenience.

# Create delegation target
ipa servicedelegationtarget-add proxy-targets
ipa servicedelegationtarget-add-member proxy-targets \
  --principals=HTTP/backend.example.com

# Create delegation rule using host principal shorthand
ipa servicedelegationrule-add proxy-delegation

# Add host principal (expands to host/proxy.example.com)
ipa servicedelegationrule-add-member proxy-delegation \
  --principals=proxy.example.com

# Verify - should show host/proxy.example.com
ipa servicedelegationrule-show proxy-delegation

# Add target to rule
ipa servicedelegationrule-add-target proxy-delegation \
  --servicedelegationtargets=proxy-targets

# The host service can now delegate to HTTP backend service

6. Auditing Service Delegation Configuration

Review all delegation rules and targets for security audit.

# Generate complete delegation report
echo "=== Service Delegation Audit Report ===" > delegation-audit.txt
echo "Generated: $(date)" >> delegation-audit.txt
echo "" >> delegation-audit.txt

# List all delegation rules
echo "=== Delegation Rules ===" >> delegation-audit.txt
ipa servicedelegationrule-find --sizelimit=0 >> delegation-audit.txt

# For each rule, show details
for rule in $(ipa servicedelegationrule-find --pkey-only | grep "Delegation name:" | awk '{print $3}'); do
  echo "" >> delegation-audit.txt
  echo "=== Rule: $rule ===" >> delegation-audit.txt
  ipa servicedelegationrule-show "$rule" >> delegation-audit.txt
done

# List all delegation targets
echo "" >> delegation-audit.txt
echo "=== Delegation Targets ===" >> delegation-audit.txt
ipa servicedelegationtarget-find --sizelimit=0 >> delegation-audit.txt

# For each target, show details
for target in $(ipa servicedelegationtarget-find --pkey-only | grep "Delegation name:" | awk '{print $3}'); do
  echo "" >> delegation-audit.txt
  echo "=== Target: $target ===" >> delegation-audit.txt
  ipa servicedelegationtarget-show "$target" >> delegation-audit.txt
done

cat delegation-audit.txt

7. Testing Service Delegation with kvno

Verify delegation is configured correctly by obtaining delegated ticket.

# On the delegating service host (e.g., webapp.example.com)
# Obtain service keytab
kinit -k host/webapp.example.com

# Obtain user's TGT (simulate user authentication)
# In real scenario, web app receives user's ticket from client

# Request S4U2Proxy ticket (requires MIT Kerberos 1.8+)
# Use kvno to test if delegation works
kvno -U testuser@EXAMPLE.COM ldap/ipa01.example.com

# If successful, delegation is working
# If fails, check delegation rule configuration
klist
# Should show ticket for ldap/ipa01.example.com for testuser

8. Removing Obsolete Delegation Configuration

Clean up delegation rules for decommissioned services.

# Identify delegation rule to remove
ipa servicedelegationrule-show old-app-delegation

# Note which targets are associated
ipa servicedelegationrule-show old-app-delegation | grep "Delegations"

# Remove the delegation rule
ipa servicedelegationrule-del old-app-delegation

# Optionally remove associated targets if no longer needed
# First verify target not used by other rules
ipa servicedelegationrule-find | grep old-app-targets

# If not referenced, safe to delete
ipa servicedelegationtarget-del old-app-targets

# Remove service principals if services decommissioned
ipa service-del app/oldapp.example.com

9. Database Proxy Server Delegation

Allow database proxy to access backend database on behalf of users.

# Create service principals
ipa service-add pgpool/proxy.example.com
ipa service-add postgres/db01.example.com
ipa service-add postgres/db02.example.com

# Create delegation target for backend databases
ipa servicedelegationtarget-add pgpool-db-targets
ipa servicedelegationtarget-add-member pgpool-db-targets \
  --principals=postgres/db01.example.com
ipa servicedelegationtarget-add-member pgpool-db-targets \
  --principals=postgres/db02.example.com

# Create delegation rule
ipa servicedelegationrule-add pgpool-db-delegation
ipa servicedelegationrule-add-member pgpool-db-delegation \
  --principals=pgpool/proxy.example.com
ipa servicedelegationrule-add-target pgpool-db-delegation \
  --servicedelegationtargets=pgpool-db-targets

# pgpool can now obtain PostgreSQL tickets on user's behalf
# Enables per-user database auditing through proxy

10. Adding Multiple Principals to Delegation Rule

Add multiple delegating services to same rule for shared backend access.

# Multiple web servers need to access same LDAP backend
ipa servicedelegationtarget-add shared-ldap-targets
ipa servicedelegationtarget-add-member shared-ldap-targets \
  --principals=ldap/ipa01.example.com,ldap/ipa02.example.com

ipa servicedelegationrule-add webfarm-ldap-delegation

# Add multiple web servers as delegating principals
ipa servicedelegationrule-add-member webfarm-ldap-delegation \
  --principals=HTTP/web01.example.com,HTTP/web02.example.com,HTTP/web03.example.com

ipa servicedelegationrule-add-target webfarm-ldap-delegation \
  --servicedelegationtargets=shared-ldap-targets

# All three web servers can now delegate to LDAP backends
# Verify all members present
ipa servicedelegationrule-show webfarm-ldap-delegation

Resource-Based Constrained Delegation (RBCD) Use Cases

Note: RBCD commands are part of the service and host command families. See ipa service-add-delegation --help and ipa host-add-delegation --help for command reference.

1. Web Service Delegating to File Server (Basic RBCD)

Allow web frontend to access SMB file server on behalf of users using resource-based delegation.

# Scenario: HTTP/web-service.example.test needs to access cifs/file.example.test

# As administrator: Grant file server control over its own delegation
# (This step is implicit - services can manage their own delegation by default)

# As file server host (using host keytab):
kinit -k  # Authenticate as host/file.example.test

# Add delegation permission to CIFS service
ipa service-add-delegation cifs/file.example.test \
  HTTP/web-service.example.test

# Verify delegation configuration
ipa service-show cifs/file.example.test --all | grep memberPrincipal
# Should show: memberPrincipal: HTTP/web-service.example.test@EXAMPLE.TEST

# Now HTTP/web-service.example.test can obtain tickets to cifs/file.example.test
# on behalf of authenticated users

2. Delegated RBCD Management to Application Team

Allow application administrators to control delegation without FreeIPA admin privileges.

# As FreeIPA administrator: Grant storage-admins group permission to manage
# delegation for file service
ipa service-allow-add-delegation cifs/file.example.test \
  --groups=storage-admins

# Verify delegation managers
ipa service-show cifs/file.example.test --all | grep ipaAllowedToPerform

# As member of storage-admins group:
kinit some-user  # Member of storage-admins

# Add delegation permission for web service
ipa service-add-delegation cifs/file.example.test \
  HTTP/webapp.example.test

# Add another delegating service
ipa service-add-delegation cifs/file.example.test \
  HTTP/api.example.test

# Remove delegation permission
ipa service-remove-delegation cifs/file.example.test \
  HTTP/webapp.example.test

# Revoke delegation management permission (admin only):
kinit admin
ipa service-disallow-add-delegation cifs/file.example.test \
  --groups=storage-admins

# Now storage-admins members can no longer modify delegation

3. Cross-Realm NFS with AD Trust (RBCD Required)

Configure NFS server to accept delegated credentials from IPA clients for AD users.

# Scenario: NFS server in AD domain, IPA client mounting shares for AD users
# This requires RBCD because services are in different realms

# On IPA side: Configure client host to delegate
kinit admin

# Enable protocol transition on IPA client host
ipa host-mod client.ipa.example.com --ok-to-auth-as-delegate=TRUE

# On AD side or NFS server: Configure RBCD to allow IPA client
# (This example assumes NFS server is AD-joined)

# Using AD PowerShell or equivalent:
# Set-ADComputer nfsserver -PrincipalsAllowedToDelegateToAccount client$

# Or if managing from IPA with appropriate permissions:
ipa service-add-delegation nfs/nfsserver.ad.example.com \
  host/client.ipa.example.com

# Configure GSSProxy on IPA client for NFS:
cat > /etc/gssproxy/99-nfs-client.conf << 'EOF'
[service/nfs-client]
  mechs = krb5
  cred_store = keytab:/etc/krb5.keytab
  cred_store = client_keytab:/etc/krb5.keytab
  cred_store = ccache:/var/lib/gssproxy/clients/krb5cc_%U
  euid = 0
  trusted = yes
  impersonate = yes
EOF

systemctl restart gssproxy

# Mount NFS with krb5p security:
mount -t nfs -o sec=krb5p nfsserver.ad.example.com:/share /mnt/nfs

# AD users can now access their files with delegated credentials

4. Testing RBCD Delegation with kvno

Verify RBCD configuration by testing S4U2Proxy operation.

# Prerequisites:
# - RBCD ACL created: ipa service-add-delegation cifs/file.test HTTP/web.test
# - Web service keytab: /path/to/web.keytab
# - Target service keytab exists (for KDC to issue tickets)

# Test delegation for user 'testuser'
kvno -U testuser \
  -k /path/to/web.keytab \
  -P HTTP/web.example.test \
  cifs/file.example.test

# Successful output shows ticket obtained:
# testuser@EXAMPLE.TEST -> cifs/file.example.test@EXAMPLE.TEST

# If RBCD ACL is missing, you'll see:
# kvno: KDC policy rejects request while getting credentials for testuser

# Check ticket cache to verify:
klist
# Should show ticket: testuser@EXAMPLE.TEST -> cifs/file.example.test@EXAMPLE.TEST

5. Host-Based RBCD for Multi-Service Delegation

Configure host to allow delegation from another host’s services.

# Scenario: appserver.example.test needs to delegate to multiple services
# on dbserver.example.test (postgres, mysql, ldap)

# As dbserver host:
kinit -k  # Authenticate as host/dbserver.example.test

# Add delegation for all services on dbserver
ipa host-add-delegation dbserver.example.test \
  host/appserver.example.test

# This allows host/appserver.example.test to delegate to:
# - postgres/dbserver.example.test
# - mysql/dbserver.example.test
# - ldap/dbserver.example.test
# - Any other service on dbserver.example.test

# Verify:
ipa host-show dbserver.example.test --all | grep memberPrincipal

# Remove delegation:
ipa host-remove-delegation dbserver.example.test \
  host/appserver.example.test

6. RBCD with Multiple Delegating Principals

Allow multiple frontend services to delegate to same backend.

# Scenario: Load-balanced web farm needs to access database

# As database host:
kinit -k

# Add multiple web servers to delegation ACL
ipa service-add-delegation postgres/db.example.test \
  HTTP/web01.example.test

ipa service-add-delegation postgres/db.example.test \
  HTTP/web02.example.test

ipa service-add-delegation postgres/db.example.test \
  HTTP/web03.example.test

# All web servers can now delegate to postgres
# Verify all members:
ipa service-show postgres/db.example.test --all | grep memberPrincipal

# Shows:
# memberPrincipal: HTTP/web01.example.test@EXAMPLE.TEST
# memberPrincipal: HTTP/web02.example.test@EXAMPLE.TEST
# memberPrincipal: HTTP/web03.example.test@EXAMPLE.TEST

Security Considerations

1. Constrained vs Unconstrained Delegation

S4U2Proxy (constrained delegation) is safer than unconstrained delegation but still grants significant privilege.

  • Constrained delegation limits which backend services can be accessed with delegated credentials
  • Compromised delegating service can impersonate any user to allowed backend services
  • Unlike unconstrained delegation, user’s TGT not forwarded; delegation target restricted
  • Always prefer constrained delegation over unconstrained (Kerberos forwardable tickets)
  • Minimize number of services granted delegation rights

2. Delegation as Privilege Escalation Path

Service delegation creates trust relationship; compromise of delegating service impacts all users.

  • Attacker gaining control of delegating service (e.g., web app) can impersonate any authenticated user
  • Compromised web server with LDAP delegation can read/modify directory as any user
  • Limit delegation to services with strong security posture and monitoring
  • Apply defense-in-depth: SELinux, application firewalls, intrusion detection
  • Regularly audit which services have delegation privileges

3. Built-in IPA Delegation Modification Risks

Modifying ipa-http-delegation and associated targets can break IPA web UI and management.

  • ipa-http-delegation allows IPA web UI to access LDAP on behalf of authenticated administrators
  • Incorrect modification can prevent web UI from functioning
  • Breaking this delegation may require command-line recovery or restoration from backup
  • Document changes before modifying; test in non-production environment first
  • Only modify under guidance from Red Hat support or with full understanding of consequences

4. Delegation Target Overreach

Overly broad delegation targets grant more access than necessary.

  • Target containing many backend services allows compromised delegator to access all of them
  • Principle of least privilege: delegate only to specific required services
  • Separate delegation targets by function (e.g., ldap-readonly vs ldap-readwrite)
  • Regularly review targets; remove services no longer requiring delegated access
  • Avoid wildcard or “all services” targets

5. Service Principal Keytab Protection

Delegating service’s keytab must be carefully protected; compromise enables impersonation.

  • Service keytab file allows authentication as that service
  • Attacker with keytab can obtain delegated tickets for any user
  • Store keytabs with restricted permissions (root:root 0600)
  • Deploy keytabs using secure methods (Ansible Vault, configuration management encryption)
  • Rotate service keytab regularly; monitor keytab access

Users typically unaware their credentials are being delegated by services.

  • No user prompt or consent when service performs S4U2Proxy delegation
  • Users cannot opt-out of delegation if authenticated to delegating service
  • Organizational policy should disclose which services perform delegation
  • Consider user education about service delegation in security awareness training
  • High-security environments may require explicit user consent mechanisms

7. Audit Trail Limitations

Delegated ticket usage may not be clearly attributable to original user in all logs.

  • Backend service sees user principal but request actually from delegating service
  • Difficult to distinguish direct user access from delegated access in backend logs
  • Correlation requires comparing timestamps and delegating service logs with backend logs
  • Implement comprehensive logging on both delegating and backend services
  • Centralize logs to SIEM for correlation and analysis

8. Cross-Realm Delegation Complexity

Delegation across Kerberos realm boundaries (cross-realm trusts) introduces additional complexity.

  • S4U2Proxy delegation can work across realms but requires careful configuration
  • Trust relationships must permit delegation (AD Trust configuration critical)
  • Delegation failures difficult to diagnose in cross-realm scenarios
  • Test cross-realm delegation thoroughly before production deployment
  • Document cross-realm delegation paths for troubleshooting

9. Service Account Compromise Detection

Compromised service accounts performing delegation may be difficult to detect.

  • Normal service behavior involves frequent delegation; anomaly detection challenging
  • Attacker using compromised service keytab may blend with legitimate traffic
  • Monitor for unusual delegation patterns: off-hours activity, unusual backend services accessed
  • Deploy User and Entity Behavior Analytics (UEBA) for service account monitoring
  • Alert on delegation rule modifications; these should be rare events

10. Delegation Rule Lifecycle Management

Delegation rules may outlive services they were created for; orphaned rules create confusion.

  • Decommissioned services may leave delegation rules in place
  • Orphaned rules complicate security audits and create confusion
  • Implement delegation rule review process as part of service decommissioning
  • Document delegation rule purpose and owning team in external documentation
  • Periodic audit to identify and remove rules for non-existent services

11. Backend Service Delegation Trust

Backend services must trust delegating service correctly validates user authentication.

  • Backend service receives delegated ticket; trusts delegating service performed proper authentication
  • Weak authentication at delegating service undermines backend security
  • Backend service cannot distinguish properly-authenticated user from impersonation
  • Delegating services must implement strong authentication (multi-factor where possible)
  • Backend services should implement their own authorization checks, not rely solely on Kerberos identity

12. S4U2Self vs S4U2Proxy Confusion

S4U2Self and S4U2Proxy serve different purposes; misunderstanding can lead to misconfiguration.

  • S4U2Self (Service-for-User-to-Self): service obtains ticket for user to itself
  • S4U2Proxy (Service-for-User-to-Proxy): service obtains ticket for user to another service
  • IPA service delegation configures S4U2Proxy; S4U2Self typically requires protocol transition
  • Protocol transition (S4U2Self without user’s initial Kerberos authentication) has security implications
  • Understand which delegation type you need before configuration

13. Resource-Based Delegation Decentralized Control

RBCD delegates access control to service owners; requires trust in service administrators.

  • Service/host owners can grant delegation to their resources without FreeIPA admin approval
  • Compromised service owner credentials allow unauthorized delegation ACL changes
  • Malicious service owner could grant excessive delegation permissions
  • Use service-allow-add-delegation to extend management rights cautiously
  • Regularly audit RBCD configurations: ipa service-show --all | grep memberPrincipal
  • Consider whether centralized (general delegation) or decentralized (RBCD) control is appropriate

14. Cross-Realm RBCD Trust Requirements

RBCD enables cross-realm delegation; verify trust relationships before configuration.

  • Cross-realm delegation requires trust between realms (IPA-AD trust, etc.)
  • Principals from untrusted realms should not appear in delegation ACLs
  • IPA validates realm trust when adding cross-realm principals to RBCD ACLs
  • Ensure target service’s realm trusts delegating service’s realm
  • Review trust configurations: ipa trust-find
  • Cross-forest delegation has additional constraints per MS-SFU specification

15. RBCD and Service Account Compromise

Resource-based delegation stores ACL in target service entry; protect service credentials.

  • Attacker with service credentials can modify delegation ACL for that service
  • Compromised service owner (managedBy) can grant unauthorized delegation access
  • Use strong keytab protection: restricted file permissions, encrypted storage
  • Monitor service entry modifications: ipa-log-audit for memberPrincipal changes
  • Limit service management permissions (managedBy) to necessary accounts only
  • Rotate service keytabs if compromise suspected

Troubleshooting

1. Delegation Not Working - Service Cannot Obtain Delegated Ticket

Symptom: Delegating service receives error when attempting S4U2Proxy to backend service.

Diagnosis:

# Verify delegation rule exists and is properly configured
ipa servicedelegationrule-show rule-name

# Check delegating principal is member of rule
ipa servicedelegationrule-show rule-name | grep "Member principals"

# Check target includes backend service
ipa servicedelegationtarget-show target-name | grep "Member principals"

# Verify rule has target linked
ipa servicedelegationrule-show rule-name | grep "Delegations"

# On delegating service host, check Kerberos logs
tail -f /var/log/krb5kdc.log

Resolution:

  • Ensure delegating service principal is member of delegation rule
  • Verify backend service principal is member of delegation target
  • Confirm target is linked to rule with servicedelegationrule-add-target
  • Check service keytabs exist and are readable by service account
  • Restart service after delegation rule changes to clear cache

2. Cannot Add Principal to Delegation Rule or Target

Symptom: servicedelegationrule-add-member or servicedelegationtarget-add-member fails with “service not found”.

Diagnosis:

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

# Check exact principal name spelling
ipa service-find webapp

# Verify principal syntax (service/host.domain or just host for host principals)

Resolution:

  • Create service principal first: ipa service-add HTTP/webapp.example.com
  • Use exact principal name as shown in ipa service-show
  • For host principals, can use shorthand: hostname expands to host/hostname.domain
  • Principal name is case-sensitive; verify capitalization
  • Ensure host is enrolled in IPA before creating service on that host

3. Delegation Works for Some Users but Not Others

Symptom: S4U2Proxy succeeds for some authenticated users but fails for others.

Diagnosis:

# Check if failing users have forwardable tickets
# S4U2Proxy requires user's initial TGT to be forwardable
klist
# Look for 'F' flag (forwardable) on user's TGT

# On delegating service, examine delegation request
# Check service logs for error details

# Verify user account not disabled or expired
ipa user-show failing-user

Resolution:

  • User’s initial TGT must have forwardable flag set
  • Check /etc/krb5.conf on client: forwardable = true in [libdefaults]
  • Verify user account is active and not expired
  • Some authentication methods may not grant forwardable tickets (e.g., PKINIT without proper flags)
  • Test with kinit: kinit -f username to explicitly request forwardable ticket

4. Delegation Rule Appears Correct But Still Fails

Symptom: Configuration looks correct but S4U2Proxy still returns error.

Diagnosis:

# Check KDC logs for detailed error
# On IPA server
tail -f /var/log/krb5kdc.log

# Attempt delegation and observe KDC response
# Common errors: "Server not found in Kerberos database"
# "Not allowed to delegate"

# Verify service has ok-to-auth-as-delegate flag
# This flag required for S4U2Proxy
ldapsearch -x -D "cn=Directory Manager" -W \
  -b "cn=services,cn=accounts,dc=example,dc=com" \
  "(krbprincipalname=HTTP/webapp.example.com*)" \
  krbTicketFlags

# Should include: 2147483648 (OK_TO_AUTH_AS_DELEGATE)

Resolution:

  • IPA automatically sets ok-to-auth-as-delegate flag when service added to delegation rule
  • Flag may not propagate immediately; wait 1-2 minutes for replication
  • Manually set flag if needed (advanced): use ldapmodify to add krbTicketFlags attribute
  • Restart KDC if flag present but still not working: systemctl restart krb5kdc
  • Check for typos in service principal names; exact match required

5. Cannot Delete Delegation Rule - Target Still Referenced

Symptom: servicedelegationrule-del fails indicating target still in use.

Diagnosis:

# Show rule to see associated targets
ipa servicedelegationrule-show rule-name

# Targets must be removed from rule before rule can be deleted

Resolution:

  • First remove targets from rule:
  ipa servicedelegationrule-remove-target rule-name \
    --servicedelegationtargets=target-name
  • Then delete rule:
  ipa servicedelegationrule-del rule-name
  • Targets can be deleted after removing from all rules:
  ipa servicedelegationtarget-del target-name

6. Delegation Target and Rule Naming Confusion

Symptom: Accidentally used rule name when target name expected, or vice versa.

Diagnosis:

# List all rules
ipa servicedelegationrule-find --pkey-only

# List all targets
ipa servicedelegationtarget-find --pkey-only

# Rules and targets are separate objects with separate namespaces

Resolution:

  • Naming convention: append “-targets” to target name, “-delegation” to rule name
  • Example: rule webapp-ldap-delegation with target webapp-ldap-targets
  • Rules contain member principals (delegating services)
  • Targets contain member principals (backend services being delegated to)
  • Rules link to targets; targets don’t directly reference rules

7. Built-in IPA Delegation Accidentally Modified

Symptom: IPA web UI not working after modifying ipa-http-delegation.

Diagnosis:

# Check current state of ipa-http-delegation
ipa servicedelegationrule-show ipa-http-delegation

# Check targets
ipa servicedelegationtarget-show ipa-ldap-delegation-targets
ipa servicedelegationtarget-show ipa-cifs-delegation-targets

# Compare with documentation or working IPA server

Resolution:

  • Restore ipa-http-delegation to correct configuration:
  # Ensure HTTP services are members
  ipa servicedelegationrule-add-member ipa-http-delegation \
    --principals=HTTP/ipa01.example.com

  # Ensure targets linked
  ipa servicedelegationrule-add-target ipa-http-delegation \
    --servicedelegationtargets=ipa-ldap-delegation-targets
  ipa servicedelegationrule-add-target ipa-http-delegation \
    --servicedelegationtargets=ipa-cifs-delegation-targets
  • If severely broken, restore from IPA backup or contact Red Hat support
  • Test web UI functionality after restoration

8. Cross-Realm Delegation Failure

Symptom: Delegation works within realm but fails across AD trust boundary.

Diagnosis:

# Verify AD trust is established
ipa trust-find

# Check if cross-realm TGT obtainable
kvno krbtgt/AD.EXAMPLE.COM@IPA.EXAMPLE.COM

# Review AD trust configuration for delegation settings

Resolution:

  • Cross-realm delegation requires AD trust configured with delegation support
  • AD side may need configuration: “Trust this user for delegation to specified services”
  • Verify trust relationship healthy: ipa trust-show ad.example.com
  • S4U2Proxy may not be supported in all trust configurations
  • Consult Red Hat documentation for cross-realm delegation requirements

9. Service Keytab Not Working After Delegation Configuration

Symptom: After creating delegation, service authentication fails with keytab.

Diagnosis:

# Test service keytab
kinit -kt /etc/krb5.keytab HTTP/webapp.example.com
klist

# Check keytab file exists and has correct permissions
ls -l /etc/krb5.keytab

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

Resolution:

  • Delegation configuration doesn’t affect keytab; likely separate issue
  • Re-retrieve keytab if corrupted:
  ipa-getkeytab -s ipa01.example.com \
    -p HTTP/webapp.example.com \
    -k /etc/krb5.keytab
  • Check keytab file permissions: should be readable by service account
  • Verify correct service principal name in keytab: klist -kt /etc/krb5.keytab

10. Multiple Delegation Rules - Unclear Which Applies

Symptom: Service is member of multiple delegation rules; unclear which target services accessible.

Diagnosis:

# Find all rules containing service
ipa servicedelegationrule-find | grep -A5 "HTTP/webapp.example.com"

# Show each rule to see targets
ipa servicedelegationrule-show rule1
ipa servicedelegationrule-show rule2

# Service can delegate to union of all targets from all matching rules

Resolution:

  • Service principal can be member of multiple delegation rules
  • Delegation allowed to union of all targets across all rules service is member of
  • This is additive; no conflicts between rules
  • For clarity, prefer single delegation rule per service when possible
  • Document reason if service requires multiple delegation rules

11. Testing Delegation Without Production Traffic

Symptom: Want to verify delegation works before enabling in production application.

Diagnosis:

# Create test service principal
ipa service-add HTTP/test-webapp.example.com

# Add to delegation rule
ipa servicedelegationrule-add-member existing-rule \
  --principals=HTTP/test-webapp.example.com

# Retrieve keytab for testing
ipa-getkeytab -s ipa01.example.com \
  -p HTTP/test-webapp.example.com \
  -k /tmp/test.keytab

Resolution:

  • Test delegation with kvno command:
  kinit -kt /tmp/test.keytab HTTP/test-webapp.example.com
  kvno -U testuser@EXAMPLE.COM ldap/ipa01.example.com
  klist  # Should show delegated ticket
  • If successful, delegation configuration is correct
  • Remove test principal after testing:
  ipa servicedelegationrule-remove-member existing-rule \
    --principals=HTTP/test-webapp.example.com
  ipa service-del HTTP/test-webapp.example.com

12. Delegation Stops Working After IPA Upgrade

Symptom: Delegation worked before IPA upgrade but now fails.

Diagnosis:

# Check delegation configuration still intact
ipa servicedelegationrule-show rule-name
ipa servicedelegationtarget-show target-name

# Review IPA upgrade logs
journalctl -u ipa -b | grep -i delegation

# Check KDC logs for new error messages
tail -100 /var/log/krb5kdc.log

Resolution:

  • IPA upgrades should preserve delegation configuration but verify
  • Re-apply delegation rule if necessary:
  ipa servicedelegationrule-mod rule-name  # Touch rule to reapply
  • Restart KDC and Apache after upgrade to ensure changes loaded:
  systemctl restart krb5kdc
  systemctl restart httpd
  • Review IPA release notes for delegation-related changes

13. Cannot Add Host Principal to Delegation - Syntax Error

Symptom: Error when adding host principal to delegation rule; principal format rejected.

Diagnosis:

# Host principals can use shorthand notation
# "hostname" expands to "host/hostname.domain"

# Verify host exists
ipa host-show webapp.example.com

# Try explicit vs shorthand syntax
ipa servicedelegationrule-add-member rule-name \
  --principals=webapp.example.com

# Or explicit:
ipa servicedelegationrule-add-member rule-name \
  --principals=host/webapp.example.com

Resolution:

  • Both hostname and host/hostname formats valid for hosts
  • Ensure host is enrolled in IPA first
  • If name ends with ’$’, treated as literal principal (AD compatibility)
  • For non-host service principals, always use service/hostname format
  • Use ipa service-find or ipa host-find to verify exact names

14. Delegation Rule Replication Delay

Symptom: Created delegation rule on one IPA server but not visible on another.

Diagnosis:

# Check replication status
ipa-replica-manage list

# Verify rule exists on creating server
ipa servicedelegationrule-show rule-name

# Wait 30-60 seconds and check other server
ssh ipa02.example.com
ipa servicedelegationrule-show rule-name

# Check replication agreements healthy
ipa topologysuffix-verify domain

Resolution:

  • Delegation rules stored in LDAP; subject to normal replication
  • Replication typically completes within seconds but can be delayed
  • If replication broken, fix replication first: ipa-replica-manage list
  • Force replication if urgent:
  ipa-replica-manage force-sync --from=ipa01.example.com
  • After replication, restart KDC on affected server

15. Understanding ok-as-delegate vs ok-to-auth-as-delegate Flags

Symptom: Confusion about Kerberos ticket flags and delegation configuration.

Diagnosis:

# Check service ticket flags
ldapsearch -x -D "cn=Directory Manager" -W \
  -b "cn=services,cn=accounts,dc=example,dc=com" \
  "(krbprincipalname=HTTP/webapp.example.com*)" \
  krbTicketFlags

# ok-as-delegate (forwardable): user's client sets this
# ok-to-auth-as-delegate: KDC sets this for S4U2Proxy services

Resolution:

  • ok-to-auth-as-delegate flag required for S4U2Proxy; IPA sets automatically when service added to delegation rule
  • ok-as-delegate different flag; relates to unconstrained delegation (forwardable tickets)
  • For constrained delegation (S4U2Proxy), only ok-to-auth-as-delegate matters
  • User’s TGT must be forwardable for delegation to work (separate from service flags)
  • Check user ticket: klist should show ‘F’ flag on TGT

RBCD-Specific Troubleshooting

The following troubleshooting scenarios are specific to Resource-Based Constrained Delegation (RBCD). For general constrained delegation issues, see the scenarios above.

16. RBCD Delegation Not Working - memberPrincipal Not Set

Symptom: Used service-add-delegation but S4U2Proxy still fails to target service.

Diagnosis:

# Verify memberPrincipal attribute exists on target service
ipa service-show cifs/file.example.test --all | grep memberPrincipal

# Check for resourceDelegation objectclass
ldapsearch -x -D "cn=Directory Manager" -W \
  -b "cn=services,cn=accounts,dc=example,dc=test" \
  "(krbprincipalname=cifs/file.example.test*)" \
  objectClass memberPrincipal

# Should show:
# objectClass: resourceDelegation
# memberPrincipal: HTTP/web-service.example.test@EXAMPLE.TEST

Resolution:

  • RBCD stores ACL in target service’s LDAP entry (not in cn=s4u2proxy)
  • Add delegation using target service’s credentials:
  # Authenticate as host managing the target service
  kinit -k host/file.example.test

  # Add delegation permission
  ipa service-add-delegation cifs/file.example.test \
    HTTP/web-service.example.test
  • Verify resourceDelegation objectclass added to target service
  • Wait 30-60 seconds for LDAP replication if multi-server deployment
  • Restart KDC if changes not taking effect: systemctl restart krb5kdc

17. RBCD Command Permission Denied

Symptom: service-add-delegation fails with “Insufficient access: Insufficient ‘write’ privilege”.

Diagnosis:

# Check who you're authenticated as
klist

# RBCD requires authentication as host managing the service
# or as user with "Modify Services" permission

# Check service's managedBy attribute
ipa service-show cifs/file.example.test | grep "Managed by"

Resolution:

  • RBCD uses service-level access control
  • Authenticate as host principal for the host where service runs:
  kinit -k host/file.example.test
  ipa service-add-delegation cifs/file.example.test principal
  • Or grant user “Modify Services” permission via RBAC
  • Alternative: Add user/host to service’s managedBy:
  # As admin
  ipa service-mod cifs/file.example.test \
    --addattr=managedby=fqdn=host.example.test,cn=computers,cn=accounts,dc=example,dc=test
  • Target service administrator controls delegation (not central administrator)

18. RBCD Cross-Realm Delegation Fails

Symptom: RBCD works within realm but fails when delegating principal is from trusted AD domain.

Diagnosis:

# Verify cross-realm principal format in memberPrincipal
ipa service-show cifs/file.example.test --all | grep memberPrincipal

# Should include realm: HTTP/webapp.ad.example.com@AD.EXAMPLE.COM

# Check KDC logs for cross-realm errors
tail -f /var/log/krb5kdc.log
# Look for: "not found in Kerberos database" for cross-realm principal

# Verify AD trust is healthy
ipa trust-show ad.example.com

Resolution:

  • Cross-realm RBCD requires fully-qualified principal with realm:
  ipa service-add-delegation cifs/file.example.test \
    'HTTP/webapp.ad.example.com@AD.EXAMPLE.COM'
  • Note single quotes to prevent shell expansion of @ symbol
  • Verify trust relationship allows delegation:
  ipa trust-show ad.example.com --all
  • MIT Kerberos 1.19+ required for cross-realm RBCD
  • Check KDC version: krb5kdc -V (must be >= 1.19)
  • AD principal may need “Trusted for delegation” set in AD

19. MIT Kerberos Version Too Old for RBCD

Symptom: RBCD commands succeed but delegation still fails; KDC logs show S4U2Proxy errors.

Diagnosis:

# Check MIT Kerberos version
krb5kdc -V

# RBCD requires >= 1.19
# Example output: Kerberos 5 release 1.19.1

# Check for RBCD support
ldapsearch -x -b "cn=config" "(cn=KDC)" kdcSupportedEnctypes

Resolution:

  • RBCD requires MIT Kerberos 1.19 or later
  • For RHEL/CentOS:
    • RHEL 9+ includes Kerberos 1.19+
    • RHEL 8 requires update to krb5-libs >= 1.19
  • Update Kerberos packages:
  # Check current version
  rpm -q krb5-libs krb5-server

  # Update if needed (RHEL 9+)
  dnf update krb5-libs krb5-server

  # Restart KDC
  systemctl restart krb5kdc
  • If Kerberos < 1.19, use general constrained delegation instead
  • Verify all IPA servers in topology have compatible Kerberos version

20. Confusion Between RBCD and General Delegation Commands

Symptom: Used servicedelegationrule-add-member for RBCD or vice versa; configuration not working.

Diagnosis:

# RBCD uses different commands than general delegation

# RBCD commands (target service controls delegation):
ipa service-add-delegation <target> <delegating-principal>
ipa host-add-delegation <target> <delegating-principal>

# General delegation commands (admin controls delegation):
ipa servicedelegationrule-add-member <rule> --principals=<delegating>
ipa servicedelegationtarget-add-member <target> --principals=<backend>

# Check if RBCD configured (look for memberPrincipal):
ipa service-show service-name --all | grep memberPrincipal

# Check if general delegation configured (look in cn=s4u2proxy):
ipa servicedelegationrule-find

Resolution:

  • RBCD and general constrained delegation use different command families
  • RBCD configuration stored in target service LDAP entry (memberPrincipal attribute)
  • General delegation stored in cn=s4u2proxy,cn=etc,$SUFFIX
  • Choose one approach per service - mixing both for same service can cause confusion
  • RBCD preferred when:
    • Service administrator should control delegation (not central admin)
    • Cross-realm/cross-forest delegation needed
    • MIT Kerberos 1.19+ available
  • General delegation preferred when:
    • Central IT controls all delegation policies
    • Kerberos < 1.19
    • Same-realm delegation only

21. RBCD ACL Replication Issues in Topology

Symptom: RBCD delegation works when KDC request goes to specific IPA server but fails on others.

Diagnosis:

# Check memberPrincipal on all IPA servers
for server in ipa01 ipa02 ipa03; do
  echo "=== $server ==="
  ssh $server "ipa service-show cifs/file.example.test --all | grep memberPrincipal"
done

# Check LDAP replication status
ipa topologysuffix-verify domain

# Check replication agreements
ipa-replica-manage list

Resolution:

  • RBCD ACL stored in LDAP service entry; subject to replication
  • Wait 30-60 seconds for replication to complete
  • Force replication if urgent:
  ipa-replica-manage force-sync --from=ipa01.example.com
  • After replication, restart KDC on affected servers:
  systemctl restart krb5kdc
  • Verify replication health:
  ipa-replica-manage list
  # Should show all replication agreements healthy
  • If replication consistently fails, investigate replication issues first

22. Cannot Remove RBCD Delegation - Principal Still Listed

Symptom: Used service-remove-delegation but principal still appears in memberPrincipal.

Diagnosis:

# Check current delegation list
ipa service-show cifs/file.example.test --all | grep memberPrincipal

# Verify exact principal name format
# Must match exactly including realm suffix

Resolution:

  • Specify exact principal name including realm:
  ipa service-remove-delegation cifs/file.example.test \
    'HTTP/webapp.example.test@EXAMPLE.TEST'
  • Use quotes around principal with @ to prevent shell expansion
  • For cross-realm principals, include full realm:
  ipa service-remove-delegation cifs/file.example.test \
    'HTTP/service.ad.example.com@AD.EXAMPLE.COM'
  • Verify removal:
  ipa service-show cifs/file.example.test --all | grep memberPrincipal
  • If persistent, use ldapmodify to manually remove:
  ldapmodify -x -D "cn=Directory Manager" -W <<EOF
  dn: krbprincipalname=cifs/file.example.test@EXAMPLE.TEST,cn=services,cn=accounts,dc=example,dc=test
  changetype: modify
  delete: memberPrincipal
  memberPrincipal: HTTP/webapp.example.test@EXAMPLE.TEST
  EOF

Commands

servicedelegationrule-add

Usage: ipa [global-options] servicedelegationrule-add DELEGATION-NAME [options]

Create a new service delegation rule.

Arguments

ArgumentRequiredDescription
DELEGATION-NAMEyesDelegation name

Options

OptionDescription
--setattr SETATTRSet an attribute to a name/value pair. Format is attr=value.
--addattr ADDATTRAdd an attribute/value pair. Format is attr=value. The attribute
--allRetrieve and print all attributes from the server. Affects command output.
--rawPrint entries as stored on the server. Only affects output format.
--no-membersSuppress processing of membership attributes.

servicedelegationrule-add-member

Usage: ipa [global-options] servicedelegationrule-add-member DELEGATION-NAME [options]

Add member to a named service delegation rule.

Arguments

ArgumentRequiredDescription
DELEGATION-NAMEyesDelegation name

Options

OptionDescription
--allRetrieve and print all attributes from the server. Affects command output.
--rawPrint entries as stored on the server. Only affects output format.
--no-membersSuppress processing of membership attributes.
--principals PRINCIPALSprincipal to add

servicedelegationrule-add-target

Usage: ipa [global-options] servicedelegationrule-add-target DELEGATION-NAME [options]

Add target to a named service delegation rule.

Arguments

ArgumentRequiredDescription
DELEGATION-NAMEyesDelegation name

Options

OptionDescription
--allRetrieve and print all attributes from the server. Affects command output.
--rawPrint entries as stored on the server. Only affects output format.
--no-membersSuppress processing of membership attributes.
--servicedelegationtargets SERVICEDELEGATIONTARGETSservice delegation targets to add

servicedelegationrule-del

Usage: ipa [global-options] servicedelegationrule-del DELEGATION-NAME [options]

Delete service delegation.

Arguments

ArgumentRequiredDescription
DELEGATION-NAMEyesDelegation name

Options

OptionDescription
--continueContinuous mode: Don’t stop on errors.

servicedelegationrule-find

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

Search for service delegations rule.

Arguments

Argument Required Description


CRITERIA no A string searched in all relevant object attributes

Options

OptionDescription
--delegation-name DELEGATION-NAMEDelegation name
--timelimit TIMELIMITTime limit of search in seconds (0 is unlimited)
--sizelimit SIZELIMITMaximum number of entries returned (0 is unlimited)
--allRetrieve and print all attributes from the server. Affects command output.
--rawPrint entries as stored on the server. Only affects output format.
--pkey-onlyResults should contain primary key attribute only (“delegation-name”)

servicedelegationrule-remove-member

Usage: ipa [global-options] servicedelegationrule-remove-member DELEGATION-NAME [options]

Remove member from a named service delegation rule.

Arguments

ArgumentRequiredDescription
DELEGATION-NAMEyesDelegation name

Options

OptionDescription
--allRetrieve and print all attributes from the server. Affects command output.
--rawPrint entries as stored on the server. Only affects output format.
--no-membersSuppress processing of membership attributes.
--principals PRINCIPALSprincipal to remove

servicedelegationrule-remove-target

Usage: ipa [global-options] servicedelegationrule-remove-target DELEGATION-NAME [options]

Remove target from a named service delegation rule.

Arguments

ArgumentRequiredDescription
DELEGATION-NAMEyesDelegation name

Options

OptionDescription
--allRetrieve and print all attributes from the server. Affects command output.
--rawPrint entries as stored on the server. Only affects output format.
--no-membersSuppress processing of membership attributes.
--servicedelegationtargets SERVICEDELEGATIONTARGETSservice delegation targets to remove

servicedelegationrule-show

Usage: ipa [global-options] servicedelegationrule-show DELEGATION-NAME [options]

Display information about a named service delegation rule.

Arguments

ArgumentRequiredDescription
DELEGATION-NAMEyesDelegation name

Options

OptionDescription
--rightsDisplay the access rights of this entry (requires —all). See ipa man page for details.
--allRetrieve and print all attributes from the server. Affects command output.
--rawPrint entries as stored on the server. Only affects output format.
--no-membersSuppress processing of membership attributes.

servicedelegationtarget-add

Usage: ipa [global-options] servicedelegationtarget-add DELEGATION-NAME [options]

Create a new service delegation target.

Arguments

ArgumentRequiredDescription
DELEGATION-NAMEyesDelegation name

Options

OptionDescription
--setattr SETATTRSet an attribute to a name/value pair. Format is attr=value.
--addattr ADDATTRAdd an attribute/value pair. Format is attr=value. The attribute
--allRetrieve and print all attributes from the server. Affects command output.
--rawPrint entries as stored on the server. Only affects output format.

servicedelegationtarget-add-member

Usage: ipa [global-options] servicedelegationtarget-add-member DELEGATION-NAME [options]

Add member to a named service delegation target.

Arguments

ArgumentRequiredDescription
DELEGATION-NAMEyesDelegation name

Options

OptionDescription
--allRetrieve and print all attributes from the server. Affects command output.
--rawPrint entries as stored on the server. Only affects output format.
--principals PRINCIPALSprincipal to add

servicedelegationtarget-del

Usage: ipa [global-options] servicedelegationtarget-del DELEGATION-NAME [options]

Delete service delegation target.

Arguments

ArgumentRequiredDescription
DELEGATION-NAMEyesDelegation name

Options

OptionDescription
--continueContinuous mode: Don’t stop on errors.

servicedelegationtarget-find

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

Search for service delegation target.

Arguments

Argument Required Description


CRITERIA no A string searched in all relevant object attributes

Options

OptionDescription
--delegation-name DELEGATION-NAMEDelegation name
--timelimit TIMELIMITTime limit of search in seconds (0 is unlimited)
--sizelimit SIZELIMITMaximum number of entries returned (0 is unlimited)
--allRetrieve and print all attributes from the server. Affects command output.
--rawPrint entries as stored on the server. Only affects output format.
--pkey-onlyResults should contain primary key attribute only (“delegation-name”)

servicedelegationtarget-remove-member

Usage: ipa [global-options] servicedelegationtarget-remove-member DELEGATION-NAME [options]

Remove member from a named service delegation target.

Arguments

ArgumentRequiredDescription
DELEGATION-NAMEyesDelegation name

Options

OptionDescription
--allRetrieve and print all attributes from the server. Affects command output.
--rawPrint entries as stored on the server. Only affects output format.
--principals PRINCIPALSprincipal to remove

servicedelegationtarget-show

Usage: ipa [global-options] servicedelegationtarget-show DELEGATION-NAME [options]

Display information about a named service delegation target.

Arguments

ArgumentRequiredDescription
DELEGATION-NAMEyesDelegation name

Options

OptionDescription
--rightsDisplay the access rights of this entry (requires —all). See ipa man page for details.
--allRetrieve and print all attributes from the server. Affects command output.
--rawPrint entries as stored on the server. Only affects output format.

Related Topics