LDAP access provider - list of groups in directory?

[John Snowdon]

Hi,

I'm currently working on an sssd configuration to replace a set of legacy
authentication and authorization mechanisms on several hundred Linux systems in our
department  - they're currently supported via shared /etc/passwd and /etc/group files.


I've got access, user and group information all working well via pam and sssd and am
now trying to find a solution to the authorisation requirements. Previously this was
managed via puppet-distributed changes to /etc/pam.d with a list of users/groups per
machine stored in the puppet nodes files. 
I'd like to move to a setup where each machine (or class of machine) just pulls the
list of allowed unix groups from it's own node in OpenLDAP.

Is there anything available in sssd.conf that would allow the ldap access provider to pull
back a list of allowed groups from ldap, rather than listing them explicitly? Sort of a
hybrid between the simple_allow_groups and ldap_access_filter?

e.g. What I would love to do

access_provider = ldap
ldap_allow_groups_dn = cn=MachineA,ou=machines,dc=network,dc=com

Where the cn=MachineA object is a groupOfNames that would look something like:

objectClass: groupOfNames
objectClass: top
cn: MachineA
description: Posix groups whose users are allowed to access MachineA
member: root
member: localusers
member: adminusers
member: webusers

I'd much rather have the lists of groups allowed to access a machine managed from
LDAP, rather than directly coded into sssd.conf, or alternatively, via pam_listfile. Is
there any way of enabling this in the current version of sssd, or emulating it somehow via
ldap_access_filter?

Cheers,
John

[Dmitri Pal]

On 07/07/2014 05:00 AM, John Snowdon wrote:
>  Hi,
>
>  I'm currently working on an sssd configuration to replace a set of legacy
> authentication and authorization mechanisms on several hundred Linux systems in our
> department  - they're currently supported via shared /etc/passwd and /etc/group
> files.
>
>  I've got access, user and group information all working well via pam and sssd and am
> now trying to find a solution to the authorisation requirements. Previously this was
> managed via puppet-distributed changes to /etc/pam.d with a list of users/groups per
> machine stored in the puppet nodes files.
>  I'd like to move to a setup where each machine (or class of machine) just pulls the
> list of allowed unix groups from it's own node in OpenLDAP. 
Have you considered FreeIPA instead of OpenLDAP?
It has a built in host based access control capability and SSSD 
naturally supports it.
With pure LDAP you would have to use ldap access provider and specify a 
filter that matches the DNs you care about. AFAIR OpenLDAP supports 
2307bis that means that there should be a memberOf attribute on the user 
entry (or something similar). This attribute would be a list of the DNs 
the user is a member of. You can use it in the filter.
I know that 389-DS supports it for sure.


>  Is there anything available in sssd.conf that would allow the ldap access provider to
> pull back a list of allowed groups from ldap, rather than listing them explicitly? Sort of
> a hybrid between the simple_allow_groups and ldap_access_filter?
>
>  e.g. What I would love to do
>
>  access_provider = ldap
>  ldap_allow_groups_dn = cn=MachineA,ou=machines,dc=network,dc=com
>
>  Where the cn=MachineA object is a groupOfNames that would look something like:
>
>  objectClass: groupOfNames
>  objectClass: top
>  cn: MachineA
>  description: Posix groups whose users are allowed to access MachineA
>  member: root
>  member: localusers
>  member: adminusers
>  member: webusers
>
>  I'd much rather have the lists of groups allowed to access a machine managed from
> LDAP, rather than directly coded into sssd.conf, or alternatively, via pam_listfile. Is
> there any way of enabling this in the current version of sssd, or emulating it somehow via
> ldap_access_filter?
>
>  Cheers,
>  John
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users 

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

[Jakub Hrozek]

On 07 Jul 2014, at 11:00, John Snowdon <John.Snowdon(a)newcastle.ac.uk&gt; wrote:

