Extension talk:LDAP Authentication/Archive 3

Select domain upon login in MediaWiki 1.15.1

Hello,

I wanted to connect my fresh MediaWiki installation to my OpenLDAP server. Unfortunatelly, after setting up the extension, the login form did not contain a list for selecting the domain. Therefore, I had to change the function modifyUITemplate of the LDAP authentication plugin. Before, the plugin checked for instances of class SpecialUserlogin and modified the variable mDomain. Now, I check for instances of class UserloginTemplate and modify the data['usedomain'] and data['domainnames'] variables. With these modifications, the plugin works fine.

I was wondering, if I did a mistake in configuring MediaWiki or the LDAP authentication plugin in the first place. Or is it an API change which made the plugin incompatible?

Best regards,

Georg Hackenberg

Huh? My code doesn't do anything like what you are talking about. Are you using a version that has been modified? Try using a new version of the extension that is completely unmodified.
--Ryan lane 21:44, 12 May 2010 (UTC)

MySQL returned error "1062: Duplicate entry '' for key 'user_name' (localhost)".

• MediaWiki: 1.12
• PHP: 5.2.9
• MySQL: 5.1.33

Error:

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: 
(SQL query hidden)
from within function "User::addToDatabase". MySQL returned error "1062: Duplicate entry '' for key 'user_name' (localhost)".

I've been trying to get the AutoAuthentication working with SSPI in Windows/Apache. So, following the Kerberos examples, I end up with a configuration like this:

$wgLDAPDomainNames = array("XXXXXX");
$wgLDAPServerNames = array("XXXXXX"=>"xxxxxx.xxxxxxxxx.com");
$wgLDAPEncryptionType = array("XXXXXX"=>"clear");
$wgLDAPAutoAuthDomain = "XXXXXX";
$wgLDAPProxyAgent = array("XXXXXX"=>"CN=xxxxxx,OU=Xxxxxx,OU=Xxxxxx,OU=xXxxxxx,DC=xxxx,DC=xxxxxxxxx,DC=xxx");
$wgLDAPProxyAgentPassword = array("XXXXXX"=>"xxxxxx");
$wgLDAPBaseDNs = array("XXXXXX"=>"dc=xxxxxx,dc=xxxxxxxxxxxx,dc=com");
$wgLDAPSearchAttributes = array("XXXXXX"=>"sAMAccountName");
$wgLDAPAutoAuthUsername = $_SERVER["REMOTE_USER"];
$wgLDAPPreferences = array("XXXXXX"=>array( "email"=>"mail","realname"=>"displayname","nickname"=>"samaccountname"));
$wgLDAPAutoAuthUsername = $_SERVER["REMOTE_USER"];
AutoAuthSetup();

(sorry for the extensive censoring)

I'm seeing the following behavior:

1. Visit site for the first time
   • A user is successfully logged in to MW, but the username is displayed as an IP address
   • The 'user' table in the database gets a new row, with the user_name blank but all other columns populated with LDAP prefs
2. Try to click into an article, ERROR
   • MySQL returned error "1062: Duplicate entry '' for key 'user_name' (localhost)"
   • (see full error above)
3. Refresh browser
   • The article loads successfully, and the proper user is logged in with the proper username
   • The 'user' table has a new, complete row for the user
   • The 'user' table STILL has the previous row with a blank username
   • There is a missing row between the blank user_name row and the proper row (like a row was created, and deleted, the user_id number skips ahead 1)

I've been scanning the Auto LDAP plug-in code, and it seems like MediaWiki is getting the mungedUsername:

        // Checks passed, create the user
        $user->loadDefaults( $mungedUsername ); //this is populated with the username, confirmed with error_log() debugging
        $user->addToDatabase();

        $wgAuth->initUser( $user, true );
            $user->setCookies();
        wfSetupSession();

Please, if you have auto auth working with kerberos/ntlm/sspi, please help. Cedarrapidsboy 20:50, 15 October 2009 (UTC)

Solution?

After looking through the source code of a different auth plugin, I found something it was doing that this auto-auth wasn't, a call to $user->setName(). I made the following edit:

    static function attemptAddUser( $user, $mungedUsername ) {
        ...
        // Checks passed, create the user
        $user->setName($mungedUsername); //<--EDIT: Added this line
        $user->loadDefaults( $mungedUsername );
        $wgAuth->printDebug( "Adding to database...", NONSENSITIVE );
        ...
        return true;
    }

Seems to work well now. New users get an account created, and logged-in. Existing users get logged-in. No more 'user' table lines with a blank user_name field. Will this edit affect other auto auth mechanisms (I'm using SSPI, will it break Smartcard, Kerberos?)? Cedarrapidsboy 15:59, 16 October 2009 (UTC)

I'll take a look at this. I'm using the same version of MediaWiki, with auto-auth, and I'm not seeing this problem. The user creation process changes constantly in MediaWiki, so auto-auth sometimes has bugs like this creep in.
--Ryan lane 15:11, 2 December 2009 (UTC)

I've tested this in newer version of MediaWiki and am not having this issue. I'm going to consider this working.
--Ryan lane 21:45, 12 May 2010 (UTC)

Can I use another authentication plugin at the same time?

Hello,

I am currently making a wiki that supports pulling authentication info from a couple sources. Right now I have this extension working BEAUTIFULLY (thank you, Ryan Lane!!) pulling users from AD and also pulling their groups and prefs. I also need to grab login info from a script on a separate server. I can parse the return values from that script without issue, but I can't seem to add another class that extends AuthPlugin and have them work in unison. Is this a limitation from MW or am I just failing?

Thanks, Tim

Unfortunately, this is a limitation of MW. I've been considering making a plugin (or adding something to core) that allows this. I usually just add whatever I need to this plugin, but some things really should be separate. I'm thinking of making a PAM like system that allows portions of different plugins to be used in a pluggable fashion. This is really low on my priority list right now though, so I wouldn't wait around for it. I can probably make a spec if you'd like to work on it before I get to it.
--Ryan lane 15:30, 17 November 2009 (UTC)

Password with dot

When a user have a password with a dot . inside, login fail sample : password = pass.word

i use last version of this plugin. regards

Other people have asked for support requests with this kind of problem before. There is nothing the plugin is doing that could cause this problem. The plugin simply passes the password to the LDAP server when doing a bind. It doesn't modify, or sanitize the password in any way. Something else must be causing the issue. Do you have mod_security enabled? Are you sanitizing input somewhere else? Have you tried disabling all other extensions?
--Ryan lane 15:33, 17 November 2009 (UTC)