Extension:LDAP Authentication/Suggestions

Suggestions

 * Use posixUser's gidMember attribute with poisxGroup's gidMember to check group members (or other fields, maybe customisable --FlorealToamikian


 * Please add check "isset( $_SESSION['wsDomain'] )" on lines 518, 609 and 613 (version 1.2b (alfa)) to fix "Notice: Undefined index: wsDomain" error notice. May be this check should be added to more places, but I received notices only for three mentioned. -- kettari
 * If the domain isn't being set, there is a problem with MediaWiki core, or somewhere else in the LDAP plugin. The code shouldn't have to check for the domain, because it should always be set.
 * I also haven't been able to reproduce these php notices. Can you post your configuration in the support section, so that I can try to reproduce the bug? --Ryan lane 13:39, 8 July 2009 (UTC)
 * I'm having this "undefined index: wsdomain" issue as well (posted details in support section). You mentioned that if this occurs then the domain isn't being set and there's a problem in the core. Just wondering if you know exactly where this domain variable is supposed to be set? --Richardj87
 * This issues has been resolved (See Extension talk:LDAP Authentication for details) --Richardj87


 * Is it possible that when using the ldap authentication plugin that the users email address would be automatically confirmed since it is being pulled out of active directory? Axelseaa 14:29, 17 July 2007 (UTC)
 * I was under the impression that this was the case; I'll take a look into this. --Ryan lane 13:42, 17 August 2007 (UTC)


 * I've had a recurring problem where mediawiki won't create a new account if the username and password in LDAP are identical - no errors are thrown, it just shows the login as incorrect. Is it possible to get an error to appear for this, or is it a restriction of mediawiki rather than the plugin? Other than that, it works perfectly, thanks a lot for your work. -- Nickt
 * I don't see why this would fail, unless it is an issue with mediawiki; I think it is a good idea of mediawiki to do this, but I generally handle this with LDAP, so I've never tested it (as that is a terribly insecure password). --Ryan lane 14:06, 5 November 2007 (UTC)
 * Understood - thanks a lot for the reply. -- Nickt
 * Seems another user had this issue, and I took the time to dig through MediaWiki core. This is a MediaWiki core issue. They don't allow username and password to be identical. This was most likely added after they had that massive sysop password crack incident. --Ryan lane 16:00, 13 December 2007 (UTC)


 * Hello Ryan and all. I just spent the better part of a working week getting Active Directory 2003 auth with Groups over SSL working with Mediawiki using this plugin. Firstly, thanks so much for writing it! However, figuring out what needs to be done is not easy, as the different versions of parameters, modifications and config examples on this page and on the net make it all very confusing. The lack of clear error returning can sometimes make it difficult to troubleshoot where a problem lies (SSL, certs, PHP, etc). I'm going to make the same changes from my test server to production next week, so I'll document it and make a step-by-step howto if anyone's interested? I imagine alot of people would be.
 * Further, would it be possible to tidy up this documentation any? I'd suggest moving the "OLD DEPRECATED" group auth into a lower section, or maybe a subpage, and the current group auth moved up, so people use that first instead of the old stuff which doesn't work. Also, a quick overview of other required auth modules and a few pointers to their config tips would also be infinitely helpful, not a walkthru, just one sentence with the basic requirements, I found just a small amount of advice like this helped me immensely when getting AD LDAP Auth working with PmWiki as well. --Super Jamie 05:32, 2 November 2007 (UTC)
 * Yes, I'd like to agree that once I understood what to do, getting it working was easy, but the documentation here is terse. It partly assumes that you know LDAP through and through, I think, but that's not always the case - I happen to be learning LDAP at the same time.  I"m not expecting for this to be an LDAP tutorial in any way, but to have more examples of how the code would be used in a real situation would have helped me understand what was meant to go where your placeholder text is much sooner. &mdash; Timotab 13:01, 2 November 2007 (UTC)
 * My #1 tip to getting this plugin working, is to never, ever, read other people's configuration examples. Only use the documentation here, as the documentation everywhere else is going to almost definately be wrong. I have to have the ability to change configuration options every once in a while when the code needs rearranging, or when I find a better way of doing something.
 * As for error returning, using "$wgLDAPDebug = 3;" will return quite a bit of error messages. I've tried adding in error reporting for when php_ldap is missing, but haven't successfully been able to check for SSL support. The prerequisites for using this plugin are listed at the top of this page.
 * A tutorial on how to set up active directory and the client system for plugin use is fine by me, but I'm unlikely to ever write it (as I don't have easy access to a Windows Server 2003 OS, if someone buys me a copy, I'll happily use it for testing). --Ryan lane 14:06, 5 November 2007 (UTC)
 * Hi guys, I've written that documentation up, located at User:Super_Jamie/LDAP_HOWTO, hope it helps someone. --Super Jamie 05:14, 7 November 2007 (UTC)
 * I would recommend a comment to the debug message if the bind fails to indicate that it may be a server connection problem. It's mentioned on the PHP:ldap_connect page, but it is confusing that a connection to the server isn't actually made until the bind, even though the debug messages return "Connected successfully" before then.
 * I can successfully login in using my LDAP credentials, and Real Name and Email are pulled form LDAP and can be seen in preferences. The issue is that none of the actions show my Real Name, only my username.  Is this an issue with  the extension or mediawiki?
 * This is normal for mediawiki. Real Name can be used in signatures, but for revision history, recent changes, etc. it will show your username, not the real name. Search the lists and you may find if this can be changed, but I'm assuming no. --Ryan lane 18:21, 15 December 2008 (UTC)
 * Is it possible to add the function strictUserAuth of AuthPlugin in the LDAP plug-in in a fashion mode? I don't see all the uses of this function, but I have to use it in our wiki to authorize e.g. WikiSysop to be authenticated with the local database (and all others with LDAP). It is possible to add a list of names authorized (or not, depending of $wgLDAPUseLocal) to be authenticated with the local database and/or to add a hook for specific usages. What do you think about all that? ~ Seb35 08:40, 7 August 2009 (UTC)
 * Yes, I'll add this for the next release. I'll probably use a syntax like:
 * $wgLDAPAllowLocalUsers = array( "DOMAIN1" => array( "user1", "user2", "..." ), "DOMAIN2" => array( "..." ) );
 * Could you also consider adding a username list for LDAP authentication (as opposed to only local authentication)? For example, if I wanted to allow specific LDAP individuals as well as members of specified LDAP groups to login I could add a list of groups AND usernames.  Something like:
 * $wgLDAPRequiredGroups = array( "DOMAIN1" => array( "group1", "group2", "..." ), "DOMAIN2" => array( "..." ) );
 * $wgLDAPRequiredUsers = array( "DOMAIN1" => array( "user1", "user2", "..." ), "DOMAIN2" => array( "..." ) );
 * I believe when I add this support it will work for either local or LDAP domains.--Ryan lane 18:03, 13 July 2010 (UTC)
 * When a group requirement is defined for access and a user who is not a member of that group attempts to login, the Login page responds with the "Login error: Incorrect password entered. Please try again." message. But this is false.  The user most likely entered the correct password.  This can lead to much confusion as the user continues to retry the login and wonders why their password is being called incorrect.  Can a way be found to distinguish these two failures (proper password and no group membership)?  One way I've seen this done is by having a dedicated "Access Denied" wiki page that the extension could send users to who successfully passed the password authentication but failed the group matching.  This page would need to be created and placed in the $wgWhitelistRead array so it could be seen by the user after their access fails due to not being in a group.  So, after a username and password are entered and the extension gets pass the password verification (From the debug log: Binding as the user / Bound successfully) and enters the check of groups and finds no group that matches (From the debug log: Couldn't find the user in any groups), the extension could send the browser to the "Access Denied" page to alert the user that they are not allowed access to the wiki based on group membership.  A single specification such as:
 * $wgLDAPAccessDeniedPage = array( "DOMAIN1" => "Access Denied" ) would set this option and define the page name to send users to.  I am not a programmer so cannot help in providing code to allow this to happen, but I have seen it in another AD authentication extension so I assume it is possible and feel would be a good additional option of this extension. JimS 18:33, 13 July 2010 (UTC)


 * Hi! If $wgLDAPUseLocal=true and local users log in without setting the domain to "local" they are successfully authenticated. But then they can't change their password. They have to set the domain to "local" to get the change password link on the preferences page. I would suggest to only authenticate against the chosen domain and fail otherwise. This forces users to set the correct domain.