>  Hi,
>  
>  I'm currently working on an sssd configuration to replace a set of legacy
> authentication and authorization mechanisms on several hundred Linux systems in our
> department  - they're currently supported via shared /etc/passwd and /etc/group files.
>
>  
>  I've got access, user and group information all working well via pam and sssd and am
> now trying to find a solution to the authorisation requirements. Previously this was
> managed via puppet-distributed changes to /etc/pam.d with a list of users/groups per
> machine stored in the puppet nodes files. 
>  I'd like to move to a setup where each machine (or class of machine) just pulls the
> list of allowed unix groups from it's own node in OpenLDAP.
>  
>  Is there anything available in sssd.conf that would allow the ldap access provider to
> pull back a list of allowed groups from ldap, rather than listing them explicitly? Sort of
> a hybrid between the simple_allow_groups and ldap_access_filter?
>  
>  e.g. What I would love to do
>  
>  access_provider = ldap
>  ldap_allow_groups_dn = cn=MachineA,ou=machines,dc=network,dc=com
>  
>  Where the cn=MachineA object is a groupOfNames that would look something like:
>  
>  objectClass: groupOfNames
>  objectClass: top
>  cn: MachineA
>  description: Posix groups whose users are allowed to access MachineA
>  member: root
>  member: localusers
>  member: adminusers
>  member: webusers
>  
>  I'd much rather have the lists of groups allowed to access a machine managed from
> LDAP, rather than directly coded into sssd.conf, or alternatively, via pam_listfile. Is
> there any way of enabling this in the current version of sssd, or emulating it somehow via
> ldap_access_filter?
>  
>  Cheers,
>  John 
Hi John,

The one-sentence answer is not easily, sorry.

The thing about ldap_access_filter to keep in mind is that the filter is applied on the
/user entry/ when the user logs in. Basically, the ldap_access_filter is AND-ed with a
filter that involves the user entry, if there is a match, the access is allowed, otherwise
the access is denied.

One solution I can think about is to use the memberof overlay with OpenLDAP and then
employ a filter on the client side that would include memberof=allowed_group_dn. But to be
honest, I don’t have too much experience with the memberof overlay, so I’m not sure if
this suggestion would work for nested groups for example.

I hope the explanation on how the ldap_access_filter works is still useful. Please let us
know if you have any more questions!

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/09/2014 05:28 PM, Jakub Hrozek wrote:
>  
>  On 07 Jul 2014, at 11:00, John Snowdon
>  <John.Snowdon(a)newcastle.ac.uk&gt; wrote:
>  
> > Hi,
> > 
> > I'm currently working on an sssd configuration to replace a set
> > of legacy authentication and authorization mechanisms on several 
> > hundred Linux systems in our department  - they're currently 
> > supported via shared /etc/passwd and /etc/group files.
> > 
> > I've got access, user and group information all working well via 
> > pam and sssd and am now trying to find a solution to the 
> > authorisation requirements. Previously this was managed via 
> > puppet-distributed changes to /etc/pam.d with a list of 
> > users/groups per machine stored in the puppet nodes files. I'd
> > like to move to a setup where each machine (or class of machine)
> > just pulls the list of allowed unix groups from it's own node in 
> > OpenLDAP.
> > 
> > Is there anything available in sssd.conf that would allow the
> > ldap access provider to pull back a list of allowed groups from
> > ldap, rather than listing them explicitly? Sort of a hybrid
> > between the simple_allow_groups and ldap_access_filter?
> > 
> > e.g. What I would love to do
> > 
> > access_provider = ldap ldap_allow_groups_dn = 
> > cn=MachineA,ou=machines,dc=network,dc=com
> > 
> > Where the cn=MachineA object is a groupOfNames that would look 
> > something like:
> > 
> > objectClass: groupOfNames objectClass: top cn: MachineA 
> > description: Posix groups whose users are allowed to access 
> > MachineA member: root member: localusers member: adminusers
> > member: webusers
> > 
> > I'd much rather have the lists of groups allowed to access a 
> > machine managed from LDAP, rather than directly coded into 
> > sssd.conf, or alternatively, via pam_listfile. Is there any way
> > of enabling this in the current version of sssd, or emulating it 
> > somehow via ldap_access_filter?
> > 
> > Cheers, John
>  
>  Hi John,
>  
>  The one-sentence answer is not easily, sorry.
>  
>  The thing about ldap_access_filter to keep in mind is that the
>  filter is applied on the /user entry/ when the user logs in.
>  Basically, the ldap_access_filter is AND-ed with a filter that
>  involves the user entry, if there is a match, the access is
>  allowed, otherwise the access is denied.
>  
>  One solution I can think about is to use the memberof overlay with 
>  OpenLDAP and then employ a filter on the client side that would 
>  include memberof=allowed_group_dn. But to be honest, I don’t have
>  too much experience with the memberof overlay, so I’m not sure if
>  this suggestion would work for nested groups for example.
>  
>  I hope the explanation on how the ldap_access_filter works is
>  still useful. Please let us know if you have any more questions! 
I think what John is really asking for is the simple access provider
with one significant enhancement: the ability to specify the contents
of the access-lists in LDAP.

