HBAC Rule Testing

HBAC rules control who can access what services on what hosts. You can use HBAC to control which users or groups can access a service, or group of services, on a target host.

Since applying HBAC rules implies use of a production environment, this plugin aims to provide simulation of HBAC rules evaluation without having access to the production environment.

Test user coming to a service on a named host against

existing enabled rules.

ipa hbactest —user= —host= —service=

[--rules=rules-list] [--nodetail] [--enabled] [--disabled]
[--sizelimit= ]

—user, —host, and —service are mandatory, others are optional.

If —rules is specified simulate enabling of the specified rules and test

the login of the user using only these rules.

If —enabled is specified, all enabled HBAC rules will be added to simulation

If —disabled is specified, all disabled HBAC rules will be added to simulation

If —nodetail is specified, do not return information about rules matched/not matched.

If both —rules and —enabled are specified, apply simulation to —rules [and]{#and}_

all IPA enabled rules.

If no —rules specified, simulation is run against all IPA enabled rules.

By default there is a IPA-wide limit to number of entries fetched, you can change it

with —sizelimit option.

EXAMPLES

1. Use all enabled HBAC rules in IPA database to simulate: $ ipa hbactest —user=a1a —host=bar —service=sshd

Access granted: True

Not matched rules: my-second-rule
Not matched rules: my-third-rule
Not matched rules: myrule
Matched rules: allow_all

2. Disable detailed summary of how rules were applied:
$ ipa hbactest --user=a1a --host=bar --service=sshd --nodetail
--------------------
Access granted: True
--------------------

3. Test explicitly specified HBAC rules:
$ ipa hbactest --user=a1a --host=bar --service=sshd \$
    --rules=myrule --rules=my-second-rule
---------------------
Access granted: False
---------------------
Not matched rules: my-second-rule
Not matched rules: myrule

4. Use all enabled HBAC rules in IPA database + explicitly specified rules:
$ ipa hbactest --user=a1a --host=bar --service=sshd \$
    --rules=myrule --rules=my-second-rule --enabled
--------------------
Access granted: True
--------------------
Not matched rules: my-second-rule
Not matched rules: my-third-rule
Not matched rules: myrule
Matched rules: allow_all

5. Test all disabled HBAC rules in IPA database:
$ ipa hbactest --user=a1a --host=bar --service=sshd --disabled
---------------------
Access granted: False
---------------------
Not matched rules: new-rule

6. Test all disabled HBAC rules in IPA database + explicitly specified rules:
$ ipa hbactest --user=a1a --host=bar --service=sshd \$
    --rules=myrule --rules=my-second-rule --disabled
---------------------
Access granted: False
---------------------
Not matched rules: my-second-rule
Not matched rules: my-third-rule
Not matched rules: myrule

7. Test all (enabled and disabled) HBAC rules in IPA database:
$ ipa hbactest --user=a1a --host=bar --service=sshd \$
    --enabled --disabled
--------------------
Access granted: True
--------------------
Not matched rules: my-second-rule
Not matched rules: my-third-rule
Not matched rules: myrule
Not matched rules: new-rule
Matched rules: allow_all

HBACTEST AND TRUSTED DOMAINS

When an external trusted domain is configured in IPA, HBAC rules are also applied on users accessing IPA resources from the trusted domain. Trusted domain users and groups (and their SIDs) can be then assigned to external groups which can be members of POSIX groups in IPA which can be used in HBAC rules and thus allowing access to resources protected by the HBAC system.

hbactest plugin is capable of testing access for both local IPA users and users from the trusted domains, either by a fully qualified user name or by user SID. Such user names need to have a trusted domain specified as a short name (DOMAINAdministrator) or with a user principal name (UPN), Administrator@ad.test.

Please note that hbactest executed with a trusted domain user as —user parameter can be only run by members of “trust admins” group.

EXAMPLES

1. Test if a user from a trusted domain specified by its shortname matches any rule:

$ ipa hbactest --user 'DOMAIN\Administrator' --host `hostname` --service sshd
Access granted: True
  Matched rules: allow_all
  Matched rules: can_login

2. Test if a user from a trusted domain specified by its domain name matches
   any rule:

$ ipa hbactest --user 'Administrator@domain.com' --host `hostname` --service sshd
Access granted: True
  Matched rules: allow_all
  Matched rules: can_login

3. Test if a user from a trusted domain specified by its SID matches any rule:

$ ipa hbactest --user S-1-5-21-3035198329-144811719-1378114514-500 \$
        --host `hostname` --service sshd
Access granted: True
  Matched rules: allow_all
  Matched rules: can_login

4. Test if other user from a trusted domain specified by its SID matches any rule:

$ ipa hbactest --user S-1-5-21-3035198329-144811719-1378114514-1203 \$
        --host `hostname` --service sshd
Access granted: True
  Matched rules: allow_all
  Not matched rules: can_login

5. Test if other user from a trusted domain specified by its shortname matches
   any rule:

$ ipa hbactest --user 'DOMAIN\Otheruser' --host `hostname` --service sshd
Access granted: True
  Matched rules: allow_all
  Not matched rules: can_login

Commands

hbactest

Usage: ipa [global-options] hbactest [options]

Simulate use of Host-based access controls

Options

Option	Description
--user USER	User name
--host HOST	Target host
--service SERVICE	Service
--rules RULES	Rules to test. If not specified, —enabled is assumed
--nodetail	Hide details which rules are matched, not matched, or invalid
--enabled	Include all enabled IPA rules into test [default]
--disabled	Include all disabled IPA rules into test
--sizelimit SIZELIMIT	Maximum number of rules to process when no —rules is specified

Use Cases

Testing New HBAC Rules Before Production Deployment

Before enabling new HBAC rules in production, administrators validate that rules grant expected access without unintended denials or excessive permissions.

# Test new rule without enabling it
ipa hbactest --user=jsmith --host=web01.example.com --service=sshd \
  --rules=new-web-admin-rule

# Output shows whether access would be granted
# Access granted: True/False
# Matched rules: new-web-admin-rule

# Test with multiple scenarios
ipa hbactest --user=contractor1 --host=web01.example.com --service=sshd \
  --rules=new-web-admin-rule
# Should show: Access granted: False (contractors excluded)

# After validation, enable rule
ipa hbacrule-enable new-web-admin-rule

Troubleshooting User Access Denials

When users report access denied errors, hbactest identifies which HBAC rules are evaluating and why access is denied.

# Simulate user's actual access attempt
ipa hbactest --user=denied-user --host=db01.example.com --service=postgresql

# Output shows matched and unmatched rules
# Access granted: False
# Not matched rules: database_admin_access
# Not matched rules: allow_all (disabled)

# Identify why rule didn't match - check rule details
ipa hbacrule-show database_admin_access

# Test if adding user to group would grant access
ipa group-add-member database-admins --users=denied-user
ipa hbactest --user=denied-user --host=db01.example.com --service=postgresql
# Now shows: Access granted: True

Validating HBAC Policy After Rule Modifications

After modifying existing HBAC rules, testing ensures changes have desired effect without breaking existing access.

# Test before modification
ipa hbactest --user=admin1 --host=server01.example.com --service=sshd

# Modify rule to add additional host group
ipa hbacrule-add-host admin_access --hostgroups=new-servers

# Test after modification with hosts in new group
ipa hbactest --user=admin1 --host=newserver01.example.com --service=sshd

# Test original access still works
ipa hbactest --user=admin1 --host=server01.example.com --service=sshd

# Test unintended users aren't granted access
ipa hbactest --user=regularuser --host=newserver01.example.com --service=sshd

Testing HBAC Rules with Disabled allow_all Rule

Organizations disabling the permissive allow_all rule test that explicit HBAC rules provide necessary access before disabling default access.

# Test current state with allow_all enabled
ipa hbactest --user=testuser --host=test.example.com --service=sshd
# Shows: Matched rules: allow_all

# Test what would happen with only explicit rules (not allow_all)
ipa hbactest --user=testuser --host=test.example.com --service=sshd \
  --rules=explicit_ssh_access
# Shows if access would be granted without allow_all

# Test multiple users and services before disabling allow_all
for user in user1 user2 user3; do
  ipa hbactest --user=$user --host=test.example.com --service=sshd
done

# After validation, disable allow_all
ipa hbacrule-disable allow_all

Comparing Enabled vs Disabled HBAC Rules

Analyzing why disabled rules were created and comparing their effect against current enabled rules helps policy review.

# Test with only enabled rules (default)
ipa hbactest --user=manager1 --host=app.example.com --service=httpd --enabled

# Test with only disabled rules to see historical policies
ipa hbactest --user=manager1 --host=app.example.com --service=httpd --disabled

# Test with both enabled and disabled to compare
ipa hbactest --user=manager1 --host=app.example.com --service=httpd \
  --enabled --disabled

# Output shows which disabled rules would match if re-enabled
# Helps decide whether to re-enable or delete disabled rules

Testing Active Directory Trusted Domain User Access

Organizations with AD trusts test whether trusted domain users can access resources via HBAC policies.

# Test AD user by UPN
ipa hbactest --user=Administrator@ad.example.com \
  --host=linux-server.ipa.example.com --service=sshd

# Test AD user by short domain name
ipa hbactest --user='ADDOMAIN\jdoe' \
  --host=linux-server.ipa.example.com --service=sshd

# Test AD user by SID
ipa hbactest --user=S-1-5-21-1234567890-1234567890-1234567890-500 \
  --host=linux-server.ipa.example.com --service=sshd

# Verify external group mappings work correctly
ipa hbacrule-show ad_user_access

Batch Testing Multiple Access Scenarios

Policy validation requires testing multiple user/host/service combinations to ensure comprehensive coverage.

# Create test matrix file
cat > hbac-test-scenarios.txt << EOF
admin1,server01.example.com,sshd
admin1,server01.example.com,sudo
developer1,devserver.example.com,sshd
contractor1,prodserver.example.com,sshd
EOF

# Run batch tests
while IFS=, read -r user host service; do
  echo "Testing: $user on $host for $service"
  ipa hbactest --user="$user" --host="$host" --service="$service"
  echo "---"
done < hbac-test-scenarios.txt

# Review results for unexpected access grants or denials

Testing Specific Rule Combinations

Complex environments with many HBAC rules benefit from testing specific rule combinations to understand rule interactions.

# Test with only specific rules
ipa hbactest --user=dbadmin --host=db.example.com --service=postgresql \
  --rules=dba_base_access --rules=postgres_specific_access

# Compare against all enabled rules
ipa hbactest --user=dbadmin --host=db.example.com --service=postgresql

# Test adding one more rule to combination
ipa hbactest --user=dbadmin --host=db.example.com --service=postgresql \
  --rules=dba_base_access --rules=postgres_specific_access \
  --rules=emergency_access

# Identify minimal rule set needed for access

Suppressing Detail for Automated Testing

Automated testing scripts use —nodetail to get simple pass/fail results without verbose rule matching output.

# Simple pass/fail output for automation
result=$(ipa hbactest --user=testuser --host=testhost --service=sshd --nodetail)

# Parse result for access decision
if echo "$result" | grep -q "Access granted: True"; then
  echo "PASS: Access granted as expected"
  exit 0
else
  echo "FAIL: Access denied unexpectedly"
  exit 1
fi

# Use in CI/CD pipeline to validate HBAC changes
# before deploying to production

Testing Source Host Parameter for Enhanced Security

Some HBAC rules consider the source host (where user is connecting from) in addition to target host for enhanced access control.

# Test access from specific source host
ipa hbactest --user=admin --srchost=jumphost.example.com \
  --host=prodserver.example.com --service=sshd

# Compare with access from different source
ipa hbactest --user=admin --srchost=workstation.example.com \
  --host=prodserver.example.com --service=sshd

# Validate jump host requirement is enforced
# Some access should only be allowed from designated jump hosts

Security Considerations

HBAC Test Does Not Reflect Real-Time Group Membership

hbactest uses cached group membership data which may not reflect very recent group changes. Group membership modifications can take time to replicate and refresh in SSSD caches. Testing immediately after group changes may show inaccurate results, either granting access that would actually be denied or vice versa.

Wait for replication and cache refresh after group membership changes before running hbactest. Force SSSD cache clear before testing: sss_cache -E. Verify group membership with ipa group-show groupname before testing. For critical access validation, test on actual target system in addition to hbactest. Document cache refresh timing in test procedures.

Testing with Disabled Rules Exposes Historical Policy

Using --disabled flag reveals historical HBAC policies that may contain sensitive information about past security requirements, organizational structure, or deprecated access patterns. Disabled rules accessible to anyone who can run hbactest provide intelligence about policy evolution and potential security gaps.

Regularly review and delete disabled HBAC rules rather than leaving them indefinitely. Document reasons for disabling rules outside of IPA if needed. Restrict access to hbactest command to administrators via RBAC. Audit who is running hbactest with —disabled flag. Consider disabled rules as configuration history requiring same protection as enabled rules.

False Confidence from Successful Tests

Passing hbactest does not guarantee actual authentication success. PAM configuration, SSSD configuration, network connectivity, Kerberos authentication, and other factors affect real authentication. Relying solely on hbactest without real authentication testing creates false security confidence.

Use hbactest as preliminary validation tool, not sole testing method. Perform actual authentication tests on target systems after hbactest validation. Test complete authentication path including Kerberos, SSSD, and PAM stack. Document that hbactest validates HBAC policy only, not complete authentication chain. Include end-to-end authentication testing in deployment procedures.

Test Results Depend on Current IPA State

hbactest evaluates current HBAC rules, group memberships, and host configurations at time of execution. Results become stale as soon as any configuration changes occur. Saving test results for future reference without timestamps and configuration version creates misleading documentation.

Include timestamps and configuration state in test documentation. Re-run tests after any HBAC policy changes. Use version control for test scenarios and results. Document IPA configuration version when recording test results. Implement automated testing that runs continuously rather than point-in-time manual tests.

Testing AD Trust Users Requires Elevated Privileges

Testing HBAC access for trusted domain users requires “trust admins” group membership. This restriction limits who can validate AD user access, potentially delaying troubleshooting. Granting trust admin privileges for testing purposes violates principle of least privilege.

Establish procedures for requesting trust admin testing from authorized personnel. Use dedicated test accounts in AD for HBAC validation rather than testing with production AD users. Document trust admin privilege requirement in testing procedures. Consider creating read-only trust test capability if available in future IPA versions. Audit trust admin privilege usage.

Service Name Mismatches Cause Misleading Results

hbactest requires exact service name matching PAM configuration. Testing with wrong service name (e.g., “ssh” vs “sshd”) produces results that don’t reflect actual authentication behavior. Administrators may incorrectly conclude rules work or don’t work based on service name typos.

Verify service names match PAM configuration before testing: check /etc/pam.d/ on target systems. Document standard service names in testing procedures. Use ipa hbacsvc-find to see available services. Create validation scripts that check service name exists before running hbactest. Include service name verification in test result documentation.

Testing Does Not Validate SSSD Configuration

hbactest assumes SSSD is properly configured to enforce HBAC. Misconfigured SSSD may not enforce HBAC at all, making hbactest results meaningless. Testing successful access in hbactest while SSSD is misconfigured creates dangerous false confidence.

Validate SSSD configuration on target systems before relying on hbactest: verify pam_sss.so is in PAM stack. Test SSSD HBAC enforcement with known-good and known-bad scenarios. Monitor SSSD logs during authentication to confirm HBAC evaluation. Document SSSD configuration requirements in testing procedures. Include SSSD configuration validation in pre-deployment checklists.

Batch Testing Generates Audit Log Noise

Running extensive batch tests with many hbactest invocations generates significant audit log volume. Audit analysis tools may flag large numbers of hbactest executions as suspicious activity. Legitimate testing becomes difficult to distinguish from reconnaissance attempts.

Document testing activities in change management tickets before execution. Use dedicated test accounts with documented purpose. Implement audit log annotation indicating planned testing activity. Run batch tests during designated maintenance windows when possible. Establish patterns distinguishing legitimate testing from reconnaissance.

Test Output Discloses Rule Names and Structure

hbactest output lists matched and unmatched rule names, revealing HBAC policy structure to anyone who can run the command. Rule names may contain sensitive information about organizational security architecture, VIP users, or critical systems. Sharing test output for troubleshooting exposes policy details.

Use generic rule names not disclosing sensitive organizational information. Sanitize test output before sharing with third parties or less privileged support staff. Restrict hbactest execution to administrators via RBAC. Review rule naming conventions for information disclosure. Include policy structure confidentiality in security awareness training.

Testing Specific Rules Bypasses Policy Intent

Using --rules to test specific disabled rules bypasses normal policy evaluation. Administrators might incorrectly assume a disabled rule would grant access if enabled, without considering rule priority or conflicts with other rules. Testing specific rules in isolation doesn’t reflect real policy evaluation.

When testing specific rules, also test without --rules flag to compare against full policy. Document that isolated rule testing doesn’t reflect actual policy evaluation. Use --rules with --enabled to test additional rules combined with active policy. Validate rule priority and conflicts beyond hbactest simulation. Include full-policy testing in validation procedures.

Host Parameter Doesn’t Validate Host Existence

hbactest accepts any host name in --host parameter without validating host exists in IPA or is enrolled. Testing with non-existent hosts produces meaningless results. Typos in hostnames cause test failures unrelated to HBAC policy.

Validate host exists before testing: ipa host-show hostname.example.com. Use tab completion or copy hostnames from IPA listings. Create test scenario templates with validated hostnames. Document standard test hosts in testing procedures. Implement validation in test automation scripts.

User Parameter Doesn’t Validate User Existence

Similar to hosts, hbactest accepts any username without validation. Testing with non-existent users, typos, or wrong username format produces results that don’t reflect actual authentication attempts.

Verify user exists: ipa user-show username before testing. For AD users, confirm UPN format and domain trust is active. Use standardized test users documented in procedures. Implement username validation in test automation. Document correct username format for IPA and AD users.

Troubleshooting

HBAC Test Shows Access Denied But User Can Actually Authenticate

Symptom: hbactest reports “Access granted: False” but the same user can successfully authenticate to the service on the target host.

Diagnosis: Check if allow_all HBAC rule is enabled on system but testing was run without it. Verify SSSD configuration on target host: HBAC may not be enforced. Check for cached credentials or other authentication paths bypassing HBAC. Review if PAM configuration actually uses pam_sss.so for HBAC evaluation.

Resolution: Test with all enabled rules: ipa hbactest --user=username --host=hostname --service=servicename --enabled. Verify SSSD enforces HBAC: check /etc/sssd/sssd.conf for access_provider = ipa. Confirm PAM uses SSSD: /etc/pam.d/service should contain pam_sss.so. Clear SSSD cache and retry: sss_cache -E && systemctl restart sssd. Test actual authentication after hbactest to compare.

HBAC Test Shows Access Granted But User Cannot Authenticate

Symptom: hbactest reports “Access granted: True” but actual authentication attempts fail with access denied.

Diagnosis: Check if group membership hasn’t propagated to target system’s SSSD cache. Verify HBAC rule references correct service name matching PAM configuration. Check for network issues preventing HBAC rule retrieval by SSSD. Review if SELinux or other access controls denying access independent of HBAC.

Resolution: Clear SSSD cache on target system: sss_cache -E && systemctl restart sssd. Verify service name matches: compare hbactest service parameter with /etc/pam.d/ filename. Check SSSD connectivity: sssctl domain-status domain.example.com. Review SSSD logs: /var/log/sssd/sssd_*.log for HBAC evaluation details. Test group membership propagated: id username on target system. Check for SELinux denials: ausearch -m AVC -ts recent.

Testing AD Trust User Fails with Permission Error

Symptom: Running hbactest with Active Directory user fails with insufficient permissions or access denied error.

Diagnosis: Verify current user is member of “trust admins” group: ipa group-show "trust admins". Check if AD trust is active: ipa trust-show ad.example.com. Review AD user format: must use UPN, short name, or SID format. Confirm Kerberos ticket is valid: klist.

Resolution: Add user to trust admins group: ipa group-add-member "trust admins" --users=adminuser. Verify AD trust exists and is active: ipa trust-find. Use correct AD user format: Administrator@ad.example.com or ADDOMAIN\Administrator or SID. Renew Kerberos ticket: kinit admin. Test with known-good AD user first to isolate format vs permission issues.

No Rules Matched Despite Valid Configuration

Symptom: hbactest shows “Access granted: False” with “Not matched rules” listing all rules, but user should have access based on rule configuration.

Diagnosis: Verify user is member of groups specified in rules: ipa user-show username --all | grep memberof. Check if host is member of hostgroups in rules: ipa host-show hostname --all. Review if service name exactly matches rule’s service: case-sensitive. Check if rules are enabled: disabled rules don’t match unless —disabled flag used.

Resolution: Verify group memberships: ipa group-show groupname | grep username. Add user to appropriate groups: ipa group-add-member groupname --users=username. Verify host memberships: ipa hostgroup-show groupname | grep hostname. Use exact service name: ipa hbacsvc-show servicename to confirm exact name. Enable rules if disabled: ipa hbacrule-enable rulename. Test with --all flag to see complete rule details: ipa hbacrule-show rulename --all.

Testing Fails with “Service Not Found” Error

Symptom: hbactest command fails with error indicating specified service does not exist or is not found.

Diagnosis: Verify service exists in IPA: ipa hbacsvc-show servicename. Check spelling and case of service name. List available services: ipa hbacsvc-find. Compare service name with PAM configuration filename.

Resolution: Create service if missing: ipa hbacsvc-add servicename --desc="Description". Use exact service name from ipa hbacsvc-find output. Verify service name matches /etc/pam.d/ filename on target system. Use tab completion to avoid typos. Check for spaces or special characters in service name.

Testing Fails with “Host Not Found” Error

Symptom: hbactest fails with error about host not existing or not being found.

Diagnosis: Verify host is enrolled: ipa host-show hostname.example.com. Check FQDN format: must include domain. Review DNS resolution: ping hostname to verify DNS works. List enrolled hosts: ipa host-find.

Resolution: Enroll host if not enrolled: ipa-client-install on target system. Use fully qualified domain name: host.example.com not host. Verify DNS resolution working: dig hostname.example.com. Use exact hostname from ipa host-find. Check for typos in hostname using tab completion.

Testing Fails with “User Not Found” Error

Symptom: hbactest reports user does not exist or cannot be found.

Diagnosis: Verify user exists: ipa user-show username. Check username spelling and case. For AD users, verify trust exists: ipa trust-find. Review AD user format: UPN vs short name vs SID.

Resolution: Create user if missing: ipa user-add username. Use correct username format: check with ipa user-find. For AD users, verify trust active: ipa trust-show ad.example.com. Use proper AD format: user@domain.com or DOMAIN\user. Check for trailing spaces or typos in username.

Test Results Inconsistent Across Multiple Runs

Symptom: Running same hbactest command multiple times produces different results without any configuration changes.

Diagnosis: Check for replication lag between IPA servers: tests may hit different servers. Review if concurrent configuration changes are occurring. Verify LDAP replication status: ipa-replica-manage list. Check for time synchronization issues.

Resolution: Wait for replication to complete: ipa-replica-manage list should show healthy status. Force replication: ipa-replica-manage force-sync --from=source-server. Run tests consistently on same IPA server: use -s servername flag. Verify time sync across servers: chronyc sources. Implement change freeze during testing windows. Re-run tests after confirming stable state.

Batch Testing Script Produces Partial Results

Symptom: Script running multiple hbactest commands completes but some tests missing from output.

Diagnosis: Check for rate limiting or resource constraints. Review script error handling: commands may be failing silently. Verify all usernames, hostnames, and service names valid. Check for shell quoting issues with special characters.

Resolution: Add error checking to script: capture and log stderr output. Run tests with delays between invocations to avoid rate limits. Validate all parameters before testing: check users, hosts, services exist. Review script logs for command failures. Test commands individually to identify problematic combinations. Use proper quoting for usernames with special characters.

HBAC Test Hangs or Times Out

Symptom: hbactest command does not return, appears to hang, or eventually times out.

Diagnosis: Check IPA server responsiveness: ipa ping. Review LDAP server status: systemctl status dirsrv@REALM. Check network connectivity to IPA server. Review if large number of rules causing performance issues. Check for LDAP query timeouts.

Resolution: Verify IPA services running: ipactl status. Restart IPA services if needed: ipactl restart. Test with smaller rule set: use --rules to test specific rules. Increase size limit: --sizelimit=500 to allow more rules. Check network connectivity: ping ipa-server. Review IPA server performance: CPU, memory, disk I/O. Test from different network location to isolate connectivity issues.

Cannot See Detailed Rule Matching Information

Symptom: hbactest output doesn’t show which rules matched or didn’t match, only shows access decision.

Diagnosis: Check if --nodetail flag was used inadvertently. Review command syntax. Verify output isn’t being truncated by terminal or piping.

Resolution: Remove --nodetail flag from command. Redirect output to file for complete review: ipa hbactest ... > output.txt. Increase terminal scrollback buffer. Run command without filters or grep that might hide details. Use tee to see output and save to file: ipa hbactest ... | tee output.txt.

Source Host Parameter Not Affecting Results

Symptom: Using --srchost parameter doesn’t seem to affect test results regardless of source host specified.

Diagnosis: Check if any HBAC rules actually use source host restrictions (most don’t). Review if HBAC rules are configured with source host requirements. Verify command syntax: --srchost vs --host distinction.

Resolution: Review HBAC rules to see if any include source host restrictions: ipa hbacrule-show rulename --all. Note that source host checking is rarely used in HBAC rules. Verify using --srchost for source and --host for target separately. If no rules use source host, parameter won’t affect results. Document that source host matching requires explicit rule configuration.

Testing Shows Wrong Allow_All Rule Behavior

Symptom: Tests show allow_all rule matching when it should be disabled, or not matching when expected.

Diagnosis: Verify allow_all rule status: ipa hbacrule-show allow_all | grep Enabled. Check if testing with --enabled flag includes disabled allow_all. Review rule name: might be different “allow all” rule vs built-in “allow_all”.

Resolution: Check exact rule status: ipa hbacrule-show allow_all. Enable or disable as needed: ipa hbacrule-enable allow_all or ipa hbacrule-disable allow_all. Verify testing with correct flags: --enabled only includes enabled rules. List all rules to identify any similar named rules: ipa hbacrule-find allow. Clear any confusion between built-in allow_all and custom rules with similar names.