Sudo Rule Management

Overview

Sudo rules in FreeIPA provide centralized, auditable management of privilege escalation across IPA-enrolled systems. Rather than maintaining local /etc/sudoers files on each system, administrators define sudo rules in IPA which are distributed to clients through SSSD. This centralization enables consistent privilege policies, simplified administration, and comprehensive audit trails of privileged command execution.

Each sudo rule defines a relationship between who (users/groups), where (hosts/hostgroups), what (commands/command groups), and as whom (RunAs users/groups). When a user attempts to execute a command via sudo, the client evaluates applicable rules to determine whether the operation is permitted. Multiple rules can apply to a single operation, with allow and deny commands providing fine-grained control over privileged access.

Sudo rules integrate with IPA’s group and host group infrastructure, enabling privilege delegation that automatically adapts as organizational structure changes. When users join groups or hosts join host groups, their sudo privileges automatically adjust according to rules targeting those groups. This dynamic membership eliminates manual sudoers file updates and ensures privilege assignments remain current.

Rule Components

Users and User Groups

The “who” dimension defines which users are affected by the rule. Individual users can be specified directly, or groups can be referenced to apply rules to collections of users. User category “all” creates rules applying to every IPA user, though such broad rules should be used cautiously as they grant universal privilege potential.

External users from trusted Active Directory domains can be included in sudo rules using external user identifiers. This enables AD users to have sudo privileges on IPA-managed systems without requiring local IPA user accounts.

When multiple rules apply to a user, all allow commands from all applicable rules are available. Deny commands take precedence over allow commands, enabling exception-based policy where broad access is granted then specific commands are prohibited.

Hosts and Host Groups

The “where” dimension specifies which hosts the rule applies to. Individual hosts can be targeted for host-specific privilege grants, or host groups enable privilege delegation across fleets of similar systems. Host category “all” creates rules applying on every enrolled IPA client.

Host targeting enables role-based privilege models: database administrators might have sudo access to database servers but not web servers, while web administrators have the inverse. This compartmentalization limits blast radius if credentials are compromised.

Combined with host groups, sudo rules support infrastructure-as-code patterns where provisioning systems automatically place new hosts into appropriate host groups, inheriting correct sudo policies without manual configuration.

Allowed and Denied Commands

Sudo rules specify which commands users can execute. Commands are represented as sudo command objects (created with sudocmd-add) defining command paths and optional argument restrictions. Sudo command groups collect related commands for easier rule management.

Allow commands grant permission to execute specific commands. Users can execute any command allowed by any applicable rule. Deny commands explicitly prohibit specific commands, taking precedence over allow directives. This enables pattern like “allow all commands except password changes.”

Command category “all” permits execution of any command (equivalent to ALL in sudoers). While convenient, “all” rules should be limited to highly trusted administrators as they grant unrestricted root access.

Arguments to sudo commands can include argument restrictions in the command definition itself. For example, /usr/bin/systemctl restart httpd permits only that specific invocation, while /usr/bin/systemctl without arguments permits any systemctl operation.

RunAs Users and Groups

The “as whom” dimension specifies which user identity sudo assumes when executing commands. By default, sudo executes as root, but RunAs specifications enable running commands as arbitrary users. This supports workflows requiring specific user contexts without granting full root access.

RunAs users specify individual users or user groups. For example, a rule might allow web administrators to run commands as the apache user to manage web server processes. RunAs groups specify the group context for command execution, controlling file ownership and permissions for created files.

External RunAs users and groups enable running commands as AD users or groups, supporting cross-domain privilege delegation in trust relationships.

Category “all” for RunAs users permits execution as any user on the system, essentially granting unrestricted sudo access. This powerful capability should be restricted to highly privileged administrators.

Sudo Options

Sudo options modify sudo behavior, replicating sudoers configuration options in IPA-managed rules. Common options include:

!authenticate: Disables password prompting (equivalent to NOPASSWD). Use cautiously as it weakens accountability by allowing passwordless privilege escalation.

mail_badpass: Sends email when incorrect passwords are entered, aiding security monitoring.

env_keep: Preserves environment variables during sudo execution. Each variable requires a separate option (e.g., env_keep=PATH, env_keep+=HOME).

type and role: Sets SELinux type and role transitions for the command, enabling SELinux policy integration with sudo privilege delegation.

Sudo options require exact sudo syntax and are not validated by IPA. Incorrect option syntax may cause sudo failures on clients. Test sudo options thoroughly before deploying to production systems.

The special rule named “defaults” contains global sudo options applying to all sudo operations on IPA clients, replicating the “Defaults” directive in traditional sudoers files.

Rule Ordering

Sudo rules can include an order attribute controlling evaluation sequence. While SSSD processes all applicable rules regardless of order, some sudo configurations respect rule ordering for conflict resolution or priority determination.

Orders are specified as unique integers. Lower numbers evaluate first. Order values need not be contiguous (orders 10, 20, 30 work as well as 1, 2, 3) and gaps between order values provide flexibility for inserting rules later without renumbering.

When order is not specified or not supported by the client, all applicable rules are evaluated and their allow/deny commands are merged. Deny commands always take precedence over allow commands regardless of rule order.

External User Support

Sudo rules support external users from trusted Active Directory forests. External users are identified by SID or domain\username format. When AD users authenticate to IPA-enrolled systems, their sudo privileges are evaluated including rules targeting external users.