John, this would actually be a rather interesting idea, but I agree
with Dmitri: if this is the level of control that you need, you would
be in a far better position with FreeIPA/Red Hat Identity Management.
It has this concept baked into its Host-Based Access Control mechanism
(which SSSD fully supports). The problem with trying to do this in
plain LDAP is that there exists no standard mechanism for maintaining
this sort of information on the LDAP server (FreeIPA's HBAC rules are
kind of a de-facto standard).
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlO+ffQACgkQeiVVYja6o6MK2ACfaF5IctMKV0k/YpNC+Vhe3NMl
> IToAn3nJNC/36XCl7h7xUe4/jjpF8qsS
> =TPY5
> -----END PGP SIGNATURE-----

[John Hodrien]

On Thu, 10 Jul 2014, Stephen Gallagher wrote:

>  John, this would actually be a rather interesting idea, but I agree
>  with Dmitri: if this is the level of control that you need, you would
>  be in a far better position with FreeIPA/Red Hat Identity Management.
>  It has this concept baked into its Host-Based Access Control mechanism
>  (which SSSD fully supports). The problem with trying to do this in
>  plain LDAP is that there exists no standard mechanism for maintaining
>  this sort of information on the LDAP server (FreeIPA's HBAC rules are
>  kind of a de-facto standard). 
By adding a group to AD per machine with suitable members, and using simple to
restrict access to that group, are you not in the same place, albeit with an
extra object in LDAP?

jh

[Dmitri Pal]

On 07/10/2014 08:11 AM, John Hodrien wrote:
>  On Thu, 10 Jul 2014, Stephen Gallagher wrote:
>
> > John, this would actually be a rather interesting idea, but I agree
> > with Dmitri: if this is the level of control that you need, you would
> > be in a far better position with FreeIPA/Red Hat Identity Management.
> > It has this concept baked into its Host-Based Access Control mechanism
> > (which SSSD fully supports). The problem with trying to do this in
> > plain LDAP is that there exists no standard mechanism for maintaining
> > this sort of information on the LDAP server (FreeIPA's HBAC rules are
> > kind of a de-facto standard).
>
>  By adding a group to AD per machine with suitable members, and using 
>  simple to
>  restrict access to that group, are you not in the same place, albeit 
>  with an
>  extra object in LDAP? 

No. HBAC is much more flexible. At uses groups of systems and groups of 
users so you have to create and maintain much less objects.
But in previous email you said OpenLDAP now you say AD. I am confused.

>  jh
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users 

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

[John Hodrien]

On Thu, 10 Jul 2014, Dmitri Pal wrote:

>  No. HBAC is much more flexible. At uses groups of systems and groups
> of 
>  users so you have to create and maintain much less objects. 
Right yes, that does sound neater, and fewer objects is always good.

>  But in previous email you said OpenLDAP now you say AD. I am
> confused. 
I'm probably not the John you're looking for.  I was just curious.

