Extension:LDAP Authentication/User Provided Information

my phone number you have is wrong some one elder is recived everything I was exposed to get I got roped off my phone number is 828 781 0460

Ability to use both Kerberos/SSO AutoAuth and standard LDAP http login page
I wanted to get both the ability to seamlessly auto-login with Kerberos/GSSAPI SSO mechanisms, without disabling the ability to login normally via Kerb/LDAP with the standard Special:UserLogin form. The following seemed to allow me to get his ability without a lot of patching. ''Warning: There is no implied warranty/safety with using this method. I have only tested it on a cursory basis, and it seems to work. More rigorous testing should be applied before putting this into production. Also, I am not entirely certain if this overburdens the server with LDAP requests.''

To get it working, I just changed LocalSettings.php to be a mix/hybrid of the AutoLogin capabilities as shown from Extension:LDAP Authentication/AD Configuration Examples and the Extension:LDAP_Authentication/Kerberos_Configuration_Examples.

LocalSettings.php:

Require user patch
You'll want to patch this by hand, not using the patch command

Here's a quick patch which allows an associative array of required users like so this allows authentication to be done in the LDAP whilst the authorization is done locally. I tried experimenting with other methods to achieve this, but none of them seemed to work right. If I turn off auto-user-creation, there's no way for admins to do it manually. Creating directly in the database seems a hassle. Setting up a group isn't really an option in this case. Is there a better way? What I really wanted to find was an admin special page for creating new users.

Patch considered to small and obvious to be copyright, use it if you like without need for attribution. This isn't a totally general solution since it doesn't deal with different policies for different domains. E.g. everybody in a group + exceptions.


 * Hmm, can't set up an LDAP group? Seems like the easiest method, but if it isn't possibly in your enviroment, this is probably a viable option. Let's change your code up a little here though:


 * Now it is generic ;). Make sure to check my code for stupid errors, as I didn't actually try this, but it should work.
 * -- Ryan Lane

Trusting self-signed SSL certificates
Anybody know how to have LdapAuthentication trust self-signed certificates, as alluded to in the "Requirements" section? It doesn't currently appear to be able to trust certs that haven't been signed by a trusted provider.
 * This is dependant upon what type of OS you are using. I'm not sure if this is the right spot for the documentation of how to do this...
 * --Ryan Lane


 * For Fedora Core 4 I added a line to /etc/openldap/ldap.conf:


 * TLS_REQCERT never


 * A similar change to this should work for any system using OpenLDAP. Be advised this tells OpenLDAP NOT to do any checking on the certificate (not the default), which will make you suceptible to a man-in-the middle attack.


 * A more secure option is to add this line:
 * TLS_CACERT /etc/openldap/cacerts/myselfsigned.crt


 * You can also add "myselfsigned.crt" to /usr/share/ssl/certs and set the following in /etc/ldap.conf:
 * tls_cacertdir  /usr/share/ssl/certs


 * If you use TLS_CACERT, you may need to also add the same info on TLS_CACERTFILE, depending on the OS (RHEL 3 seems to need this).

_____________

I think the issue is can your ldap even recognize your self-signed certs; it may be just a matter of adding the public key of the CA you used to sign your certs to your ldap configuration.

I think this is the same problem I am having. My ldap.conf is configured for TLS_REQCERT=never. The ldaps is working fine for ssh authentication and other(verified with ssldump and ethereal). But for some reason it seems that the /etc/ldap.conf is ignored by php.

Hmmmmmm.


 * I believe ALL of /etc/ldap.conf is ignored by php. php uses /etc/openldap/ldap.conf I believe. I run into this problem every time I set up a system by hand. The easy solution (and a generally safe solution) is to remove /etc/openldap/ldap.conf and symlink it to /etc/ldap.conf. Of course, you can't do that if you are using openLDAP server on that system, but no one in their right mind would run a webserver on their LDAP server right? :)
 * -- Ryan Lane

Right. And I have symlinked it. I guess it is just odd behavior how the php is behaving. I wonder if there is a case sensitivity issue with php? I did notice tls_reqcert in my ldap.conf is all lowercase.

