[Freeipa-users] HBAC

[TomK]

On 10/1/2015 12:04 PM, Simo Sorce wrote:
> On 30/09/15 21:22, TomK wrote:
>>
>>
>> On 9/30/2015 8:12 AM, Martin Kosek wrote:
>>> On 09/30/2015 07:50 AM, Alexander Bokovoy wrote:
>>>> On Tue, 29 Sep 2015, TomK wrote:
>>>>> Hey Guy's,
>>>>>
>>>>> (Sending this again as I didn't have this email included in the
>>>>> freeipa-users
>>>>> mailing list so not sure if the other message will get posted.)
>>>>>
>>>>> Before I post a ticket to RH Support for an RFE, I'll post the
>>>>> request here
>>>>> to get some feedback on options and what ideas folks have.  I've a
>>>>> situation
>>>>> as follows.  I have the following setup in WS 2012 AD DC:
>>>>>
>>>>> TomK (user)
>>>>> TomK Groups:
>>>>>                 unixg
>>>>>                 windowsg
>>>>>
>>>>> unixg has the 'host' attribute defined 'lab01,lab02,lab03,lab04'
>>>>> windowsg has the 'host' attribute defined 'lab06,lab07,lab08,lab09'
>>>>>
>>>>> TomK(user) also has the 'host' attribute defined as per the proper
>>>>> RFC for
>>>>> LDAP.  With SSSD rules I can define the rules to read the user 'host'
>>>>> attribute but not the group 'host' attribute:
>>>>>
>>>>>
>>>>> |access_provider = ldap ldap_access_order = host
>>>>> ldap_user_authorized_host =
>>>>> host|
>>>>>
>>>>>
>>>>> Essentially TomK to be given access to hosts listed in the 'host'
>>>>> attribute
>>>>> but denied entry into lab05 for example (not listed in any group 
>>>>> 'host'
>>>>> attribute above) to the server.   If I have a new user that has
>>>>> joined that
>>>>> particular team at our organization, I can simply add her/him to the
>>>>> above
>>>>> groups and this user would get access only to the listed servers in
>>>>> 'host'
>>>>> attribute by default. I don't need to specify new groups in 
>>>>> customized
>>>>> sssd.conf or ldap.conf files or in sshd config files. Hence less to
>>>>> update
>>>>> with Salt or any other CM suite.  I've managed to setup SUDO rules
>>>>> and with
>>>>> the openssh-ldap.diff schema SSH public keys could be stored in AD
>>>>> as well
>>>>> and be read by OpenSSH.  So aside from the HBAC capability on groups,
>>>>> virtually all our needs are handled by the WS2012 AD DC as it has to
>>>>> follow
>>>>> the OpenLDAP standard anyway.  Now to get this we considered and are
>>>>> still
>>>>> considering FreeIPA.  However this idea poses a set of challenges:
>>>>>
>>>>> 1) In large organizations where the AD support department are only
>>>>> trained in
>>>>> Windows AD setup and configuration (Only windows guy's) this would
>>>>> require a
>>>>> minimal of 3 bodies to support that know LDAP/Linux.  This is a
>>>>> large cost.
>>>>>
>>>>> 2) The additional server requires the same hardening as the Windows
>>>>> AD DC
>>>>> servers meaning a new procedure has to be carved out for the 2+ 
>>>>> FreeIPA
>>>>> servers to be supported, hardened and maintained (upgraded).
>>>>>
>>>>> Now I probably sound somewhat anti-FreeIPA, however the challenges of
>>>>> implementing it in large organizations surface after some
>>>>> deliberation, so
>>>>> probably better to list then as it may help direct development of
>>>>> the product
>>>>> to contend with the challenges (Like having a document fully
>>>>> dedicated to
>>>>> hardening a FreeIPA server with selinux and other technologies in
>>>>> easy to
>>>>> maintain configuration).   I could be mistaken but some folks
>>>>> mention that
>>>>> it's 'better' to implement this sort of HBAC through other means (??
>>>>> iptables
>>>>> ??) but never tried the alternatives yet.
>>>>>
>>>>> So, cutting to the end, would it be possible to add an attribute 
>>>>> like:
>>>>>
>>>>> |ldap_user_authorized_host|
>>>>>
>>>>> but perhaps called 'ldap_group_authorized_host' to the SSSD code to
>>>>> enable
>>>>> reading the 'host' attribute on AD/LDAP defined groups?
>>>> In FreeIPA we support HBAC rules for AD users and groups. What exactly
>>>> is wrong with that?
>>>>
>>>> See 'ipa help trust' for details how to map AD groups to IPA groups 
>>>> and
>>>> then 'ipa help hbacrule' for how to limit access of those groups to
>>>> specific hosts and services on them.
>>>>
>>>> This is all covered well in the guide:
>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html 
>>>>
>>>>
>>> More reading on External groups used for AD access control:
>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/active-directory-trust.html#trust-win-groups 
>>>
>>>
>>>
>>> I would also suggest a video with HBAC and Trust in action:
>>>
>>> https://www.youtube.com/watch?v=sQnNFJOzwa8
>>>
>>> HTH,
>>> Martin
>>
>> We already defined HBAC rules in the manner that all the links you
>> pointed out indicate as an early implementation.  As a product, there is
>> no issue in IDM from that perspective.  This is all great and the
>> product is fine from that perspective.
>>
>> It would be good to have a dual option of either allowing SSSD or IDM /
>> FreeIPA have full HBAC capability not just FreeIPA / IDM as in our
>> organization that would be a huge cost savings vs implementing IDM as a
>> separate Linux DC to be managed by a separate team.  So for those
>> customers that wish to go directly to AD or have already invested in AD
>> can choose SSSD only (If MS bundles AD with certain purchases, for
>> example, that is an actual cost savings for a company).  Other customers
>> who wish to keep the two separate so they do not flood AD DC's with non
>> Windows AD settings can integrate IDM.
>>
>> There will be cases where there could be a potential to save on costs vs
>> AD so the Linux IDM could be chosen as an Enterprise DC to which Windows
>> server authenticate as well as Linux ones or vice versa, whereas those
>> organizations already implementing Windows AD can have the option to
>> have Linux servers connecting to the AD DC via SSSD.
>>
>> Since SSSD and IDM are so closely coupled, for someone who requires
>> HBAC, the choice is either take both SSSD and IDM or neither. So other
>> solutions are being explored instead.
>>
>> Do these reasons make sense as to why I posted the original ask?
>
> When SSSD is integrated directly in AD you can use Group Policies to 
> define access controls. See ad_gpo_access_control in sssd-ad(5)
>
> Simo.
>
>
>
This is one of the things we tried in AD to define on groups/users and 
use the ad_gpo_access_control but it was very cumbersome and to scale 
that to the number of groups and users we have it would make a much 
larger mess.

