ldap2Add my vote for this tag create new tag
, view all tags

LdapContribDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on LdapContrib contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please file bug reports in the LdapContrib bug database.

Discussion forum for the LdapContrib

NOTE: Please use Bugs:LdapContrib to report bugs. Thanks.

-- MichaelDaum - 19 Jul 2006

Thank you very much for sharing this contrib with the TWikiCommunity! Many people have been asking for this functionality. Perfect fit to the TWikiMission!

-- PeterThoeny - 19 Jul 2006

I tagged the LdapContrib topic. Help on tag votes to make this contrib show up early in the tag search.

-- PeterThoeny - 19 Jul 2006

I configured LdapContrib, and it works fine, I can login successfully with my LDAP accounts.

Is it possible to use both LDAP and the TWiki .htpasswd validation? This way we could use our LDAP accounts and have external people register themselves (basically TWikiGroupsBackoff, but for users ...)?

(I did not try the groups yet - have to talk with our LDAP people about some necessary changes first ...)

Thanks for your great work!

I can't imagine how one can do both ldap and htpasswd based authentication. In general this fails because the LoginManager configuration has to be set to do either one or the other. But I see the usefulness of that in your case. The idea of a TWikiUsersBackOff is good! to fall back to a secondary authentication mechanism.

-- MichaelDaum - 02 Aug 2006

-- MichaelRedinger - 20 Jul 2006

I've installed the LdapContrib with the idea of using this to determine if a user can edit a page or not (even something as simple as adding a comment with the comment plugin). I am working to avoid any registration on Twiki to gain access, just use Ldap. I have no problem authenticating, but authorizing is a different story. Anyhow, what I have not been able to figure out is HOW to use the LdapContrib other than configure the parameters. Is it something we can actually write code to use the plugin? How? Thanks.

-- ChristineHowell - 02 Aug 2006

Hi Christine, I am not sure what your question is. Have a look at TWikiAccessControl to get an idea how to configure TWiki's different authorization schemes.

-- MichaelDaum - 02 Aug 2006

Michael, I understand how TWiki's Access control works, MANUALLY. I'd like to be able to have certain users have access to edit certain topics based on their ldap group. We do not wish to have them go through the twiki registration process. And it'd be nice to be able to map ldap groups to TwikiGroups (how?). I can't tell from any of the documentation if that's even possible. It seems like it is possible, but then I see something elsewhere that says no. I'm struggling to understand and figure out how, when, where to write/add anything of my own in TWiki to manage access without registration. Does this help clarify my question?

-- ChristineHowell - 02 Aug 2006

Ah, now I see. The answer is yes. The LdapContrib allows you to map groups defined in your directory onto TWiki groups. See the LdapContrib#User_Groups docu. Add $TWiki::cfg{UserMappingManager} = 'TWiki::Users::LdapUserMapping'; to your LocalSite.cfg and have a look at the relevant options at LdapContrib#Advanced_Settings .

Once you've configured that you can manage group membership using LDAP tools. Nevertheless, assigning the ACLs to webs and topics is still done by adding your LDAP users and groups to the web/topic settings the TWiki way, that is the ACLs themselves are still stored in topics.

-- MichaelDaum - 02 Aug 2006

Thank you. A couple more questions...I assume that I will have to upgrade to 4.0.3 in order to utilize the group mapping feature. Is that correct? By convention, Twiki Groups are WikiWords...how do the LDAP user groups (names) fit in with that? Do I use LDAP group names for TwikiGroup names? Our Ldap groupnames are all lowercase.

-- ChristineHowell - 03 Aug 2006

Yes, the group mapping feature has just been recently added. Best is to grab the most recent stable release. Wrt group names: there's no problem if they are not a WikiWord. They are taken as they are.

-- MichaelDaum - 03 Aug 2006

Ok...my difficulty in following this is this: There's the ldap for authentication, there's the ACL for authorization, HOW are they TIED together? Do we still have to have users register? This is the very thing we are trying to avoid. So, essentially, do I still need to come up with a script or something that registers users the first time they login? Sure they can login via ldap and look around but they cannot edit unless they are twiki users and in twiki groups. I still don't see how ldap groups tie in with twiki groups. For example, I have an ldap group cn=dev_team, the twikigroup is DevGroup. How are these related? Or am I barking up the wrong tree here?

-- ChristineHowell - 03 Aug 2006

It is a great addon and I'm nearly there. I get groups listed and I registered my user and was logged in. All ok, so I started to test with access control with the ldap groups. We run Novell edir 8.7. I never found out more because now when I click on "log in" nothing happens, and I cannot edit topics unless login manager is set to none. Could need a more detailed example of the setup regarding apache2 also.

-- LarsEik - 16 Aug 2006

One question: What is the LoginFilter for?? I configured the LoginFilter : (&(objectClass=*)(employeeType=XY)) but this has no effect. LdapContrib grants access for all users stored in ldap (if they can bind) but i want grant access only to users who are of employeeType XY. What must i do??

-- AndreasNigl - 17 Aug 2006

Hello, I'm working on tying TWiki-4.0.4+LdapContrib with our Win2003 AD. I got a some of those (Hmmm?) questions :

1. In bin/configure, when {PasswordManager}=TWiki::Users::LdapUser, does {Htpasswd}{Encoding} has any effect on the authentication ?

2. I've configured LdapContrib, now how do I make it ask me for username/password ?

3. Is there any logs I can check for errors? Does this script outputs anything at all?

4. Since I've installed the Plugin, clicking "Log In" which points to (http://wiki/twiki/bin/logon/Main/WebHome) gives me (http://wiki/twiki/bin/view/Main/WebHome), with no error or nothing. Is this the how it's supposed to work ?

Thank you, Maxim.

-- MaximVexler - 24 Aug 2006

Hi Maxim, you have to enable the TemplateLogin mechanism in configure. It looks like you are still using the htpasswd login scheme. Use

$TWiki::cfg{LoginManager} = 'TWiki::Client::TemplateLogin';

in LocalSite.cfg instead. The htpasswd encoding has no effect on authentication any more once you switched over to TemplateLogin.

