On Mon, Feb 10, 2014 at 11:38 AM, Thomas Mortagne <[email protected]> wrote: > On Mon, Feb 10, 2014 at 11:26 AM, Eric Kimn <[email protected]> wrote: >> Hi Thomas, >> >> Thanks for the replies~! Really appreciate it. >> >> To answer your questions: >> >> For the group DN, I was watching the logs, and while yes, I could have put >> the full dn in there, it does a check to see if it can find it with the >> group dn alone and if it can’t find it, it then tries to find it with the >> base dn and then the group dn as a filter. So that’s why I just put the >> cn=mygroup in the group name. > > Yes it's supposed to work (and now it does) but using the full group > DN is simply better for performance since it less LDAP requests. > >> >> My group ldif looks like: >> This is the query i run, it’s the same query xwiki is executing when trying >> to if I’m a member of the group: >> ldapsearch -x -h od.mycompany.com -s sub -b dc=mycompany,dc=com cn=mygroup >> attributes objectClass uid memberUid >> >> # extended LDIF >> # >> # LDAPv3 >> # base <dc=mycompany,dc=com> with scope subtree >> # filter: cn=mygroup >> # requesting: attributes objectClass uid memberUid >> # >> >> # mygroup, groups, mycompany.com >> dn: cn=mygroup,cn=groups,dc=mycompany,dc=com >> objectClass: posixGroup >> objectClass: mycompany-group >> objectClass: extensibleObject >> objectClass: top >> memberUid: member1 >> memberUid: member2 >> memberUid: member3 >> memberUid: member4 >> etc…. >> >> >> Finally, I read the jira bug and I’m not totally sure (from the >> description) if that’s the issue I’m seeing. You said that an LDAP subgroup >> is listed as UID it’s not expanded. But the issue I’m running into isn’t >> related to subgroups, it’s that when there are multiple memberUid’s in the >> group, that logic isn’t adding all of them into the member map object, thus >> it incorrectly determines that a person isn’t in a group, if they’re not the >> first in the list. Please correct me if I’m seeing it wrong. > > Actually it is :) > > As I told you in my previous mail "cn=mygroup" does not means your > group, your group is a subgroup of what we call a group in XWiki which > mean either a group DN, a filter or an organization usint. In you case
s/usint/unit/ > the group "cn=mygroup" has a member called > "cn=mygroup,cn=groups,dc=mycompany,dc=com" which was not expanded. > >> >> And doubly finally, if I’m wrong and the issue is fixed (which would >> awesome), when can I get the fix? It’s really holding up using xwiki on a >> broader scale because I can’t get it integrated with our LDAP. > > Again you should be fine with full group DN, did you tested with it ? > 4.5.1 release is planned tomorrow. > >> >> >> >> Best, >> >> >> Eric Kyungsuk Kimn >> 김경석 >> Senior Back End Developer >> [email protected] >> >> >> >> >> >> >> >> On Feb 10, 2014, at 2:04 AM, Thomas Mortagne <[email protected]> >> wrote: >> >>> Created and fixed http://jira.xwiki.org/browse/XWIKI-10031. Thanks for >>> the report ! >>> >>> On Mon, Feb 10, 2014 at 10:18 AM, Thomas Mortagne >>> <[email protected]> wrote: >>>> Hmm actually could be something else. >>>> >>>> How does your group ldiff looks like ? Looks like there is a bug with >>>> subgroups containing uids instead of complete DNs. >>>> >>>> On Mon, Feb 10, 2014 at 9:47 AM, Thomas Mortagne >>>> <[email protected]> wrote: >>>>> From what I understand from you use case you should not put >>>>> "cn=mygroup" but your complete group DN >>>>> ("cn=mygroup,cn=groups,dc=mycompany,dc=com=member1"). "cn=mygroup" >>>>> does not really mean that group but "everything that matches >>>>> "cn=mygroup"" (which is why it list you the group as found member by >>>>> the way). There is still a bug in the fact that it seems to not expand >>>>> the found groups to find submembers when using partial DN but if you >>>>> use complete DN in the configuration you should be fine. >>>>> >>>>> I will try to reproduce and debug the partial DN use case. Thanks for >>>>> the report. >>>>> >>>>> On Sun, Feb 9, 2014 at 3:16 AM, Eric Kimn <[email protected]> wrote: >>>>>> Hey all, >>>>>> >>>>>> I managed to view the code for this class by a google search. But i’m >>>>>> noticing a problem with the getGroupMembers logic and I’m experiencing >>>>>> it myself in my 5.4 install of xwiki. >>>>>> Some background: I am using Apple’s open directory as my ldap server. >>>>>> My ldap config is as such (using the LDAP application): >>>>>> >>>>>> Restrict to group: >>>>>> cn=mygroup >>>>>> >>>>>> LDAP base dn: >>>>>> dc=mycompany,dc=com >>>>>> >>>>>> LDAP UID Attribute name >>>>>> memberUid >>>>>> >>>>>> >>>>>> The symptom: When XWiki tries to locate the members of a group, it finds >>>>>> only one, typically the alphabetically first one, and not all. >>>>>> >>>>>> The source of the problem: >>>>>> The entry point is here: >>>>>> public Map<String, String> getGroupMembers(String groupDN, XWikiContext >>>>>> context) >>>>>> >>>>>> which calls with a new map of <String, String> for members, this line -> >>>>>> boolean isGroup = getGroupMembers(groupDN, members, new >>>>>> ArrayList<String>(), context); >>>>>> >>>>>> That method has this signature -> >>>>>> public boolean getGroupMembers(String groupDN, Map<String, String> >>>>>> memberMap, List<String> subgroups, XWikiContext context) >>>>>> >>>>>> which falls to >>>>>> if (searchAttributeList != null) { >>>>>> isGroup = getGroupMembers(fixedDN, memberMap, subgroups, >>>>>> searchAttributeList, context); >>>>>> } >>>>>> >>>>>> But of course there are search attributes, so it calls this-> >>>>>> public boolean getGroupMembers(String groupDN, Map<String, String> >>>>>> memberMap, List<String> subgroups, List<XWikiLDAPSearchAttribute> >>>>>> searchAttributeList, XWikiContext context) >>>>>> >>>>>> And this is where the problem is: >>>>>> It for loops through the search attributes and executes a query, if it >>>>>> gets a response that isn’t a group and the member map doesn’t already >>>>>> contain that key, it will add it: >>>>>> if (!memberMap.containsKey(groupDN)) { >>>>>> memberMap.put(groupDN.toLowerCase(), id == null ? "" : >>>>>> id.toLowerCase()); >>>>>> } >>>>>> >>>>>> But then it RETURNS isGroup, which is now true, >>>>>> And that flows back up the chain, except it never iterates through the >>>>>> rest of the entries. >>>>>> >>>>>> My logs show: >>>>>> 2014-02-08 17:45:22,858 >>>>>> [http://myserver/xwiki/bin/loginsubmit/XWiki/XWikiLogin] DEBUG >>>>>> c.x.x.p.l.XWikiLDAPUtils - Looks like [cn=mygroup] is not a DN, >>>>>> lets try filter or id >>>>>> 2014-02-08 17:45:22,858 >>>>>> [http://myserver/xwiki/bin/loginsubmit/XWiki/XWikiLogin] DEBUG >>>>>> c.x.x.p.l.XWikiLDAPConnection - LDAP search: >>>>>> baseDN=[dc=mycompany,dc=com] query=[cn=mygroup] attr=[[objectClass, uid, >>>>>> memberuid, memberUid]] ldapScope=[2] >>>>>> 2014-02-08 17:45:22,864 >>>>>> [http://myserver/xwiki/bin/loginsubmit/XWiki/XWikiLogin] DEBUG >>>>>> c.x.x.p.l.XWikiLDAPUtils - Found group [cn=mygroup] members >>>>>> [{cn=mygroup,cn=groups,dc=mycompany,dc=com=member1}] >>>>>> 2014-02-08 17:45:22,864 >>>>>> [http://myserver/xwiki/bin/loginsubmit/XWiki/XWikiLogin] DEBUG >>>>>> c.x.x.p.l.XWikiLDAPUtils - Found user dn in user group [null] >>>>>> 2014-02-08 17:45:22,865 >>>>>> [http://myserver/xwiki/bin/loginsubmit/XWiki/XWikiLogin] DEBUG >>>>>> u.i.L.XWikiLDAPAuthServiceImpl - Local LDAP authentication failed. >>>>>> com.xpn.xwiki.XWikiException: Error number 8001 in 8: LDAP user member2 >>>>>> does not belong to LDAP group cn=mygroup. >>>>>> >>>>>> >>>>>> Am I reading the logs or code wrong? If I am, then what am I doing >>>>>> wrong with my ldap configuration? I’m clearly part of mygroup but it >>>>>> consistently fails to find me. >>>>>> >>>>>> Best, >>>>>> >>>>>> >>>>>> Eric Kyungsuk Kimn >>>>>> 김경석 >>>>>> Senior Back End Developer >>>>>> [email protected] >>>>>> _______________________________________________ >>>>>> devs mailing list >>>>>> [email protected] >>>>>> http://lists.xwiki.org/mailman/listinfo/devs >>>>> >>>>> >>>>> >>>>> -- >>>>> Thomas Mortagne >>>> >>>> >>>> >>>> -- >>>> Thomas Mortagne >>> >>> >>> >>> -- >>> Thomas Mortagne >>> _______________________________________________ >>> devs mailing list >>> [email protected] >>> http://lists.xwiki.org/mailman/listinfo/devs >> >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs > > > > -- > Thomas Mortagne -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