jh

[Dmitri Pal]

On 07/10/2014 09:35 AM, John Hodrien wrote:
>  On Thu, 10 Jul 2014, Dmitri Pal wrote:
>
> > No. HBAC is much more flexible. At uses groups of systems and groups 
> > of users so you have to create and maintain much less objects.
>
>  Right yes, that does sound neater, and fewer objects is always good.
>
> > But in previous email you said OpenLDAP now you say AD. I am confused.
>
>  I'm probably not the John you're looking for.  I was just curious.
>
>  jh 
Ah, sorry. I did not realize that.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

[Michael Ströder]

Dmitri Pal wrote:
>  Have you considered FreeIPA instead of OpenLDAP?
>  It has a built in host based access control capability and SSSD naturally
>  supports it. 
What exactly is this "host based access control capability"?

>  With pure LDAP you would have to use ldap access provider and specify
> a filter
>  that matches the DNs you care about. AFAIR OpenLDAP supports 2307bis that
>  means that there should be a memberOf attribute on the user entry (or
>  something similar). This attribute would be a list of the DNs the user is a
>  member of. You can use it in the filter.
>  I know that 389-DS supports it for sure. 
I've developed a schema and a bunch of set-based OpenLDAP ACLs which authorize
server groups to only see user accounts and groups and sudoers entries linked
to the server group. Every LDAP client has to really authenticate to the LDAP
server though. With this mech the authorization is implemented by whether a
user entry is visible or not on a host.

BTW: I'd really love to see SASL/EXTERNAL being supported with TLS client
certs. Should be fairly simple since using a TLS client cert is already
implemented.

Ciao, Michael.

[Dmitri Pal]

On 07/10/2014 04:04 PM, Michael Ströder wrote:
>  Dmitri Pal wrote:
> > Have you considered FreeIPA instead of OpenLDAP?
> > It has a built in host based access control capability and SSSD naturally
> > supports it.
>  What exactly is this "host based access control capability"?
>
> > With pure LDAP you would have to use ldap access provider and specify a filter
> > that matches the DNs you care about. AFAIR OpenLDAP supports 2307bis that
> > means that there should be a memberOf attribute on the user entry (or
> > something similar). This attribute would be a list of the DNs the user is a
> > member of. You can use it in the filter.
> > I know that 389-DS supports it for sure.
>  I've developed a schema and a bunch of set-based OpenLDAP ACLs which authorize
>  server groups to only see user accounts and groups and sudoers entries linked
>  to the server group. Every LDAP client has to really authenticate to the LDAP
>  server though. With this mech the authorization is implemented by whether a
>  user entry is visible or not on a host. 
HBAC is very similar to this but already
done for you.
http://www.freeipa.org/docs/master/html-desktop/index.html#configuring-ho...

>  BTW: I'd really love to see SASL/EXTERNAL being supported with TLS client
>  certs. Should be fairly simple since using a TLS client cert is already
>  implemented. 
Are you talking about this?
https://fedorahosted.org/sssd/ticket/561

If you use SSSD with IPA it will use SASL GSSAPI for connection to the 
server.

But we would love this functionality to be implemented too.
Are you interested in contributing this functionality to the project?


>  Ciao, Michael.
>  

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

[Michael Ströder]

Dmitri Pal wrote:
>  On 07/10/2014 04:04 PM, Michael Ströder wrote:
> > Dmitri Pal wrote:
> >> Have you considered FreeIPA instead of OpenLDAP?
> >> It has a built in host based access control capability and SSSD naturally
> >> supports it.
> > What exactly is this "host based access control capability"?
> >
> >> With pure LDAP you would have to use ldap access provider and specify a filter
> >> that matches the DNs you care about. AFAIR OpenLDAP supports 2307bis that
> >> means that there should be a memberOf attribute on the user entry (or
> >> something similar). This attribute would be a list of the DNs the user is a
> >> member of. You can use it in the filter.
> >> I know that 389-DS supports it for sure.
> > I've developed a schema and a bunch of set-based OpenLDAP ACLs which authorize
> > server groups to only see user accounts and groups and sudoers entries linked
> > to the server group. Every LDAP client has to really authenticate to the LDAP
> > server though. With this mech the authorization is implemented by whether a
> > user entry is visible or not on a host.
>
>  HBAC is very similar to this but already done for you.
>  http://www.freeipa.org/docs/master/html-desktop/index.html#configuring-ho...
Does it also disallow LDAP read access to users/groups/sudoers which are not
allowed to login or to be used on a host?

