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:

I would also suggest a video with HBAC and Trust in action:



Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project

Reply via email to