Ok, Cool. So, I stopped sssd, removed the cachefile for my domain, started it with logging to file. Since I'm not comfortable with exposing our whole ad to the internet I pasted a snippet out of the logfile, please tell me if you need anything more.
But the behavior is the same, here is an example, I have a group called aapp, ldapsearch 'ou=Groups,dc=xx,dc=xx,dc=xx' "(&(objectclass=*)(cn=aapp))" returns, ------ member: CN=xxxx,OU=People,DC=xx,DC=xx,DC=xx member: CN=xxxx,OU=People,DC=xx,DC=xx,DC=xx member: CN=xxxx,OU=People,DC=xx,DC=xx,DC=xx memberUid: xxxx memberUid: xxxx memberUid: xxxx memberUid: xxxx memberUid: xxxx memberUid: a000590 ------ ldapsearch 'ou=People,dc=xx,dc=xx,dc=xx' "(&(objectclass=*)(cn=a000590))" | grep -i memberof returns a list of groups, however _not_ aapp. So, the "groupobject" lists a000590 as a memberUid, but the "userobject" dosn't list aapp as a memberOf. First of all, is that right ? Here's sssd log snippets, (tell me if you need anything else). (Fri Dec 10 16:38:12 2010) [sssd[be[xx]]] [sdap_parse_entry] (9): OriginalDN: [CN=aapp,OU=Groups,DC=xx,DC=xx,DC=xx]. (Fri Dec 10 16:38:12 2010) [sssd[be[xx]]] [sdap_process_result] (8): Trace: sh[0xae77a0], connected[1], ops[0xae80f0], ldap[0xae79c0] (Fri Dec 10 16:38:22 2010) [sssd[be[xx]]] [sdap_save_group_send] (7): Adding original DN [CN=aapp,OU=Groups,DC=xx,DC=xx,DC=xx] to attributes of [aapp]. (Fri Dec 10 16:38:22 2010) [sssd[be[xx]]] [sdap_save_group_send] (6): Storing info for group aapp (Fri Dec 10 16:38:22 2010) [sssd[be[xx]]] [sysdb_search_entry_done] (6): Error: Entry not Found! (Fri Dec 10 16:38:22 2010) [sssd[be[xx]]] [sysdb_search_entry_done] (6): Error: Entry not Found! (Fri Dec 10 16:38:22 2010) [sssd[be[xx]]] [sdap_save_groups_loop] (9): Group 592 processed! (Fri Dec 10 16:39:05 2010) [sssd[be[xx]]] [sdap_save_grpmem_send] (7): Adding member users to group [aapp] (Fri Dec 10 16:39:05 2010) [sssd[be[xx]]] [sdap_fill_memberships] (9): [IPA or AD Schema] (Fri Dec 10 16:39:05 2010) [sssd[be[xx]]] [sdap_fill_memberships] (7): member #0 (CN=xx,OU=People,DC=ad,DC=smhi,DC=se): [name=xx,cn=users,cn=xx,cn=sysdb] (Fri Dec 10 16:39:05 2010) [sssd[be[xx]]] [sdap_fill_memberships] (7): member #1 (CN=xx,OU=People,DC=ad,DC=smhi,DC=se): [name=xx,cn=users,cn=xx,cn=sysdb] (Fri Dec 10 16:39:05 2010) [sssd[be[xx]]] [sdap_fill_memberships] (7): member #2 (CN=xx,OU=People,DC=ad,DC=smhi,DC=se): [name=xx,cn=users,cn=xx,cn=sysdb] (Fri Dec 10 16:39:05 2010) [sssd[be[xx]]] [sdap_save_grpmem_send] (6): Storing members for group aapp The users beeing added to the group aapp here in the log have both 'member' and 'memberUid' attributes, does that makes sence ? Best regards, Patrik Martinsson, Sweden. On 12/10/2010 04:11 PM, Sumit Bose wrote: > On Fri, Dec 10, 2010 at 03:58:08PM +0100, Patrik Martinsson wrote: >> Hey again, >> >> Thanks for answering so quick! >> >> Ok. So I asked our Windowsdepartment what kind of RFC we are using today >> and got the answer "Don't know if we satisfy any RFC today, the base is >> AD4Unix.". I don't really know what to make of that, however I do know >> that i want sssd to base groupmembership on memberUid, and therefore i >> should use "ldap_schema = rfc2307". So that's what I did and here is the >> what i got. >> >> I do an ldapsearch on a fubar-group and i see that >> memberuid: foo >> >> I do a getent group fubar and i get a list of users in that group, >> however not the user foo. >> So why is it that foo user is shown in the ldapsearch but not in sssd ? >> Actually the only users sssd is showing is the ones having 'member' >> attributes, not the memberUid users. >> Is it being cached in some way ? I do restart sssd after each >> configuration change. > Yes, there is a cache. You can try to remove > '/var/lib/sss/db/cache_*.ldb' and start sssd again. > >> How can i debug this more ? I would really like to get this working. > You can start sssd with the option '-d 9' to get full debug output and > '-f' to write everything to log files in /var/log/sss/. > > bye, > Sumit > >> Thanks in advance, >> Patrik Martinsson, Sweden. >> >> >> >> >> >> On 12/10/2010 12:55 PM, Stephen Gallagher wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>> On 12/10/2010 06:32 AM, Patrik Martinsson wrote: >>>> Hello, >>>> >>>> I've almost managed to get sssd to work as I want, however I have this >>>> problems with groupmembers. >>>> >>>> If I do an ldapsearch on a group I get this result, >>>> >>>> --------- >>>> member: CN=x1,OU=People,DC=x,DC=x,DC=x >>>> member: CN=x2,OU=People2,OU=People,DC=x,DC=x,DC=x >>>> member: CN=x3,OU=People,DC=x,DC=x,DC=x >>>> member: CN=x4,OU=People,DC=x,DC=x,DC=x >>>> member: CN=x5,OU=People,DC=x,DC=x,DC=x >>>> >>>> memberUid: x1 >>>> memberUid: x2 >>>> memberUid: x5 >>>> memberUid: x7 >>>> memberUid: x8 >>>> memberUid: x9 >>>> --------- >>>> >>>> A college told me that the difference (between members in 'member' and >>>> 'memberUid') is because 'member' is the attribute set up for windows >>>> accounts, and 'memberUid' is for the unixaccounts, and although these >>>> often should be synced it could be some cases where its not (in our >>>> setup anyway). >>>> >>>> So what I want is getting sssd to map groupmembers to the memberUid. >>>> >>>> Here's a snippet from my sssd.conf >>>> >>>> --------- >>>> ldap_user_object_class = User >>>> ldap_user_name = sAMAccountName >>>> ldap_user_uid_number = uidNumber >>>> ldap_user_gid_number = gidNumber >>>> ldap_user_shell = loginShell >>>> ldap_user_gecos = mail >>>> ldap_user_principal = userPrincipalName >>>> ldap_user_member_of = memberOf >>>> ldap_user_home_directory = msSFUHomeDirectory >>>> >>>> ldap_group_object_class = Group >>>> ldap_group_name = cn >>>> ldap_group_gid_number = gidNumber >>>> ldap_group_member = memberuid >>>> # ldap_group_member = member >>>> # ldap_group_member = memberUid >>>> # ldap_group_uuid = memberUid >>> UUID != UID. Don't assign these to the same attribute. >>> >>>> --------- >>>> >>>> I've tried different setups here but I cant really seem to figure it >>>> out. If I run with the above settings i get no groups for users, and the >>>> following is printed in sssd debug, >>>> --------- >>>> [sysdb_search_entry_done] (6) Error : Entry not found! >>>> [sdap_fill_memberships] (7) member #60 (x): not found! >>>> --------- >>>> >>>> If I use the member instead of memberuid/Uid the users are mapped to >>>> groups from the 'member' attribute, which seems logical, however that's >>>> not what I want, as I said before, I want to map usergroups against the >>>> memberUid. >>>> >>> When using >>> ldap_schema = rfc2307 >>> which is the default if it's unspecified, the default for >>> ldap_group_member = memberUid >>> This is because RFC 2307 requires that members be a list of group names. >>> >>> If you use ldap_schema = rfc2307bis, this changes group membership >>> lookups to use the DN format and the 'member' attribute, because RFC >>> 2307bis (the standard ActiveDirectory normally uses) requires that >>> members be specified as DN entries in the LDAP server. >>> >>> The only differences between the RFC 2307 and RFC2307bis format is >>> whether groups are looked up by 'memberuid' or 'member' attributes, >>> respectively. So if you want to use 'memberuid', just set 'ldap_schema = >>> rfc2307' >>> >>> See also https://fedorahosted.org/sssd/ticket/445 for our future plans >>> to support a hybrid mode that can read both attributes. >>> >>> - -- >>> Stephen Gallagher >>> RHCE 804006346421761 >>> >>> Delivering value year after year. >>> Red Hat ranks #1 in value among software vendors. >>> http://www.redhat.com/promo/vendor/ >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v1.4.11 (GNU/Linux) >>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ >>> >>> iEYEARECAAYFAk0CFSYACgkQeiVVYja6o6NVkQCgkX7dnPre9xQm5CTFWO5kbi0P >>> 2qsAoJirCpSXuaOycNNB8Q/trx1F90Sc >>> =FJas >>> -----END PGP SIGNATURE----- >>> _______________________________________________ >>> sssd-devel mailing list >>> [email protected] >>> https://fedorahosted.org/mailman/listinfo/sssd-devel >> _______________________________________________ >> sssd-devel mailing list >> [email protected] >> https://fedorahosted.org/mailman/listinfo/sssd-devel > _______________________________________________ > sssd-devel mailing list > [email protected] > https://fedorahosted.org/mailman/listinfo/sssd-devel _______________________________________________ sssd-devel mailing list [email protected] https://fedorahosted.org/mailman/listinfo/sssd-devel