External RunAs users enable sudo operations running as AD users, supporting scenarios where AD service accounts manage infrastructure on IPA-enrolled systems without requiring duplicate IPA accounts.

External user sudo rules require proper trust configuration between IPA and Active Directory. The trust must be established and functional before external users can authenticate or be referenced in sudo rules.

Sudo Bind DN

IPA provides a dedicated LDAP bind DN for sudo queries: uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com. Some legacy sudo configurations query LDAP directly rather than using SSSD. For these configurations, setting a password on the sudo bind DN enables authentication.

Modern IPA deployments use SSSD for sudo integration, eliminating direct LDAP queries and the need for sudo bind DN passwords. SSSD caches sudo rules locally, improving performance and enabling offline sudo operation when IPA servers are unreachable.

The sudo bind DN is provided for backward compatibility. New deployments should configure SSSD sudo integration rather than direct LDAP queries.

Use Cases

Database Administrator Restricted Sudo

Scenario: DBAs need to restart database services and edit configurations, but not full root access.

Solution:

# Create sudo commands for database operations
ipa sudocmd-add '/usr/bin/systemctl restart postgresql'
ipa sudocmd-add '/usr/bin/systemctl restart mysql'
ipa sudocmd-add '/usr/bin/systemctl status postgresql'
ipa sudocmd-add '/usr/bin/systemctl status mysql'
ipa sudocmd-add '/usr/bin/vi /etc/postgresql/*'
ipa sudocmd-add '/usr/bin/vi /etc/mysql/*'

# Create command group
ipa sudocmdgroup-add db_mgmt
ipa sudocmdgroup-add-member db_mgmt \
    --sudocmds='/usr/bin/systemctl restart postgresql' \
    --sudocmds='/usr/bin/systemctl restart mysql' \
    --sudocmds='/usr/bin/systemctl status postgresql' \
    --sudocmds='/usr/bin/systemctl status mysql' \
    --sudocmds='/usr/bin/vi /etc/postgresql/*' \
    --sudocmds='/usr/bin/vi /etc/mysql/*'

# Create sudo rule
ipa sudorule-add dba_sudo --desc="DBAs manage database services"
ipa sudorule-add-user dba_sudo --groups=dba
ipa sudorule-add-host dba_sudo --hostgroups=database_servers
ipa sudorule-add-allow-command dba_sudo --sudocmdgroups=db_mgmt

# DBAs can restart services and edit configs, but cannot run other root commands

Web Administrator Service Management with NOPASSWD

Scenario: Web admins need passwordless restart of web services for emergency response.

Solution:

# Create commands
ipa sudocmd-add '/usr/bin/systemctl restart httpd'
ipa sudocmd-add '/usr/bin/systemctl restart nginx'
ipa sudocmd-add '/usr/bin/systemctl reload httpd'
ipa sudocmd-add '/usr/bin/systemctl reload nginx'

# Create rule with NOPASSWD
ipa sudorule-add webadmin_nopasswd --desc="Web service restart without password"
ipa sudorule-add-user webadmin_nopasswd --groups=web_admins
ipa sudorule-add-host webadmin_nopasswd --hostgroups=web_servers
ipa sudorule-add-allow-command webadmin_nopasswd \
    --sudocmds='/usr/bin/systemctl restart httpd' \
    --sudocmds='/usr/bin/systemctl restart nginx' \
    --sudocmds='/usr/bin/systemctl reload httpd' \
    --sudocmds='/usr/bin/systemctl reload nginx'
ipa sudorule-add-option webadmin_nopasswd --sudooption='!authenticate'

# Web admins can restart services without password for rapid incident response

RunAs User for Application Management

Scenario: Developers need to run commands as application user without root.

Solution:

# Create sudo rule running as app user
ipa sudorule-add app_deploy --desc="Deploy as app user"
ipa sudorule-add-user app_deploy --groups=developers
ipa sudorule-add-host app_deploy --hostgroups=app_servers
ipa sudorule-mod app_deploy --cmdcat=all  # All commands
ipa sudorule-add-runasuser app_deploy --users=appuser

# Developers can run any command as appuser
# Example: sudo -u appuser /opt/app/deploy.sh

Sudo with Deny Commands for Security

Scenario: Ops team has broad sudo access except password/user modification commands.

Solution:

# Create commands to deny
ipa sudocmd-add '/usr/bin/passwd'
ipa sudocmd-add '/usr/sbin/useradd'
ipa sudocmd-add '/usr/sbin/userdel'
ipa sudocmd-add '/usr/sbin/usermod'
ipa sudocmd-add '/usr/bin/ipa'

# Create deny group
ipa sudocmdgroup-add user_mgmt_deny
ipa sudocmdgroup-add-member user_mgmt_deny \
    --sudocmds='/usr/bin/passwd' \
    --sudocmds='/usr/sbin/useradd' \
    --sudocmds='/usr/sbin/userdel' \
    --sudocmds='/usr/sbin/usermod' \
    --sudocmds='/usr/bin/ipa'

# Create sudo rule allowing all except user management
ipa sudorule-add ops_sudo --desc="Ops full access except user mgmt"
ipa sudorule-add-user ops_sudo --groups=operations
ipa sudorule-add-host ops_sudo --hostgroups=linux_servers
ipa sudorule-mod ops_sudo --cmdcat=all
ipa sudorule-add-deny-command ops_sudo --sudocmdgroups=user_mgmt_deny

