HBAC rules control who can access what services on what hosts and from where.
You can use HBAC to control which users or groups on a source host 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 from source host to a service on a named host against
 existing enabled rules.

 ipa hbactest --user= --srchost= --host= --service=
              [--rules=rules-list] [--nodetail] [--enabled] [--disabled]

 --user, --srchost, --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_
 all IPA enabled rules.

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

EXAMPLES:

    1. Use all enabled HBAC rules in IPA database to simulate:
    $ ipa  hbactest --user=a1a --srchost=foo --host=bar --service=ssh
    --------------------
    Access granted: True
    --------------------
      notmatched: my-second-rule
      notmatched: my-third-rule
      notmatched: myrule
      matched: allow_all

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

    3. Test explicitly specified HBAC rules:
    $ ipa hbactest --user=a1a --srchost=foo --host=bar --service=ssh --rules=my-second-rule,myrule
    ---------------------
    Access granted: False
    ---------------------
      notmatched: my-second-rule
      notmatched: myrule

    4. Use all enabled HBAC rules in IPA database + explicitly specified rules:
    $ ipa hbactest --user=a1a --srchost=foo --host=bar --service=ssh --rules=my-second-rule,myrule --enabled
    --------------------
    Access granted: True
    --------------------
      notmatched: my-second-rule
      notmatched: my-third-rule
      notmatched: myrule
      matched: allow_all

    5. Test all disabled HBAC rules in IPA database:
    $ ipa hbactest --user=a1a --srchost=foo --host=bar --service=ssh --disabled
    ---------------------
    Access granted: False
    ---------------------
      notmatched: new-rule

    6. Test all disabled HBAC rules in IPA database + explicitly specified rules:
    $ ipa hbactest --user=a1a --srchost=foo --host=bar --service=ssh --rules=my-second-rule,myrule --disabled
    ---------------------
    Access granted: False
    ---------------------
      notmatched: my-second-rule
      notmatched: my-third-rule
      notmatched: myrule

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

Only rules existing in IPA database are tested. They may be in enabled or
disabled disabled state.

Specifying them through --rules option explicitly enables them only in
simulation run.

Specifying non-existing rules will not grant access and report non-existing
rules in output.

Fix several test failures when issuer does not match the one
generated by make-testcert (CN=Certificate Authority,O=<realm>).

https://fedorahosted.org/freeipa/ticket/1527

When using the add_indirect helper we create a new map and then add a key
for it all in one step. If adding the key fails for any reason be sure to
remove the map we added.

https://fedorahosted.org/freeipa/ticket/1520

It won't appear in the UI/CLI but is still available via XML-RPC.
allow is the default and deny will be rejected.

https://fedorahosted.org/freeipa/ticket/1495

The pairwise grouping used to form RDN's and AVA's proved to be
confusing in practice, this patch removes that functionality thus
requiring programmers to explicitly pair attr,value using a tuple or
list.

In addition it was discovered additional functionality was needed to
support some DN operations in freeipa. DN objects now support
startswith(), endswith() and the "in" membership test. These functions
and operators will accept either a DN or RDN.

The unittest was modified to remove the pairwise tests and add new
explicit tests. The unittest was augmented to test the new
functionality. In addition the unittest was cleaned up a bit to use
common utilty functions for improved readabilty and robustness.

The documentation was updated.

fix test_role_plugin use of DN to avoid pairwise grouping

The unit tests were incorrectly expecting the removed data back when
removing external users.

Add a new command that lets you wait for an attribute to appear in
a value. Using this you can do things like wait for a managed entry
to be created, adding a new objectclass to the parent entry.

This is controlled by a new booleon option, wait_for_attr, defaulting
to False.

https://fedorahosted.org/freeipa/ticket/1144

Some object names had spaces in them which was bad, update the tests
to reflect the new names.

Implement a test for new dnszone-find option --forward-only.
Fix example for reverse zone (zone was not fully qualified and
DNS plugin would forbid adding PTR records).

https://fedorahosted.org/freeipa/ticket/1473

New rules will all be allow type. Existing rules cannot be changed to
deny.

The type attribute now defaults to allow with autofill so it won't be
prompted in interactive mode in the cli.

https://fedorahosted.org/freeipa/ticket/1432