Item5303: LdapContrib for TWiki-4.2

-- MichaelDaum - 30 Jan 2008

Should have put my comments from LdapContribDev here:

-- BryanEllsaesser - 07 Feb 2008

I can confirm a variation on Kevin's issue as well with 2.99.3. I am using LdapContrib with LdapNGPlugin and NewUserPlugin. Everything works great, my new user topics are autocreated on first login by Windows AD users. I can even set the TWikiAdminGroup GROUP= to include a user. I think because the topic exists, the TWikiGroups topic shows the membership as set, but the actual membership is not applied. When logged in as a user in TWikiAdminGroup, I don't have change priviledges for a web eventhough Preferences has this group set to Allow Changes.

-- BryanEllsaesser - 06 Feb 2008

As a follow up to my earlier post: If in TWikiAdminGroup, I

   * Set GROUP = Main.BryanEllsaesser 

Because BryanEllsaesser exists in Main, it shows up in the TWikiGroups summary topic for the TWikiAdminGroup. But BryanEllsaesser does not have modification access despite group membership. If I add my loginid (ellsabr1) to the group

   * Set GROUP=Main.BryanEllsaesser, ellsabr1

Then everything works great, except of course TWikiGroups lists BryanEllsaesser twice!.

-- BryanEllsaesser - 06 Feb 2008

-- BryanEllsaesser - 07 Feb 2008

I debugged this problem further: TWiki 4.2.0 internally does all access checks with username, not wikiname (if both are different) TWiki::Access::checkAccessPermission uses TWiki::User::isInList to check for a username in the lists for allow or deny of different actions. Groupnames should be expanded to lists ot usernames. This is correct for a "standard" (non-SSO) setup with TWikiUserMapping and without LdapUserMapping. It is also correct when using LdapUserMapping, as long as ldap groups are concerned. But with

  $TWiki::cfg{Ldap}{TWikiGroupsBackoff} = 1;

TWiki::Users::LdapUserMapping::eachGroupMember falls back to TWiki::Users::TWikiUserMapping::eachGroupMember, when the group does not exist inside ldap. In this case TWikiUserMapping knows nothing about the ldap based usernames, so a group like TWikiAdminGroup is expanded only to wikinames not usernames. Therefore the username can not be identified to be an admin.

If my analysis is correct, another workaround for this problem would be: Manually define a "wikiname - username" entry inside Main.TWikiUsers for every member of a "backoff" TWikiGroup. Normally thís is without any function when using TWiki::Users::LdapUserMapping. But now TWiki::Users::TWikiUserMapping::eachGroupMember has knowledge of the relevant wikiname to username transformation. And the checkAccessPermission now can successfully compare the membership of the current user inside non-ldap groups.

-- MarkusSchuh - 20 Feb 2008

I can confirm this bug on TWiki 4.2.0 and LdapContrib 2.99.4 where wikinames do not work with group assignments, but usernames do. User SimonHarrison submitted a patch to Users.pm on 22 Apr 2008 in the comments section of LdapContribDev. In said patch, he seems to have changed $user to $wn on line 543 of Users.pm in his TWiki installation. As he mentions, I'm not sure what the ramifications of such a global change are, but maybe it will give MichaelDaum some ideas or otherwise escalate this to a general TWiki 4.2.0 bug.

-- KavehAhmadian - 26 Apr 2008