I will test and post back.

Just tested. No joy.

I wrote this up after I finally figured out this issue:

Here is some documentation from microsoft for enabling LDAP over SSL: --Ryan Lane

/etc/ldap.conf belongs to the operation system authorization and authentification interfaces pam_ldap and nss_ldap. It would not be used from PHP in this case. /etc/openldap/ldap.conf belongs to the openldap client libraries and would be used indirect from PHP. Both files should have different content. TLS_CACERTDIR could be used with all CA certificates in own files. It should be necessary to use c_rehash on a directory with CA certificates and TLS_CACERTDIR.
 * -- Ralf Hansen

Adding WikiSysop
Finally you'll need to add a WikiSysop user to LDAP. Which is a little tricky because WikiSysop isn't a real user. This is what I used.

dn: ou=applications,dc=example,dc=org objectClass: top objectClass: organizationalUnit ou: applications dn: uid=WikiSysop,ou=applications,dc=example,dc=org uid: WikiSysop cn: WikiSysop userPassword: secret objectClass: shadowAccount objectClass: simpleSecurityObject objectClass: applicationProcess

Full instructions here http://caldergroup.com/configure/wikildapauthentication.html


 * You can also create your own user before the system is configured for LDAP (make sure to use all lowercase letters...), and give your user sysop privileges, then configure it for LDAP. After doing so, you can give anyone else sysop privileges with your user. -- Ryan Lane


 * If you are feeling adventurous you can also modify the 'user_groups' table in the database. First find your user id in the 'user' table:
 * then do something like
 * All of this assumes you have write access to the DB and that you are pretty proficient/comfortable with SQL. --James Candalino
 * All of this assumes you have write access to the DB and that you are pretty proficient/comfortable with SQL. --James Candalino
 * All of this assumes you have write access to the DB and that you are pretty proficient/comfortable with SQL. --James Candalino

Allow LDAP users to act as SysOps or Bureaucrat based on groups
If you want Mediawiki authorization to based solely on LDAP and still allow multiple Bureaucrat or Sysops roles you'll need to create a group in LDAP and retrieve associated groups on login.
 * actually this can easily be done with autopromote in your localsettings.php, no need to create any special groups.

Windows configuration
If your instance of MediaWiki is hosted on a Windows machine running IIS, Apache, etc, there are some key items to configure to confirm that PHP has secure LDAP functionality enabled.


 * 1) In php.ini (in your apache/bin directory NOT your php directory!!!) make sure the following lines are uncommented
 * 2) *extension=php_ldap.dll
 * 3) *extension=php_openssl.dll
 * 4) Also in PHP.ini; Confirm those dll's are in the directory referenced by extension_dir (ex. c:\php\ext)
 * 5) Copy several files from the DLL folder of the PHP/Win32 binary package to the SYSTEM folder of your windows machine. (Ex: C:\WINNT\SYSTEM32, or C:\WINDOWS\SYSTEM). For PHP <= 4.2.0 copy libsasl.dll, for PHP >= 4.3.0 copy libeay32.dll and ssleay32.dll to your SYSTEM folder.
 * 6) Create a text file called ldap.conf in the directory C:\openldap\sysconf\. The first line must be TLS_REQCERT never . (For some reason OpenLdap has this as a hard-coded required file.)

Deactivating manual password change
Since I disabled usage of the passwords stored in the MediaWiki database and since there is no way for me to write into our LDAP directory I chose to deactivate the passwort fields in Special:Preferences and to write a message into them how to change your password. Simply insert these lines into MediaWiki:Monobook.js:

Password change is disabled by default
 * Note: This works on Firefox, but not on IE 6 --Flominator 07:04, 6 August 2007 (UTC)
 * Note: This will only work if the user has javascript enabled --Ryan lane 19:12, 6 August 2007 (UTC)
 * So is there other means to hide password changes and new user registration? --User:Anonymous 13:31, 23 December 2008 (UTC)

