On Tue, 29 Sep 2015, TomK wrote:
(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
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:
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
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:
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:
/ Alexander Bokovoy
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project