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?
Thanks,
TomK
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
