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
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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
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.
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-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
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.
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-host-...
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.
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-host-...
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.
On Fri, 11 Jul 2014 10:45:10 +0200 Jakub Hrozek jhrozek@redhat.com 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-host-...
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.
-----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@redhat.com 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-host-...
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.
On Fri, 11 Jul 2014 06:34:12 -0400 Stephen Gallagher sgallagh@redhat.com wrote
On 07/11/2014 05:20 AM, Michael Ströder wrote:
On Fri, 11 Jul 2014 10:45:10 +0200 Jakub Hrozek jhrozek@redhat.com 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.
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@redhat.com 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-host-...
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 :-)
On Fri, 11 Jul 2014 14:08:27 +0200 Jakub Hrozek jhrozek@redhat.com 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@redhat.com 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-host-...
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.
On 07 Jul 2014, at 11:00, John Snowdon John.Snowdon@newcastle.ac.uk 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!
-----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@newcastle.ac.uk 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).
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
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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
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
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.
sssd-users@lists.fedorahosted.org
-
Dmitri Pal -
Jakub Hrozek -
John Hodrien -
John Snowdon -
Michael Ströder -
Stephen Gallagher