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.
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
| Feature | General Constrained Delegation | Resource-Based Constrained Delegation |
|---|---|---|
| Management | Centralized by FreeIPA administrators | Decentralized to service/host owners |
| Control location | Delegating service (proxy) | Target service (resource) |
| LDAP storage | cn=s4u2proxy,cn=etc,$SUFFIX | Target service’s own LDAP entry |
| Commands | servicedelegationrule-*, servicedelegationtarget-* | service-add-delegation, host-add-delegation |
| Cross-realm | Same realm only | Supports cross-realm/cross-forest |
| Use case | Internal IPA services, centralized control | Services in trusted domains, delegated management |
| Availability | FreeIPA 3.0.0+ | MIT Kerberos 1.19+ required |
| Required for | IPA 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-delegationAdd a new constrained delegation target:
ipa servicedelegationtarget-add ftp-delegation-targetAdd a principal to the rule:
ipa servicedelegationrule-add-member --principals=ftp/ipa.example.com ftp-delegationAdd a host principal of the host ‘ipa.example.com’ to the rule:
ipa servicedelegationrule-add-member --principals=ipa.example.com ftp-delegationAdd our target to the rule:
ipa servicedelegationrule-add-target --servicedelegationtargets=ftp-delegation-target ftp-delegationAdd a principal to the target:
ipa servicedelegationtarget-add-member --principals=ldap/ipa.example.com ftp-delegation-targetDisplay information about a named delegation rule and target:
ipa servicedelegationrule_show ftp-delegation ipa servicedelegationtarget_show ftp-delegation-targetRemove 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
6. User Visibility and Consent
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-delegationto 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-auditformemberPrincipalchanges - 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:
hostnameexpands tohost/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.confon client:forwardable = truein [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 usernameto 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
ldapmodifyto 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-delegationwith targetwebapp-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
hostnameandhost/hostnameformats 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/hostnameformat - Use
ipa service-findoripa host-findto 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:
klistshould 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
resourceDelegationobjectclass 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
| Argument | Required | Description |
|---|---|---|
DELEGATION-NAME | yes | Delegation name |
Options
| Option | Description |
|---|---|
--setattr SETATTR | Set an attribute to a name/value pair. Format is attr=value. |
--addattr ADDATTR | Add an attribute/value pair. Format is attr=value. The attribute |
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--no-members | Suppress processing of membership attributes. |
servicedelegationrule-add-member
Usage:
ipa [global-options] servicedelegationrule-add-member DELEGATION-NAME [options]
Add member to a named service delegation rule.
Arguments
| Argument | Required | Description |
|---|---|---|
DELEGATION-NAME | yes | Delegation name |
Options
| Option | Description |
|---|---|
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--no-members | Suppress processing of membership attributes. |
--principals PRINCIPALS | principal to add |
servicedelegationrule-add-target
Usage:
ipa [global-options] servicedelegationrule-add-target DELEGATION-NAME [options]
Add target to a named service delegation rule.
Arguments
| Argument | Required | Description |
|---|---|---|
DELEGATION-NAME | yes | Delegation name |
Options
| Option | Description |
|---|---|
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--no-members | Suppress processing of membership attributes. |
--servicedelegationtargets SERVICEDELEGATIONTARGETS | service delegation targets to add |
servicedelegationrule-del
Usage:
ipa [global-options] servicedelegationrule-del DELEGATION-NAME [options]
Delete service delegation.
Arguments
| Argument | Required | Description |
|---|---|---|
DELEGATION-NAME | yes | Delegation name |
Options
| Option | Description |
|---|---|
--continue | Continuous 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
| Option | Description |
|---|---|
--delegation-name DELEGATION-NAME | Delegation name |
--timelimit TIMELIMIT | Time limit of search in seconds (0 is unlimited) |
--sizelimit SIZELIMIT | Maximum number of entries returned (0 is unlimited) |
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--pkey-only | Results should contain primary key attribute only (“delegation-name”) |
servicedelegationrule-remove-member
Usage:
ipa [global-options] servicedelegationrule-remove-member DELEGATION-NAME [options]
Remove member from a named service delegation rule.
Arguments
| Argument | Required | Description |
|---|---|---|
DELEGATION-NAME | yes | Delegation name |
Options
| Option | Description |
|---|---|
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--no-members | Suppress processing of membership attributes. |
--principals PRINCIPALS | principal to remove |
servicedelegationrule-remove-target
Usage:
ipa [global-options] servicedelegationrule-remove-target DELEGATION-NAME [options]
Remove target from a named service delegation rule.
Arguments
| Argument | Required | Description |
|---|---|---|
DELEGATION-NAME | yes | Delegation name |
Options
| Option | Description |
|---|---|
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--no-members | Suppress processing of membership attributes. |
--servicedelegationtargets SERVICEDELEGATIONTARGETS | service delegation targets to remove |
servicedelegationrule-show
Usage:
ipa [global-options] servicedelegationrule-show DELEGATION-NAME [options]
Display information about a named service delegation rule.
Arguments
| Argument | Required | Description |
|---|---|---|
DELEGATION-NAME | yes | Delegation name |
Options
| Option | Description |
|---|---|
--rights | Display the access rights of this entry (requires —all). See ipa man page for details. |
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--no-members | Suppress processing of membership attributes. |
servicedelegationtarget-add
Usage:
ipa [global-options] servicedelegationtarget-add DELEGATION-NAME [options]
Create a new service delegation target.
Arguments
| Argument | Required | Description |
|---|---|---|
DELEGATION-NAME | yes | Delegation name |
Options
| Option | Description |
|---|---|
--setattr SETATTR | Set an attribute to a name/value pair. Format is attr=value. |
--addattr ADDATTR | Add an attribute/value pair. Format is attr=value. The attribute |
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
servicedelegationtarget-add-member
Usage:
ipa [global-options] servicedelegationtarget-add-member DELEGATION-NAME [options]
Add member to a named service delegation target.
Arguments
| Argument | Required | Description |
|---|---|---|
DELEGATION-NAME | yes | Delegation name |
Options
| Option | Description |
|---|---|
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--principals PRINCIPALS | principal to add |
servicedelegationtarget-del
Usage:
ipa [global-options] servicedelegationtarget-del DELEGATION-NAME [options]
Delete service delegation target.
Arguments
| Argument | Required | Description |
|---|---|---|
DELEGATION-NAME | yes | Delegation name |
Options
| Option | Description |
|---|---|
--continue | Continuous 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
| Option | Description |
|---|---|
--delegation-name DELEGATION-NAME | Delegation name |
--timelimit TIMELIMIT | Time limit of search in seconds (0 is unlimited) |
--sizelimit SIZELIMIT | Maximum number of entries returned (0 is unlimited) |
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--pkey-only | Results should contain primary key attribute only (“delegation-name”) |
servicedelegationtarget-remove-member
Usage:
ipa [global-options] servicedelegationtarget-remove-member DELEGATION-NAME [options]
Remove member from a named service delegation target.
Arguments
| Argument | Required | Description |
|---|---|---|
DELEGATION-NAME | yes | Delegation name |
Options
| Option | Description |
|---|---|
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |
--principals PRINCIPALS | principal to remove |
servicedelegationtarget-show
Usage:
ipa [global-options] servicedelegationtarget-show DELEGATION-NAME [options]
Display information about a named service delegation target.
Arguments
| Argument | Required | Description |
|---|---|---|
DELEGATION-NAME | yes | Delegation name |
Options
| Option | Description |
|---|---|
--rights | Display the access rights of this entry (requires —all). See ipa man page for details. |
--all | Retrieve and print all attributes from the server. Affects command output. |
--raw | Print entries as stored on the server. Only affects output format. |