The various files have a global variable $debug (each) that will trigger some writeDebug("message") here and there. Some of them might still be disabled in the code to not to be overwhelmed by log messages. These will either end up in data/debug.txt or in STDERR. See your apache error log for those (if you didn't redirect STDERR to some data/error.txt file).

-- MichaelDaum - 24 Aug 2006

Thank you! But I'm still struggling with the MS AD linking. I've Wireshark'ed the network on the wiki server side, I can see it binding to the LDAP server, and the query does pulls the the ldap server users data (all of them !?). But I still get the error "Unrecognized user and/or password" in the template login screen. Here are the setting I'm using for the plugin, could someone please have a view at them and correct/comment on them. LdapContribLocalSiteW2k3

-- MaximVexler - 25 Aug 2006

Hm, at first glance everything seems ok, although the subtree containing the groups and users can be tightened to improve performance. Use

BasePasswd = 'CN=Users,dc=corp,dc=CORP-DOMAIN,dc=com'

You use

$TWiki::cfg{Ldap}{GroupFilter} = '';

... Try to filter for your groups' objectClass. You need group objects. Directions that only support memberOf in user objects are not supported. See LdapContrib#Membership.

Try an external tool to query your directory and check objectClass=user and see if you are using your sAMAccountName to login.

-- MichaelDaum - 25 Aug 2006

Michael, Thank you so far. I've followed your suggestions and created a group in our AD structure called TWikiAdminGroup. I do have reason to believe that group mapping is not the issue here, please look at the attached (debug enabled) error log. I'm using the "administrator" here to eliminate "permission problems". Please also note that I have otrs.org (v1.3) working from this server using Net::LDAP.

If I understand the log correctly, the binding succeed - The script was able to get members of the LDAP TWikiAdminGroup, my AD server does not allow anonymous binding!

I would appreciate your help, I'd love to "Make it Work" (tm)

[Fri Aug 25 22:01:16 2006] [error] [client 192.168.x.x] LdapContrib - called LdapContrib constuctor, referer: http://wiki/twiki/bin/login/Main/WebHome
[Fri Aug 25 22:01:16 2006] [error] [client 192.168.x.x] LdapContrib - called LdapContrib constuctor, referer: http://wiki/twiki/bin/login/Main/WebHome
[Fri Aug 25 22:01:16 2006] [error] [client 192.168.x.x] LdapContrib - called connect, referer: http://wiki/twiki/bin/login/Main/WebHome
[Fri Aug 25 22:01:16 2006] [error] [client 192.168.x.x] LdapContrib - bind for administrator, referer: http://wiki/twiki/bin/login/Main/WebHome
[Fri Aug 25 22:01:16 2006] [error] [client 192.168.x.x] LdapContrib - LdapContrib - 49: 80090308: LdapErr: DSID-0C090334, comment: AcceptSecurityContext error, data 525, vece, referer: http://wiki/twiki/bin/login/Main/WebHome
[Fri Aug 25 22:01:17 2006] [error] [client 192.168.x.x] LdapContrib - called search(objectClass=user, OU=PS,DC=corp,DC=OUR-CORP,DC=com, sub, 0, ARRAY(0x8da416c)), referer: http://wiki/twiki/bin/login/Main/WebHome
[Fri Aug 25 22:01:17 2006] [error] [client 192.168.x.x] LdapContrib - called connect, referer: http://wiki/twiki/bin/login/Main/WebHome
[Fri Aug 25 22:01:17 2006] [error] [client 192.168.x.x] LdapContrib - proxy bind, referer: http://wiki/twiki/bin/login/Main/WebHome
[Fri Aug 25 22:01:17 2006] [error] [client 192.168.x.x] LdapContrib - done search, referer: http://wiki/twiki/bin/login/Main/WebHome
[Fri Aug 25 22:01:17 2006] [error] [client 192.168.x.x] LdapContrib - called getGroupMembers(TWikiAdminGroup), referer: http://wiki/twiki/bin/login/Main/WebHome
[Fri Aug 25 22:01:17 2006] [error] [client 192.168.x.x] LdapContrib - called getGroup(TWikiAdminGroup), referer: http://wiki/twiki/bin/login/Main/WebHome
[Fri Aug 25 22:01:17 2006] [error] [client 192.168.x.x] LdapContrib - called search((&(objectClass=group)(cn=TWikiAdminGroup)), CN=Users,DC=corp,DC=OUR-CORP,DC=com, sub, 0, ARRAY(0x8ddb7f0)), referer: http://wiki/twiki/bin/login/Main/WebHome
[Fri Aug 25 22:01:17 2006] [error] [client 192.168.x.x] LdapContrib - done search, referer: http://wiki/twiki/bin/login/Main/WebHome
[Fri Aug 25 22:01:17 2006] [error] [client 192.168.x.x] LdapContrib - this is an ldap group, referer: http://wiki/twiki/bin/login/Main/WebHome
[Fri Aug 25 22:01:17 2006] [error] [client 192.168.x.x] LdapContrib - found member=CN=IT_testuser,OU=PS,DC=corp,DC=OUR-CORP,DC=com, referer: http://wiki/twiki/bin/login/Main/WebHome
[Fri Aug 25 22:01:17 2006] [error] [client 192.168.x.x] LdapContrib - following indirection, referer: http://wiki/twiki/bin/login/Main/WebHome
[Fri Aug 25 22:01:17 2006] [error] [client 192.168.x.x] LdapContrib - called search(objectClass=*, CN=IT_testuser,OU=PS,DC=corp,DC=OUR-CORP,DC=com, base, 1, ARRAY(0x8ddd76c)), referer: http://wiki/twiki/bin/login/Main/WebHome
[Fri Aug 25 22:01:17 2006] [error] [client 192.168.x.x] LdapContrib - done search, referer: http://wiki/twiki/bin/login/Main/WebHome
[Fri Aug 25 22:01:17 2006] [error] [client 192.168.x.x] LdapContrib - found indirect member=IT_testuser, referer: http://wiki/twiki/bin/login/Main/WebHome
[Fri Aug 25 22:01:17 2006] [error] [client 192.168.x.x] LdapContrib - called getGroupNames, referer: http://wiki/twiki/bin/login/Main/WebHome
[Fri Aug 25 22:01:17 2006] [error] [client 192.168.x.x] LdapContrib - called search(objectClass=group, CN=Users,DC=corp,DC=OUR-CORP,DC=com, sub, 0, ARRAY(0x8b8488c)), referer: http://wiki/twiki/bin/login/Main/WebHome
[Fri Aug 25 22:01:17 2006] [error] [client 192.168.x.x] LdapContrib - done search, referer: http://wiki/twiki/bin/login/Main/WebHome
[Fri Aug 25 22:01:17 2006] [error] [client 192.168.x.x] LdapContrib - called disconnect(), referer: http://wiki/twiki/bin/login/Main/WebHome
[Fri Aug 25 22:01:17 2006] [error] [client 192.168.x.x] LdapContrib - called disconnect(), referer: http://wiki/twiki/bin/login/Main/WebHome

-- MaximVexler - 25 Aug 2006

Hi, I might be wrong here (being a perl newbie) but I believe I've found a small syntax mixup that caused the script to fail:

--- LdapContrib/lib/TWiki/Contrib/LdapContrib.pm        2006-08-02 22:45:00.000000000 +0300
+++ LdapContrib/lib/TWiki/Contrib/LdapContrib_synfix.pm 2006-08-26 00:48:28.293335536 +0300
@@ -155,7 +155,7 @@
   if (defined($login)) {
     die "illegal call to connect()" unless defined($passwd);
     my $msg = $this->{ldap}->bind(
-      "$this->{loginAttribute}=$login,$this->{basePasswd}",
+      "$this->{loginAttribute}=$login","$this->{basePasswd}",
     #writeDebug("bind for $login");

-- MaximVexler2 - 26 Aug 2006


I use Apache-NTLM module for auto - authenticating into my TWikiv4.0.4 pages basically to avoid remoteusers.txt maintainence and the users registrations. So, Will installing the ldapcontrib plugin/package and removing the ntlm dependency make me still have the password-less authentication from the browsers while having the ACLs defined ?


-- NikhilMulley - 04 Sep 2006

Michael, I and many other users seem to have trouble authenticating to the LDAP server with just our username and password. I think this is because:

the LDAP server only binds with the password and:

  1. the full DN (Distinguished Name), like "cn=Jones,\ Tom,ou=users,dc=company,dc=org"
  2. the RDN (Relative Distinguished Name), which is usually the CN, like "Jones, Tom", or
  3. userprincipalname, if assigned, which is our email address

It would be nice if the LDAP server allowed binding with the password and the samaccountname, or whatever LDAP attribute happens to hold the "username". This is not the fault of the LdapContrib but of the LDAP server.

How hard would it be for you to add a subroutine that fetches the DN of a user and then tries to bind with that -- sort of like your Member Indirection piece?

-- AndrewBanks - 05 Sep 2006

Hi, I have configured LdapContrib but i cant seem to logon, Is there anyway to see a log of everything that is done with the PLugin to see where the errors are? at the moment im just trying new settings and seeing if that works. It would be helpfull if i could see an error log for the LDAP login. My Config is in LdapContribCannotLogon

-- LarreDo - 06 Sep 2006

For support, please put your questions in the the Support Web. There, for example, is how to get the plugin's progress in your error log (by uncommenting the writeDebug lines in LdapContrib.pm)

-- AndrewBanks - 06 Sep 2006

I suggest the following small addition :

        $wikiName =~ s/^([a-zA-Z])/uc($1)/e;
        $wikiName =~ s/( [a-z])/uc($1)/e;


      $wikiName =~ s/[^$TWiki::regex{mixedAlphaNum}]//g;

in LdapUserMapping.pm for the case where cn contains lower case names... for what it's worth. Hope this can be usefull.

-- OlivierBerger - 05 Oct 2006

I've tried and package this plugin for Debian... Here are the sources for the package : http://picolibre.enst-bretagne.fr/cvsweb/picolibre/src/picolibre_twiki/debian/LdapContrib/ http://picoforge.int-evry.fr/websvn/listing.php?repname=twldapdeb&path=/twiki-ldapcontrib/ (URL updated -- OlivierBerger - 26 May 2008) please let me know of any remarks.

-- OlivierBerger - 06 Oct 2006

Hi, Great Plugin. configuration was easy, and accurate. There is one issue, to map the login name to WIKINAME, I enabled $TWiki::cfg{UserMappingManager} = 'TWiki::Users::LdapUserMapping'; Now viewing any pages, authenticated or not takes about one minute to load. We have no groups in our LDAP server and have about 35000+ entries. Is there any way to speed this up?

-- CurtWilhelm - 09 Oct 2006

FYI, I've updated the packaging for Debian. Also packaged newer version 0.7 / 061103. Everything needed to rebuild the package may be found at : http://picolibre.enst-bretagne.fr/cvsweb/picolibre/src/picolibre_twiki/debian/LdapContrib/?sortby=date#dirlist https://picoforge.int-evry.fr/twiki/Twldapdeb/Web/ (URL updated -- OlivierBerger - 26 May 2008)

-- OlivierBerger - 24 Nov 2006

Thanks Oliver for packaging this for Debian. You can consider maintaining it in TWiki's SVN. See ReadmeFirst and PluginsInSubversion.

-- PeterThoeny - 26 Nov 2006

The plugin topic mentions %INCLUDE{"TWiki04.LdapContrib"}% which is not correct: should be %INCLUDE{"%TWIKIWEB%.LdapContrib"}%.

-- ArthurClemens - 28 Nov 2006

MichaelDaum: This is great stuff, works fine here. It's a nice combination using LdapContrib LdapNgPlugin and NewUserPlugin. One nice feature would be if we could config how the WikiName is build, our cn filed is like "Klaassen, Jan van" and a nicer way would be if we could combine the ldap fields givenName, middleName, sn to JanVanKlaasen. Do you have an idea if this would be possible ?

-- MauriceKok - 21 Dec 2006

Agreed, concistency is good: Build the WikiName the same way the javascript in the registration topic does: Change entities to ASCII representation (e.g. to oe), capitalize initial characters (after white-space), and remove spaces.

-- PeterThoeny - 23 Dec 2006

Has anybody had any problems with LdapContrib and Twiki upgraded to 4.1.1? When I did the upgrade, the result is a wiki where I can view the pages (even logged in), but when I try to edit anything, I fall into a "please log in" loop (even though I'm already logged in before I start editing). The setup worked under 4.1.0.

-- MatijaGrabnar - 12 Feb 2007

There is a small bug in v0.91 in LdapUserMapping.pm in getGroupMembers, resulting in a problem when using the MapGroups feature together with an Active Directory server. AD groups list their members by DN, not by account name (so memberIndirection is enabled).

The result is that users with non-ASCII characters in their DN (e.g. CN=Heinz Mller) do not belong to any group.

The problem appears to be just a small mixup; memberIndirection is only checked after the conversion from UTF-8. The following patch should fix that:

--- lib/TWiki/Users/LdapUserMapping.pm.orig     2007-02-22 20:10:46.000000000 +0100
+++ lib/TWiki/Users/LdapUserMapping.pm  2007-02-23 14:46:33.000000000 +0100
@@ -524,7 +524,6 @@
   # fetch all members
   my @members = ();
   foreach my $member ($groupEntry->get_value($this->{ldap}{memberAttribute})) {
-    $member = from_utf8(-string=>$member, -charset=>$TWiki::cfg{Site}{CharSet});

     #writeDebug("found member=$member");

@@ -542,7 +541,10 @@
         last unless $this->loadLdapMapping();
       next unless $found;
+    } else {
+      $member = from_utf8(-string=>$member, -charset=>$TWiki::cfg{Site}{CharSet});
     push @members,$member;

-- EnnoEwers - 23 Feb 2007

Hi, I am trying to get the LdapContrib plugin to work. I also want to map LdapGroups and Users to twiki groups and users. I have it configured now such that all of the Ldap groups show up on the TWikiGroups page, but I have not been able to get the users to show up in TWikiUsers. I enabled all of the debug statements (see snippet below);

$TWiki::cfg{Ldap}{Host} = 'server.com';
$TWiki::cfg{Ldap}{Port} = 389;
$TWiki::cfg{Ldap}{Base} = 'dc=server,dc=com';
$TWiki::cfg{Ldap}{BasePasswd} = 'dc=server,dc=com';
$TWiki::cfg{Ldap}{BaseGroup} = 'dc=server,dc=com';
$TWiki::cfg{Ldap}{LoginAttribute} = 'sAMAccountName';
$TWiki::cfg{Ldap}{WikiNameAttribute} = 'givenName, sn';
$TWiki::cfg{Ldap}{NormalizeWikiNames} = 1;
$TWiki::cfg{Ldap}{LoginFilter} = 'objectClass=user';
$TWiki::cfg{Ldap}{GroupAttribute} = 'ou';
$TWiki::cfg{Ldap}{GroupFilter} = 'objectClass=organizationalUnit';
$TWiki::cfg{Ldap}{TWikiGroupsBackoff} = 1;
$TWiki::cfg{Ldap}{MemberAttribute} = 'department';
$TWiki::cfg{Ldap}{MemberIndirection} = 0;
$TWiki::cfg{Ldap}{BindDN} = 'cn=appsuser,ou=Sales,dc=server,dc=com';
$TWiki::cfg{Ldap}{BindPassword} = 'password';
$TWiki::cfg{UserMappingManager} = 'TWiki::Users::LdapUserMapping';
$TWiki::cfg{Ldap}{SSL} = 0;
$TWiki::cfg{Ldap}{MaxCacheHits} = -1;
$TWiki::cfg{Ldap}{MapGroups} = 100;
$TWiki::cfg{Ldap}{Exclude} = 'TWikiGuest, TWikiContributor, TWikiRegistrationAgent, TWikiAdminGroup, NobodyGroup';
$TWiki::cfg{Ldap}{PageSize} = 200;

[Thu Mar 15 12:51:34 2007] [error] [client] LdapUserMapping - adding wikiName=JocelynRamirez, loginName=Ramirezj, referer:
[Thu Mar 15 12:51:34 2007] [error] [client] LdapUserMapping - adding wikiName=BettyHubbard, loginName=hubbard, referer:
[Thu Mar 15 12:51:34 2007] [error] [client] LdapUserMapping - adding wikiName=ClaudiaDiaz, loginName=Diaz, referer:

Please help, this is my last stumbling block.

-- SeanSleicher - 15 Mar 2007

Summary of IRC conversation, MichaelDaum and PeterThoeny:

  • It would be nice to have a {Ldap}{Debug} flag in configure. This is the first place and most logical place to look when trying to integrate TWiki with an LDAP server.
  • It would be nice to have a {Ldap}{TWikiUsersMapping} flag to let TWiki handle the mapping from login name to WikiName. This is for sites where users should be authenticated via LDAP, and users still have a TWiki account. ( LdapUserMapping::addUserMapping() calls its super class if enabled)
  • Question how to solve the issue of same cn (first name last name) for different login names, such as logins jsmith and jxsmith sharing same name John Smith. Could map by appending login name, such as JohnSmithJxsmith, but this is long and ugly. Could store mapping exceptions externally to LDAP, such as jxsmith to JohnXSmith, but this might be slow.
-- PeterThoeny - 15 Mar 2007


I run twiki 4.1.2 release on winxp sp2 host running apache 2.2.4. and Active perl 5.8.8. i use ldapcontrib hoping that it will fetch user details from my Windows 2000 Active Directory and autopolulate the registeration form. Pls see the error reported at SvcErr:DSID-020A00C0Problem5012Ldap.

pls help me out on this

-- SibiJoseph - 20 Mar 2007

Sorry the link dint come as expected pl see SvcErr:DSID-020A00C0Problem5012Ldap

-- SibiJoseph - 20 Mar 2007

I have LdapUserMapping.pm patched as per EnnoEwers - 23 Feb 2007, the users page in main web does not show any users (other than the default ones that comes with twiki)

-- SibiJoseph - 22 Mar 2007

Hi Strangely the question i asked at SvcErrDSID020A00C0Problem5012Ldap seems to be truncated automatically.. Anyway the problem there was with my ldapserver

-- SibiJoseph - 22 Mar 2007

Alright, have a nice time ldaping.

-- MichaelDaum - 22 Mar 2007

Would it be possible to use this contrib with NT accounts?

-- ArthurClemens - 29 Mar 2007

... using an Active Directory Server? Yes, that's possible.

-- MichaelDaum - 29 Mar 2007

Hi Michael

The install on windows XP was successful even though i could not get the Main.users page populated (actually no entries could be found there) .

Now i decided to move on to Ubuntu-server version with apache 2.2 server and perl 5.8.8. on installing LdapContrib using configure i get the error (Note i run twiki 4.1.2 release version)

Fetching http://twiki.org/p/pub/Plugins/LdapContrib/LdapContrib.tgz...

Warning: I can't install http://twiki.org/p/pub/Plugins/LdapContrib/LdapContrib.tgz because I don't recognise the download as a gzip file. 
Warning: Extension may not have been packaged correctly. Trying for a .zip file instead. 

Fetching http://twiki.org/p/pub/Plugins/LdapContrib/LdapContrib.zip...

Error: Failed to move file 'lib/TWiki/Contrib/LdapContrib/' to /home/twiki/lib/TWiki/Contrib/LdapContrib: Is a directory
Software error:
Installation terminated at /home/twiki/lib/TWiki/Configure/UIs/EXTEND.pm line 149.

-- SibiJoseph - 30 Mar 2007

Sibi, this is doesn't seem to be an LdapContrib related issue, but one of the BuildContrib that is used to package it. Please, report this issue on BuildContribDev or at Bugs:BuildContrib. Short-term workaround is to download the zip file and unzip it in your twiki root directory, presumably /home/twiki in your case.

-- MichaelDaum - 30 Mar 2007

Our company bought some other company department as a result we now have two LDAP servers. Would it be possible to consider multiple LDAP server architecture in future development? Does that make any sense at all? smile For now the guys on the other LDAP server have only read access to TWiki. I which I could get that fix at some point. As anyone dealt with something like that in the past?

For now our TWiki works with apache ldap auth and we are using LdapPlugin to generate user pages and register them with login/TWikiName mapping in TWikiUsers. I'm not even sure apache supports multiple ldap server. I had the impression that apache 2.2 did support that though.

-- StephaneLenclud - 30 Mar 2007

Supporting mutiple LDAP sources sounds like a useful enhancement to the LdapContrib. May be you can ask Michael to create this for you as a consultant?

-- PeterThoeny - 30 Mar 2007

I'd love too. I just have to convince my boss to pay for that. Mind you that would only be fair after all the benefice Navigon got for free from TWiki (besides my own efforts of course). I wonder how important it is for them to give TWiki write access to the guys in the US. I'll investigate.

BTW What does LdapContrib do exactly? Does it removes the need to use apache ldap auth? What about the feasibility of that multiple LDAP things?

-- StephaneLenclud - 31 Mar 2007

LdapContrib and apache auth_ldap have similar goals, you can use one or the other to authenticated TWiki users against an ldap database. LdapContrib also maps ldap groups into TWiki groups, I do not know if the auth_ldap module supports that or not.

-- PeterThoeny - 31 Mar 2007

Thanks for the clarification Peter. That's what I thought then. I guess we better of getting ride of the auth_ldap and go LdapContrib then, especially with that dual LDAP server. As I understand it, it could also remove the need to create new user topics using LdapPlugin to generate UnprocessedRegistrations. That's the way I'm doing it at the moment... smile

-- StephaneLenclud - 31 Mar 2007

I talked with Reiner today, he is our System Administrator. It seems we will have to deal with multiple LDAP servers for sometimes and possibly even more than 2. He said he was already trying to get LdapPlugin to work with multiple server.

-- StephaneLenclud - 02 Apr 2007

Does LdapContrib need to be able to query multiple LDAP servers? Perhaps, but I didn't see anyone suggest that the LDAP server admin set up an LDAP server with referrals which would bring two separate LDAP trees on separate servers by acting as a proxy for both. I haven't done this myself, but I keep seeing it mentioned in the docs on the OpenLDAP slapd servers. Check out the OpenLDAP Admin guide (http://www.openldap.org/doc/admin23/) sections 3 and 13. If I am wrong about this or completely off topic, sorry.

-- NuZapa - 03 Apr 2007

I have been working with Linux/Apache/LDAP/Perl for many years now. Over the past month I have been dedicating myself to learning TWiki. Out-of-the box everything works great, and most of the configuration made sense. Then, I tried integrating LDAP into TWiki for authentication. There were three things that tripped me up, which I would like to help future users avoid:

  1. Apache <2.2 vs Apache >2.2....mod_auth_ldap changes significantly such that many of the examples floating around the internet which, don't clearly specify Apache version, will lead people astray. I know that this isn't a TWiki problem, but I figured I would mention it. (The TWKI.ORG site does have users post Apache version when discussing bugs...so 'kudos' to the team on that).
  2. I set up an LDAP directory with numeric 'uid's and got Apache LDAP authentication working with TWiki...great! However, I spent hours trying to figure out the error message I got when trying to save any edited page. The problem boils down to RCS used in the Store implementation for pages doesn't like numeric usernames (not on Gentoo Linux) at least. Once I discovered this I was motivated to investigate the SVN version of the Store implementation. Perhaps we should add BIG BOLD warning message in the Store implementation (now I am off-topic) to help people on this. From what I have seen, this problem bites people like me trying out LDAP, where numeric UID logins are common.
  3. The configuration $TWiki::cfg{Ldap} parameters {Base} vs {BasePasswd}. I have worked with LDAP for a long time. I knew what Base was. I saw BasePasswd and thought "I am not going to bind for user searches, so I will leave BasePasswd blank!". Then I see the parameters BindDN and BindPasswd...ok, I know what those are, so what was that BasePasswd parameter? Oh well, it probably doesn't matter".
That was the last sane thought I had while tearing my hair out trying to get LdapUserMapping to work for 2 weeks. After finally debugging all the LDAP calls, I finally saw why LdapUserMapping kept failing and passing back up to SUPER where it continued to fail mapping un-registered users. The 'loadLdapMapping' routine in lib/TWiki/Users/LdapUserMapping.pm is using basePasswd as the search base for mapping. If you left BasePasswd blank in the LocalSite.cfg, then lib/TWiki/Contrib/LdapContrib.pm will default it to 'ou=people'+$TWiki::cfg{Ldap}{Base}. Unfortunately, this branch of my LDAP directory is non-existent, so all name lookups failed. By making sure that I filled out $TWiki::cfg{Ldap}{BasePasswd} (incidentally with the exact same value as $TWiki::cfg{Ldap}{Base}), everything started to work fine.

So, here are my only questions/suggestions:

  • Why is BasePasswd the name of the config parameter which is used to look up username mappings? Why does this contain 'Passwd'...it is not a password! This completely threw me off the trail of a proper configuration.
  • Given that the parameter used to configure group lookups is BaseGroup, isn't it logical that the parameter used for user lookups would be BaseUser? Given my experience with LDAP, I would actually vote for UserLookupSearchBase and GroupLookupSearchBase (see the ldapsearch man page from OpenLDAP).
Well, those are my experiences. Based on this past month's worth of experiences, I think that these problems are common for other TWiki users trying to get LDAP working. I will try to go through the pages discussing TWIKI+LDAP and see if I can help out other lost souls.

-- NuZapa - 03 Apr 2007

Thanks for sharing your experience. Please feel free to help make the docs more explicit.

-- PeterThoeny - 03 Apr 2007

Thank you michael For the reply. Have made the report at BuildContribDev

-- SibiJoseph - 03 Apr 2007

BTw somethig strage michael while running LdapContrib _installer from command prompt , i think the file downloaded has a "..tgz" (note 2 dots)LdapContrib..tgz ..

the error i get is "Could not open tar file "

-- SibiJoseph - 03 Apr 2007

NuZapa, great feedback. I cant recap what drove me to name BasePasswd BasePasswd. I will rename it to UserBase and BaseGroup to GroupBase. The old names will be deprecated and provided for backwards compatibility. In addition, UserBase and GroupBase will default to Base if they are not defined and don't default to adding ou=people and ou=groups.

Final note, RTFM wink

-- MichaelDaum - 03 Apr 2007

How about querying multiple LDAP servers in a round-robin fashion (or randomly). We currently have $TWiki::cfg{Ldap}{Host} and could similarly have a $TWiki::cfg{Ldap}{Hosts} that takes a list.

-- MichaelDaum - 03 Apr 2007

That would be useful. Not random, but with a predefined sequence. For example, you'd want to search first the employee directory, than the contractors directory.

-- PeterThoeny - 03 Apr 2007

If the ldap directories are not redundant and you want to merge their entries, the LdapContrib is not the right place to do that. That's better done on the server side as outline above. Querying multiple servers from within the LdapContrib is only there to balance load among redundant ldap servers, as far as I know.

-- MichaelDaum - 03 Apr 2007

NAVIGON AG has multiple site world wide and is using different non-redundant LDAP server for user authentication.

So the idea was to query LDAP servers one after the other looking for the user account.

Duplicate login from one server to the other should not cause problem unless even the password is identical which seems very unlikely, unless it's the same user -redundant- in which case we don't care which LDAP server gave us the go ahead anyway.

Duplicate login for different user from one LDAP server to the other could however mess up the user topic matching. I'm sure we could implement a solution for that too.

-- StephaneLenclud - 04 Apr 2007

Stephane, I see your case. Sometimes having another LDAP server that acts as a proxy/cache/chainer for the others might not be an option...

The case for authenticating and user-mapping might be different. While the first consists of O(n) bind tries on n servers. The latter will result in a massive network traffic collecting all the information from all of the servers. I am pretty sure that this is going to be real slow as you will have to wade through all of the records of the first servers til you get the information you need. This actually undermines any query optimizations that the database could do for us. It seems as if a better approach would be to have an LDAP server act as a proxy with referrals and chaining. See this paper.

-- MichaelDaum - 05 Apr 2007

can anyone help resolve: LdapContribLoginsAreSpotty , LdapContribUsersGroupsDoNotDisplay and SvcErrDSID020A00C0Problem5012Ldap ?

-- SvenDowideit - 30 Apr 2007

and DomainGroupForWebAuthorization

-- SvenDowideit - 02 May 2007

I see the the German umlaute letters are converted from the loginnames into two letters substitutes. Included is the diff for the conversions for Danish letters , , and the capital counterparts , and for LdapContrib version 1.01.

--- lib/TWiki/Users/LdapUserMapping.pm.bak      Mon Apr 30 14:49:06 2007
+++ lib/TWiki/Users/LdapUserMapping.pm  Thu May  3 20:56:14 2007
@@ -363,6 +363,16 @@
         $value =~ s/?/Oe/go;
         $value =~ s/?/Ue/go;
         $value =~ s/?/ss/go;
+       # replace Danish letters , , , , , 
+       $value =~ s/\xa6/ae/go;
+       $value =~ s/\xb8/oe/go;
+       $value =~ s/\xa5/aa/go;
+       $value =~ s/\x86/Ae/go;
+       $value =~ s/\x98/Oe/go;
+       $value =~ s/\x85/Aa/go;
         foreach my $part (split(/[^$TWiki::regex{mixedAlphaNum}]/, $value)) {
           $wikiName .= ucfirst($part);

-- FlemmingKjaerJensen - 07 May 2007

LDAP is case insensitive, but TWiki is case sensitive. If a user does not login with their username exactly as it appears in the LDAP tree itself (with identical caps), TWiki will successfully authenticate the user with an LDAP bind, but will fail to map the user to a WikiName? , and will not recognize the user as being a member of any LDAP groups. This disjoint between LDAP and TWiki causes a variety of problems.

Im sure my issue is not unique, and it could be responsible for at least some of the unresolved LDAP-authentication-access/control questions that litter the TWiki.org Support Web and other forums. It seems that almost all of the unresolved issues are posted by folks using Microsoft technology and Active Directory. It is typical for such setups to use capital letters for usernames and other information, unlike Linux/Unix. I would assume this is probably why linux-using contributors have not been able to diagnose the problem. See LdapContribUsersGroupsDoNotDisplay, LdapContribLoginsAreSpotty, LdapContribUsersGroupsDoNotDisplay, etc for more.

I have made a post in LdapAuthenticationCaseSensitivityBug so users can be aware of the issue and can perhaps implement workarounds (and also maybe help me fix it).


-- KevinFirko - 17 May 2007

Hi all,

I keep getting these kind of errors when trying to enable LdapUser and LdapUserMapping.

" Software error:

Password Manager: Can't locate TWiki/Users/LdapUser.pm in @INC (@INC contains: /var/www/twiki/lib/CPAN/lib//arch /var/www/twiki/lib/CPAN/lib//5.8.5/i386-linux-thread-multi /var/www/twiki/lib/CPAN/lib//5.8.5 /var/www/twiki/lib/CPAN/lib/ /var/www/twiki/lib . /usr/lib/perl5/5.8.5/i386-linux-thread-multi /usr/lib/perl5/5.8.5 /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.4/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl/5.8.4 /usr/lib/perl5/site_perl/5.8.3 /usr/lib/perl5/site_perl/5.8.2 /usr/lib/perl5/site_perl/5.8.1 /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.2/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl/5.8.4 /usr/lib/perl5/vendor_perl/5.8.3 /usr/lib/perl5/vendor_perl/5.8.2 /usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl) at (eval 19) line 2. BEGIN failed--compilation aborted at (eval 19) line 2.

For help, please send mail to the webmaster (root@localhost), giving this error message and the time and date of the error.

Both LdapUser.pm and LdapUserMapping.pm are in /var/www/twiki/lib/TWiki/Users, permissions are as follow: "

-rw-r--r-- 1 apache apache 4.9K Apr 30 08:49 LdapUser.pm -rw-r--r-- 1 apache apache 17K Apr 30 08:49 LdapUserMapping.pm

What am I doing wrong? Thanks in advance.

-- HungTamNguyen - 22 May 2007

One more vote for eventually providing a fall back option for authentication using the regular .htpasswd mechanism. Like MichaelRedinger, we need to give TWiki access to some external people, but adding them to the Ldap is not wanted.

-- JosMaccabiani - 02 Jun 2007

When you switch to Ldap authentication, you probably also change TWiki in some other ways:

  • remove the possibility to use TWikiRegistration and change its text to something indicating that Ldap is used
  • remove the functionality for ResetPassword and ChangePassword
  • change to text on the TWiki TemplateLogin screen

Removing all links to TWikiRegistration, ResetPassword and ChangePassword

Now is the time to use the backlinks functionality in the action bar at the bottom of your TWiki pages. It lists which topics are linking to them. Take care of the topics where your users are likely to arrive at some point (eg: TWikiUsers which points to UserListBy topics).

Removing link to TWikiRegistration in the WebLeftBar

The WebLeftBar includes the topic WebLeftBarLogin. To remove the link to the registration page, I've created a new topic WebLeftBarLdapLogin and included that topic instead. The contents of this WebLeftBarLdapLogin are as follows:

%STARTINCLUDE%<div class="patternLeftBarPersonal">
%IF{"context authenticated" then='%MAKETEXT{"Hello [_1]" args="[[%WIKIUSERNAME%][%SPACEOUT{%WIKINAME%}%]]"}%'}%%IF{"$ LOGOUT != ''" then='%BR%<ul><li class="patternLogOut">%LOGOUT%</li></ul>'}%%IF{"$ LOGIN != '' and not context authenticated" then='<ul><li class="patternLogIn">%LOGIN%</li></ul>'}%
<div class="patternLeftBarPersonalContent">%INCLUDE{"%MAINWEB%.%WIKINAME%LeftBar" warn="<ul><li><a href=\"%SCRIPTURLPATH{"edit"}%/%MAINWEB%/%WIKINAME%LeftBar?templatetopic=%TWIKIWEB%.WebLeftBarPersonalTemplate&amp;topicparent=%WIKINAME%\">%MAKETEXT{"Create personal sidebar"}%</a></li></ul>"}%</div></div>

Changing text in the TemplateLogin screen

For the last thing, I created a skin file in /templates, called login.ldapchanges.tmpl, which contains:


%TMPL:DEF{"authenticationnote"}%<p><span class="twikiSmallish twikiGrayText">%MAKETEXT{"Enter your login name and password. (Typically your standard company login name and password). Contact %WIKIWEBMASTER% if you do not succeed."}%</span></p>%TMPL:END%


The 'forgot password' link is cleared, since TWiki does not know this password.

-- JosMaccabiani - 03 Jun 2007

Jos, thanks that you mention that. This should actually be integrated into the documentation. Feel free to do so by either checking in to svn or attaching a patch here.

The latest LdapContrib fixes a couple of utf8 issues as well as LdapAuthenticationCaseSensitivityBug.

-- MichaelDaum - 04 Jun 2007

Actually I think the last update also introduces new bugs:

  • when i'm not authenticated, previously edited topics show 'Main.josmaccabiani' or 'Main.twikicontributor' as the authors. Clearly this shouldn't happen as the links are broken.
  • more importantly: access permissions are off - i'm no longer recognized as being in the TWikiAdminGroup (probably because of the Main.josmaccabiani thing)
  • Twiki gave an 'internal' error when I try to view the TWikiGroups page. I do not use the option to map Ldap groups to TWiki groups.
  • Disturbingly, re-installing the previous release does not have any effect frown
Note: the wiki name is constructed from the $cn "Jos Maccabiani, mcb" --> "JosMaccabiani,mcb" --> "JosMaccabiani" (in the previous release)

I heard mentioning of a Cache feature for non-accelerator users. Is that already in this release or will it be in a future release?

I'm glad to be able to help with documenting. But do you really want to add this to the Contrib docs, or would you rather ship an extra topic which has info on TWiki customisation? I can probably create a new topic, but don't know how to create patches.

I notice that there is an option to list users/groups that should not be authenticated through Ldap (like TWikiGuest). When I add a username to this topic, it doesn't look up the username in .htpasswd, does it? (At least it didn't work in my case). Would it be possible to add this, so you can specify special external users which are also allowed to use the wiki but who are not in the Ldap? (Of course, a configurable behaviour of 'if Ldap auth fails, try .htpasswd auth' would be even nicer for me, but I'm too shy to ask for that wink )

-- JosMaccabiani - 04 Jun 2007

Documentation is in LdapAuthenticatedTwikiModifications

-- JosMaccabiani - 05 Jun 2007

My setup is experiencing similar bugs as Jos' setup. While the new update now allows authentication with lowercase usernames (at least for my setup using mod_auth_ldap... thanks!), it still handles WikiNames funny.

I can replicate the following errors on my setup:

  • I found that in some cases (eg: on a newly created topic) the creator's name resolved to Main.kevinfirko instead of KevinFirko. I unfortunately can't replicate it consistently. Perhaps it has to do with not being authenticated as Jos suggested but I'm using mod_auth_ldap so I can't exactly replicate that state on my setup.
  • Messed up access permissions. I no longer am recognized as TWikiAdminGroup and get denied viewing topics that have access controls... TWikiAdminGroup members should always have access to anything... Right now I'm using SSH to my TWiki server to temporarily change the data files of topics directly so I can get in...
  • Some LDAP groups don't work for authentication (eg: for ALLOWTOPICVIEW =...), but others do. I haven't been able to find how to exactly replicate the bug, but one thing I noticed is the group where things worked has all lower-case characters in its name, but this could be a coincidence.
Unlike Jos, I can view my TWikiGroups page just fine, and it lists all members of LDAP groups. Of course, I am using the option to map LDAP groups to TWiki groups and Jos is not.

However, on the groups topic, there is something interesting... I notice there are two EMPTY groups called "twikiadmingroup" (all lowercase) at the bottom of the list (yes, two of them, one after the other...). I have a group called TWikiAdminsGroup in my LDAP intentionally (note the 's' to differentiate from TWiki) so the empty twikiadmingroup is probably from TWiki itself... Perhaps that's why Jos and I are experiencing problems with this admin group. Hopefully this quirk can give some insight into where that bug lies and assist with your ability to replicate our error on your stack.

If you need any more details, settings, screenshots, whatever, please email me directly... kevin[dot]firko[at] gmail

Thanks everyone for all your efforts!

-- KevinFirko - 18 Jun 2007

Just FYI: My problems disappeared when upgrading to the release Michael provided a few days after my bug post, and I am NOT using LDAP groups for TWiki access control, just the TWiki groups.

-- JosMaccabiani - 18 Jun 2007

Jos: Cool... I'll try the upgrade and report back. I'll be at the office again on Wednesday and will have a bit of time to play with TWiki. I'll try everything and will post back here if any of the bugs persist. I read the update description and it seems that it's a good candidate for fixing the bugs. Thanks Michael!

-- KevinFirko - 18 Jun 2007

Update: The latest LdapContrib works perfectly. As far as I can tell, all of the previously reported bugs have been addressed, and there are no more issues that I can find related to messed up capitalization of usernames/wikinames/groupnames. Thanks Jos and Michael!

-- KevinFirko - 20 Jun 2007

I'm using the LdapContrib (on TWiki 4.1.2) in connection with an ActiveDirectory server. Our user names are of the form "abc123" and are translated into WikiNames using "givenName, sn" and "!NormalizeWikiNames" in config. Today, I've upgraded from Rev. 12509 to Rev. 14059 because of this case-sensitivity bug. Now the translation from user name to WikiName doesn't work reliably anymore. Every now and again I'm logged in as "abc123" instead of my WikiName. I also get kicked out once in a while and have to log in again. So far, I haven't figured out what triggers these events. Any thoughts? In the meantime, I reverted back to the old revision taking over all the lc() statements from the new code.

-- MartinKaufmann - 21 Jun 2007

What kind of login method are you using? mod_auth_ldap with Apache? Template Login? When I first reported the initial case sensitivity bug, I noted different behaviour with the different auth types. With the new LdapContrib versions that include a fix for the bug, I haven't experienced your error (I'm using auth_ldap), but that could be because in my case the REMOTE_USER variable is always set and this is what gets mapped to the Wikiname.

-- KevinFirko - 21 Jun 2007

Sorry, I should have mentioned that I'm using TemplateLogin.

-- MartinKaufmann - 21 Jun 2007

is it possible to use a user attribute instead of the group object to define groups? in our organization, each user has an attribute called "Department" defined, and I want to be able to create groups and define access based on this attribute.

I got it work to some extent, (i can see the department names under the group page), but things break after that. Only one group member is shown, and their name is not in the WikiName format, so, permissions don't work.

any help would be appreciated.

-- DhavalShah - 24 Jun 2007

I posted a bug regarding how LdapContrib handles caching (show stopper at my site) (Item4291). Hasn't been touched in almost a week.... I need to understand why it appears that LdapContrib wants to cache the entire LDAP directory when a simple login process is started. Perhaps I'm missing something simple, but the current code is not functional in a large environment.

-- CrisRhea - 27 Jun 2007

I'm having a problem with LdapContrib (latest version from 8 Jun on TWiki 4.1.2). I tried to resolve it by looking at how the code works; however, I'm not a Perl master, so I'd appreciate any help.

I have configured TWiki to do Apache login which authenticates via an Ldap server (that part works fine). TWiki is then supposed to map login names to WikiNames and also do the group mapping. Both work fine for a while after the apache is started. Some time later, however, the WikiName mapping suddenly breaks, showing only the login names instead of the WikiNames.

From the code in LdapUserMapping.pm the mapping seems to be read from the Ldap server by loadLdapMapping (which works fine), setting $isLoadedMapping to 1. After a while, the Ldap cache is cleared and the mapping is lost. But isLoadedMapping seemingly stays at its value of 1, so loadLdapMapping never re-reads the mapping.

Any hints on what could go wrong here?

-- MichaelRitter - 12 Jul 2007

Michael, many thanks for this hint. I can reproduce this issue and will look follow the hints you gave.

-- MichaelDaum - 13 Jul 2007

I'm using LdapContrib on a very large directory w/ twiki 4.0.5. We are not using groups. When loading a page (not authenticated) LdapContrib loads all the users into the map. Without the map loaded, and requesting a topic, it takes about 4 minutes to load the map and display the Topic. Then again after 10 minutes the map loads again, which takes another 4 min. To a user, the site will appear broken, and unusable.

We have set the LdapUserMapping to get the WikiName of the users. Without LdapUserMapping, all we get is the login value for the WikiName.

Is there way to map the WikiName for the authenticated user, and not create the large map.

Thanks in advance for your advice!

-- CurtWilhelm - 19 Jul 2007

This should work:

  • In configure,
    • set {MapUserToWikiName}
    • in {UserMappingManager}, use the standard TWiki::Users::TWikiUserMapping (not the one from the LDAP contrib)
  • Ask users to register
    • this will create Main.TWikiUsers entries with WikiWord name and login name ( TWiki::Users::TWikiUserMapping uses this to map names)
-- PeterThoeny - 20 Jul 2007

Peter, I made the suggested changes. The WikiName becomes the same value as the login name. I want the WikiName to be the 'cn' attribute from the ldap. I also have LdapNgPlugin and NewUserPlugin installed to automatically create the TWikiUsers entry and user topic. After the user logs in, the user topic is created as expected.

Do you have any further suggestions.


-- CurtWilhelm - 20 Jul 2007

Is there a way to set the WikiName to a LDAP attribute without loading all the ldap users into cache or a large map With very large directories, mapping all the users is undesirable.

In my installation the WikiName is set to the 'cn' attribute and with LdapUserMapping enabled the values are correct. Because the map takes too long to load, we don't want to use it. I'd like to have only the logged in user(s) mapped.

-- CurtWilhelm - 23 Jul 2007

This is about -- HungTamNguyen - 22 May 2007 request (Password Manager: Can't locate TWiki/Users/LdapUser.pm) I got similar error. It happens to be an SELinux error dur to a bad context (For non LINUX could also simply be bad ownership/read rights)

SELinux (FC7) Recommended context for Twiki base directory: root:object_r:httpd_sys_script_exec_t

Recommended context for data, pub, locale, templates root:object_r:httpd_sys_content_t

-- JoseREMY - 29 Sep 2007

Made a new 2.o release today.

-- MichaelDaum - 11 Oct 2007

I also work for a very large company (100,000's of employees) and when I try to enable ldap the page just hangs as it is apparently trying to cache the entire directory. This is a small website I want to setup - I just want to authenticate those users that want to use it.

-- LarryOrcutt - 16 Oct 2007

I found many records in my httpd error log like below:

  • [Mon Dec 17 14:44:46 2007] [error] [client] adding wikiName=StyangB, loginName=styangb, referer: ...
  • [Mon Dec 17 14:44:46 2007] [error] [client] got 18000 keys in cache, referer: ...
  • [Mon Dec 17 14:44:46 2007] [error] [client] called loadLdapMapping(), referer: ...
  • [Mon Dec 17 14:44:46 2007] [error] [client] need to fetch mapping, referer: ...
  • [Mon Dec 17 14:44:46 2007] [error] [client] called search(filter=objectClass=organizationalPerson, base=OU=PCEO,OU=CO,OU=OrgRoot,DC=tsmc, scope=sub, limit=0, attrs=cn,cn), referer: ...
  • [Mon Dec 17 14:44:46 2007] [error] [client] found 500 entries, referer: ...
  • [Mon Dec 17 14:44:46 2007] [error] [client] done search, referer: ...
  • [Mon Dec 17 14:44:46 2007] [error] [client] adding wikiName=TktsengB, loginName=tktsengb, referer: ...
  • [Mon Dec 17 14:44:46 2007] [error] [client] adding wikiName=CcchengX, loginName=ccchengx, referer: ...
These messages occur when I:
  1. Setup userBase at the top node of my LDAP that include more than 40000 users under my "LoginFilter"
  2. When user browse some specific topic like UserList
  3. Sometimes user get "internal server error" msg in the browser and fail to see the topics.
Does "adding wikiName" means adding something into LDAPContrib cache? What is the timing of this kind of backend actions? What is the limitation of scalibility? Please Help!!!

-- MagicYang - 17 Dec 2007

These messages are displayed if you enable the debug flag in LdapContrib. They show you which records are stored into the LDAP cache. The maximum age of these records is configurable. If this time interval expires, the cache gets refreshed completely. It defaults to every 24h. You can trigger updating the LDAP cache hitting the red button on the LdapContrib topic. Another option is to have a cronjob that triggers the update offline.

-- MichaelDaum - 18 Dec 2007

Thanks Michael. Could you kindly tell me how to run LdapContrib by command-line because I want to add it in my cronjob?

perl ./twiki/lib/TWiki/Contrib/LdapContrib.pm??

I got some errors like "Can't locate Unicode/MapUTF8.pm in @INC (@INC c...." and I think I am fail!

BTW, I map LDAP groups. These groups appear in my TWikiGroups page but actual group topics are not exist like screen capture below:

And I can't use these groups for access control. How can I do?

-- MagicYang - 20 Dec 2007

There's a patch for the %GROUPS% tag of TWiki-4.1.2 that comes with the LdapContrib. It is also available on TWiki.org.

Triggering a refresh for the LDAP cache via a cronjob is done like this:

  • disable automatic cache aging: $TWiki::cfg{Ldap}{MaxCacheAge} = 0;
  • add a cronjob that updates the LDAP cache 0:05 every day:
    5 0 * * * cd <twiki-install-path>/bin && ./view <strike>refreshcache</strike>refreshldap=on Main/WebHome >/dev/null
-- MichaelDaum - 20 Dec 2007

Hi, Michael:

I apply the patch but still have some problems:

  1. LDAP groups look ok in my TWikiGroups page:
  2. I create a TWiki group based on LDAP groups but it seems have some problem (Is it WikiName problem?)
  1. I try to setup my access control like "Set ALLOWTOPICVIEW = Main.Org-00604706" but didn't work, either...=(
-- MagicYang - 21 Dec 2007

Try normaliting group names. This will take out the -. Not sure if that will cure the problem. But it is worth a try.

-- MichaelDaum - 21 Dec 2007


Sorry that I don't know how to normalize my group name! Does LdapContrib has a setting to do the normalize?

The LDAP can't change becuase it's my company's wide used LDAP and the org ID I use (cn) is the only LDAP attribute that is suitable for the group name....

-- MagicYang - 24 Dec 2007

Dear Michael:

I have a big problem about LdapContrib performance influence, the table below shows my experiment on my site:

Scenario Ldap Search User Cnt Map group Refresh Cache View Edit Cancel Logout Login
Small scope ~1 ~550 X ~2 ~2.5 ~2.5 ~3.5 ~4 ~3.5
Small scope with groups ~1 ~550 V(130 groups) ~2.5 ~2.5 ~2.5 ~4 ~4.5 ~3.5
Large scope ~5 ~20000 X ~20 ~20 ~20 ~40 ~40 ~21
Large scope with complex search 6~9 ~23000 X ~21 20~23 ~21 35~40 ~40 ~23

  • All # in the table is in Second! More user mapped means slower activity in every aspect (view, edit, cancel=save+view...)
  • Ldap Search means same filter search string query time in LdapBrowser
HELP! What can I do? (BTW, there is a strange oops process after view or edit that also take some time running...)

-- MagicYang - 24 Dec 2007


I found my mod_perl not enable and I think it might be the root cause of performance problem. Then I followed the step in ApacheConfigGenerator to add some content in my twiki.conf and also put a "mod_perl_startup.pl" in /twiki/tools. Now I think my mod_perl is working because I see "httpd" process running (occupy CPU) instead of "view" or "edit" process.

The result is:

  • Sometimes my action (ex: view, edit, logout) become faster (about 2~4sec) but only SOMETIMES!
  • My login account is twyang and it was shown in TwyanG (wikiword mapped by LdapContrib) in twiki but now it is shown in twyang and I have problem in access control now! Originally TwyanG is in admin group but now twyang is not.
Does anybody have experience about this? HELP again!

-- MagicYang - 25 Dec 2007


I need to change my comment in the previous notes:

  1. The cache (mod_perl) works and the speed become very unstable & unpredictable.
    Sometimes slow but sometimes fast for the same action.
  2. Login wiki name problem investigation:
    1. When I login with name twyang (User page TwyanG was created before mod_perl enabled) and browse topic "CommitteeTicCEI", the name looked ok!
    2. When I browse to topic "CommitteeTIC", the name at the left changed!!
    3. When I browse back to topic "CommitteeTicCEI", the name still have problem!
    4. Login with an account y_darcy (User page YDarcY was created before mod_perl enabled) and I received a notification of new topic "y_darcy" created!
    5. Actually these new account topics are not created but listed in WebTopicList!
  3. All these situations only occurred when Mod_Perl enabled and everything is ok if I switch off the Mod_Perl.
-- MagicYang - 26 Dec 2007

Here are some more investigations:

  1. Per Michael's suggestion, I disabled automatic cache aging by setting $TWiki::cfg{Ldap}{MaxCacheAge} = 0; and add daily night run cronjob to generate cache
  2. But it seems that this setting create many problems like:
    1. When I didn't enable mod_perl, all actions became very slow and took almost the same time (20s) as "cache refresh" (this didn't happen when I set MaxCacheAge =86400 even I didn't enable mod_perl)
    2. When I enable mod_perl, user account wiki name problem occerred!
  3. Now I set MaxCacheAge back to 86400s, remove cronjob and enable mod_perl, everything looks ok!
I am curious about:
  1. At the beginning my mod_perl is not enabled but only a few topics (ex: UserList, TWikiGroups) is slow and that is the reason I start all the tuning actions. WHY? I think all topics should slow because I don't have any perl accelerator!
  2. Why MaxCacheAge =0 fail?
Even the performance look ok now! I still have a group wiki name (Org-xxx) problem.....=(

Does anybody have good suggestion or solution?

-- MagicYang - 27 Dec 2007

Yes, normalizing the groups is an LdapContrib setting have a look at LdapContrib#Group_settings. Mod-perl or any other perl accelerator should have no influence on LdapContrib anymore. Btw. which version of LdapContrib did you install. Please use the very latest that I uploaded last week.

On behalf of the caching. I will rethink the implementation once again and try to work around the most common hassles. Basically, TWiki only needs the user records from LDAP that have logged in at least once. It does not need to handle access control for someone who never logged in anyway. So instead of fetching a subset of all user records that might log in, those are added one by one when they log in. So LdapContrib will maintain a list of all user records to be updated in its internal cache. This has two advantages: (1) no more bulk downloads of LDAP records (2) user records don't have to be identified by a common base DN; most LDAP directories store user records all over the place anyway which means that the base for all user records is the root.

If you are using LdapContrib in a big setup and you want this to be implemented as fast as possible, please think about funding this work and contact me.

-- MichaelDaum - 28 Dec 2007

Hi, Michael:

Always thanks for your help! But after I set $TWiki::cfg{Ldap}{NormalizeGroupName} = 1;, I still get Org-xxxx group names. It seems that Org-xxxx is considered as normalized but it will cause problem as I mentioned before. =(

Could we have a patch for this problem?

-- MagicYang - 02 Jan 2008

MagicYang, please do me a favour and use Bugs:LdapContrib to report bugs. Thanks.

-- MichaelDaum - 02 Jan 2008

Hello everyone. We work with TWiki, the LdapContrib and OpenLDAP for more then one year without any problems. Then i saw that the new version supports to change a user's LDAP password, a feature i was missing. Today i use the configure script to upgrade the LdapContrib but now i can't see any LDAP Groups in the TWikiGroups topic and the access control doesn't work.

-- RaphaelWeis - 04 Jan 2008

Did you populate the LdapContrib 's cache? If not, please go to the TWiki.LdapContrib topic in your installation and press the big red button saying "Refresh Cache".

-- MichaelDaum - 04 Jan 2008

yes i did:

updating cache
called refreshCache
called refreshUsersCache()
called search(filter=objectClass=*, base=ou=users,dc=clavis-bremen,dc=info, scope=sub, limit=0, attrs=uid,mail,cn)
proxy bind
found 44 entries
no loginName for ou=users,dc=clavis-bremen,dc=info ... skipping
done reading pages
got 43 keys in cache
flushing db to disk
replacing working copy

when i open the TWikiGroups topic:

called getListOfGroups()

-- RaphaelWeis - 04 Jan 2008

Aren't there any lines like adding wikiName ... and adding groupName ... ? Please check your $TWiki::cfg{Ldap}{MapGroups} settings.

-- MichaelDaum - 04 Jan 2008

No, there is only this one line. here are the Ldap settings:

$TWiki::cfg{Ldap}{UserBase} = 'ou=users,dc=clavis-bremen,dc=info';
$TWiki::cfg{Ldap}{LoginAttribute} = 'uid';
$TWiki::cfg{Ldap}{WikiNameAttribute} = 'cn';
$TWiki::cfg{Ldap}{NormalizeWikiNames} = 1;
$TWiki::cfg{Ldap}{LoginFilter} = 'objectClass=*';
$TWiki::cfg{Ldap}{MapGroups} = 1;
$TWiki::cfg{Ldap}{GroupBase} = 'ou=groups,dc=clavis-bremen,dc=info';
$TWiki::cfg{Ldap}{GroupAttribute} = 'cn';
$TWiki::cfg{Ldap}{GroupFilter} = 'objectClass=*';
$TWiki::cfg{Ldap}{TWikiGroupsBackoff} = 1;
$TWiki::cfg{Ldap}{MemberAttribute} = 'uniqueMember';
$TWiki::cfg{Ldap}{MemberIndirection} = 1;
$TWiki::cfg{Ldap}{MaxCacheHits} = -1;
$TWiki::cfg{Ldap}{MaxCacheAge} = 86400;
$TWiki::cfg{Ldap}{Exclude} = 'TWikiGuest, TWikiContributor, TWikiRegistrationAgent, TWikiAdminGroup, NobodyGroup';
$TWiki::cfg{Ldap}{PageSize} = 600;
$TWiki::cfg{Ldap}{Debug} = 1;
$TWiki::cfg{Ldap}{UseSASL} = 0;
$TWiki::cfg{Ldap}{SASLMechanism} = 'PLAIN CRAM-MD5';
$TWiki::cfg{Ldap}{NormalizeLoginName} = 0;
$TWiki::cfg{Ldap}{AllowChangePassword} = 1;
$TWiki::cfg{Ldap}{SecondaryPasswordManager} = 'none';
$TWiki::cfg{Ldap}{NormalizeGroupName} = 0;

-- RaphaelWeis - 05 Jan 2008

same problem for me also, i took a look at the code, it seems this line has troubles:

my $result = $this->refreshUsersCache(\%tempData); if (defined($result) && $this->{mapGroups}) { $result ||= $this->refreshGroupsCache(\%tempData); }

the if branch is excuted, but refreshgroups doesn't get called

-- MarcoRomano - 06 Jan 2008

Found the error the next release v2.1.1 should fix Bugs:Item5214 and Bugs:Item5192. Please have a test.

-- MichaelDaum - 07 Jan 2008

Tested and working, however even if LDAP Users and Groups are properly shown in TWikiGroups topic, I don't have any of my ldap users in the TWikiUsers topic. Is this normal?

-- MarcoRomano - 07 Jan 2008

Yes. Add an %LDAPUSERS% somewhere to show a list of users known to LdapContrib and having logged in at least once.

-- MichaelDaum - 08 Jan 2008

Thanks Michael, another question: how do I reference an LDAP group for access control purposes? To be more specific: I'd like to add an LDAP group to be allowed to edit a certain web.

-- MarcoRomano - 08 Jan 2008

Just use its name as it is shown on the TWikiGroups. Example:

   * Set ALLOWTOPICCHANGE = clavis-sales-roma 

-- MichaelDaum - 08 Jan 2008

Ehm... what about LDAP group names with spaces?

-- MarcoRomano - 08 Jan 2008

These are invalid inside TWiki and need to be normalized so that you get a proper id. Try $TWiki::cfg{Ldap}{NormalizeGroupName} = 1;

-- MichaelDaum - 08 Jan 2008

Thank you Michael, group ACL now works! There is still another thing: I tried writing %LDAPUSERS% in a page but it's not getting replaced with the list of users. Instead I can read %LDAPUSERS% in the rendered page.

-- MarcoRomano - 08 Jan 2008

Dear Michael:

I install newest version of LdapContrib and NewUserPlugin and have a question! I set NormalizeWikiNames & NormalizeLoginName both to 1 and login with my LDAP account ("cn" of my LDAP account is twyang)

I can login with twyang, Twyang, or TWYANG and corresponding topics (twyang.txt, Twyang.txt or TWYANG.txt) are created! But some (ex: twyang or TWYANG) topics are invalid TWiki topics and produce some problems.

I want to re-test Bug 5192 but I can't see my LDAP groups in TWikiGroups (TWikiGroupsBackoff =1 & NormalizeGroupName =1)

Do you have any good suggestion?

-- MagicYang - 09 Jan 2008

What is the setting of your $TWiki::cfg{Ldap}{WikiNameAttribute} ?

-- MichaelDaum - 09 Jan 2008

My WikiNameAttribute & LoginAttribute are both "cn" (the value in LDAP are all lower case like twyang)

-- MagicYang - 10 Jan 2008

That's bad unusual as no proper WikiWord can be derived from it to get you a valid HomeTopic. Try to use (a list of) other attributes, e.g. by using the attributes that keep your first and last name.

-- MichaelDaum - 10 Jan 2008

I don't know where is the problem and "cn" is the only attribute I can use.

I use a tricky method to avoid this situation. (Add some javascript code in login page to transfer user typed account name to wikiword like TwyanG)...=Q

Now my biggest problem is that I can't see my LDAP groups in TWikiGroups. I will try to get some logs here!

-- MagicYang - 10 Jan 2008


I am maintaining an intranet wiki based on TWiki. We have a corporate Active Directory with LDAP interface, and I tried to use the LdapContrib? plugin to help with this. Here are the settings I used (edited machine and proxy user details for security) -

$TWiki::cfg{Ldap}{Host} = 'ldaphost.domain.com';
$TWiki::cfg{Ldap}{Port} = 389;
$TWiki::cfg{Ldap}{Version} = '3';
$TWiki::cfg{Ldap}{Base} = 'dc=domain,dc=com';
$TWiki::cfg{Ldap}{BindDN} = 'CN=proxyuser,DC=domain,DC=com';
$TWiki::cfg{Ldap}{BindPassword} = 'proxypassword';
$TWiki::cfg{Ldap}{SSL} = 0;
$TWiki::cfg{Ldap}{UseSASL} = 0;
$TWiki::cfg{Ldap}{Debug} = 1;
$TWiki::cfg{Ldap}{UserBase} = 'dc=domain,dc=com';
$TWiki::cfg{Ldap}{LoginFilter} = 'objectClass=user';
$TWiki::cfg{Ldap}{LoginAttribute} = 'sAMAccountName';
$TWiki::cfg{Ldap}{WikiNameAttribute} = 'cn';
$TWiki::cfg{Ldap}{NormalizeWikiNames} = 1;
$TWiki::cfg{Ldap}{NormalizeLoginName} = 0;
$TWiki::cfg{Ldap}{AllowChangePassword} = 0;
$TWiki::cfg{Ldap}{SecondaryPasswordManager} = 'TWiki::Users::HtPasswdUser';

I get the following errors in the log file -

[Wed Jan 09 22:13:49 2008] [error] [client] updating cache
[Wed Jan 09 22:13:49 2008] [error] [client] called refreshCache
[Wed Jan 09 22:13:49 2008] [error] [client] called refreshUsersCache()
[Wed Jan 09 22:13:49 2008] [error] [client] called search(filter=objectClass=*, base=dc=domain,dc=com, scope=sub, limit=0, attrs=sAMAccountName,mail,cn)
[Wed Jan 09 22:13:49 2008] [error] [client] error in search: failed to connect to ldaphost.domain.com: IO::Socket::INET: connect: Permission denied
[Wed Jan 09 22:13:49 2008] [error] [client] error refeshing the user cashe: failed to connect to ldaphost.domain.com: IO::Socket::INET: connect: Permission denied

and also when logging in, I get the following errors -

[Wed Jan 09 22:16:45 2008] [error] [client] called checkPassword(loginuser, passU), referer: http://wiki.domain.com/cgi-bin/login/TWiki/TeamsAndPeopleBar
[Wed Jan 09 22:16:45 2008] [error] [client] dn not found, referer: http://wiki.domain.com/cgi-bin/login/TWiki/TeamsAndPeopleBar

Please let me know if I have done anything wrong, or if I need to do something special to get over this error.


-- NarendraLoganathan - 10 Jan 2008

I figured it out. It had to with FC7's default SELinux settings once I set it to be permissive, everything was fine.


-- NarendraLoganathan - 10 Jan 2008

Dear Michael:

When I login, I got:

constructed a new LdapContrib object, referer: .../twiki/bin/login/Main/WebHome?origurl=/twiki/bin/view/Main/WebHome
called checkPassword(TwyanG, passU), referer: .../twiki/bin/login/Main/WebHome?origurl=/twiki/bin/view/Main/WebHome

When I press refresh cache button, I got:

updating cache, referer: .../twiki/bin/view/Main/WebHome?topic=TWiki.LdapContrib
called refreshCache, referer: .../twiki/bin/view/Main/WebHome?topic=TWiki.LdapContrib
called refreshUsersCache(), referer: .../twiki/bin/view/Main/WebHome?topic=TWiki.LdapContrib
called search(filter=&(objectCategory=person)(objectClass=user)(!(userAccountControl:1.2.840.113556.1.4.803:=2)), base=DC=tsmc, scope=sub, limit=0, attrs=cn,mail,cn), referer: .../twiki/bin/view/Main/WebHome?topic=TWiki.LdapContrib
proxy bind, referer: .../twiki/bin/view/Main/WebHome?topic=TWiki.LdapContrib
found 200 entries, referer: .../twiki/bin/view/Main/WebHome?topic=TWiki.LdapContrib
adding wikiName='Htliud', loginName='htliud', dn=CN=htliud,......, referer: .../twiki/bin/view/Main/WebHome?topic=TWiki.LdapContrib
adding wikiName='Kwliu', loginName='kwliu', dn=CN=kwliu,......, referer: .../twiki/bin/view/Main/WebHome?topic=TWiki.LdapContrib
done reading pages, referer: .../twiki/bin/view/Main/WebHome?topic=TWiki.LdapContrib
got 22787 keys in cache, referer: .../twiki/bin/view/Main/WebHome?topic=TWiki.LdapContrib
called search(filter=&(&(cn=Org-006*)(memberOf=*))(member=*), base=OU=Groups,OU=OrgRoot,DC=tsmc, scope=sub, limit=0, attrs=cn,member), referer: .../twiki/bin/view/Main/WebHome?topic=TWiki.LdapContrib
found 118 entries, referer: .../twiki/bin/view/Main/WebHome?topic=TWiki.LdapContrib
adding groupName='Org00623000', dn=CN=Org-00623000,......, referer: .../twiki/bin/view/Main/WebHome?topic=TWiki.LdapContrib
adding groupName='Org00622006', dn=CN=Org-00622006,......, referer: .../twiki/bin/view/Main/WebHome?topic=TWiki.LdapContrib
flushing db to disk, referer: .../twiki/bin/view/Main/WebHome?topic=TWiki.LdapContrib
replacing working copy, referer: .../twiki/bin/view/Main/WebHome?topic=TWiki.LdapContrib
finishing, referer: .../twiki/bin/view/Main/WebHome?topic=TWiki.LdapContrib

We can see that the account's wikiName (ex: Kwliu) is not a TWiki valid wikiname. The groupName looks good now. (ex: Org00623000)

But when I browse TWikiGroups, I only got:

constructed a new LdapContrib object

and nothing appeared in the page!

Some of my settings are:

$TWiki::cfg{Ldap}{LoginAttribute} = 'cn';
$TWiki::cfg{Ldap}{WikiNameAttribute} = 'cn';
$TWiki::cfg{Ldap}{NormalizeWikiNames} = 1;
$TWiki::cfg{Ldap}{NormalizeLoginName} = 1;
$TWiki::cfg{Ldap}{GroupAttribute} = 'cn';
$TWiki::cfg{Ldap}{MemberAttribute} = 'member';
$TWiki::cfg{Ldap}{MemberIndirection} = 1;
$TWiki::cfg{Ldap}{TWikiGroupsBackoff} = 1;
$TWiki::cfg{Ldap}{NormalizeGroupName} = 1;
$TWiki::cfg{Ldap}{MapGroups} = 1;

-- MagicYang - 11 Jan 2008

The logs look fine. The "WikiName" you get is also as I would expect it looking at your settings.

You have to remember, that the LdapContrib tries to construct a WikiName based on the users' LDAP attributes. This is a sort of "display name" that TWiki then uses to refer to this user further on. I.e. it uses this WikiName to construct a home topic for her/him.

This WikiName must be a proper WikiWord (camel case).

However, if you don't feed enough information to the LdapContrib, it will fail to derive a proper WikiWord and use it as a display name for the users.

Try feeding it more WikiNameAttributes.

-- MichaelDaum - 11 Jan 2008

I am running TWiki-4.2.0-rc2 and LdapContrib v2.11, as soon as i switch to LdapUser as the PasswordManager I get the following error message : Can't locate object method "fetchUsers" via package "TWiki::Users::LdapUser" at /data/www/twiki/lib/TWiki/Users/TWikiUserMapping.pm line 1028. Does anyone have a suggestion, I am stuck right now smile

-- MauriceKok - 11 Jan 2008

Maurice, LdapContrib has not yet been ported to TWiki-4.2. But good news: funding has been approved to port it to the latest TWiki. That is, the next major release, LdapContrib-3.0 is under way, and it will include support for TWiki-4.2. Stay tuned.

-- MichaelDaum - 11 Jan 2008

Thanks for your quick reaction, guess I'll have to wait then smile When do think 3.0 will be available, weeks or months, please let me know if I can help to test it.

-- MauriceKok - 11 Jan 2008

Dear Michael:

It's my fault! I forgot to set {UserMappingManager} to LdapUserMapping so that my LDAP groups were not generated in TWikiGroups. It's ok now!

But I find another problem and I think there is a bug somewhere. I set {NormalizeWikiNames} & {NormalizeLoginName} to both TRUE and login with account y_kevin3 (LDAP cn=y_kevin3). YKevin3 topic is created but variable


returns Y_kevin3! So I can use Y_kevin3 only to do authorization control but this will confuse TWiki user a lot because the user topic is YKevin3!

NewLdapUserTemplate will render out

   * Set ALLOWTOPICCHANGE = Main.YKevin3 

and user can't modify his own page!

-- MagicYang - 12 Jan 2008


-- MichaelDaum - 12 Jan 2008

Another strange situation is: I have a line " Set GROUP = ...,Y_kevin3" to form a group. (Because I can use Y_kevin3 to do authorization only) But it shows "....,YKevin3" in topic TWikiGroups and this group definition is workable!

Should I report this as a bug?

-- MagicYang - 13 Jan 2008

Yes, please.

-- MichaelDaum - 14 Jan 2008


Do you have any idea as to when this might be updated for 4.2? I did an install of 4.2, and when I log in it shows my login name, not my normalized Wiki Name. Have you experienced this with 4.2? Hopefully it is a minor thing that 4.2 broke and can be quickly updated.


-- ScottJaffa - 24 Jan 2008


I get the same issue as ScottJaffa. The current LdapContrib is simply not compatible with the newest release of TWiki. Unfortunately this means I have to delay an update to 4.2.0!

Wiki names fail to resolve (it shows login name), and worse, groups fail to resolve. Access control on our system is built around groups based in LDAP, and thus our access control scheme completely fails for existing 4.1.x webs brought over into the new 4.2.x unless they are modified to use local groups (which we'd rather not).

LDAP queries work inside topics via LdapNgPlugin (eg: look up someone's email or something), so clearly I'm set up correctly. In fact, all of my LDAP settings identically mirror an existing TWiki 4.1.x install on a different server that is correctly integrated with LDAP and functioning perfectly.

If anyone has an idea as to a timeline as to when a 4.2.x-compatible LdapContrib will be released, please share!

PS: I made a note on the LdapContrib topic under the Installation header (Note: LdapContrib may not function 100% correctly with TWiki version 4.2.x. This is a known issue and an update is pending). Had I seen something like that, I wouldn't have gone through the headache and would have checked the Dev and Bugs topics before installing.


-- KevinFirko - 28 Jan 2008


at the bottom of every plugin topic there is a PackageForm which contains the entry TestedOnTWiki indicating the versions a particular plugin was tested on. If your version is not listed there, it pays to check the Dev topic to see whether there are any reports on compatibility. Having said that, I would also be interested to know whether there is already a timeline for the next release available (without pushing Michael too much...). smile

-- MartinKaufmann - 28 Jan 2008

About end of Feb.

-- MichaelDaum - 28 Jan 2008

Thanks Michael! If you want to deploy any test runs on my TWiki, don't hesitate to get in touch.

Martin, thanks for the feedback. Though, I think I would have still benefited from being spoonfed to accept that it was "Known" 4.2 wasn't compatible, rather than simply "Not Tested", which is the scope of PackageForm... Hence my addition to the topic.

-- KevinFirko - 28 Jan 2008

Dear Michael,

I am running LdapContrib v2.1.1 on TWiki-4.1.2 and opnldap. I have a problem with the TWikiGroups page. When I hit 'Refresh Cache' no LDAP-Groups are shown on the page. From the logs i got the following:

called search(filter=objectClass=posixGroup, base=ou=Groups,dc=company,dc=de, scope=sub, limit=0, attrs=cn,memberUid), referer: https://wiki.company.de/bin/view/Main/TWikiGroups?refreshldap=on&refresh=on
4: Sizelimit exceeded, referer: https://wiki.company.de/bin/view/Main/TWikiGroups?refreshldap=on&refresh=on
error refeshing the groups cashe: 4: Sizelimit exceeded, referer: https://wiki.company.de/bin/view/Main/TWikiGroups?refreshldap=on&refresh=on

I have tried to set a higher 'sizelimit' in the slapd.conf, but that did'nt solve the problem. I also found a chatlog with the same problem I think, but without the solution: http://koala.ilog.fr/twikiirc/bin/irclogger_log/twiki?date=2007-06-01,Fri

And there is another thing: The config option LdapSSL did'nt worked for me. I had to change LdapContrib.pm like this:

> use Net::LDAPS;
<   #$this->writeDebug("called connect");
<   #$this->writeDebug("dn=$dn", 2) if $dn;
<   #$this->writeDebug("passwd=***", 2) if $passwd;
>   $this->writeDebug("called connect");
>   $this->writeDebug("dn=$dn", 2) if $dn;
>   $this->writeDebug("passwd=***", 2) if $passwd;
<   $this->{ldap} = Net::LDAP->new($this->{host},
>   $this->{ldap} = Net::LDAPS->new($this->{host},


-- MarcTeichgraeber - 29 Jan 2008

Thanks for the SSL patch.

As you are using OpenLDAP there's a better way to set limits.

sizelimit size.soft=500
sizelimit size.hard=unlimited
sizelimit size.pr=1000

This will remove limits from paged results, each page at max 1000, while keeping a limit of 500 entries when fetching unpaged search results.

-- MichaelDaum - 29 Jan 2008

Thank you! That worked.

-- MarcTeichgraeber - 29 Jan 2008

Nops guys! You don't need patch LdapContrib to use SSL! It works fine only install of the libio-socket-ssl-perl. I got the libnet-ldap-perl (in my debian installation) and when I tried to use the Net::LDAPS the perl warn the missing of IO/Socket/SSL.pm that it's contained in libio-socket-ssl-perl in my installation.

From the LdapContrib side, it enough to configure:

  • $TWiki::cfg{Ldap}{Host} = 'ldaps://ldaphost.domain.com';
  • $TWiki::cfg{Ldap}{Port} = 636;
I hope this help and I suggest to update the dependencies list with this warning around the LDAP over SSL.

-- AmadeuJunior - 30 Jan 2008

I started the beta round with LdapContrib-2.99.2 that is supposed to run on TWiki-4.2 as well as TWiki-4.1.2. Checkins are tracked at Bugs:Item5303.

Please have a try.

-- MichaelDaum - 30 Jan 2008

Thanks, Amadeu, for clarifying that. I removed the explicit SSL flag from the LdapContrib config and added an optional CPAN dependency.

-- MichaelDaum - 30 Jan 2008

The beta looks good so far. Much thanks for getting it out so quickly.

-- ScottJaffa - 30 Jan 2008

Wow, that didn't take long! I tested it quickly and so far everything works (LDAP is an Active Directory server). Perfect! Thanks a lot for all the work you've put in!

-- MartinKaufmann - 30 Jan 2008

Thank you Michael! With first tests, we can log against a Windows 2000 AD server fine. I will test it more throuroughly in the next days but so far so good!

-- ColasNahaboo - 31 Jan 2008

Next beta LdapContrib-2.99.3. This one works around a bug in TWiki-4.2 that may result in an infinit recursion in TWiki::Users::TWikiUserMapping::getEmails()

-- MichaelDaum - 01 Feb 2008

Does LdapContrib allow me to filter which users I want to be able to log in based on another attribute? I think that the LoginFilter is used to determine which accounts are users, but I want to do something like: (&(userAccount)(Locked=FALSE)). I tried putting that into the LoginFilter but it didn't have the desired effect.

-- DeanSpicer - 01 Feb 2008

This should work. Please enable debugging and watch out for the lines that get reported when updating the ldap cache.

-- MichaelDaum - 04 Feb 2008

Got it to work. After refreshing the cache everything works as expected. Thanks for your patience. Very nice work on the contrib BTW.

-- DeanSpicer - 04 Feb 2008

One more question. I noticed that even thought the "locked user" is not allowed to log in and not showing in the TWikiUsers list, he still shows up in the TWikiGroups as belonging in a group. Is this behavior intended? Is there a way I can exclude this user from being listed in the groups?

-- DeanSpicer - 04 Feb 2008

(Running 2.99.3) -- It doesn't appear to respect usernames added to the TWikiAdminGroup. The TWikiGroups topic lists all LDAP groups (good), but the TWikiAdminGroup at the bottom DOES NOT INCLUDE the users listed in SET GROUP in the TWikiAdminGroup topic as it did in 4.1.x.

Most annoying is the fact that the internal admin login link now seems broken. When I click it, it no longer even suggests a username. If I fill in the user/pass, I get redirected to Main. The WORST part of this all is I can type ANYTHING I want into the user/pass and it just goes on through. Unfortunately instead of saying "TWikiAdminUser", it says the old (LDAP) mapped username of the REMOTE HOST (we're using ApacheLogin with mod authnz ldap)

These issues have only manifested AFTER installing the 2.99.3 ...

-- KevinFirko - 04 Feb 2008

Update: So, I can get it to work if in the TWikiAdminGroup topic I SET GROUP to equal an LDAP group that includes my desired admin users. This is good.

However, I cannot list usernames separated by commas here, so the LDAP group is my only option. Listed users simply aren't recognized, and they don't appear as members in the TWikiGroups topic. This works fine on a 4.1.x install (+ old LdapContrib) that I have running where individual WikiNames as well as an LDAP group are listed. It is kind of frustrating to provide a comma separated list of users and not have one of them get "picked up" by TWiki, but again, going all-out LDAP and creating an admin group in LDAP is a decent workaround.

Also, the session/internal admin link continues to fail, but I'm not worried since the LDAP route worked for me, but this is probably a bug for at least some users.

-- KevinFirko - 05 Feb 2008

I can confirm Kevin's issue with TwikiAdminGroup. If I SET GROUP = MartinKaufmann, %GROUPS% still only shows TWikiAdminUser as the only member of TWikiAdminGroup. In our setup, creating a new LDAP group for TWiki isn't an option - at least at the moment.

Btw, I can't confirm Kevin's earlier issue about the internal admin link being broken. This one does work for me (and is the only way I can change protected topics).

-- MartinKaufmann - 05 Feb 2008

I noticed (running 2.99.2) that I had to use the login name when setting the group, then it worked (SET GROUP = deans).

-- DeanSpicer - 05 Feb 2008

Notso sure if this may still be a problem for current versions of TWiki and LdapContrib, but I had to patch TWiki/Users.pm in expandUserList() in order to have LDAP groups parsed OK if their uid contain "-" :

-     $names =~ s/\s*([$TWiki::regex{mixedAlphaNum}_\.\,\s\%]*)\s*(.*)/$1/go;
+     $names =~ s/\s*([$TWiki::regex{mixedAlphaNum}_\-\.\,\s\%]*)\s*(.*)/$1/go;

-- OlivierBerger - 05 Feb 2008

Dean, Thanks for your help. Using the login name instead of the wikiname for the GROUP definition did the trick. That might be something for the documentation.

-- MartinKaufmann - 05 Feb 2008

I don't know if this behavior is intended, but using wikinames to define the groups is more intuitive in my opinion. I'm hoping that Michael has a comment here.

-- DeanSpicer - 05 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

Ok, I have the same issue here as you guys (GROUP members are ignored if defined by their WikiName). A fix will be nice for the final version of course, but in the meantime I did not see any other problem.

-- ColasNahaboo - 08 Feb 2008

There seems to be a general issue regarding user mapping under 4.2. See for example TWikibug:Item5339. It looks related but I'm not sure if it's the same issue.

-- MartinKaufmann - 08 Feb 2008

Just a trick that can help others to debug their installation. By applying the attached 1-line patch LdapBypassLogin.patch you can log in as any user by giving any password, to test user name mapping. To be used only on your private dev instance, of course...

-- ColasNahaboo - 12 Feb 2008

Hi all made a 2.99.4 pre-release and put it out on LdapContrib. There is an issue reported at GroupADIntegrationNotWorking that I am going to investigate. But 2.99.4 is pretty close to final.

-- MichaelDaum - 14 Feb 2008

I have made a patch for a problem with using LDAP (actually AD) groups for access to topics. The code fails for groups because the group members are created using the WikiName rather than the login name as the login name. It still does not work for nested groups. With this patch, moving a user into or out of a group will control access to a topic which relies directly on that group (need to have refreshed the cache of course).

Patch is

--- LdapUserMapping.pm.orig   2008-02-14 14:05:24.000000000 +0000
+++ LdapUserMapping.pm   2008-02-14 14:09:33.000000000 +0000
@@ -120,7 +120,7 @@
     foreach my $name (@$ldapMembers) {
       my $wikiName = $this->{ldap}->getWikiNameOfLogin($name) || $name;
-      my $memberUser = $this->{session}->{users}->findUser($wikiName); 
+      my $memberUser = $this->{session}->{users}->findUser($name); 
       if ($this->isGroup($memberUser)) {
         foreach my $user (@{$this->groupMembers($memberUser)}) {

-- NigelWhitley - 14 Feb 2008

Just thought i'd add that I have managed to get LDAPContrib to authenticate users from Active Directory... with TWiki itself running on windows server.

Unicode::MapUTF8 doesn't seem to work in ActiveState Perl, but it was very simple to edit LDAPContrib.pm and switch from MapUTF8 to UTF8simple.

UTF8simple has far less dependencies and is written in pure Perl (no C)

-- DavidWall - 28 Feb 2008

Does the {Ldap}{PageSize} setting control how many results the LdapContrib object tries to get from LDAP? I've set mine to several different numbers (200, 500, 25, 0) and when I turn on LdapContrib debugging and watch the debug entries in /var/log/httpd/ssl_error_log, it looks like it's trying to grab every entry out of LDAP...there's no search limit. <pre> [Thu Feb 28 16:06:46 2008] [error] [client xxx.xxx.xxx.xxx] called search(filter=objectclass=person, base=ou=people,dc=mysite,dc=com, scope=sub, limit=0, attrs=uid,mail,givenname,sn), referer: https://www.mysite.com/wiki/bin/configure </pre>

-- MattMencel - 28 Feb 2008

Is it possible to somehow allow users from 2 or more different "UserBase" OU's to authenticate with LdapContrib?

Our users have the base of:


but the IT staff are based in:


-- DavidWall - 05 Mar 2008

That's a feature people have been asking for a couple of times. In short: not possible right now, you will have to make the UserBase the common parent DN.

-- MichaelDaum - 05 Mar 2008

I'm having a strange issue, i've had LdapContrib working - I authenticate with username dwall (LoginAttribute), and my WikiNameAttribute is cn, which is "David Wall".

This has been working for a few days now, however today upon logging in it displays my wiki name as "dwall" instead of "David Wall".

I haven't changed any TWiki or LDAP settings, just cleaned up some excess packages. Any ideas why my wiki name is now equal to my login attribute instead of cn?

-- DavidWall - 11 Mar 2008

I refreshed the cache, and it has returned to normal. :-s

-- DavidWall - 11 Mar 2008


-- MichaelDaum - 11 Mar 2008

Having a lot of trouble with LDAP and Wiki / Getting this error when trying to open the wiki:

Software error: Can't locate Net/LDAP.pm in @INC (@INC contains: c:\PROGRA~1\TWiki\twiki\lib . C:/perl/site/lib C:/perl/lib c:\PROGRA~1\TWiki\twiki\lib/CPAN/lib//arch c:\PROGRA~1\TWiki\twiki\lib/CPAN/lib//5.8.8/MSWin32-x86-multi-thread c:\PROGRA~1\TWiki\twiki\lib/CPAN/lib//5.8.8 c:\PROGRA~1\TWiki\twiki\lib/CPAN/lib/) at c:\PROGRA~1\TWiki\twiki\lib/TWiki/Contrib/LdapContrib.pm line 21. BEGIN failed--compilation aborted at c:\PROGRA~1\TWiki\twiki\lib/TWiki/Contrib/LdapContrib.pm line 21. Compilation failed in require at c:\PROGRA~1\TWiki\twiki\lib/TWiki/Users/LdapUserMapping.pm line 22. BEGIN failed--compilation aborted at c:\PROGRA~1\TWiki\twiki\lib/TWiki/Users/LdapUserMapping.pm line 22. Compilation failed in require at (eval 33) line 3.

I have done this:

To use an LDAP server for authentication you have to use the PasswordManager LdapUser. To Use groups defined in LDAP enable the UserMappingManager LdapUserMapping. (see the Security Setting section)

And here is my cfg file:

$TWiki::cfg{Ldap}{Host} = 'server'; $TWiki::cfg{Ldap}{Port} = 389; $TWiki::cfg{Ldap}{Version} = '3'; $TWiki::cfg{Ldap}{Base} = 'dc=local810,dc=net'; $TWiki::cfg{Ldap}{BindDN} = 'cn=BINDuser,dc=local810,dc=net'; $TWiki::cfg{Ldap}{BindPassword} = 'Password; $TWiki::cfg{Ldap}{UseSASL} = 0; $TWiki::cfg{Ldap}{SASLMechanism} = 'PLAIN CRAM-MD5 EXTERNAL ANONYMOUS'; $TWiki::cfg{Ldap}{Debug} = 0; $TWiki::cfg{Ldap}{UserBase} = 'ou=local810,dc=local810,dc=net'; $TWiki::cfg{Ldap}{LoginFilter} = 'objectClass=posixAccount'; $TWiki::cfg{Ldap}{LoginAttribute} = 'uid'; $TWiki::cfg{Ldap}{WikiNameAttribute} = 'cn'; $TWiki::cfg{Ldap}{NormalizeWikiNames} = 1; $TWiki::cfg{Ldap}{NormalizeLoginName} = 0; $TWiki::cfg{Ldap}{AllowChangePassword} = 0; $TWiki::cfg{Ldap}{SecondaryPasswordManager} = 'none'; $TWiki::cfg{Ldap}{GroupBase} = 'ou=SecurityGroups,dc=my,dc=domain,dc=com'; $TWiki::cfg{Ldap}{GroupFilter} = 'objectClass=posixGroup'; $TWiki::cfg{Ldap}{GroupAttribute} = 'cn'; $TWiki::cfg{Ldap}{MemberAttribute} = 'memberUid'; $TWiki::cfg{Ldap}{MemberIndirection} = 0; $TWiki::cfg{Ldap}{TWikiGroupsBackoff} = 1; $TWiki::cfg{Ldap}{NormalizeGroupName} = 0; $TWiki::cfg{Ldap}{MapGroups} = 1; $TWiki::cfg{Ldap}{MaxCacheAge} = 86400; $TWiki::cfg{Ldap}{PageSize} = 500; $TWiki::cfg{Ldap}{Exclude} = 'TWikiGuest, TWikiContributor, TWikiRegistrationAgent, TWikiAdminGroup, NobodyGroup '; 1;

Someone please help!


-- StephenGarriques - 13 Mar 2008

Did you install the perl-ldap package Net::LDAP?

-- MichaelDaum - 13 Mar 2008

how do I install that / I get errors when I try to

-- StephenGarriques - 13 Mar 2008

Stephen, to more effectively help you out it is better tp move this support question to the Support web. Open a new support question there.

-- PeterThoeny - 14 Mar 2008

Alright It won't install the Net::LDAP package, Having a problem with dependencies. It goes all the way to Net::SSLeay and I get this and the installation process stops.

Cannot determine perl version info from lib/Net/SSLeay.pm Cannot determine license info from lib/Net/SSLeay.pm * Could not find OpenSSL If it's already installed, please set the OPENSSL_PREFIX environment variable accordingly. If it isn't installed yet, get the latest version from http://www.openssl.org/.

-- StephenGarriques - 14 Mar 2008

I am having trouble with LDAP lookup after a successful Kerberos authentication via Apache. Is the update that is tested/supported under Twiki 4.2 far away. I feel guilty reporting errors/bugs and asking for help on an unsupported release.

-- AaranStent - 15 Mar 2008

CharlieHerron who just registered changed the "tested on" field and the "modification policy" and the "installed on TWikki.org" form fields in the LdapContrib page. Please verify for accuracy and fix.

-- PeterThoeny - 21 Mar 2008

Reverted it.

-- MichaelDaum - 21 Mar 2008

How is the support state for the Twiki Version 4.2 - Is this beta usable?

-- MatthiasSutter - 25 Mar 2008

I am not a Perl expert and can't make the patch! Does anybody have a solution to solve the recursive group problem? (NigelWhitley - 14 Feb 2008)

-- MagicYang - 03 Apr 2008

I do a little more investigation and here is my result:

  1. I didn't apply any patch (including patch from NigelWhitley - 14 Feb 2008)
  2. LdapContrib version is 2.99.4 and TWiki is 4.2.0
  3. My test user account is directly a member of user defined group AaaGroup and LDAP group Org00604706
  4. LDAP group Org00604706 is shown correctly in the topic TWikiGroups with my test user in it!
  5. I setup topic's ALLOWTOPICVIEW to following groups and see if my account can read the topic or not

Group Group type Use have access right correctly
AaaGroup (contains test account directly) user defined YES
BbbGroup (contains AaaGroup) user defined YES
Org00604706 (contains test account directly) from LDAP NO
CccGroup (contains Org00604706) user defined NO
-- MagicYang - 03 Apr 2008

I am seeing some strange behaviour with access control. Using TWiki V4.2 and latest LDAP Contrib (obtained yesterday).

I am using LDAP to authenticate via apache, and use the LDAPContrib for mapping but I am not using LDAP groups (i.e. MapGroups is off, and TWikiGroupsBackoff is on)

The user login to Wiki Name mapping is happening fine, and it correctly recognizes me when I login.

I am listed as a member of TWikiAdminGroup yet I cannot modify that topic unless I log in as the admin user.

It seems that the access controls are defaulting to using the default twiki mapping (I can see it loading up TWikiUsers) but since users are not listed there, the access controls fail.

Even if I use NewUserPlugin, it only creates the user topic, not the listing in TWikiUsers.

Why is the group access control not being done via LDAP Contrib? Surely the LdapUserMapping should be doing this not TWikiUserMapping?

I do not want our users to have to register. How is this done? Many thanks.

-- DarrenElkerton - 16 Apr 2008

Additional - if I add my login name (not wikiname) to TWikiAdminGroup it seems to work. Unfortunately, this is not desirable behaviour. Seems like the mapping is not happening when resolving group membership?

-- DarrenElkerton - 16 Apr 2008

We have mapping issues as well. It seems that not every login name maps to the proper wikiname. Those that are not alpha-numeric (legacy system), such as uid=shiva.goudarzi, do not map to the wikiname within the cache.db file. Instead, a new topic is created, but not in wikiname syntax: shivagoudarzi. So, access control for Shiva is ineffective, and Shiva has more than one wikiname associated with her login name, depending on the capitalization used when logging in. But in the cache.db file, there's only one wikiname associated with the loginName shiva.goudarzi.

Any insight is appreciated, as we've already modified LdapContrib plugin at the code level to generate proper wikiname syntax in the cache.db file. Now, we just need all names to be picked up from cache.db, which apparently is not a natural tendency.

-- ShivaGoudarzi - 16 Apr 2008

I was seeing the group mapping issues also, but a change I made to the Users.pm has fixed this for me, I'm not too sure of the ramifications of it though... I have Twiki 4.2 and Ldap Contrib 2.99.4

The change to Users.pm

--- Users.pm.orig       2008-04-22 11:48:33.000000000 +1000
+++ Users.pm    2008-04-21 17:07:13.000000000 +1000
@@ -540,7 +540,7 @@
         next unless $ident;
         return 1 if( $ident eq $wn );
         if( $this->isGroup( $ident )) {
-            return 1 if( $this->isInGroup( $user, $ident ));
+            return 1 if( $this->isInGroup( $wn, $ident ));
     return 0;

ALSO, my LDAP server does not support the "paged" control, so the caching mechanism would not work for me, LdapContrib would only download the first 100 users and nothing more, so no one could log in if they weren't in that bunch.

I made this change to the LdapUser.pm

--- LdapUser.pm.orig    2008-04-11 13:17:23.000000000 +1000
+++ LdapUser.pm 2008-04-22 11:59:11.000000000 +1000
@@ -122,6 +122,9 @@
   # guest has no password
   return 1 if $login eq $TWiki::cfg{DefaultUserWikiName};

+  # Run cache check before getting the user record to ensure that this user is in the cache
+  $this->{ldap}->checkCacheForLoginName($login);
   # get user record
   my $dn = $this->{ldap}->getDnOfLogin($login);
   $this->{ldap}->writeDebug("dn not found") unless $dn;

This seems to avoid any caching of users who do not access the wiki, which is my desired behaviour.

Other Info: I am not using {Ldap}{MapGroups}, I am using:

-- SimonHarrison - 22 Apr 2008

I can also confirm the group mapping issues using TWiki 4.2.0 and LdapContrib 2.99.4 as mentioned by a few users above. I can also confirm that using user names in group definitions works. I referenced the patch by SimonHarrison above in the comments of TWikibug:Item5303 so hopefully it will be resolved soon.

-- KavehAhmadian - 26 Apr 2008

In response to the comment by SeanSleicher on 15 Mar 2007. As MichaelDaum pointed out, you can add %LDAPUSERS% to the TWikiUsers topic to get a listing of users.

However, I have a AD setup very similar to yours, where groups are not as useful as a user's "department" which happens to be an organizational unit. I replicated the setup SeanSleicher provided, and all the OUs are brought into TWiki as groups and show up on the TWikiGroups page, but they are not populated with users. Does anyone have a similar setup and can this be accommodated by LdapContrib?

-- KavehAhmadian - 26 Apr 2008

Hi, I get the following error on 2.99.4 : search: Use of uninitialized value $loginName in string eq at /usr/share/perl5/TWiki/Users/LdapUserMapping.pm line 299.

I suspect it's because my user is like that : uid: berger_o cn: berger_o berger_o Which renders its wikiname as BergerOBergerO ...

Any ideas ?

-- OlivierBerger - 28 May 2008

Does anyone know how to get UTF8simple to work with LdapContrib?

I'm running Active Perl 5.8.8 build 820 on a win32 platform and of course the Unicode modules do not work on win32 platforms. DavidWall mentioned he is successfully running UTF8simple on win32 but I don't have the Perl expertise to change LdapContrib from MapUTF8 to UTF8simple.

Can anyone give the steps required to implement this? Thanks in advance.

-- MikeLowrie - 30 May 2008

To all trying to use LdapContrib on a TWiki-4.2 engine: please have a look at the patches to TWiki listed in Bugs:Item5118.

-- MichaelDaum - 03 Jun 2008

The fix listed there helped, but LdapContrib didn't provide login names to TWiki in CUID format. We had to correct that using the fixes at LdapUserMappingWithDotInLoginname.

Otherwise the dots in our login names precluded a match against the CUIDs with _46 in place of the period, and we are now able to use LDAP group or user names as well as wiki names in access lists.

-- MattEverson - 05 Jun 2008

Okay, I'm using LdapContrib in combination with Active-Directory, LdapNgPlugin, GluePlugin and LoginNameAliasesPlugin. Thanks to LoginNameAliasesPlugin the UserName was shortened to just givenName,sn. Whatever I set in LocalSite.cfg, Twiki welcomes me all the time with "Hello myfirstnameandlastname" yes, in small letters. Even if I try to set WikiNameAttribute just to "givenName" Twiki welcomes me with my givenName+sn in small letters.

$TWiki::cfg{Ldap}{LoginAttribute} = 'uid'; $TWiki::cfg{Ldap}{WikiNameAttribute} = 'givenName'; $TWiki::cfg{Ldap}{NormalizeWikiNames} = 1; $TWiki::cfg{Ldap}{NormalizeLoginNames} = 1;

Any ideas?

-- JuergenTolksdorf - 03 Jul 2008

Hi everyone,

we're using twiki for a few month. FIrst we used the normal TWiki authentication, now we decided to switch to the LDAP authentication.

I installed the LDAPContrib and i think this is working correctly (in TWiki Groups all Groups from our AD and the Users are displayed). But the Users in TWikiUsers are missing. I've the following problem:

1. The Login with LDAP accounts is possible, but all names that aren't registered with the normal TWiki authorisation are integrated like this: "givenName,sn?" and the Questionmark allows you to create a new topic.

Now I think, there is something like the NewUserPlugin missing or s.th. else.

Or, what isn't working correctly ?

Best Regards

-- CarstenCrampen - 10 Jul 2008

Yep, you got it: NewUserPlugin is the natural completion of that setup. Note, that LDAP accounts naturally never show up in TWikiUsers. The standard registration agent maintains that page automatically - a thing that is not needed using LDAP. Replace all of the page's content with an %LDAPUSERS% to display the know LDAP users that logged in to TWiki at least once. That's more or less what you where looking for, I hope.

-- MichaelDaum - 10 Jul 2008

Hello again, yes thank, now it's working. I installed GluePlugin, LdapNGPlugin and NewUserPlugin. The problem is that until the activation of the NewUserPlugin the TWiki sites aren't displayed correctly -> In the WebLeftBar I miss the Icons, the Webs have no color .... and variables are displayed with the code instead of the correct link.

Now I disabled the plugin to make the TWiki working correctly.

-- CarstenCrampen - 14 Jul 2008

Sorry, it is not a problem with this Plugin. WYSIWYG Editor mislabeled s.th.



-- CarstenCrampen - 14 Jul 2008

I've just finished setting up LdapContrib and it works well. I curently have both LdapContrib and Apache LDAP authentication configured. Is there a way to pass the login info from the Apache authentication to TWiki so that users only have to log in once?


-- ChristopherMoore - 16 Jul 2008

Hi again,

is it correct that the ldap login crampenc that is correctly mapped to CarstenCrampen differs from the TWiki login CarstenCrampen?

If I login with crampenc, I'm welcome as "CarstenCrampen" but I've other rights as if i had logged in with the TWiki user CarstenCrampen !?

-- CarstenCrampen - 17 Jul 2008

Any reason why the plugin doesn't use TWiki::Func::getWorkArea(), and instead uses the $session->{store}->getWorkArea('LdapContrib'); (which relies on= {RCS}{WorkAreaDir}=) ?

-- OlivierBerger - 15 Aug 2008

Because the LdapContrib objects is needed very early in TWiki's initialization process. At that stage $TWiki::Plugins::SESSION isn't initialized yet, rendering all of the TWiki::Func API useless. So either I take over initializing the Func API from within the LdapContrib constructor, or I use the $session object right away.

-- MichaelDaum - 15 Aug 2008

Just FYI, the Debian package I maintain at http://picoforge.int-evry.fr/projects/twldapdeb/ is now candidate for an official Debian package and is expected (if all goes well) in the unstable distribution any time soon.

-- OlivierBerger - 17 Aug 2008

Also, I've tested LdapContrib together with CasLoginContrib (that I've just packaged for TWiki) and a CAS server relying on the same LDAP server, and that seems to offer a very valid SSO solution over LDAP.

-- OlivierBerger - 17 Aug 2008

Great news!

-- MichaelDaum - 17 Aug 2008

FYI, the package has just entered the Debian unstable archive.

-- OlivierBerger - 17 Sep 2008

I just uploaded a small patch to connect to the LDAP server using TLS, it lacks useful help texts in the configuration dialog, support for CA directories (only one file supported atm) and probably much more, but it "works for me". smile

-- WolfgangKarall - 03 Oct 2008

Neat and clean. Thanks a lot, Wolfgang. Will add it to the next release.

-- MichaelDaum - 04 Oct 2008

Hey guys, here's a new beta to use LdapContrib on 4.2.3: LdapContrib.zip. Please have a try. Note, that with this release - 2.99.7 - the package does not support previous TWiki versions any more, that is TWiki 4.1.x and TWiki-4.2.[012]. The internals got much too hairy to accommodate support for all of these TWiki engines. As you probably know, the internal user code api of TWiki changed a couple of times during the 4.2 release cycle so that supporting these versions is virtually impossible. You shouldn't be running any previous TWiki-4.2.x versions anyway. So here's yet another reason to upgrade to 4.2.3 if you didn't already >:)

I also added Wolfgang's TLS code and added the few bits that where missing to also have CA directories etc.

-- MichaelDaum - 06 Oct 2008

Please note, that the class LdapUser has been renamed to LdapPassword. You will have to adjust your password manager settings:

$TWiki::cfg{PasswordManager} = 'TWiki::Users::LdapPassword';

-- MichaelDaum - 15 Oct 2008

I hope this is the right place to raise my question. I just setup an instance of Twiki 4.2.3 using the Beta LdapContrib plugin and I'm getting the following error.

Failed to create LdapContrib work area. Check your setting of {RCS}{WorkAreaDir}

I already checked the WorkAreaDir setting in the LocalSite.cfg file and it's set correctly. The permission is fine. I'm able to use the local authentication method fine bue as soon as I switch to using the Ldap method, it gives me this error. Any help is appreciated.


-- NamLe - 24 Oct 2008

I'm using TWiki 4.2.3 with LdapContrib beta attached to this site. It seems work but plugin does not support the "paged" control. I couldn't to get access to web where I should have access. Plugin shows groups and username correctly but I get deny when I try to display "secret" web, where I should have access.I'm using LDAP based on Windows 2003 server.

I tested TWiki 4.2.3 with official LdapContrib and there permission worked fine, but anoying was username. On this version my username was MateuszPles, but it should be mateusz.ples. And it worked on TWiki 4.1.2.

I tried to find resolution on Bugs:LdapContrib and on this page, but all changes i did, didn't work.

Do you know this case?? Could you help me resolve problem or point to another site where is resolution?? Upgrade to the newest version is imposible now without this correction frown


-- MateuszPles - 08 Nov 2008

Nam: Not sure if the contrib does that for you, but may be you need to create a twiki/working/work_areas/LdapContrib/ directory.

-- PeterThoeny - 08 Nov 2008

I have LDAP working (love it!) but need to make some final tweaks. I am trying to change the login page's help by changing the skin as suggested in LdapAuthenticatedTwikiModifications . I have also read through much skin-related info but just can't get it to work! We are using 4.2.3. My skins are "set skin=ldapchanges,pattern" but I still see the help as defined in login.classic.tmpl !!?? I'd really appreciate any suggestions. Thanks.

-- GarryFerguson - 09 Dec 2008

Ignore above. I've sorted it. I had to modify lib/TWiki.spec though!

-- GarryFerguson - 09 Dec 2008

Hi, the normalization of WikiNames is hardcoded to the latin1 aka ISO8859-1 charset, as that's what the source file is saved in. I made a patch that is translating the german umlauts and sharp-s to their ASCII counterparts and takes UTF-8 into consideration. This patch is needed to have my WikiNames be translated correctly from LDAP. The same treatement should probably be given to the normalizeLoginName function. What do you think?

Do other people not have problems with LDAP umlauts when they are running TWiki in UTF8? Anyway, here's the preliminary patch:

--- ./lib/TWiki/Contrib/LdapContrib.pm.orig   2009-03-11 07:49:05.000000000 +0100
+++ ./lib/TWiki/Contrib/LdapContrib.pm   2009-03-11 08:22:53.000000000 +0100
@@ -1000,16 +1000,30 @@
   # remove @mydomain.com part for special mail attrs
   # SMELL: you may have a different attribute name for the email address
-  # replace umlaute
-  $name =~ s//ae/go;
-  $name =~ s//oe/go;
-  $name =~ s//ue/go;
-  $name =~ s//Ae/go;
-  $name =~ s//Oe/go;
-  $name =~ s//Ue/go;
-  $name =~ s//ss/go;
+  # replace umlaute, take site charset into consideration
+  # use \x instead of real values to make it independent of this file's encoding
+if (1) {
+  if ($TWiki::cfg{Site}{CharSet} =~ /^utf-?8$/i) {
+    $name =~ s/\xc3\x84/Ae/go;
+    $name =~ s/\xc3\x96/Oe/go;
+    $name =~ s/\xc3\x9c/Ue/go;
+    $name =~ s/\xc3\x9f/ss/go;
+    $name =~ s/\xc3\xa4/ae/go;
+    $name =~ s/\xc3\xb6/oe/go;
+    $name =~ s/\xc3\xbc/ue/go;
+  } else {
+    $name =~ s/\xc4/Ae/go;
+    $name =~ s/\xd6/Oe/go;
+    $name =~ s/\xdc/Ue/go;
+    $name =~ s/\xdf/ss/go;
+    $name =~ s/\xe4/ae/go;
+    $name =~ s/\xf6/oe/go;
+    $name =~ s/\xfc/ue/go;
+  }
   my $wikiName = '';
+  ### This breaks with umlauts in UTF-8 strings, although mixedAlphNum contains [[:upper:][:lower:]]
   foreach my $part (split(/[^$TWiki::regex{mixedAlphaNum}]/, $name)) {
     $wikiName .= ucfirst($part);

-- UlrichSpoerlein - 21 Mar 2009

Thank you Ulrich, this should go into the next release.

-- PeterThoeny - 22 Mar 2009

Seems the change in October of the password Manager from LdapUser to LdapPassword causes the SELECTCLASS to fail in lib/Twiki.spec (I am using 4.3.0). I had to add the LdapPassword to the SELECTCLASS to get it to work. Is this expected? Should I file a bug?

-- TimAnderson - 2009-04-14

I uplouded new my LdapContrib beta version for TWiki 4.3.1. Below changes I've made:

  • fixed geting emails for groups and login names
  • allow utf8 chars in passwords; all strings from LDAP are tainted, even if it comes from mod_ldap via remote_user; only use LDAP query as a last resort to check if a user exists; prevent explicitly excluded login names to be added to the cache
  • fixing nested ldap groups
  • added RewriteGroups and MergeGroups feature
  • extended transliteration of utf8 chars to polish chars (Bartosz Dziuda)
-- MateuszPles - 2009-07-20


There are a few problems with your changes for TWiki 4.3.1:

lib/TWiki/LoginManager/LdapApacheLogin.pm needs to be changed to:

$authUser = TWiki::Sandbox::untaintUnchecked($authUser);

lib/TWiki/LoginManager/LdapApacheLogin.pm requires several changes:

Change line 239 to:

require TWiki::ListIterator;

Add this to line 323:

require TWiki::ListIterator;

Once these changes are in place, it works fine with 4.3.1 under TWiki. I'll bundle these changes up and make an attachment.

diff -crB old/lib/TWiki/LoginManager/LdapApacheLogin.pm new/lib/TWiki/LoginManager/LdapApacheLogin.pm
*** old/lib/TWiki/LoginManager/LdapApacheLogin.pm       2009-07-17 10:33:56.000000000 -0700
--- new/lib/TWiki/LoginManager/LdapApacheLogin.pm       2009-07-30 16:32:46.000000000 -0700
*** 39,45 ****
    # explicitly untaint it as this string comes from LDAP, and all strings
    # from LDAP are tainted, even if they come via mod_ldap
!   $authUser = Foswiki::Sandbox::untaintUnchecked($authUser);
    # remove kerberos realm
    $authUser =~ s/\@.*$//g if defined $authUser;
--- 39,45 ----
    # explicitly untaint it as this string comes from LDAP, and all strings
    # from LDAP are tainted, even if they come via mod_ldap
!   $authUser = TWiki::Sandbox::untaintUnchecked($authUser);
    # remove kerberos realm
    $authUser =~ s/\@.*$//g if defined $authUser;
diff -crB old/lib/TWiki/Users/LdapUserMapping.pm new/lib/TWiki/Users/LdapUserMapping.pm
*** old/lib/TWiki/Users/LdapUserMapping.pm      2009-07-17 11:12:30.000000000 -0700
--- new/lib/TWiki/Users/LdapUserMapping.pm      2009-07-30 16:32:12.000000000 -0700
*** 236,242 ****
  sub eachUser {
    my $this = shift;
!   require Twiki::ListIterator;
    my @allCUIDs = ();
--- 236,242 ----
  sub eachUser {
    my $this = shift;
!   require TWiki::ListIterator;
    my @allCUIDs = ();
*** 319,324 ****
--- 320,328 ----
  sub eachGroupMember {
+   require TWiki::ListIterator;
    my ($this, $groupName, $seen) = @_;
    $this->{ldap}->writeDebug("called eachGroupMember($groupName)");

-- TimothyDemarest - 2009-07-31

Thank you Mateusz and Timothy for working on this important piece of code. Once stable feel free to update the SVN repository and package. ReadmeFirst has details how to get started with extension development.

-- PeterThoeny - 2009-08-01

Peter, can I commit my new LdapContrib to svn and release new version?

-- MateuszPles - 2011-03-31

Yes, thank you! Please make sure that it is tested on TWiki-5.0.

-- PeterThoeny - 2011-03-31

FYI : http://twiki.org/cgi-bin/view/Support/SID-01398

-- OlivierGuillard - 2012-02-09

FYI : http://twiki.org/cgi-bin/view/Support/SID-01398

Note : I just tested, and it works : I can log in using ldap uid and passwd ( that are stored in PosixAccount attr )

I would like to be able to list my users ( aka : to list users that are registered in ldap in when pointing to Main/UserList ): is there anyway to do that ? I haven't managed to list my users

-- OlivierGuillard - 2012-02-09

A rewrite of this LdapContrib came up in Support.SID-01429. From what I have learned using this contrib I see the following items that could be improved.

  • Better/easier way to debug when configuring the settings. LDAP has so many knobs to dial, so good debg/error handling is key.
  • Scaling issue if LDAP has > 10k users. I have seen an installation with 50k+ users in LDAP, the refresh takes a few minutes (and a race condition happens if the user gets impatient and reloads the screen). I don't see a reason to cache all users when one user tries to authenticate. It could cache just this one user, or may be 64 at a time. The cache expire could be tracked for each user.
  • Ability to configure the contrib:
    1. compose WikiWord from first name and last name (and TWiki should keep track and resolve name collisions, e.g. JohnSmith, JohnSmith2, etc), or
    2. delegate this to TWiki (e.g. users login with their ldap name, and users need to register in TWiki to get a WikiName)
  • Support LDAP groups, e.g. transpose groups in LDAP into the TWiki space.
-- PeterThoeny - 2012-03-20

I enhanced the LdapContrib with a new {Ldap}{CaseSensitiveLogin} setting, default is now case insensitive to make Windows users happy.

-- PeterThoeny - 2012-06-08

I enhanced LdapContrib so that it supports GSSAPI mechanism for SASL authentication.

-- HideyoImazu - 2012-06-21

Here are additons for Croatian charaters transliteration if LDAP is used as user backend. Without this WikiNames are generated in unwanted way. e.g. Perodero ends as PeroDero which is not wanted. It shoud be PeroZdero.

[root@wiki5 Contrib]# diff -p /tmp/LdapContrib.pm LdapContrib.pm
*** /tmp/LdapContrib.pm 2012-08-06 14:25:00.564543039 +0200
--- LdapContrib.pm      2012-08-06 14:02:41.868662170 +0200
*************** sub transliterate {
*** 1512,1517 ****
--- 1512,1530 ----
      $string =~ s/\xc5\xb9/Z/go; # Z acute
      $string =~ s/\xc5\xbc/z/go; # z dot
      $string =~ s/\xc5\xbb/Z/go; # Z dot
+     #OptimIT addons - Croatian specific
+     $string =~ s/\xc5\xa1/s/go; # s caron
+     $string =~ s/\xc5\xa0/S/go; # S caron
+     $string =~ s/\xc4\x91/d/go; # d stroke
+     $string =~ s/\xc4\x90/D/go; # D stroke
+     $string =~ s/\xc4\x8d/c/go; # c caron
+     $string =~ s/\xc4\x8c/C/go; # C caron
+     $string =~ s/\xc4\x87/c/go; # c acute
+     $string =~ s/\xc4\x86/C/go; # C acute
+     $string =~ s/\xc5\xbe/z/go; # z caron
+     $string =~ s/\xc5\xbd/Z/go; # Z caron
    } else {
      $string =~ s/\xe0/a/go; # a grave
      $string =~ s/\xe1/a/go; # a acute
*************** sub transliterate {
*** 1593,1598 ****
--- 1606,1624 ----
      $string =~ s/\x01\x79/Z/go; # Z acute
      $string =~ s/\x01\x7c/z/go; # z dot
      $string =~ s/\x01\x7b/Z/go; # Z dot
+     #OptimIT addons - Croatian specific
+     $string =~ s/\x01\x61/s/go; # s caron
+     $string =~ s/\x01\x60/S/go; # S caron
+     $string =~ s/\x01\x11/d/go; # d stroke
+     $string =~ s/\x01\x10/D/go; # D stroke
+     $string =~ s/\x01\x0d/c/go; # c caron
+     $string =~ s/\x01\x0c/C/go; # C caron
+     $string =~ s/\x01\x07/c/go; # c acute
+     $string =~ s/\x01\x06/C/go; # C acute
+     $string =~ s/\x01\x7e/z/go; # z caron
+     $string =~ s/\x01\x7d/Z/go; # Z caron

    return $string;

-- GoranJakovljevic - 2012-08-06

Thank you Goran for providing this patch. This is now in SVN. Extension topic is updated as well.

-- PeterThoeny - 2012-08-07

LdapContrib Enhancements:

-- Terje Ness Andersen - 2013-08-27

Cool, thanks Terje!

-- Peter Thoeny - 2013-08-29

Functionality implemented with tag TWikibug:Item7332 and TWikibug:Item7331. Updated the LdapContrib topic as well, and tested the extension. Things seem to be working fine.

-- Terje Ness Andersen - 2013-09-03

Nice! Thank you Terje!

-- Peter Thoeny - 2013-09-04

See TWikibug:Item7498 for numerous enhancements deployed into the LdapContrib add-on: database locks, preserving users deleted from LDAP, not adding all LDAP users - only updating the existing ones, ++

A "ldapdbtest" tool is added to test the reliability of the database, very handy when enhancing the logic which writes to and reads from the database.

Also: have a look at TWiki:Plugins.LdapContribAdminPlugin which provides an admin panel to administer the LdapContrib database. I was wondering if this admin panel should be a part of LdapContrib, and not as a separate plug-in. Anyone?

-- Terje Ness Andersen - 2014-05-21

Hi,I am having the same doubt as DhavalShah had.I need to map the users based on the user attribute in LDAP.In my LDAP directoty there is an user atribute called title.I need to map user groups based on that and manage ACL

-- Gobinath Manokaran - 2014-06-25

Gobinath: Not sure I understand. If you want to change the login to the 'title' attribute, set the {Ldap}{LoginAttribute} accordingly. Best to open a question in the Support forum if you need further assistance.

-- Peter Thoeny - 2015-10-10

NOTE: Please use Bugs:LdapContrib to report bugs. Thanks.

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatpatch LdapBypassLogin.patch r1 manage 0.4 K 2008-02-12 - 17:38 ColasNahaboo a patch, for DEBUG USE ONLY to allow login as any user with any password
Unknown file formatpatch LdapContrib.TLS.patch r1 manage 1.5 K 2008-10-03 - 22:56 UnknownUser A preliminary patch to allow using TLS when connecting to the LDAP server.
Unknown file formatgz LdapContrib.patch.gz r1 manage 0.6 K 2009-07-31 - 21:24 TimothyDemarest Patch diff against MateuszPles's myLdapContrib4.3.1.zip which fixes a few issues and works with TWiki 4.3.1
Compressed Zip archivezip LdapContrib.zip r4 r3 r2 r1 manage 39.0 K 2008-10-06 - 13:34 UnknownUser new beta for 4.2.3
Compressed Zip archivezip LdapContrib_4.30.zip r1 manage 54.7 K 2011-03-31 - 06:24 MateuszPles New LdapContrib 4.30 for TWiki 5.0 with new features. Based on LdapContrib by MichaelDaum from Foswiki
Compressed Zip archivezip myLdapContrib.zip r1 manage 52.2 K 2009-03-14 - 12:41 MateuszPles It's fixed LdapContrib for TWiki 4.2.3. This fixes based on fixes by MichaelDaum from Foswiki.
Compressed Zip archivezip myLdapContrib4.3.1.zip r2 r1 manage 38.9 K 2009-07-20 - 07:21 MateuszPles My new beta version for TWiki 4.3.1
Edit | Attach | Watch | Print version | History: r259 < r258 < r257 < r256 < r255 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r259 - 2015-10-10 - PeterThoeny
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.