# Ops can run all commands via sudo except user management
# Deny takes precedence over allow

Active Directory User Sudo Access

Scenario: AD domain admins need sudo on Linux servers via trust.

Solution:

# Create external group for AD admins
ipa group-add ad_admins_external --external
ipa group-add-member ad_admins_external --external 'AD\Domain Admins'

# Create POSIX group
ipa group-add ad_linux_admins --desc="AD admins on Linux"
ipa group-add-member ad_linux_admins --groups=ad_admins_external

# Create sudo rule
ipa sudorule-add ad_admin_sudo --desc="AD admins full sudo"
ipa sudorule-add-user ad_admin_sudo --groups=ad_linux_admins
ipa sudorule-mod ad_admin_sudo --hostcat=all --cmdcat=all

# AD Domain Admins have full sudo on all Linux servers

Per-Environment Sudo Policies

Scenario: Different privilege levels for dev, staging, production environments.

Solution:

# Development: developers have full sudo
ipa sudorule-add dev_sudo --desc="Full sudo in dev"
ipa sudorule-add-user dev_sudo --groups=developers
ipa sudorule-add-host dev_sudo --hostgroups=dev_servers
ipa sudorule-mod dev_sudo --cmdcat=all

# Staging: only ops have full sudo, developers have service restart
ipa sudorule-add staging_ops_sudo
ipa sudorule-add-user staging_ops_sudo --groups=operations
ipa sudorule-add-host staging_ops_sudo --hostgroups=staging_servers
ipa sudorule-mod staging_ops_sudo --cmdcat=all

ipa sudorule-add staging_dev_sudo
ipa sudorule-add-user staging_dev_sudo --groups=developers
ipa sudorule-add-host staging_dev_sudo --hostgroups=staging_servers
ipa sudorule-add-allow-command staging_dev_sudo \
    --sudocmds='/usr/bin/systemctl restart *'

# Production: only senior ops have sudo, requires password
ipa sudorule-add prod_sudo --desc="Production sudo (senior ops only)"
ipa sudorule-add-user prod_sudo --groups=senior_operations
ipa sudorule-add-host prod_sudo --hostgroups=prod_servers
ipa sudorule-mod prod_sudo --cmdcat=all
# No NOPASSWD option - requires password for accountability

Break-Glass Emergency Sudo Access

Scenario: Disabled emergency sudo rule for security incidents.

Solution:

# Create disabled emergency rule
ipa sudorule-add emergency_sudo --desc="EMERGENCY: Incident response full access"
ipa sudorule-add-user emergency_sudo --groups=incident_response
ipa sudorule-mod emergency_sudo --hostcat=all --cmdcat=all
ipa sudorule-add-option emergency_sudo --sudooption='!authenticate'
ipa sudorule-disable emergency_sudo

# During incident, enable temporarily
ipa sudorule-enable emergency_sudo

# After incident resolved, disable and audit
ipa sudorule-disable emergency_sudo
# Review sudo logs for emergency access usage

Automation Account Passwordless Sudo

Scenario: Ansible service account needs passwordless sudo for configuration management.

Solution:

# Create automation user
ipa user-add ansible --first=Ansible --last=Service

# Create sudo rule for automation
ipa sudorule-add ansible_sudo --desc="Ansible automation passwordless sudo"
ipa sudorule-add-user ansible_sudo --users=ansible
ipa sudorule-mod ansible_sudo --hostcat=all --cmdcat=all
ipa sudorule-add-option ansible_sudo --sudooption='!authenticate'

# ansible user can run any command via sudo without password
# Use with SSH key authentication for automation

Examples

Basic Rule Management

Create a new sudo rule:

ipa sudorule-add restart_services --desc="Allow service restarts"

Create a rule with all categories (unrestricted - use cautiously):

ipa sudorule-add admin_all --usercat=all --hostcat=all --cmdcat=all

Delete a sudo rule:

ipa sudorule-del restart_services

Display rule details:

ipa sudorule-show restart_services --all

Search for rules by name pattern:

ipa sudorule-find restart

Find all enabled rules:

ipa sudorule-find --enabled=TRUE

Find rules affecting a specific user:

ipa sudorule-find --users=jsmith

User Assignment

Add individual users to a rule:

ipa sudorule-add-user restart_services --users=jsmith

Add multiple users:

ipa sudorule-add-user restart_services --users=jsmith --users=alee

Add user groups to a rule:

ipa sudorule-add-user restart_services --groups=sysadmins

Add both users and groups:

ipa sudorule-add-user restart_services --users=jsmith --groups=operators

Remove users from a rule:

ipa sudorule-remove-user restart_services --users=jsmith

Host Assignment

Add individual hosts to a rule:

ipa sudorule-add-host restart_services --hosts=web01.example.com

Add host groups:

ipa sudorule-add-host restart_services --hostgroups=webservers

Add multiple hosts and hostgroups:

ipa sudorule-add-host restart_services --hosts=web01.example.com --hostgroups=databases

Remove hosts from a rule:

ipa sudorule-remove-host restart_services --hosts=web01.example.com

Command Management

Create sudo commands first:

ipa sudocmd-add /usr/bin/systemctl
ipa sudocmd-add '/usr/bin/systemctl restart httpd'
ipa sudocmd-add /usr/sbin/reboot

Add allowed commands to a rule:

ipa sudorule-add-allow-command restart_services --sudocmds='/usr/bin/systemctl restart httpd'

Create and use sudo command groups:

ipa sudocmdgroup-add service_management
ipa sudocmdgroup-add-member service_management --sudocmds='/usr/bin/systemctl'
ipa sudorule-add-allow-command restart_services --sudocmdgroups=service_management

Add denied commands (take precedence over allowed):

ipa sudorule-add-deny-command restart_services --sudocmds='/usr/sbin/reboot'

Remove allowed commands:

ipa sudorule-remove-allow-command restart_services --sudocmds='/usr/bin/systemctl'

RunAs Configuration

Configure RunAs users (run commands as specific user):

ipa sudorule-add-runasuser web_management --users=apache

Add RunAs user groups:

ipa sudorule-add-runasuser app_management --groups=appusers

Configure RunAs groups (set group context):

ipa sudorule-add-runasgroup log_management --groups=adm

Remove RunAs users:

ipa sudorule-remove-runasuser web_management --users=apache

Sudo Options

Create defaults rule for global sudo options:

ipa sudorule-add defaults --desc="Global sudo defaults"

Add option to disable password prompting:

ipa sudorule-add-option restart_services --sudooption='!authenticate'

Add multiple options:

ipa sudorule-add-option restart_services --sudooption='!authenticate' --sudooption='mail_badpass'

Preserve environment variables:

ipa sudorule-add-option app_management --sudooption='env_keep=PATH'
ipa sudorule-add-option app_management --sudooption='env_keep+=HOME'
ipa sudorule-add-option app_management --sudooption='env_keep+=LANG'

Set SELinux context transitions:

ipa sudorule-add-option selinux_admin --sudooption='type=unconfined_t'
ipa sudorule-add-option selinux_admin --sudooption='role=unconfined_r'

Remove sudo options:

ipa sudorule-remove-option restart_services --sudooption='!authenticate'

Rule Ordering

Set rule order (lower numbers evaluate first):

ipa sudorule-mod emergency_admin --order=10
ipa sudorule-mod regular_admin --order=20

Rule State Management

Disable a rule temporarily:

ipa sudorule-disable restart_services

Re-enable a disabled rule:

ipa sudorule-enable restart_services

External User Support (AD Integration)

Add external AD users to a rule:

ipa sudorule-add user_rule --externaluser='AD\alice'
ipa sudorule-add user_rule --externaluser='bob@ad.example.com'

Configure external RunAs users:

ipa sudorule-add-runasuser cross_domain --runasexternaluser='AD\svcaccount'

Configure external RunAs groups:

ipa sudorule-add-runasgroup cross_domain --runasexternalgroup='AD\Admins'

Complete Rule Examples

Web server management - Allow sysadmins to restart web services:

ipa sudorule-add web_restart --desc="Restart web services"
ipa sudorule-add-user web_restart --groups=sysadmins
ipa sudorule-add-host web_restart --hostgroups=webservers
ipa sudocmd-add '/usr/bin/systemctl restart httpd'
ipa sudocmd-add '/usr/bin/systemctl restart nginx'
ipa sudorule-add-allow-command web_restart --sudocmds='/usr/bin/systemctl restart httpd' --sudocmds='/usr/bin/systemctl restart nginx'

Database administration - Allow DBAs full sudo on database servers:

ipa sudorule-add dba_sudo --desc="DBA full access"
ipa sudorule-add-user dba_sudo --groups=dbas
ipa sudorule-add-host dba_sudo --hostgroups=databases
ipa sudorule-add-allow-command dba_sudo --cmdcat=all
ipa sudorule-add-runasuser dba_sudo --users=postgres --users=mysql

Limited file viewing - Allow helpdesk to read logs:

ipa sudorule-add view_logs --desc="Read system logs"
ipa sudorule-add-user view_logs --groups=helpdesk
ipa sudorule-add-host view_logs --hostcat=all
ipa sudocmd-add /usr/bin/less
ipa sudocmd-add /usr/bin/tail
ipa sudocmd-add /usr/bin/cat
ipa sudocmdgroup-add log_readers
ipa sudocmdgroup-add-member log_readers --sudocmds=/usr/bin/less --sudocmds=/usr/bin/tail --sudocmds=/usr/bin/cat
ipa sudorule-add-allow-command view_logs --sudocmdgroups=log_readers
ipa sudorule-add-option view_logs --sudooption='!authenticate'

Emergency access - Full access for specific user in emergencies:

ipa sudorule-add emergency --desc="Emergency admin access"
ipa sudorule-add-user emergency --users=emergency_admin
ipa sudorule-add-host emergency --hostcat=all
ipa sudorule-add-allow-command emergency --cmdcat=all
ipa sudorule-mod emergency --order=1
ipa sudorule-disable emergency  # Enable only during emergencies

Best Practices

Rule Design

Follow least privilege: Grant minimal necessary commands rather than broad access. Specific command rules are more secure than --cmdcat=all.

Use groups instead of individual users: Target user groups and host groups rather than individual users/hosts. This enables privilege delegation that automatically adapts as group membership changes.

Create role-based rules: Design rules around organizational roles (web admin, database admin, help desk) rather than individual people. This improves maintainability and clarity.

Separate concerns: Create multiple focused rules rather than single complex rules. For example, separate “restart services” from “modify configurations” even if the same users need both.