> > BTW: I'd really love to see SASL/EXTERNAL being supported
> with TLS client
> > certs. Should be fairly simple since using a TLS client cert is already
> > implemented.
>  
>  Are you talking about this?
>  https://fedorahosted.org/sssd/ticket/561 
Yes.

>  If you use SSSD with IPA it will use SASL GSSAPI for connection to
> the server. 
Sorry, the systems are already in production and I don't want to use Kerberos
or IPA (although I shortly looked at FreeIPA before). But most of the systems
have puppet with puppet client cert and therefore it would be nice to use
SASL/EXTERNAL.

>  But we would love this functionality to be implemented too.
>  Are you interested in contributing this functionality to the project? 
The main obstacle is that I'm not a C programmer. And also we're using sssd
LTS release 1.9.6.

Ciao, Michael.

[Jakub Hrozek]

On Fri, Jul 11, 2014 at 08:58:10AM +0200, Michael Ströder wrote:
>  > HBAC is very similar to this but already done for you.
>  > http://www.freeipa.org/docs/master/html-desktop/index.html#configuring-ho...
>  
>  Does it also disallow LDAP read access to users/groups/sudoers which are not
>  allowed to login or to be used on a host? 
No, it's pure access control evaluated during the PAM access phase.

[Michael Ströder]

On Fri, 11 Jul 2014 10:45:10 +0200 Jakub Hrozek <jhrozek(a)redhat.com&gt; wrote

>  On Fri, Jul 11, 2014 at 08:58:10AM +0200, Michael Ströder wrote:
>  > > HBAC is very similar to this but already done for you.
>  > >
>  > >
http://www.freeipa.org/docs/master/html-desktop/index.html#configuring-ho...
>  > > ccess > 
>  > Does it also disallow LDAP read access to users/groups/sudoers which are
>  > not allowed to login or to be used on a host?
>  
>  No, it's pure access control evaluated during the PAM access phase. 
This means: If a server gets hacked the attacker can find out more about the
rest of the server infrastructure by queyring FreeIPA's LDAP backend.

Ciao, Michael.

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/11/2014 05:20 AM, Michael Ströder wrote:
>  On Fri, 11 Jul 2014 10:45:10 +0200 Jakub Hrozek
>  <jhrozek(a)redhat.com&gt; wrote
>  
> > On Fri, Jul 11, 2014 at 08:58:10AM +0200, Michael Ströder wrote:
> >>> HBAC is very similar to this but already done for you.
> >>> 
> >>> 
>  http://www.freeipa.org/docs/master/html-desktop/index.html#configuring-ho...
> >>>
>   
ccess >
> >> Does it also disallow LDAP read access to
> users/groups/sudoers
> >> which are not allowed to login or to be used on a host?
> > 
> > No, it's pure access control evaluated during the PAM access
> > phase.
>  
>  This means: If a server gets hacked the attacker can find out more
>  about the rest of the server infrastructure by queyring FreeIPA's
>  LDAP backend.
>   
Client-side restrictions would do nothing to change this. If you want
to restrict what a particular client can see on the LDAP server, you
need to do that on the LDAP server itself.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlO/vaQACgkQeiVVYja6o6PqIACcD24cBYcBOEINRK3outNibexF
> EmYAn3Aoqu/uN1pMFi9TVqzJhJnTogHt
> =bFis
> -----END PGP SIGNATURE-----

[Michael Ströder]

