---+!! %TOPIC% %TOC% ---++ Introduction This package offers basic LDAP services for Foswiki and offers authentication of wiki users by binding to an LDAP server as well as incorporate LDAP user groups into access control. Optionally, if you need an interface to query your LDAP directory and display the results in a topic install the <nop>LdapNgPlugin which will make use of the <nop>LdapContrib services. This work is a rewrite of the <nop>LdapPlugin by Gerard Hickey while bringing authentication, user management and other LDAP applications onto a common base. This package downloads all relevant records from your LDAP server into a local cache the first time you use it. This can take a noticeable period of time depending on the size of your LDAP database. This cache will be refreshed on a configurable interval (defaults to once a day). You can also disable automatic refreshing and refresh the <nop>LdapContrib's cache manually using the "Refresh Cache" button below. Read the documentation of =MaxCacheAge= in the section "Performance Settings" in <a href="%SCRIPTURLPATH{"configure"}%">configure</a>. %STARTSECTION{"refreshbutton"}%<!-- --> %BUTTON{ "%MAKETEXT{"%IF{ "defined label" then="%label%" else="Refresh Cache"}%" }%" icon="arrow_refresh" href="%SCRIPTURLPATH{"view"}%/%BASEWEB%/%BASETOPIC%?refreshldap=on" }% %CLEAR% <!-- -->%ENDSECTION{"refreshbutton"}% Tip: You can add this button on any page by adding <verbatim> %INCLUDE{"%SYSTEMWEB%.LdapContrib" section="refreshbutton"}% </verbatim> to it. ---++ LDAP questionnaire Before you can further configure the LDAP connection you will have to answer a set of basic questions about your LDAP server. These are: 1 What's the host name (or IP address) of the LDAP server (e.g. ldap.my.domain.com)? 1 What port does it listen to LDAP requests (e.g. 389)? 1 Does your LDAP Server use SASL to authenticate connections? If so which authentication mechanism does it use (EXTERNAL, DIGEST-MD5, ...)? 1 Do you have a kind of "proxy" user that the wiki can use to perform the initial connection? You need its DN and credentials. Advice: don't use the LDAP admin account, you only need a simple user that has read access to all of the directory (or the relevant parts); it does not need any write access. 1 What is the "base dn" of the directory (e.g. =dc=my,dc=domain,dc=com= )? 1 What is the common root/branch for all users? For example, Are they all found under =ou=people,dc=my,dc=domain,dc=com= or are they are scattered all over the place? 1 What is the common root/branch where all groups are defined (e.g. ou=group,dc=my,dc=domain,dc=com)? 1 What object class do user records have (e.g. =objectClass=organizationalPerson= )? 1 What object class do group records have (e.g. =objectClass=group= )? 1 Which attribute of a user record should be used to log in (must be unique)? 1 Which attribute(s) of a user record do you want to use to construct a <nop>WikiName (used to display them online, pointing to their homepage)? 1 What's the name attribute of a group? 1 Which attribute in a group record defines its members (e.g. member or memberUid)? Note, that if the member attribute of a group is a DN you need to enable "member indirection" (see [[#Membership]]). Collect the answers to these questions either yourself using your favorite LDAP browser, or ask your friendly LDAP admin. ---++ Authentication To authenticate wiki users using your LDAP server you have to register the <nop>LdapPasswdUser class as the so called <nop>PasswordManager. This is done by adding the following lines in the =lib/LocalSite.cfg= configuration file (or by using the =configure= tool alternatively): <verbatim>$Foswiki::cfg{PasswordManager} = 'Foswiki::Users::LdapPasswdUser';</verbatim> There is a further option to fallback to the normal authentication mechanism by defining a secondary password manager. This allows you to create native wiki accounts, e.g. a <nop>WikiAdmin account and authenticate him without LDAP. Use the following setting to fallback to a htpasswd based authentication. <verbatim>$Foswiki::cfg{Ldap}{SecondaryPasswordManager} = 'Foswiki::Users::HtPasswdUser';</verbatim> So whenever authentication against LDAP fails, this second password manager will be used. ---++ User Groups LDAP group records can be used in access control lists by registering a <nop>UserMappingManager implementation. This is done by adding the following to your =lib/LocalSite.cfg= configuration file (or by using the =configure= tool alternatively): <verbatim>$Foswiki::cfg{UserMappingManager} = 'Foswiki::Users::LdapUserMapping';</verbatim> In addition you can decide if you want to _add_ the LDAP groups or use LDAP groups solely. This is controlled by the <nop>WikiGroupsBackoff flag. If switched on then LDAP groups will be added. If there's a name clash LDAP groups take precedence. If switched off <nop>WikiGroups are ignored. You might decide in not using your LDAP groups but still map login names to <nop>WikiNames. Both, LDAP user groups _and_ name mapping is done by the <nop>UserMappingManager. So to make use of name mapping but _not_ its group feature, register the <nop>LdapUserMapping implementation for the <nop>UserMappingManager but disable the <nop>MapGroups setting. When multiple groups in your LDAP directory clash on the same group name you might actually wish to merge these groups as used online in your wiki. This is done using the =MergeGroups= flag. When disabled, clashing groups are reported as a warning in the server log files when the LDAP cache is refreshed. ---++ Membership LDAP servers follow different schemata to define "membership". They store the information either using a set of unique ids in the group object (posixGroup) or the full DNs of the user objects (groupOfNames). In the latter case the user objects' unique ids have to be fetched separately based on their distinguished name. This mode has to be switched on using the =MemberIndirection= setting. The reverse relation, where the _user objects_ hold membership information (for example using a =memberOf= attribute) is maintained by some LDAP servers automatically. Those that encode membership this way _only_ are not supported by the <nop>LdapContrib yet. Furthermore, user objects may have one _primary_ group attribute. This is a simple value that stores the id of a default group that user is member of. This attribute is defined by specifying the =PrimaryGroupAttribute= setting a. <nop>LdapContrib reads membership information as they are stored in the group objects, and may map the member object indirectly to the login name. In addition any "primary group" setting stored in the user objects is consulted as well. ---++ Normalization of login, wiki and group names <nop>LdapContrib reads three kinds of names from your LDAP server and reuses this information as needed. These are the login names - used to log in -, the <nop>WikiNames - used to display users online -, and the group names - used in access control lists. The <nop>WikiName can be generated by setting the parameters * =WikiNameAttributes=: a comma sedparated list of LDAP attributes taht are then assembled to form a proper <nop>WikiName * =NormalizeWikiName=: boolean flag; if set a couple of extra operations are performed to generate a proper <nop>WikiName, i.e. removing illegal characters. * =WikiNameAliases=: a comma separated key=value list of <nop>WikiNames to be mapped to another <nop>WikiName (DEPCRETATED: use =RewriteWikiNames= instead). * =RewriteWikiNames=: a list of rewrite rules; see below Given the setting <verbatim> $Foswiki::cfg{Ldap}{WikiNameAttributes} = 'givenName,sn'; $Foswiki::cfg{Ldap}{NormalizeWikiNames} = 1; </verbatim> The =givenName= and =sn= (surname) LDAP attributes will be fetched and concatenated to form a proper <nop>WikiName, so that "givenName=Hans-Peter,sn=Schwarze" will result in the <nop>WikiName "<nop>HansPeterSchwarze". The login name can be normalized by enabling the <verbatim>$Foswiki::cfg{Ldap}{NormalizeLoginNames} = 1;</verbatim> setting. This will also strip off any '<nop>@...' string from the login as found when logging ing using the mail attribute or when using !LdapContrib in combination with a kerberos single sign on strategy. In most scenarios users prefer not to care about case sensitivity of their login names for convenience. If however your authentication requires an exact match of the login name including case sensitivity, the use <verbatim>$Foswiki::cfg{Ldap}{CaseSensitiveLogin} = 1;</verbatim> to switch that on. Similar to the <nop>WikiName of a user, group names can be normalized using <verbatim>$Foswiki::cfg{Ldap}{NormalizeGroupNames} = 1;</verbatim> If a user in your LDAP directory changed his name, e.g. because of a marriage, this use can be mapped to his/her old account using an alias that points back from the old !WikiName to the new one. This is done using a setting like this: <verbatim>$Foswiki::cfg{Ldap}{WikiNameAliases} = 'MaryMalone=MaryForrester, ...'</verbatim> The parameter takes a comma separated list of =FromWikiName=ToWikiName=. Whenever this account is still used in an access control list, its rights will be inherited by the targeted =ToWikiName= account. Group names can be rewritten using a set of rewrite rules. This is useful when the names as stored in your LDAP directory don't satisfy your criteria for being displayed online. In conjunction with the <nop>MergeGroups flag, separate LDAP groups can be merged onto one group as it is used online in your wiki. A group rewrite rule is specified using <verbatim> $Foswiki::cfg{Ldap}{RewriteGroups} = { 'pattern1' => 'substitution1', 'pattern2' => 'substitution2', ... }; </verbatim> Each rule consists of a pattern that will be substituted in the group name as specified. The substitute can contain variables =$1=, =$2=, ... , =$5= to insert the first, second, ..., fifth bracket pair in the key pattern. (see perl manual for regular expressions). Example: <verbatim> $Foswiki::cfg{Ldap}{RewriteGroups} = { '(.*)_users' => '$1' }; </verbatim> !WikiNames can be processed similarly using the =$Foswiki::cfg{Ldap}{RewriteWikiNames}= parameter. Given the !WikiName is derived from the mail attribute, then use the following rule to strip off domain parts from the wiki name: <verbatim> $Foswiki::cfg{Ldap}{RewriteWikiNames} = { '^(.*)@.*$' => '$1' }; </verbatim> This can be further refined to prevent name clashes by adding back the domain part: <verbatim> $Foswiki::cfg{Ldap}{RewriteWikiNames} = { '^(.*)@(.*?)\..*\..*$' => '$1_$2' }; </verbatim> So given your company uses email addresses like <nop>john.doe@germany.mycompany.com and <nop>john.doe@spain.mycompany.com it will generate the wiki names <nop>JohnDoeGermany and <nop>JohnDoeSpain from it (given <nop>NormalizeWikiNames is switched on too). Another trick is to add additional LDAP attributes to the =WikiNameAttributes= that help to create unique <nop>WikiNames, and then strip off unwanted parts again with an appropriate rewrite rule. Example: <verbatim> $Foswiki::cfg{Ldap}{WikiNameAttributes} = 'givenName, sn, sAMAccountName'; $Foswiki::cfg{Ldap}{RewriteWikiNames} = { '^(.*) [^ ]+?\-adm$' => '$1 Admin', '^(.*) (?!\-adm$)[^ ]+?$' => '$1', } </verbatim> This might look wild at first but does the following: * generate a temporary <nop>WikiName concatenating the attributes according to the =WikiNameAttributes= setting, e.g. "John-Doe Smith jds", where jds is the sAMAccountName value * let's say there's also a second record for John-Doe Smith that he uses to log in * with admin rights using his =jds-adm= login. * rule 1 of the =RewriteWikiNames= will match the =jds-adm= and will generate a nice John-Doe Smith Admin, whereas * rule 2 will only match those records that don't have the =-adm= suffic at their sAMAccountName. * note that both rules only copy over the first part of the string captured in brackets (.*) over to the result leaving out the trailing sAMAccountName part. * finally the string is wikified to make it a proper <nop>CamelCase word by all non-alphabetic characters between the parts of the name ---++ <nop>WikiName clashes Depending on the choice of =WikiNameAttributes= and =RewriteWikiNames= rules your LDAP records will be mapped onto a proper <nop>WikiName. These have to be unique to represent the identity of the person granted access to Foswiki. However, while you LDAP records are unique due to their Distinguished Names, it is quite common that two independent records result in the same <nop>WikiName. That's a so called name clash. You are strongly encouraged to control the way <nop>WikiNames are generated to keep the number of name clashes as low as possible. Use appropriate rewrite rues as described above. In real world you will most probalby run into a name clash that you can't possibly resolve. In that case !LdapContrib will _enumerate_ all !JohnSmiths as they are found, calling them !JohnSmith, !JohnSmith1, !JohnSmith2, etc. Each of these maps back to a unique Distinguished Name in your LDAP directory of course. !LdapContrib tries to keep the choice which of the !JohnSmiths maps to which DN stable over time. Whenever you refresh the LDAP cache the previous <nop>WikiNames will be reused while new LDAP records will get a higher number attached to the <nop>WikiName. When !LdapContrib is building up its cache for the first time, the actual mapping is pretty arbitrary, given there are no additional means to distinguish the names. From there on !WikiNames are kept, _even when you reconfigure !LdapContrib itself_. This is the default behavior not to risk mapping a different identity to a <nop>WikiName. You still might decide to nuke the decisions once made while resolving name clashes by refreshing the ldap cache using the =refreshldap=force= url parameter (compared to =refreshldap=on= to up the cache regularly). %X% Note doing this later in the life time of your wiki might accidentally swap the mapping of LDAP records to <nop>WikiNames in case they clash. So be very cautious when doing that. ---++ SSO and <nop>LdapContrib First of all, <nop>LdapContrib does not provide any SSO solution. Nor does LDAP per se. However, LDAP directories might come with SSO facilities that they provide via kerberos or similar. Unfortunately, nowadays browsers themselves are not kerberized. They depend on talking to the webserver using HTTP means, which then decides which tickets are valid for the remote user by talking to the actual authority. That is, authentication is implemented using an appropriate apache module. <nop>LdapContrib can then be used to complete an LDAP integration by providing the mapping to <nop>WikiNames as well as email information and group definitions drawn from the LDAP directory directly. The remaining problem is that, when a new user has been added to your LDAP directory recently, and he/she then dashes off to sign on to the wiki right away, <nop>LdapContrib's cache most probably is outdated. This situation is different from one where users were authenticated by the build-in <nop>TemplateLogin mechanism. The user would then not be able to login until the cache has been refreshed manually or automatically. So when the new user is authenticated using SSO and then hits the wiki, it might fail to compute the proper <nop>WikiName. The solution to this problem is to use the <nop>LdapApacheLogin login manager as a drop in replacement to the standard <nop>ApacheLogin that would have been used in this situation. The <nop>LdapApacheLogin will then take care that the remote user is known to the cache and add this single record if it is missing. Bottomline: whenever you are using apache to authenticate, do use the <nop>LdapApacheLogin manager. Or in other words, whenever you configured the wiki to use the standard <nop>ApacheLogin manager, and you now install <nop>LdapContrib, change it to <nop>LdapApacheLogin to assure <nop>LdapContrib's cache is up to date. ---++ Simple Example For the sake of this documentation we assume that users accounts in your database are at least of the type =posixAccount= and optionally also of type =inetOrgPerson= storing email addresses. Moreover users are stored in a subtree =ou=people= and groups are defined in =ou=group=. Here are some example LDAP records: <verbatim> dn: uid=testuser1,ou=people,dc=my,dc=domain,dc=com objectClass: inetOrgPerson objectClass: posixAccount cn: Test User1 uid: testuser1 uidNumber: 1024 gidNumber: 100 homeDirectory: /home/testuser1 loginShell: /bin/bash mail: testuser1@my.domain.com dn: uid=testuser2,ou=people,dc=my,dc=domain,dc=com objectClass: inetOrgPerson objectClass: posixAccount cn: Test User2 uid: testuser2 uidNumber: 1024 gidNumber: 100 homeDirectory: /home/testuser2 loginShell: /bin/bash mail: testuser2@my.domain.com mail: testuser2@gmx.com # users, Group, nats.informatik.uni-hamburg.de dn: cn=users,ou=group,dc=my,dc=domain,dc=com objectClass: posixGroup cn: users gidNumber: 100 memberUid: testuser1 memberUid: testuser2 </verbatim> Please have a look at your LDAP manual on how to set up an LDAP server and populate it with user account records. Have a look at the [[http://www.openldap.org/doc/admin23/quickstart.html][Quick-Start Guide]] on how to install [[http://www.openldap.org/][OpenLdap]]. Use the following settings for the above example: <verbatim> $Foswiki::cfg{Ldap}{Host} = 'ldap.my.domain.com'; $Foswiki::cfg{Ldap}{Port} = 389; $Foswiki::cfg{Ldap}{UserBase} = ['ou=people,dc=my,dc=domain,dc=com']; $Foswiki::cfg{Ldap}{LoginFilter} = 'objectClass=posixAccount'; $Foswiki::cfg{Ldap}{LoginAttribute} = 'uid'; $Foswiki::cfg{Ldap}{WikiNameAttributes} = 'cn'; $Foswiki::cfg{Ldap}{NormalizeWikiNames} = 1; $Foswiki::cfg{Ldap}{GroupBase} = ['ou=group,dc=my,dc=domain,dc=com']; $Foswiki::cfg{Ldap}{GroupFilter} = 'objectClass=posixGroup'; $Foswiki::cfg{Ldap}{GroupAttribute} = 'cn'; $Foswiki::cfg{Ldap}{MemberAttribute} = 'memberUid'; $Foswiki::cfg{Ldap}{MemberIndirection} = 0; $Foswiki::cfg{Ldap}{MapGroups} = 1; </verbatim> ---++ LDAPS <verbatim> $Foswiki::cfg{Ldap}{Host} = 'ldaps://ldap.my.domain.com'; $Foswiki::cfg{Ldap}{Port} = 636; $Foswiki::cfg{Ldap}{TLSCAPath} = '/etc/openldap/cacerts/'; $Foswiki::cfg{Ldap}{TLSCAFile} = 'cer.pem'; $Foswiki::cfg{Ldap}{TLSClientCert} = 'cer.pem'; $Foswiki::cfg{Ldap}{TLSClientKey} = 'cer.key'; </verbatim> ---++ Configuration The <nop>LdapContrib package is configured using a set of variables that need to be added to the =lib/LocalSite.cfg= configuration file. Use the <a href="%SCRIPTURLPATH{"configure"}%">configure</a> tool (at least once) after you installed this package. Have a look at your =lib/LocalSite.cfg= file afterwards. You might also make your changes therein directly to accommodate your installation to your specific LDAP installation and user accounting. See the documentation within the =configure= tool for an explanation of the various options. ---++ Updating the LDAP cache using a cronjob In some environments, updating the internal LDAP cache of the <nop>LdapContrib might take considerable time. The intervals the cache data is thought to be "expired" is configured using the =MaxCacheAge= setting. This setting defaults to updating the cache every 24 hours. The refresh procedure will then be triggered by the first request that hits the site when this period expired. To remove this burden from the "first visitor in the morning", the automatic refresh procedure can be disabled by setting <verbatim>$Foswiki::cfg{Ldap}{MaxCacheAge} = 0; </verbatim> This means that the age of the cached data will not be checked _automatically_ anymore. The responsibility that the data is updated is now up to you, that is you have to update the cache _explicitly_. This can be done by either hitting the red "Refresh Cache" button above, or by setting up an appropriate cronjob on the machine running your wiki server. To trigger an explicit update of the cache on 5 past midnight every day use a cronjob similar to: <verbatim> 5 0 * * * cd <wiki-install-path>/bin && ./view refreshldap=on Main/WebHome >/dev/null </verbatim> This will call the engine on the command line and provide the necessary query parameters so that the <nop>LdapContrib will force an update of the cache data. ---++ Debugging !LDAP Very often either the directory structure of your LDAP server is rather complicated or the settings of !LdapContrib are not as intuitive or easy to comprehend. For this reason the first best thing to do is to enable ={Ldap}{Debug}= in <a href="%SCRIPTURLPATH{"configure"}%">configure</a> and analyze the output as generated in the error.log file of your web server. Try to examine the output as generated by (a) a normal access to the site versus (b) a =refresh= of the LDAP cache. There should be sufficient information in the log files to get to know what exactly happens during this imporant step. Note that that ={Ldap}{Debug}= will _only_ switch on debug notes of !LdapContrib, _not_ of your web server performing ldap requests on its own depending on your setup. Independent from !LdapContrib and Foswiki itself there is a small perl utility in =<wiki-install-path>/tools/ldaptools= that can be used to explore the records as returned by your LDAP server on various search requests. This file is easy to understand and should be modified with a text editor before using it for the first time to reflect the specific settings required to connect your LDAP server. ---++ Implementation documentation * <a href="%SCRIPTURLPATH{"view"}%/%SYSTEMWEB%/PerlDoc?module=Foswiki::Contrib::LdapContrib">Foswiki::Contrib::LdapContrib</a> * <a href="%SCRIPTURLPATH{"view"}%/%SYSTEMWEB%/PerlDoc?module=Foswiki::LoginManager::LdapApacheLogin">Foswiki::LoginManager::LdapApacheLogin</a> * <a href="%SCRIPTURLPATH{"view"}%/%SYSTEMWEB%/PerlDoc?module=Foswiki::Users::LdapUserMapping">Foswiki::Users::LdapUserMapping</a> * <a href="%SCRIPTURLPATH{"view"}%/%SYSTEMWEB%/PerlDoc?module=Foswiki::Users::LdapPasswdUser">Foswiki::Users::LdapPasswdUser</a> ---++ Dependencies <table class="foswikiTable" border="1"><tr><th>Name</th><th>Version</th><th>Description</th></tr><tr><td align="left">Authen::SASL</td><td align="left">>=2.00</td><td align="left">Optional</td></tr><tr><td align="left">DB_File</td><td align="left">>=1.00</td><td align="left">Required</td></tr><tr><td align="left">Digest::MD5</td><td align="left">>=2.36</td><td align="left">Required</td></tr><tr><td align="left">Net::LDAP</td><td align="left">>=0.33</td><td align="left">Required</td></tr><tr><td align="left">IO::Socket::SSL</td><td align="left">>=1.0</td><td align="left">Optional</td></tr></table> ---++ Installation Instructions You do not need to install anything in the browser to use this extension. The following instructions are for the administrator who installs the extension on the server. Open configure, and open the "Extensions" section. Use "Find More Extensions" to get a list of available extensions. Select "Install". If you have any problems, or if the extension isn't available in =configure=, then you can still install manually from the command-line. See http://foswiki.org/Support/ManuallyInstallingExtensions for more help. * Read the above documentation, i.e. the [[#Configuration][Configuration]] section. * Use <a href="%SCRIPTURLPATH{"configure"}%">configure</a> to set the LDAP settings. ---++ Contrib Info <!-- * Set SHORTDESCRIPTION = LDAP services for Foswiki --> This work was partly sponsored by * [[http://www.spanlink.com][Spanlink Communications]] * [[http://www.trivadis.com][Trivadis]] * [[http://www.ibm.com][IBM]] * [[http://www.dfs.de][Deutsche Flugsicherung]] * [[http://www.testo.de][Testo]] * [[http://www.1and1.com][1&1]] | Author: | Michael Daum | | Copyright ©: | 2006-2012 Michael Daum http://michaeldaumconsulting.com | | License: | GPL ([[http://www.gnu.org/copyleft/gpl.html][GNU General Public License]]) | | Release: | 5.04 | | Version: | 16201 (2012-12-13) | | Change History: | <!-- versions below in reverse order --> | | 29 Nov 2012: | fixed decoding of ldap strings | | 21 Nov 2012: | fixed ldap login manager using old api; \ fixed recursive traversal of distributed ldap directories; \ storing all blobs into a subdirectory of their own reachable by the web server | | 19 Nov 2012: | fixed non-paged requests no terminating; \ fixed encoding of baseDN in search; \ fixed case comparison when excluding wiki names; \ added support for non-utf8 ldap directories | | 11 Nov 2012: | added support for multiple subtrees searching for users and groups | | 09 Nov 2012: | add support for ldap referrals and references for distributed ldap directories | | 17 Oct 2012: | Item12159: added =passwords_modifyable= context to re-enable changing passwords from the core topics (by Sven Dowideit) | | 10 Jul 2012: | improved unicode transliteration; fixed error in regular expression testing for unknown users and groups (by Jim Hague) | | 26 Jun 2012: | added =CaseSensitiveLogin= feature, defaulting to =off=; \ performance improvements looking up the ldap cache (by Jayen Ashar) | | 11 Jan 2012: | fixed using !ListIterators on undefined list values | | 20 Dec 2011: | fixes deep recursion when adding !AdminGroup to !AdminGroup; fixed sizelimit not properly being applied to ldap query; disabled expensive debug message | | 16 Dec 2010: | implemented new =expand= feature of =GROUPINFO= found in newer foswikis | | 02 Dec 2010: | fixed glitch where IDs weren't extracted from the cache db | | 01 Dec 2010: | added workaround to make the Foswiki::Func API usable early enough in the processing chain; \ fixed the way name clashes are resolved to stabilize choices once made; \ added =refreshldap=force= feature to override previous decisions resolving name clashes; \ deprecated =WikiNameAliases= in favor of =RewriteWikiNames= | | 22 Nov 2010: | fixed removing realm from login again; improved clash report message | | 16 Nov 2010: | added tool to debug ldap server connection and structure | | 09 Nov 2010: | removed every lowercasing of login names; \ added docu and better defaults for =RewriteWikiNames= | | 17 Sep 2010: | fixed build script; \ removed hardcoded normalization that stripped off domain parts from login and wiki names; \ fixed utf8 transcoding for modern perls; \ be more careful when translation of !WikiNameAttributes to proper !WikiNames checking existing homepages; \ implemented =groupAllowsChange()= for modern Foswikis | | 17 Nov 2009: | incremental cache updates for _big_ ldap directories and inner groups feature (Cyril Bousquet, IBM); \ added scope parameter searching for users and groups; \ added rewrite rules for wiki names; \ added name clash resolution for wiki names; \ fixed race condition in cache update leading to file corruption; \ cleanup of internal API to properly deal with interim caching structures | | 25 May 2009: | extended transliteration of utf8 chars to polish chars (Bartosz Dziuda) | | 09 Apr 2009: | added <nop>RewriteGroups and <nop>MergeGroups feature | | 08 Apr 2009: | fixing nested ldap groups | | 02 Mar 2009: | prevent error when called in the middle of the Foswiki constructor | | 27 Feb 2009: | fixing use of uninitialized value in user mapper; \ optimized check for existing user to respect the exclude configuration setting; \ renamed <nop>LdapPassword to <nop>LdapPasswdUser again to please configure; \ transliteration of umlaut (this seems to happen occasionally during svn ci/co or whatever) | | 11 Feb 2009: | 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 | | 20 Jan 2009: | fixed getting emails for groups and login names | | 19 Dec 2008: | fixed group mapping under <nop>MapGroup=off | | 05 Dec 2008: | fixed group mapping | | 04 Dec 2008: | fixed getting email info | | 06 Oct 2008: | dropped support for TWiki < 4.2.3; \ added support TLS encryption (by Wolfgang Karall) | | 12 Jun 2008: | added workarounds to use LDAP and <nop>MailInContrib on TWiki-4.2.0 | | 25 May 2008: | added alias feature, \ fixed normalization error, \ fixed cache update issue \ added login manager for 4.2 | | 05 May 2008: | implemented !WikiNamesAliases | | 14 Feb 2008: | allow to disable cache aging setting <nop>MaxCacheAge to zero | | 01 Feb 2008: | distinguish groups clashing with user names by appending a suffix | | 30 Jan 2008: | first beta towards TWiki-4.2 | | 07 Jan 2008: | fixed initializing the cache | | 21 Dec 2007: | added <nop>LdapApacheLogin, \ made updating the cache quasi atomic | | 22 Nov 2007: | fixed recognition of <nop>WikiGroups in a mixed setting | | 05 Oct 2007: | enabled native user registration using the secondary password manager; \ added support to change a user's LDAP password from within TWiki; \ added patch for =TWiki.pm= that backports some of the fixes from TWiki-4.2 \ to TWiki-4.1.2 | | 05 Sep 2007: | added SASL support, \ added normalization of login and group names, \ added secondary password manager | | 31 Aug 2007: | rewrite of the cache | | 08 June 2007: | don't use the store object during TWiki's destructor; \ don't lookup login names of groups | | 04 June 2007: | don't be case sensitive for login names; \ fixed several utf8 issues; \ fixed crash when no groups where found; \ caching mapping privately; added <nop>MaxCacheAge; \ added support for nested LDAP groups | | 30 Apr 2007: | fixed return value on illegal lookup calls | | 24 Apr 2007: | be robust against the lookup-API being called with the wrong parameters; \ added =Debug= flag; \ fixed/improved group loading; \ deprecating =BasePasswd= in favor of =UserBase=; \ deprecating =BaseGroup= in favor of =GroupBase= | | 04 Apr 2007: | fixed group mapping on >4.1.2; \ renamed <nop>BasePasswd config parameter to <nop>UserBase; \ renamed <nop>BaseGroup config parameter to <nop>GroupBase; \ working around broken =configure= in 4.1.x | | 12 Jan 2007: | enhanced normalization of <nop>WikiNames so that they are proper <nop>WikiWords; \ <nop>WikiNames can be constructed from a list of \ LDAP attributes now | | 18 Dec 2006: | various performance improvements; \ fixed usage of =limit= argument; \ renamed configuration option "<nop>WikiNameRemoveWhiteSpace" to "<nop>NormalizeWikiName"; \ support for large databases using paged LDAP search results; \ new configuration option "Exclude" to exclude standard TWiki user accounts, e.g. <nop>RegistrationAgent, \ from being looked up in LDAP; \ added support for faster API implementing =isMemberOf=; \ added Config.spec file to integrate the <nop>LdapContrib into TWiki's "configure" tool; \ added support for <nop>WikiNames derived from mail attributes | | 03 Nov 2006: | fixed binding to the server by first searching the full dn instead of assuming a fixed one \ (issue found by Cederic Weber); \ added new feature <nop>MapGroup to be able to switch off group mapping and have; \ login-to-wikiname conversion only | | 02 Aug 2006: | added a user accounts in memory cache | | 19 July 2006: | public release | | 24 May 2006: | API adjustments, improved wikiname generation | | 28 Apr 2006: | Initial version | | Home: | Foswiki:Extensions/%TOPIC% | | Support: | Foswiki:Support/%TOPIC% |
主题: System
>
LdapContrib
主题版本:
2013-05-08,
AdminUser
(检示源码)
版权所有 © 所有作者。本合作平台的所有资料归内容提贡者所有。
请
回馈
有关 HEPG 的建议、需求及问题。