Extension talk:LDAP Authentication/LQT Archive 1

Please ask support questions here, posting new questions via LiquidThreads.

Archives

 * Archive 1
 * Archive 2

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  of the LDAP authentication plugin. Before, the plugin checked for instances of class  and modified the variable. Now, I check for instances of class  and modify the   and   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

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
 * 2) *A user is successfully logged in to MW, but the username is displayed as an IP address
 * 3) *The 'user' table in the database gets a new row, with the user_name blank but all other columns populated with LDAP prefs
 * 4) Try to click into an article, ERROR
 * 5) *MySQL returned error "1062: Duplicate entry '' for key 'user_name' (localhost)"
 * 6) *(see full error above)
 * 7) Refresh browser
 * 8) *The article loads successfully, and the proper user is logged in with the proper username
 * 9) *The 'user' table has a new, complete row for the user
 * 10) *The 'user' table STILL has the previous row with a blank username
 * 11) *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)

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)

Not updating Groups in the MW Database
Hi,

we use the LDAP extension to sync LDAP groups with the MW Database, so that other extensions like accesscontrol can use these groups. But its not working anymore and i dont know what to do about it.

Here is our current configuration and debug logs of a test user logging in:

$wgAuth = new LdapAuthenticationPlugin; $wgLDAPDebug = 3; $wgDebugLogGroups["ldap"] = "/tmp/test-wiki/ldap.debug.log"; $wgLDAPDomainNames = array( "domain" ); $wgLDAPServerNames = array( "domain"=>"server.com" ); $wgLDAPUseLocal = false; $wgLDAPEncryptionType = array( "domain"=>"ssl" ); $wgLDAPSearchStrings = array( "domain"=>"domain\\USER-NAME" ); $wgLDAPProxyAgent = array( "domain"=>"cn=searchonly,cn=Users,dc=server,dc=domain,dc=com" ); $wgLDAPProxyAgentPassword = array( "domain"=>"xxx" ); $wgLDAPSearchAttribudomains = array( "domain"=>"sAMAccountName" ); $wgLDAPBaseDNs = array( "domain"=>"dc=server,dc=domain,dc=com" ); $wgLDAPMailPassword = false; $wgLDAPPreferences = array ( "domain"=>array( "email"=>"mail","realname"=>"displayName","nickname"=>"cn","language"=>"preferredLanguage") ); $wgLDAPDisableAutoCreate = array( "domain"=>false ); $wgMinimalPasswordLength = 1; $wgLDAPGroupUseFullDN = array( "domain"=>true ); $wgLDAPGroupBaseDNs = array( "domain"=>"ou=Groups,ou=department,dc=server,dc=domain,dc=com" ); $wgLDAPLowerCaseUsername = array( "domain"=>true ); $wgLDAPGroupUseRetrievedUsername = array( "domain"=>false ); $wgLDAPGroupObjectclass = array( "domain"=>"group" ); $wgLDAPGroupAttribudomain = array( "domain"=>"member" ); $wgLDAPGroupNameAttribudomain = array( "domain"=>"cn" ); $wgLDAPUseLDAPGroups = array( "domain"=>true ); $wgLDAPGroupLowerCaseUsername = array( "domain"=>true );

