Hi all, I'm jumping in to using sssd-ad here at BU. I'm able to domain join a CentOS7 and pull our AD entries successfully but am having troubles with ad_access_filter to restrict access to a group.
Due to FERPA restrictions here, we can't query memberOf for random people via a machine account, so things like:
ad_access_filter = (memberOf=CN=group-of-admins,OU=XYZ,DC=blah,DC=blah,DC=blah)
won't work. I see from debug level 7 that this translates into a query like:
(&(sAMAccountName=nik)(objectclass=user)(memberOf=CN=group-of-admins,OU=Groups,OU=XYZ,DC=blah,DC=blah,DC=blah))
I've verified independently with ldapsearch that if I do this under the machine account, I don't get anything back. Note that if this query was done in the context of the user just logging in ("nik") then it would work since I have the privs to see my own memberOf. But, I think (I guess) that the query is being done by SSSD-AD as the machine account.
I've also played around with doing a filter like "(&(objectCategory=group)(CN=group-of-admins))" which does actually return a list of "member:" entries for an ldapsearch when using the machine account privs. However, if I plug this into ad_access_filter, it's not allowing access I think because of the (&sAMAccountName=…) being a query of a user object whereas the group query is a group object and the filter isn't being satisfied. From looking at the code I think it's not designed to handle being returned an object which has a list of "member:" entries and looking for the user in that list. SMOP I guess :)
So, misc blathering aside, does anybody have any suggestions on how I should go about restricting access to groups in cases where machine accounts aren't allowed access to the memberOf information for users? Is there a way to get it via a group filter, or should/could the memberOf query be done under the context and privs of the user accessing it? (I guess that would have implications on caching though…)
Any ideas or suggestions which direction I should go with this? Thanks in advance.
Nik Conwell Boston University nik@bu.edumailto:nik@bu.edu
On Wed, Nov 22, 2017 at 07:56:57PM +0000, Conwell, Nik wrote:
Hi all, I'm jumping in to using sssd-ad here at BU. I'm able to domain join a CentOS7 and pull our AD entries successfully but am having troubles with ad_access_filter to restrict access to a group.
Due to FERPA restrictions here, we can't query memberOf for random people via a machine account, so things like:
ad_access_filter = (memberOf=CN=group-of-admins,OU=XYZ,DC=blah,DC=blah,DC=blah)
won't work. I see from debug level 7 that this translates into a query like:
(&(sAMAccountName=nik)(objectclass=user)(memberOf=CN=group-of-admins,OU=Groups,OU=XYZ,DC=blah,DC=blah,DC=blah))
I've verified independently with ldapsearch that if I do this under the machine account, I don't get anything back. Note that if this query was done in the context of the user just logging in ("nik") then it would work since I have the privs to see my own memberOf. But, I think (I guess) that the query is being done by SSSD-AD as the machine account.
I've also played around with doing a filter like "(&(objectCategory=group)(CN=group-of-admins))" which does actually return a list of "member:" entries for an ldapsearch when using the machine account privs. However, if I plug this into ad_access_filter, it's not allowing access I think because of the (&sAMAccountName=…) being a query of a user object whereas the group query is a group object and the filter isn't being satisfied. From looking at the code I think it's not designed to handle being returned an object which has a list of "member:" entries and looking for the user in that list. SMOP I guess :)
So, misc blathering aside, does anybody have any suggestions on how I should go about restricting access to groups in cases where machine accounts aren't allowed access to the memberOf information for users? Is there a way to get it via a group filter, or should/could the memberOf query be done under the context and privs of the user accessing it? (I guess that would have implications on caching though…)
Would: access_provider = simple simple_allow_groups = group-of-admins do the trick for you?
Interesting, thanks. I had tried the simple provider but this didn't restrict access. Since the docs noted that it didn't honor the "expired" expired attribute I didn't look into it any closer. I'll try this again and look through debug logs to see where it broke down; potentially my groups aren't being resolved yet. Are you saying that the simple provider iterates group membership, which in turn SSSD-LDAP should be returning?
-nik
-----Original Message----- From: Jakub Hrozek [mailto:jhrozek@redhat.com] Sent: Thursday, November 23, 2017 2:47 PM To: sssd-users@lists.fedorahosted.org Subject: [SSSD-users] Re: ad_access_filter question
On Wed, Nov 22, 2017 at 07:56:57PM +0000, Conwell, Nik wrote:
Hi all, I'm jumping in to using sssd-ad here at BU. I'm able to domain join a CentOS7 and pull our AD entries successfully but am having troubles with ad_access_filter to restrict access to a group.
Due to FERPA restrictions here, we can't query memberOf for random people via a machine account, so things like:
ad_access_filter = (memberOf=CN=group-of-admins,OU=XYZ,DC=blah,DC=blah,DC=blah)
won't work. I see from debug level 7 that this translates into a query like:
[snip]
Would: access_provider = simple simple_allow_groups = group-of-admins do the trick for you? _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Fri, Nov 24, 2017 at 10:02:15AM +0000, Conwell, Nik wrote:
Interesting, thanks. I had tried the simple provider but this didn't restrict access.
Did you look into the logs why it didn't? Did you use a group that showed up in the group list of the "id" command?
Since the docs noted that it didn't honor the "expired" expired attribute I didn't look into it any closer.
Yes, this is unfortunately true. We have a long-standing RFE to allow "chaining" of the access providers, but it's not implemented yet.
I'll try this again and look through debug logs to see where it broke down; potentially my groups aren't being resolved yet. Are you saying that the simple provider iterates group membership, which in turn SSSD-LDAP should be returning?
The simple access provider looks at user entry itself and their groups in the sssd cache - unlike the access filter, which is applied against the entry in the LDAP server.
So yes, SSSD first resolves the groups during the initgroups operation and then runs the simple access check on the result.
On 11/24/17, 8:22 AM, "Jakub Hrozek" jhrozek@redhat.com wrote:
On Fri, Nov 24, 2017 at 10:02:15AM +0000, Conwell, Nik wrote:
The simple access provider looks at user entry itself and their groups in the sssd cache - unlike the access filter, which is applied against the entry in the LDAP server.
So yes, SSSD first resolves the groups during the initgroups operation and then runs the simple access check on the result.
Hi, sorry for the radio silence on this. I took a look at groups available and picked one appropriate for membership and using the simple_allow_groups restricts/enables access as desired. Success!
I've also discovered that even though we restrict access to memberOf, there are other fields in AD that are visible for the access filter, so I can do things like:
ad_access_filter = (|(department=IT)(manager=CN=myboss,OU=People,DC=blah,DC=blah,DC=com))
to allow access to a department or people who are in my immediate group.
Thanks very much for your help Jakub!
-nik
_______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users@lists.fedorahosted.org
-
Conwell, Nik -
Jakub Hrozek