Spent a bit of time with a few AD guy's to see if that would be doable 
but no.  The reason for this is that if I have say 4000 groups, to deny 
access to all but 1 to a set of servers, I have to:

1) Specify to ALLOW for a group/user within that GPO policy.
2) Then specify 3999 times a DENY on all the other groups within that 
one policy.  (I cannot specify an allow ahead of a deny like I can with 
iptables and the AD guy's didn't indicate any shortcuts with that.  I 
can't do wild cards with GPO either nor can I specify ! or * and this 
makes it impossible to use for even small number of groups.)
3) Create an OU to then hold the systems that I want to give that one 
group access too.
4) Apply the GPO Policy to that OU.

So this causes a much larger mess in AD, even if there were shortcuts, 
because:

1) I will now have to keep and maintain a huge list of OU's that hold 
host objects separately.  AD teams will never go for that in large 
institutions.
2) I will also now have a huge list of GPO Policies to maintain as well.
3) Anytime I add a group, I then have to add it to the previous GPO 
Policies to restrict it's access to the rest of the hosts or users in 
that new group would get access in addition to adding a new host.

And with such a large definition, it would become unsupportable and 
would cause a big mess where we do not need one.  We also tried WMI that 
Microsoft suggested but that was no better and added another layer of 
complexity.  IDM itself has wild cards and such which is convenient but 
again all the concerns come up with it with a large organization that I 
raised earlier.  If such wildcard matches can be included in SSSD to 
read the 'host' attribute on a group, such as *mdm* that would make 
things even easier as I wouldn't have to keep adding new hosts in.

With the host attribute on the user it's simple. If I don't specify any 
value for host, the user can't login anywhere.  If I specify * he/she 
can login anywhere.  If I specify a host list it restricts to that 
list.  I can use ! as well.  So much more practical and with REGEX added 
in, very powerfull.

Hence the ask for reading the 'host' attribute.  There's an 
libpam-python someone wrote that perhaps this could be achieved through 
that but that's more on the customization side so we would prefer to see 
an official feature add instead, if possible.

This raises another question.  Any thoughts about adding plugin 
mechanisms into SSSD?  With that I could parse REGEX pressions in AD 
attributes and act on them.  But I think that's more PAM then SSSD.

Cheers,
Tom