Hi! Need help :) I must create an Wiki, that runs on an IIS Windows Webserver. But it gets the users from our Active Directoy Server. I dont understand this, really.

Can anyone help me? need it.

Contact me pleas @ Brockmeyer.S@atlas.de or ICQ 177440248.

LG Sascha Brockmeyer

Can we get working patches for 1.4.0? Both of the patches on that bug seem to be saved as some unspecified binary format. Can you re-post them as text/plain?

Don.

They are actually tar.gz files (run unix file on the downloaded files to get file type information).
Ed

Yes, they are tar.gz files. Since some core code modification is required, I included a tar set of diffs, I thought this would be easier. I will be working on a new set of patches for 1.4 to bring it up to version .8
Ryan Lane

Found out just a bit late. I noted in the bug about use of the 'patch' identifier when download isn't really a patch file. Why not just supply a single .diff?

Any idea if/when this code will make its way into mediawiki proper?

Don.

Sorry, I'm not actually very familiar with making patches. I always merge my code by hand. I believe that Brion is looking over my code for addition to 1.5, so soon enough you shouldn't have to worry about it anymore (you'll just drop LdapAuthentication.php into includes).
Ryan Lane

Quick question: Where the heck is the actual file! I have been poking around for half an hour and can't find any such file! ARGH!!!!! - Abdon

The files are in the bugzilla, at the following link: [1]
This is at the very top of this article.
Ryan Lane

Couple of Questions:

I just want to verify that I can have a clean wiki install, set up ldap authentication, and when a user first goes to the wiki, they'll be asked for their ldap credentials, and if they authenticate, they will be added as a wiki user.
Can the ldap code handle nested ldap group searches? e.g. in a large organisation where an ldap entry may contain groups (which may contain groups) etc it may require nested/recursive searching. I sure hope so...

Thanks in advance JR

Yes, this is the default behavior.
The code doesn't support search by groups at all, only by users. The newest version supports filtered LDAP searches though. I may add support for groups in the future.
Ryan Lane

'Bug or bad installation?'

Call to a member function on a non-object

First

We've applied the patch on an fresh installation of the wiki. We're athentication vs. a Novell eDirectory (LDAP).

User is going to log in, the following message apears:

Fatal error: Call to a member function on a non-object in /srv/www/htdocs/wiki-test/includes/SpecialUserlogin.php
on line 291

When I click on the "back" button in my browser an try again to authenticate, it works fine. Any hints where to look further?

This seems like a strange bug. I don't even modify code around this area. Did you manually add the patch in? Like I say above, I'm not terribly familiar with making patches. It'll go a lot easier if you patch by hand (its pretty small).
Ryan Lane

It came up sometimes when playing around with Wiki and patch. It's coming up right now. Freshly installed 1.4.0 with your patch 8.14. Using the patch-command there was no error.

Authentification via SSL doesn't seem to work

Second

Athentification via SSL doesn't seem to work. The answer is: "bad password". Any hints?

THX KNEBB

Authentication with SSL should work with no problems. Does the system you are running this from trust the certificate on the LDAP server? If not, SSL will fail. There are a couple settings in "ldap.conf" that can you set to ignore the fact that you don't trust the certificate (this bypasses a security measure, but it is still more secure than not using SSL). One is "tls_checkpeer no" the other is "TLSREQCERT never". Check "man ldap.conf" to be sure those are right.
Ryan Lane

Ok, also my fault. As written above, we're playing around with eDirectory. There is SSL enabled, by on out OPENLDAP it isn't- so it couldn't work. I'll try to test it only with eDirectory.

Wiki+LDAP on an OES

Another question

I've installed the wiki on the new Novell OpenEnterpriseServer (OES). It's an SuSE Linux Enterprise Server 9 with Novell components.

I installed my wiki (1.4.0) an could log in as WikiSysop. Good.

Now I applied the LDAP-Patches (for testing not on eDir an no SSL). When I try to login I run in an blank page after clicking on the login-button an can't edit any pages. It doesn't matter if I try to login with an existing or non-existing user or the wrong or right password. Even if the pwd is empty, there's a feedback.

Any hint's why I can't log-in? The URL is: path_to_wiki/index.php?title=Spezial:Userlogin&action=submit&returnto=Hauptseite (Haupseite means Mainpage)

THX KNEBB

password min length limit curiosity

It's over my head, but the authors may be interested in this user's findings:

-- Sy / ^(talk) 12:30, 15 September 2005 (UTC)[reply]

Ah, good to know. I'm probably not checking the password limit when creating users. This will have to be an outstanding bug for a while. I'm currently evacuated from new orleans, and have no ability to work on the patch.
-- Ryan Lane

Installaton instructions

Can anyone provide a simple README that would describe how to apply these LDAP patches? They're not patching cleanly for me, and I'm not enough of a guru to figure out what's going wrong. --Tim

For version 1.5, you don't need to patch, you just need to drop "LdapAuthentication.php" into the "includes" directory. The rest of the patch has been merged into the core code. If you are using version 1.4, you'll need to merge the patch. Unfortunately, I do not have a version that will merge cleanly with the newest version of 1.4, so you'll have to merge it by hand using an editor. I am no longer supporting 1.4, only focusing my attention on 1.5.
-- Ryan Lane

$wgLDAPSearchStrings vs $wgLDAPSearchAttributes

Why do we need both the $wgLDAPSearchStrings and $wgLDAPSearchAttributes? Seems like we only really need one of them.

I have made a few updates to just use $wgLDAPSearchAttributes, and be able to use a search for binding rather than an exact bind with $wgLDAPSearchStrings. I updated the getUserDN() to find the proper userdn, then use that userdn to bind and authenticate in authenticate().

function getUserDN($ldapconn, $username) {
       global $wgLDAPProxyAgent, $wgLDAPProxyAgentPassword;
       global $wgLDAPSearchAttributes, $wgLDAPBaseDNs;
       if (isset($wgLDAPProxyAgent)) {
           $bind = @ldap_bind( $ldapconn, $wgLDAPProxyAgent, $wgLDAPProxyAgentPassword );
           $searchString = $this->getSearchString($username);
       } else {
           $bind = @ldap_bind( $ldapconn );
           $searchString = $wgLDAPBaseDNs[$_SESSION['wsDomain']];
       }
       if (!$bind) {
           return ;
       }
       $filter = "(" . $wgLDAPSearchAttributes[$_SESSION['wsDomain']] . "=$username)";
       //we need to do a subbase search for the entry
       $entry = @ldap_search($ldapconn, $searchString, $filter);
       if (!$entry) {
           return ;
       }
       $info = @ldap_get_entries($ldapconn, $entry);
       $userdn = $info[0]["dn"];
       return $userdn;
   }

Any thoughts on just having one search criteria instead of two? or am I missing something.

- Chris Chan, cchan@spikesource.com