2009-10-28 09:47:26 wikidb_test: Entering validDomain 2009-10-28 09:47:26 wikidb_test: User is not using a valid domain. 2009-10-28 09:47:26 wikidb_test: Setting domain as: invaliddomain 2009-10-28 09:47:26 wikidb_test: Entering allowPasswordChange 2009-10-28 09:47:26 wikidb_test: Entering modifyUITemplate 2009-10-28 09:47:29 wikidb_test: Entering validDomain 2009-10-28 09:47:29 wikidb_test: User is not using a valid domain. 2009-10-28 09:47:29 wikidb_test: Setting domain as: invaliddomain 2009-10-28 09:47:29 wikidb_test: Entering allowPasswordChange 2009-10-28 09:47:29 wikidb_test: Entering modifyUITemplate 2009-10-28 09:47:34 wikidb_test: Entering validDomain 2009-10-28 09:47:34 wikidb_test: User is using a valid domain. 2009-10-28 09:47:34 wikidb_test: Setting domain as: domain 2009-10-28 09:47:34 wikidb_test: Entering getCanonicalName 2009-10-28 09:47:34 wikidb_test: Username isn't empty. 2009-10-28 09:47:34 wikidb_test: Munged username: Testneu 2009-10-28 09:47:34 wikidb_test: Entering authenticate 2009-10-28 09:47:34 wikidb_test: 2009-10-28 09:47:34 wikidb_test: Entering Connect 2009-10-28 09:47:34 wikidb_test: Using SSL 2009-10-28 09:47:34 wikidb_test: Using servers:  ldaps://server.com 2009-10-28 09:47:34 wikidb_test: Connected successfully 2009-10-28 09:47:34 wikidb_test: Lowercasing the username: Testneu 2009-10-28 09:47:34 wikidb_test: Entering getSearchString 2009-10-28 09:47:34 wikidb_test: Doing a straight bind 2009-10-28 09:47:34 wikidb_test: userdn is: domain\testneu 2009-10-28 09:47:34 wikidb_test: 2009-10-28 09:47:34 wikidb_test: Binding as the user 2009-10-28 09:47:39 wikidb_test: Bound successfully 2009-10-28 09:47:39 wikidb_test: Entering getUserDN 2009-10-28 09:47:39 wikidb_test: Created a regular filter: (sAMAccountName=testneu) 2009-10-28 09:47:39 wikidb_test: Entering getBaseDN 2009-10-28 09:47:39 wikidb_test: basedn is not set for this type of entry, trying to get the default basedn. 2009-10-28 09:47:39 wikidb_test: Entering getBaseDN 2009-10-28 09:47:39 wikidb_test: basedn is dc=server,dc=domain,dc=com 2009-10-28 09:47:39 wikidb_test: Using base: dc=server,dc=domain,dc=com 2009-10-28 09:47:39 wikidb_test: Fetched username is not a string (check your hook code...). This message can be safely ignored if you do not have the SetUsernameAttributeFromLDAP hook defined. 2009-10-28 09:47:39 wikidb_test: Pulled the user's DN: CN=test userNEU,OU=Users,OU=department,DC=server,DC=domain,DC=com 2009-10-28 09:47:39 wikidb_test: Entering getGroups 2009-10-28 09:47:39 wikidb_test: Retrieving LDAP group membership 2009-10-28 09:47:39 wikidb_test: Searching for the groups 2009-10-28 09:47:39 wikidb_test: Entering searchGroups 2009-10-28 09:47:39 wikidb_test: Entering getBaseDN 2009-10-28 09:47:39 wikidb_test: basedn is ou=Groups,ou=department,dc=server,dc=domain,dc=com 2009-10-28 09:47:39 wikidb_test: Search string: (&(member=CN=test userNEU,OU=Users,OU=department,DC=server,DC=domain,DC=com)(objectclass=group)) 2009-10-28 09:47:39 wikidb_test: Binding as the proxyagent 2009-10-28 09:47:39 wikidb_test: Returned groups: cn=test123,ou=groups,ou=department,dc=server,dc=domain,dc=com 2009-10-28 09:47:39 wikidb_test: Entering checkGroups 2009-10-28 09:47:39 wikidb_test: Entering getPreferences 2009-10-28 09:47:39 wikidb_test: Retrieving preferences 2009-10-28 09:47:39 wikidb_test: Retrieved email (test123@test.com) using attribute (mail) 2009-10-28 09:47:39 wikidb_test: Retrieved nickname (test userNEU) using attribute (cn) 2009-10-28 09:47:39 wikidb_test: Entering synchUsername 2009-10-28 09:47:39 wikidb_test: Authentication passed 2009-10-28 09:47:39 wikidb_test: Entering updateUser 2009-10-28 09:47:39 wikidb_test: Setting user preferences. 2009-10-28 09:47:39 wikidb_test: Setting nickname. 2009-10-28 09:47:39 wikidb_test: Setting email. 2009-10-28 09:47:39 wikidb_test: Setting user groups. 2009-10-28 09:47:39 wikidb_test: Entering setGroups. 2009-10-28 09:47:39 wikidb_test: Locally managed groups is unset, using defaults:  bot::sysop::bureaucrat 2009-10-28 09:47:39 wikidb_test: Available groups are:  bot::sysop::bureaucrat 2009-10-28 09:47:39 wikidb_test: Effective groups are:  *::user::autoconfirmed 2009-10-28 09:47:39 wikidb_test: Checking to see if user is in: bot 2009-10-28 09:47:39 wikidb_test: Entering hasLDAPGroup 2009-10-28 09:47:39 wikidb_test: Checking to see if user is in: sysop 2009-10-28 09:47:39 wikidb_test: Entering hasLDAPGroup 2009-10-28 09:47:39 wikidb_test: Checking to see if user is in: bureaucrat 2009-10-28 09:47:39 wikidb_test: Entering hasLDAPGroup 2009-10-28 09:47:39 wikidb_test: Saving user settings. 2009-10-28 09:47:43 wikidb_test: Entering allowPasswordChange

If i understand the log correctly the group is returned but when i check the database its not updated there.


 * MediaWiki won't add the groups to the database, unless they are defined with permissions in LocalSettings.php; see: Manual:User_rights. Also, depending on the access control extension you are using, you may also need to set "$wgLDAPGroupsPrevail"; see Extension:LDAP_Authentication/Options --Ryan lane 15:39, 17 November 2009 (UTC)


 * Hi, we use this extension: Extension:Group_Based_Access_Control. I tried with $wgLDAPGroupsPrevail set but it wont work anyway. So your LDAP extension wont add the ldap groups to the MW database? Only to the $wgGroupPermissions array... Maybe thats the problem?


 * No. The code calls $user->addGroup to add users to a group. $wgLDAPGroupsPrevail tells the plugin to add all LDAP groups to $wgGroupPermissions, which should add those groups to the database. I don't test this use case, because I never use any access control plugins (they are flawed, and in my opinion, not worth using).


 * However, looking at the code, there is a possibility that there is a bug. The following block of code:


 * May need to be placed above:


 * As later in the code, I iterate over $localAvailGrps. $localAvailGrps may be missing the groups from the $wgLDAPGroupsPrevail code block. Try moving that code block, and let me know if it works. If it does, I'll add this change in SVN. --Ryan lane 16:11, 18 November 2009 (UTC)