Document rule purposes: Use --desc to clearly explain each rule’s purpose. Future administrators will thank you.

Command Specification

Be specific with command paths: Use full paths (/usr/bin/systemctl) not relative names. This prevents PATH-based exploits.

Restrict command arguments when possible: Define commands with specific arguments (/usr/bin/systemctl restart httpd) rather than unrestricted commands when the use case permits.

Use command groups for related commands: Group related commands (web_service_management) for easier rule management and consistent policy application.

Test deny commands carefully: Deny commands override allow commands. Ensure denied commands don’t inadvertently block legitimate operations.

Sudo Options

Avoid !authenticate unless necessary: Passwordless sudo weakens accountability. Only use for automated systems or very limited commands.

Test options before production: Sudo option syntax is not validated. Test thoroughly in non-production before deploying.

Use env_keep cautiously: Preserving environment variables can introduce security risks. Only preserve variables that are truly necessary.

Monitor mail_badpass alerts: If using mail_badpass, ensure alerts are monitored. Failed sudo attempts may indicate attack attempts.

RunAs Configuration

Limit RunAs users: Don’t grant --runasusercat=all unless users truly need to run as arbitrary accounts. This is nearly equivalent to full root.

Use RunAs for least privilege: Rather than granting root access, use RunAs to execute commands as specific service accounts (apache, postgres).

Consider group context: RunAs group affects file ownership. Ensure RunAs group settings align with file permission requirements.

Security Considerations

Regular rule audits: Periodically review sudo rules to ensure they still match organizational needs and haven’t become overly permissive.

Monitor sudo usage: Review sudo logs for unusual patterns. Unexpected sudo usage may indicate compromised accounts or policy violations.

Disable unused rules: Don’t delete rules that might be needed later. Use sudorule-disable to temporarily deactivate them.

Protect emergency rules: Emergency full-access rules should normally be disabled, enabled only during actual emergencies, then disabled again.

Test rules before deployment: Create test rules and verify they work as expected before deploying to production systems. Incorrect rules can block legitimate operations or grant unintended access.

Operational Practices

Use rule ordering for precedence: When rules might conflict, use order to establish precedence. Lower numbers evaluate first.

Plan for SSSD cache refresh: Sudo rule changes may take time to reach clients due to SSSD caching. For urgent changes, flush SSSD cache or restart SSSD on affected clients.

Maintain command object library: Create sudo commands and command groups as reusable building blocks. This ensures consistency across rules.

Version control rule changes: Maintain documentation or version control tracking of sudo rule changes. This aids troubleshooting and provides rollback capability.

Coordinate with HBAC: Ensure HBAC rules permit the access that sudo rules grant. If HBAC blocks user access to a host, sudo rules on that host are moot.

External User Integration

Validate trust configuration: Before creating external user sudo rules, verify the Active Directory trust is functional and stable.

Use external groups when possible: Rather than individual external users, use external groups in sudo rules for easier management.

Document external user mappings: Maintain clear records of which AD users/groups have sudo privileges and why.

Test external user sudo carefully: External user sudo depends on trust integrity, AD reachability, and proper name resolution. Test thoroughly.

Security Considerations

cmdcat=all grants unrestricted root access: Rules with --cmdcat=all enable users to execute any command as root. This is functionally equivalent to full root access. Restrict cmdcat=all to highly trusted administrators only.

NOPASSWD weakens accountability: Passwordless sudo (!authenticate option) allows privilege escalation without verification of user presence. Enables automated attacks if account compromised. Use only for automation accounts or time-critical service restart commands.

RunAs all users nearly equals root: --runasusercat=all permits executing commands as any user. Attackers could switch to root or manipulate other user contexts. Restrict to specific RunAs users when possible.

Deny commands require careful testing: Deny commands take precedence over allow. Overly broad deny commands can inadvertently block legitimate operations. Always test deny rules thoroughly before production deployment.

Command argument restrictions can be bypassed: Restricting sudo commands to specific arguments (/usr/bin/systemctl restart httpd) provides limited security. Users can often find alternate syntax or symlinks to bypass restrictions. Don’t rely solely on argument restrictions for security.

