[Freeipa-users] HBAC

[Simo Sorce]

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.



-- 
Simo Sorce * Red Hat, Inc * New York