Deactivating New User Signup / Registration
Insert the following into LocalSettings.php $wgWhitelistAccount = array ( "user" => 0, "sysop" => 1, "developer" => 1 ); $wgGroupPermissions['*'   ]['createaccount']   = false;
 * 1) Prevent new user registrations

Testing LDAP binding and searching
LDAP Browser is a good way to test your searching and binding configuration. --Flominator 18:59, 10 August 2007 (UTC)

Active Directory Primary Group Patch
Active Directory does not list the Primary Group of the user when getting members from the group object. This patch fixes that by getting the primary group id from the user object, creating a SID to find the group and then add the group to the rest of the user's groups. There is no easier way of doing this through LDAP. This code has not been tested on non-AD LDAPs, but should just skip if it is not querying an AD LDAP. This also fixes an issue where the groups are not added soon enough when using $wgLDAPGroupsPrevail and the Group Based Access Control extension. This prevented new groups added to AD from being available for access control.

REMOTE_USER
Is there a posibility to use the REMOTE_USER given by IE to automatically login a user available in the AD? I found an extension but it did not work for me. Can someone help? - JB


 * Yes. This extension can do this; but, if you only want to do authentication, and no authorization, or preference pulling, this extension is overkill. See the kerberos examples for information on how to do this with this plugin. See the HttpAuth extension for something that will only do authentication. BTW, you really should put stuff like this into the support section. --Ryan lane 22:06, 15 June 2009 (UTC)

Separate Authentication and Authorization Providers Patch
I needed a way to authenticate with our LDAP environment, but use Active Directory groups to authorize users. This patch will add this functionality to the plugin.

Define both providers in the LocalSettings.php as the plugin instructions suggest. But instead of adding your authorization provider to $wgLDAPDomainNames, define a new array with a mapping to the authentication provider.

where TestAuthnProvider is the authentication provider and TestAuthzProvider is the authorization provider.

Capitalize user name as in LDAP
We use long user names in LDAP with proper capitalization (e.g. first name and surname is capitalized, such as "John Miller"). The module, as it is now, forces capital first letter, and everything else lowercase. I patched the module so that getCanonicalName gets the properly capitalized name from LDAP, and then uses that name for logging in to the Wiki.

The patch is very simple, but it has the downside that it connects to the LDAP server twice during authentication. Getting rid of that would have required much more extensive code changes. -- Andre.Spiegel 08:40, 20 July 2009 (UTC)

In addition to the patch below, you need the following implementation of the hook SetUsernameAttributeFromLDAP:

And here is the patch:

Fetching All Groups Fails in Large AD Installations
In the alpha version of the plugin 1.2(b), search for all groups will effectively bomb out for a large Active Directory deployment. By the time this line is called, userdn is already defined, so the following patch worked for us:

This avoids doing a costly (&(member=*)(objectClass=group)) search, during authentication.


 * The idea behind $wgLDAPGroupsPrevail is that you can avoid this search completely nearly all of the time. $wgLDAPGroupsPrevail allows you to populate the entire list of groups - this was done for compatibility with another extension. If you want to avoid the search, don't set "$wgLDAPGroupsPrevail = array( "mydomain" => true );". The default for this is false.


 * If you do, for some reason, need to pull all of the groups, then this patch breaks the functionality. --Ryan lane 21:09, 14 October 2009 (UTC)

Group name limitations
If you want to use the group syncronization option $wgLDAPUseLDAPGroups combined with the $wgGroupPermissions usage... there is a default 16 character limit on the length of the group name. The group name gets stored in the database, in the user_groups table, ug_group column. The datatype of this column is varbinary(16). The behavior that I saw was that the user could authenticate, the groups would appear Special:ListGroupRights page, but the user would not be in the appropriate groups.

I didn't want to be stuck with 16 character group names, so to fix this alter the existing column to increase the size:

Otherwise, you can alter the maintenance\table.sql script before you create the wiki site:

Using v1.2d and MediaWiki 1.16.

Group mapping
If you already have groups that don't fit the sysop/bureaucrat-wikimedia-schema there is a simple patch to enable GroupMapping:

addGroupMapping.patch:

You can than add the domain-specific configuration option GroupMapping:

LocalSettings.php