ad_access_filter question

[Conwell, Nik]

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
[e-mail]<mailto:[e-mail]>

[Jakub Hrozek]

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?

[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:[e-mail]] 
Sent: Thursday, November 23, 2017 2:47 PM
To: sssd-users(a)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(a)lists.fedorahosted.org To unsubscribe send an email
to sssd-users-leave(a)lists.fedorahosted.org

[Jakub Hrozek]

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.

[Conwell, Nik]

On 11/24/17, 8:22 AM, "Jakub Hrozek" <jhrozek(a)redhat.com&gt; 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(a)lists.fedorahosted.org
    To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org