On 10/1/2015 12:04 PM, Simo Sorce wrote:
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
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:
(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
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:
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
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
Essentially TomK to be given access to hosts listed in the 'host'
but denied entry into lab05 for example (not listed in any group
attribute above) to the server. If I have a new user that has
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
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
the openssh-ldap.diff schema SSH public keys could be stored in AD
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
Windows AD setup and configuration (Only windows guy's) this would
minimal of 3 bodies to support that know LDAP/Linux. This is a
2) The additional server requires the same hardening as the Windows
servers meaning a new procedure has to be carved out for the 2+
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
probably better to list then as it may help direct development of
to contend with the challenges (Like having a document fully
hardening a FreeIPA server with selinux and other technologies in
maintain configuration). I could be mistaken but some folks
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
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
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)
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,
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
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