Wildcard commands are dangerous: Commands like /usr/bin/systemctl * httpd or /bin/* enable exploitation via wildcard expansion. Attackers could create files matching patterns to execute arbitrary code. Avoid wildcards in sudo commands.

Environment variable preservation risks: env_keep options preserve environment variables during sudo. Malicious users could manipulate LD_PRELOAD, PATH, or other variables to inject code. Only preserve absolutely necessary variables.

Local sudoers file can override IPA rules: Root users can modify /etc/sudoers on clients to bypass IPA sudo rules. Physical or root access undermines centralized sudo policy. Complement with system hardening and file integrity monitoring.

SSSD cache can serve stale rules: Clients cache sudo rules for performance. Urgent privilege revocations may not take effect immediately. For critical revocations, clear SSSD cache manually on affected systems: sssctl cache-expire --everything.

Sudo logs are local, not centralized: Sudo command executions logged locally on clients (/var/log/secure or journald). Detecting abuse requires log aggregation. Implement centralized logging for sudo security monitoring.

Multiple rules combine permissions: Users affected by multiple rules gain union of all allowed commands. Overlapping rules can create unintended privilege combinations. Review all rules affecting each user/group comprehensively.

External user sudo depends on trust health: AD trust compromise could grant unauthorized sudo access to IPA systems. Monitor trust health and revoke external user sudo rules if trust integrity questioned.

Order attribute may not be honored: Some sudo configurations ignore order attribute. Don’t rely on order for security-critical allow/deny precedence. Use deny commands which always take precedence over allow.

Disabled rules remain in directory: Disabled sudo rules aren’t deleted, just inactive. Re-enabling old rules can restore dangerous privilege grants. Review carefully before re-enabling historical rules.

Troubleshooting

User denied sudo despite rule existing:

# Verify rule applies to user
ipa sudorule-show rule_name | grep -A5 "Users"

# Check if user is member of specified groups
id username

# Verify rule applies to current host
ipa sudorule-show rule_name | grep -A5 "Hosts"
hostname

# Clear SSSD cache and retry
sudo sssctl cache-expire --everything
sudo systemctl restart sssd

# Test sudo
sudo -l

Sudo works on some hosts but not others:

# Check which hosts rule applies to
ipa sudorule-show rule_name | grep -A5 "Hosts"

# Verify host is member of host groups
ipa hostgroup-show hostgroup_name

# On affected host, check SSSD sudo cache
sudo sssctl sudo-list username

# If rule missing from cache, clear and refresh
sudo sssctl cache-expire --everything

Command denied even though allowed by rule:

# Check if deny commands override allow
ipa sudorule-show rule_name | grep -A5 "Deny"

# Find if other rules have deny commands affecting this user
ipa sudorule-find --users=username
# Review each rule for deny commands

# Verify exact command path matches
sudo -l  # Lists allowed commands with exact paths
# Must match command definition exactly

NOPASSWD not working, still prompts for password:

# Verify !authenticate option set
ipa sudorule-show rule_name --all | grep sudooption

# Check sudo option syntax (common typo: "NOPASSWD" instead of "!authenticate")
# Correct syntax: --sudooption='!authenticate'

# Clear cache
sudo sssctl cache-expire --everything

# Test again
sudo <command>

Sudo rule changes not taking effect on clients:

# SSSD caches sudo rules; changes may take time

# On affected client, check cache timestamp
sudo sssctl cache-expire --everything
sudo systemctl restart sssd

# Verify rule cached
sudo sssctl sudo-list username

# If rule still not appearing, check client connectivity
ipa ping

Cannot determine which rule is granting access:

# List all rules affecting user
ipa sudorule-find --users=username
ipa sudorule-find --groups=groupname

# On client, enable sudo debug logging
# Edit /etc/sssd/sssd.conf:
[domain/example.com]
debug_level = 9

sudo systemctl restart sssd

# Attempt sudo command
sudo <command>

# Review SSSD logs
sudo journalctl -u sssd -n 200 | grep -i sudo

External user sudo not working with AD trust:

# Verify trust is functional
ipa trust-show ad.example.com

# Verify external group membership
ipa group-show ad_linux_admins_external
ipa group-show ad_linux_admins  # POSIX group

# Verify sudo rule references POSIX group (not external)
ipa sudorule-show ad_sudo | grep "User Groups"

# Test AD user resolution on client
id 'aduser@ad.example.com'

# Clear SSSD cache
sudo sssctl cache-expire --everything

Deny command not preventing execution:

# Verify deny command syntax matches exactly
ipa sudorule-show rule_name --all | grep "Deny commands"

# Check if allow command is more specific (arguments)
# Deny: /usr/bin/passwd
# Allow: /usr/bin/passwd user  (would still allow passwd with args)

# Solution: Make deny command more comprehensive
ipa sudorule-add-deny-command rule_name --sudocmds='/usr/bin/passwd *'

Sudoers file warnings about IPA rules:

# Symptom: "sudo: unable to resolve host" or similar warnings

# Verify SSSD sudo provider configured
grep -i sudo /etc/sssd/sssd.conf

# Should have:
[domain/example.com]
sudo_provider = ipa

# If missing, add and restart SSSD
sudo systemctl restart sssd

Sudo command works interactively but fails in scripts:

# Interactive sudo may have different environment than scripts

# Check sudo options for environment variables
ipa sudorule-show rule_name --all | grep env_keep

# Scripts may need specific env variables preserved
ipa sudorule-add-option rule_name --sudooption='env_keep+=PATH'

# Or run script with sudo -E to preserve environment
sudo -E ./script.sh

Cannot add command to sudo rule - command not found:

# Sudo commands must be created before adding to rules
ipa sudocmd-add '/usr/bin/newcommand'

# Verify command exists
ipa sudocmd-show '/usr/bin/newcommand'

# Add to rule
ipa sudorule-add-allow-command rule_name --sudocmds='/usr/bin/newcommand'

Order attribute not affecting evaluation:

# Order not supported by all sudo configurations
# Modern SSSD-based sudo may ignore order

# Don't rely on order for security
# Use deny commands for precedence (always override allow)

# Verify SSSD version
sssd --version

# Check SSSD sudo respects order
# (behavior varies by version)

RunAs user not working, still executes as root:

# Verify RunAs user specified
ipa sudorule-show rule_name | grep "RunAs Users"

# Must specify RunAs user explicitly in sudo command
sudo -u targetuser <command>

# Without -u flag, sudo defaults to root even with RunAs configured

User has sudo on all hosts despite specific rule:

# Check for multiple rules with broad host categories
ipa sudorule-find --users=username

# Look for rules with --hostcat=all
# These override more restrictive rules

# Disable overly permissive rules
ipa sudorule-disable broad_rule_name

Sudo performance slow on clients:

# Large number of sudo rules can slow SSSD

# Check SSSD sudo cache timeout
grep sudo_timeout /etc/sssd/sssd.conf

# Increase timeout to reduce frequency of rule retrieval
# /etc/sssd/sssd.conf:
[domain/example.com]
sudo_timeout = 1800  # 30 minutes

sudo systemctl restart sssd

Integration with Other IPA Components

Sudo Commands and Command Groups

Sudo commands (sudocmd-*) define individual commands. Sudo command groups (sudocmdgroup-*) organize commands into collections. Rules reference these objects rather than embedding command paths directly.

User and Group Management

Sudo rules reference user groups created through group-* commands. As users join or leave groups, their sudo privileges automatically adjust according to rules targeting those groups.

Host and Host Group Management

Sudo rules reference host groups created through hostgroup-* commands. As hosts join or leave host groups, the sudo rules active on those hosts automatically change.

HBAC Rules

Host-based access control must permit access before sudo rules apply. If HBAC blocks a user from accessing a host, sudo rules on that host never evaluate for that user. HBAC and sudo rules work together to control access.

External Users and Trust Relationships

Sudo rules can target external users from trusted Active Directory domains. Trust configuration (trust-* commands) must be functional for external user sudo rules to work.

SSSD Integration

SSSD on IPA clients retrieves sudo rules from IPA servers and caches them locally. SSSD handles rule evaluation and provides sudo with authorization decisions. SSSD configuration affects sudo rule refresh timing and offline operation.

Commands

sudorule-add

Usage: ipa [global-options] sudorule-add SUDORULE-NAME [options]

Create new Sudo Rule.

Arguments

Argument	Required	Description
SUDORULE-NAME	yes	Rule name

Options

Option	Description
--desc DESC	Description
--usercat USERCAT	User category the rule applies to
--hostcat HOSTCAT	Host category the rule applies to
--cmdcat CMDCAT	Command category the rule applies to
--runasusercat RUNASUSERCAT	RunAs User category the rule applies to
--runasgroupcat RUNASGROUPCAT	RunAs Group category the rule applies to
--order ORDER	integer to order the Sudo rules
--externaluser EXTERNALUSER	External User the rule applies to (sudorule-find only)
--runasexternaluser RUNASEXTERNALUSER	External User the commands can run as (sudorule-find only)
--runasexternalgroup RUNASEXTERNALGROUP	External Group the commands can run as (sudorule-find only)
--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.

sudorule-add-allow-command

Usage: ipa [global-options] sudorule-add-allow-command SUDORULE-NAME [options]

Add commands and sudo command groups affected by Sudo Rule.

Arguments

Argument	Required	Description
SUDORULE-NAME	yes	Rule 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.
--sudocmds SUDOCMDS	sudo commands to add
--sudocmdgroups SUDOCMDGROUPS	sudo command groups to add

sudorule-add-deny-command

Usage: ipa [global-options] sudorule-add-deny-command SUDORULE-NAME [options]

Add commands and sudo command groups affected by Sudo Rule.

Arguments

Argument	Required	Description
SUDORULE-NAME	yes	Rule 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.
--sudocmds SUDOCMDS	sudo commands to add
--sudocmdgroups SUDOCMDGROUPS	sudo command groups to add

sudorule-add-host

Usage: ipa [global-options] sudorule-add-host SUDORULE-NAME [options]

Add hosts and hostgroups affected by Sudo Rule.

Arguments

Argument	Required	Description
SUDORULE-NAME	yes	Rule 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.
--hosts HOSTS	hosts to add
--hostgroups HOSTGROUPS	host groups to add
--hostmask HOSTMASK	host masks of allowed hosts

sudorule-add-option

Usage: ipa [global-options] sudorule-add-option SUDORULE-NAME [options]

Add an option to the Sudo Rule.

Arguments

Argument	Required	Description
SUDORULE-NAME	yes	Rule name

Options

Option	Description
--sudooption SUDOOPTION	Sudo Option
--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.

sudorule-add-runasgroup

Usage: ipa [global-options] sudorule-add-runasgroup SUDORULE-NAME [options]

Add group for Sudo to execute as.

Arguments

Argument	Required	Description
SUDORULE-NAME	yes	Rule 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.
--groups GROUPS	groups to add

sudorule-add-runasuser

Usage: ipa [global-options] sudorule-add-runasuser SUDORULE-NAME [options]

Add users and groups for Sudo to execute as.

Arguments

Argument	Required	Description
SUDORULE-NAME	yes	Rule 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.
--users USERS	users to add
--groups GROUPS	groups to add

sudorule-add-user

Usage: ipa [global-options] sudorule-add-user SUDORULE-NAME [options]

Add users and groups affected by Sudo Rule.

Arguments

Argument	Required	Description
SUDORULE-NAME	yes	Rule 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.
--users USERS	users to add
--groups GROUPS	groups to add

sudorule-del

Usage: ipa [global-options] sudorule-del SUDORULE-NAME [options]

Delete Sudo Rule.

Arguments

Argument	Required	Description
SUDORULE-NAME	yes	Rule name

Options

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

sudorule-disable

Usage: ipa [global-options] sudorule-disable SUDORULE-NAME [options]

Disable a Sudo Rule.

Arguments

Argument	Required	Description
SUDORULE-NAME	yes	Rule name

sudorule-enable

Usage: ipa [global-options] sudorule-enable SUDORULE-NAME [options]

Enable a Sudo Rule.

Arguments

Argument	Required	Description
SUDORULE-NAME	yes	Rule name

sudorule-find

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

Search for Sudo Rule.

Arguments

Argument Required Description

---

CRITERIA no A string searched in all relevant object attributes

Options

Option	Description
--sudorule-name SUDORULE-NAME	Rule name
--desc DESC	Description
--usercat USERCAT	User category the rule applies to
--hostcat HOSTCAT	Host category the rule applies to
--cmdcat CMDCAT	Command category the rule applies to
--runasusercat RUNASUSERCAT	RunAs User category the rule applies to
--runasgroupcat RUNASGROUPCAT	RunAs Group category the rule applies to
--order ORDER	integer to order the Sudo rules
--externaluser EXTERNALUSER	External User the rule applies to (sudorule-find only)
--runasexternaluser RUNASEXTERNALUSER	External User the commands can run as (sudorule-find only)
--runasexternalgroup RUNASEXTERNALGROUP	External Group the commands can run as (sudorule-find only)
--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 (“sudorule-name”)

sudorule-mod

Usage: ipa [global-options] sudorule-mod SUDORULE-NAME [options]

Modify Sudo Rule.

Arguments

Argument	Required	Description
SUDORULE-NAME	yes	Rule name

Options

Option	Description
--desc DESC	Description
--usercat USERCAT	User category the rule applies to
--hostcat HOSTCAT	Host category the rule applies to
--cmdcat CMDCAT	Command category the rule applies to
--runasusercat RUNASUSERCAT	RunAs User category the rule applies to
--runasgroupcat RUNASGROUPCAT	RunAs Group category the rule applies to
--order ORDER	integer to order the Sudo rules
--externaluser EXTERNALUSER	External User the rule applies to (sudorule-find only)
--runasexternaluser RUNASEXTERNALUSER	External User the commands can run as (sudorule-find only)
--runasexternalgroup RUNASEXTERNALGROUP	External Group the commands can run as (sudorule-find only)
--setattr SETATTR	Set an attribute to a name/value pair. Format is attr=value.
--addattr ADDATTR	Add an attribute/value pair. Format is attr=value. The attribute
--delattr DELATTR	Delete an attribute/value pair. The option will be evaluated
--rights	Display the access rights of this entry (requires —all). See ipa man page for details.
--all	Retrieve and print all attributes from the server. Affects command output.
--raw	Print entries as stored on the server. Only affects output format.
--no-members	Suppress processing of membership attributes.
--rename RENAME	Rename the sudo rule object

sudorule-remove-allow-command

Usage: ipa [global-options] sudorule-remove-allow-command SUDORULE-NAME [options]

Remove commands and sudo command groups affected by Sudo Rule.

Arguments

Argument	Required	Description
SUDORULE-NAME	yes	Rule 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.
--sudocmds SUDOCMDS	sudo commands to remove
--sudocmdgroups SUDOCMDGROUPS	sudo command groups to remove

sudorule-remove-deny-command

Usage: ipa [global-options] sudorule-remove-deny-command SUDORULE-NAME [options]

Remove commands and sudo command groups affected by Sudo Rule.

Arguments

Argument	Required	Description
SUDORULE-NAME	yes	Rule 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.
--sudocmds SUDOCMDS	sudo commands to remove
--sudocmdgroups SUDOCMDGROUPS	sudo command groups to remove

sudorule-remove-host

Usage: ipa [global-options] sudorule-remove-host SUDORULE-NAME [options]

Remove hosts and hostgroups affected by Sudo Rule.

Arguments

Argument	Required	Description
SUDORULE-NAME	yes	Rule 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.
--hosts HOSTS	hosts to remove
--hostgroups HOSTGROUPS	host groups to remove
--hostmask HOSTMASK	host masks of allowed hosts

sudorule-remove-option

Usage: ipa [global-options] sudorule-remove-option SUDORULE-NAME [options]

Remove an option from Sudo Rule.

Arguments

Argument	Required	Description
SUDORULE-NAME	yes	Rule name

Options

Option	Description
--sudooption SUDOOPTION	Sudo Option
--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.

sudorule-remove-runasgroup

Usage: ipa [global-options] sudorule-remove-runasgroup SUDORULE-NAME [options]

Remove group for Sudo to execute as.

Arguments

Argument	Required	Description
SUDORULE-NAME	yes	Rule 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.
--groups GROUPS	groups to remove

sudorule-remove-runasuser

Usage: ipa [global-options] sudorule-remove-runasuser SUDORULE-NAME [options]

Remove users and groups for Sudo to execute as.

Arguments

Argument	Required	Description
SUDORULE-NAME	yes	Rule 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.
--users USERS	users to remove
--groups GROUPS	groups to remove

sudorule-remove-user

Usage: ipa [global-options] sudorule-remove-user SUDORULE-NAME [options]

Remove users and groups affected by Sudo Rule.

Arguments

Argument	Required	Description
SUDORULE-NAME	yes	Rule 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.
--users USERS	users to remove
--groups GROUPS	groups to remove

sudorule-show

Usage: ipa [global-options] sudorule-show SUDORULE-NAME [options]

Display Sudo Rule.

Arguments

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