[SSSD-users] Re: ad_access_filter question

2017-11-23 Thread 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


[SSSD-users] Re: group naming help

2017-11-23 Thread Jakub Hrozek
On Mon, Nov 20, 2017 at 09:29:06AM -0700, Zane Zakraisek wrote:
> Hi, I'm looking at migrating my Red Hat 7.4 machines off nslcd and onto
> sssd.
> 
> I've got a very simple sssd.conf here running SSSD 1.15.2.
> 
> [sssd]
> domains = my.domain
> config_file_version = 2
> services = nss, pam
> 
> [domain/my.domain]
> ad_domain = my.domain
> krb5_realm = MY.DOMAIN
> realmd_tags = manages-system joined-with-samba
> cache_credentials = False
> id_provider = ad
> krb5_store_password_if_offline = false
> ldap_id_mapping = false
> access_provider = ad
> #enumerate = true
> 
> A lot of my groups have a samAccountName that differs from their cn.
> I've noticed that I can't seem to get consistent group names.
> When running 'ls -l', it seems like some files show the samAccountName
> of the group, others show the cn of the group.
> 
> Running 'groups' or 'id $USER' always shows the samAccountName.
> 
> Is there a way that I can get SSSD to do everything by the cn of the
> group?

ldap_group_name = cn

but it's strange that you sometimes see different names, is the
samaccountname attribute maybe multi-valued by any chance?
___
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org