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
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
as follows.  I have the following setup in WS 2012 AD DC:

TomK (user)
TomK Groups:

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 =

Essentially TomK to be given access to hosts listed in the 'host'
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
groups and this user would get access only to the listed servers in
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
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
the OpenLDAP standard anyway.  Now to get this we considered and are
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
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 (??
??) 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
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:

More reading on External groups used for AD access control:

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



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)


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.


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

Reply via email to