On Tue, 25 Mar 2014, KodaK wrote:
I've been working with support on how to set up HBAC and sudo rules with AD
From what they've described I can only manage them on an aggregate level
using an external group.
For example, I can define an hbac rule, but that hbac rule will be vaild
for *all* AD users in the external group that was created to handle them.
Am I missing something? If that's the case then this isn't flexible enough
for our needs. I have to be able to specify rules based on individual
It seems like there might be a work-around by using multiple external
groups and having each AD user in their own external group, but that would
be really cumbersome (if it's even possible.)
Do I have any other options?
Group membership in IPA follows LDAP membership rules. This means
objects must have DN to be included into an LDAP group. AD users do not
exist in IPA LDAP server, thus they cannot be referenced by DN.
HBAC rules refer objects by their LDAP DNs too.
To overcome absence of LDAP DNs for AD users and groups we have
concept of "external" groups in IPA LDAP. These are normal LDAP groups,
that lack POSIX attributes and have special attribute to store SIDs of
external objects which 'belong' to this group. We then use DN of the
"external" group to be a member.
When SSSD evaluates HBAC groups against certain AD user, it uses group
membership from Keberos ticket defined in MS-PAC structure to verify
against the set of HBAC rules. That group membership in the MS-PAC is
defined in terms of SIDs. SSSD downloads all HBAC rules related to the
host, then unrolls all groups that are referenced in the HBAC rules and
applies special handling to "external" groups by taking that specific
attribute which stores SIDs of "external" group members.
So at this point SSSD has all information to match SIDs of AD user
against HBAC rules. There is no other way to do it.
So there are two ways to handle your case -- by grouping at IPA side or
by grouping at AD side.
The latter approach is to have a group in AD that says "these users
have access to this server" and make an "external" group in IPA that
references the AD group. By deleting AD user from AD group you will
effectively deny access to an IPA machine without touching IPA rules.
There are no other ways.
/ Alexander Bokovoy
Freeipa-users mailing list