[SSSD-users] Re: ad_access_filter question

[Conwell, Nik]

On 11/24/17, 8:22 AM, "Jakub Hrozek"  wrote:

>On Fri, Nov 24, 2017 at 10:02:15AM +, 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-le...@lists.fedorahosted.org


___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: ad_access_filter question

[Jakub Hrozek]

On Fri, Nov 24, 2017 at 10:02:15AM +, 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.
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: ad_access_filter question

[Conwell, Nik]

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:jhro...@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 +, 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-le...@lists.fedorahosted.org
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

[SSSD-users] Re: ad_access_filter question

[Jakub Hrozek]

On Wed, Nov 22, 2017 at 07:56:57PM +, 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 (=…) 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?
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org