Product SiteDocumentation Site

14.4. Testing Host-Based Access Control Rules

Implementing host-based access controls effectively can be tricky because it requires that all of the hosts be properly configured and the access is properly applied to users and services.
The hbactest command can test different host-based access control scenarios to make sure that the rules are working as expected.

14.4.1. The Limits of Host-Based Access Control Configuration

When a request is made to one of the domain services, the identifier of the source host is sent to a PAM interface for the login application (like OpenSSH, telnet, or rlogin) which is used to access SSSD on the target host machine. This identifier can be the hostname, the IP address, or even the alias of the source host.
This is essentially a long chain, from the source host to the target host to the service. The access control mechanism uses the identifier that is sent to the SSSD service on the target machine to verify that the source host has proper authorization granted in an access control rule.
However, if the identifier sent to SSSD cannot be traced back to the source host, then authorization fails. This can happen if any part of the host information does not match the access control rule configuration:
  • The source host uses an alias which is not listed in the rule.
  • The domain service on the target host sends an IP address instead of the hostname.
  • DNS is misconfigured and does not return the proper information for the DNS lookup or reverse lookup.
  • The client sends a malformed string to SSSD.
The name that is sent by the client must match the name in the rule, otherwise host-based access control fails.
The access control configuration should always be tested before it is implemented to prevent authorization failures.

14.4.2. Test Scenarios for Host-Based Access Control

Host-based access control rules depend on a lot of interactions — between hosts, services, DNS lookups, and users. If any element is misconfigured, then the rule can behave in unexpected ways.
FreeIPA includes a testing tool to verify that access control rules are behaving in the expected way by testing the access in a defined scenario. There are several situations where this testing is useful:
  • A new rule needs to be tested before it is implemented.
  • There are problems with the existing rules, and the testing tool can identify what rule is behaving badly.
  • A subset of existing rules can be tested to see how they are performing.
The hbactest command tests configured host-based access control rules in very specific situations. A test run defines:
  • The user to run the operation as to test the rule performance for that user (--user).
  • From the source host X (--srchost).
  • Using the login client Y (--service).
  • To target host Z (--host).
  • The rule to test (--rules); if this is not used, then all enabled rules are tested.
  • Optional The hbactest returns detailed information about which rules were matched, not matched, or invalid. This detailed rule output can be disabled using --nodetail, so the test simply runs and returns whether access was granted.

NOTE

The hbactest script does not actually connect to the target host. Instead, it uses the rules within the FreeIPA database to simulate how those rules would be applied in a specific situation as if an SSSD client were connecting to the FreeIPA server.
More briefly, it performs a simulated test run based on the given information and configuration, but it does not actually attempt a service request against the target host.
Example 14.4. Testing All Active Rules
The most basic command checks all active rules. It requires a specific connection scenario, so the user, login service, source host, and target host have to be given, and the testing tool checks the connection.
$ ipa  hbactest --user=jsmith --srchost=source.example.com --host=target.example.com --service=ssh
--------------------
Access granted: True
--------------------
  notmatched: my-second-rule
  notmatched: my-third-rule
  matched: myrule
  matched: allow_all

Example 14.5. Testing a Specific Rule
It is possible to check a specific rules (or several rules).
$ ipa hbactest --user=jsmith --srchost=source.example.com --host=target.example.com --service=ssh --rules=myrule
---------------------
Access granted: True
---------------------
   notmatched: myrule

Example 14.6. Testing Specific Rules Plus All Enabled
The --rules option lists specific rules to test, but it may be useful to test the specified rules against all of the enabled rules in the domain. This can be done by adding the --enabled option, which includes the (unspecified) enabled rules along with the specified rules.
$ ipa hbactest --user=jsmith --srchost=source.example.com --host=target.example.com --service=ssh --rules=myrule --enabled
--------------------
Access granted: True
--------------------
  matched: my-second-rule
  notmatched: my-third-rule
  matched: myrule
  matched: allow_all
It is possible to run a similar comparison against disabled rules by using the --disable option. With the --rules option, the specified rule plus all of the disabled rules are checked. With the --disabled option, all disabled rules are checked.