--


 * Change line 874 in LdapAuthentication.php to:
 * if ( ($wgLDAPUseLocal && isset($_SESSION['wsDomain']) && 'local' == $_SESSION['wsDomain']) || $wgLDAPMailPassword ) {
 * What do you think about that behavior? Could this be integrated in next release? Probably configurable for old and new behavior by adding something like $wgLDAPUseLocalAsFallback
 * I want to vote this up, please! Without this fix, a user can login without choosing "local" in the domain dropdown, but still using his local password. When he does so, he subsequently cannot change his local password in his preferences! I took over that fix, and it works correctly. With it, logging in is only possible in the correct ways: either choose a domain and provide the domain password, or choose "local" and provide the "local" password.

--

if (strstr($username, '@')) {       $this->printDebug( "Username contained @, returning username", NONSENSITIVE ); return $username; }
 * In the getCanonicalName function, usernames are "munged" by first being converted to lowercase, and then having the first character converted to uppercase. For users of the username mapping hook (and maybe others?), it would be nice to have an option like $wgMungUserName = True*/False. This would be for cases where you *know* that what you're pulling in is valid and unique.
 * Seconded. Many Directories use case-sensitive usernames, an option with regard to username munging would be invaluable (and save having to hack/patch things to achieve the desired functionality. Gwsuperfan 23:38, 13 October 2011 (UTC)
 * First time here so dont hate me:) We have made a small modification to the LdapAuthentication.php file to allow users to login using full email while checking against our Global Catalog. We have a large AD setup with 15+ subforests and configuring a special login for each was tedious. This prompted us to attempt login using full email using a single configuration. We also wanted to check against userPrincipalName instead of sAMAccountName (again full email not just username). To allow this we needed to change the usage of suggested wgLDAPSearchString value from USER-NAME@DOM. Using full email would break binding as it would attempt e.g. full@email.test.com@email. We made a small change in the getSearchString method that would change this behavior if an email was given. After line 991 we added:
 * This would allow bind to use the full email to bind which is successful and allow us to use filter on userPrincipalName. Had we changed USER-NAME@DOM to just USER-NAME the test at lines at 370-372 would look for the users DN by generating it from the definded baseDNs in the configuration file which we wanted. This lead to the above fix.