On Fri, 11 Jul 2014 06:34:12 -0400 Stephen Gallagher <sgallagh(a)redhat.com&gt;
wrote
>  On 07/11/2014 05:20 AM, Michael Ströder wrote:
>  > On Fri, 11 Jul 2014 10:45:10 +0200 Jakub Hrozek
>  > <jhrozek(a)redhat.com&gt; wrote
>  > 
>  >> On Fri, Jul 11, 2014 at 08:58:10AM +0200, Michael Ströder wrote:
>  >>>> HBAC is very similar to this but already done for you.
>  >>> Does it also disallow LDAP read access to users/groups/sudoers
>  >>> which are not allowed to login or to be used on a host?
>  >> 
>  >> No, it's pure access control evaluated during the PAM access
>  >> phase.
>  > 
>  > This means: If a server gets hacked the attacker can find out more
>  > about the rest of the server infrastructure by queyring FreeIPA's
>  > LDAP backend.
>  
>  Client-side restrictions would do nothing to change this. 
Yes.

>  If you want
>  to restrict what a particular client can see on the LDAP server, you
>  need to do that on the LDAP server itself. 
That's exactly what I'm doing (as described in my prior posting).

Ciao, Michael.

[Jakub Hrozek]

On Fri, Jul 11, 2014 at 11:20:25AM +0200, Michael Ströder wrote:
>  On Fri, 11 Jul 2014 10:45:10 +0200 Jakub Hrozek
> <jhrozek(a)redhat.com&gt; wrote
>  
>  > On Fri, Jul 11, 2014 at 08:58:10AM +0200, Michael Ströder wrote:
>  > > > HBAC is very similar to this but already done for you.
>  > > >
>  > > >
>  http://www.freeipa.org/docs/master/html-desktop/index.html#configuring-ho...
>  > > > ccess > 
>  > > Does it also disallow LDAP read access to users/groups/sudoers which are
>  > > not allowed to login or to be used on a host?
>  > 
>  > No, it's pure access control evaluated during the PAM access phase.
>  
>  This means: If a server gets hacked the attacker can find out more about the
>  rest of the server infrastructure by queyring FreeIPA's LDAP backend. 
I think this is more generic attack vector than just reading the info
from LDAP. If the attacker gains control over an IPA client, they can
impersonate the host completely, because they have access to the host
keytab..

bottom line -- set up sane ACIs :-)

[Michael Ströder]

On Fri, 11 Jul 2014 14:08:27 +0200 Jakub Hrozek <jhrozek(a)redhat.com&gt; wrote

>  On Fri, Jul 11, 2014 at 11:20:25AM +0200, Michael Ströder wrote:
>  > On Fri, 11 Jul 2014 10:45:10 +0200 Jakub Hrozek <jhrozek(a)redhat.com&gt; wrote
>  > 
>  > > On Fri, Jul 11, 2014 at 08:58:10AM +0200, Michael Ströder wrote:
>  > > > > HBAC is very similar to this but already done for you.
>  > > > >
>  > > > >
>  >
>  > 
http://www.freeipa.org/docs/master/html-desktop/index.html#configuring-ho...
>  > > > > ccess > 
>  > > > Does it also disallow LDAP read access to users/groups/sudoers which
>  > > are > not allowed to login or to be used on a host?
>  > > 
>  > > No, it's pure access control evaluated during the PAM access phase.
>  > 
>  > This means: If a server gets hacked the attacker can find out more about
>  > the rest of the server infrastructure by queyring FreeIPA's LDAP backend.
>  
>  I think this is more generic attack vector than just reading the info
>  from LDAP. If the attacker gains control over an IPA client, they can
>  impersonate the host completely, because they have access to the host
>  keytab..
>  
>  bottom line -- set up sane ACIs :-) 
Yes, my ACLs limit what a server or service can see:
Only the users, groups and sudoers rules it really needs.

Somewhat the "side effect" of this is the authorization who can logon where...
;-)

Ciao, Michael.