Ryan et al.:
Congrats on Extension:LDAP_Authentication, You're doing some great work here.
Thanks.
Our systems are:
FreeBSD 6.x / amd64
OpenLDAP 2.3.4x
Apache 2.3
PHP 5.2.5
WM 1.11.0 from Ports
TLS works
Proxy User works
I've managed to make things work with our non-standard LDAP tree
So far the only problems that I've encountered
- "Proxy Agent" is ambiguous and even misleading. If you look at something like PADL PAM_LDAP or NSS_LDAP, they simply refer to these as "bindpw" and "bindcn" -- or even a better name is
"MetaUser" since LDAP as a whole is ambiguous as to what constitutes a user or identity (a DN).
Yeah, this is slightly ambiguous. In some cases it does actually act like a proxy user though. I've thought about changing it in the past, but unfortunately, changing options causes serious support/documentation issues. I could keep backwards compatability, and assign the new variable to the old one in the code, but then the code will start to get messy (and messy usually equals buggy).
- WRT groups, It isn't entirely clear which settings control
which group a UID=/CN= must be a member of (PADL calls this $pam_groupdn) v.s. how meta-group member _WITHIN_ media-wiki is determined (PADL call it $nss_base_group)
Essentially, you use the group settings to let the plugin know how your groups are defined using:
http://www.mediawiki.org/wiki/Ldap#Group_options
Once the wiki knows how to find groups, you can tell the wiki to syncronize groups with mediawiki's groups using:
$wgLDAPUseLDAPGroups
If you want to restrict login access to specific groups, you define those groups in:
$wgLDAPRequiredGroups (this attribute serves the same purpose as pam_groupdn)
If you want the plugin to search inside of specific ou instead of using the basedn, you define:
$wgLDAPGroupBaseDNs (this attribute serves the same purpose as nss_base_group)
I *should* have modeled my plugin a little more off of PADL, but overall the way things work in the plugin arent too far off. PADL has a set of defaults that is geared to a Linux/Unix style LDAP setup; my plugin doesn't, which is why you need to set more options.
- $wgLDAPProxyAgentPassword isn't accepting a proper SHA1+Base64'd password -- I've resorted to storing it in cleartext. Will debug later.
I may have been crazy when I wrote that using hashes works. I know at some point in time I tried it and it worked, but I haven't been able to get that to work in quite a while. I'm considering removing that info from the documentation. If you get it working, please let me know.
- $wgLDAPRetrievePrefs isn't documented well -- or it is defaulting to off. It should say/document something like "Enable to extract CN attribute / value pairs from LDAP"
Essentially everything in the plugin except using TLS defaults to off (and I only default to TLS because I'm paranoid). It does pretty much what it suggests though. It syncs selected preferences from LDAP to MediaWiki (and optionally the opposite way).
- It is not entirely clear how other mediawiki settings not defined in the posixAccount or inetOrgPerson foundation ObjectClasses
for things such as Skins and Editing preferences should be stored (semi-overlapping entries in the SQL database side?)
Unfortunately, none of these preferences are pulled/stored from/in LDAP at the current moment. I'll probably need to make a schema specifically for MediaWiki for this kind of functionality. The good thing is, MediaWiki stores a majority of its preferences in a blob in the database; so, I can just map the needed non-blob preferences to existing LDAP attributes, and make one new (binary) attribute for the blob in LDAP. Mapping the preferences back and forth is easy enough, and it done in a completely overlapping way on the SQL database side.
I will examine these closer during the day today.
~BAS
PS. On that topic of LDAP<->MW prefs, it might be recommended to use a wiki table to map SQL columns in mediawiki.wmuser SQL table to LDAP attributes!
wikidb-# \d mediawiki.mwuser;
Table "mediawiki.mwuser" Column | Type | Modifiers
--------------------------+--------------------------+--------
user_id | integer | not null default nextval('mediawiki.user_user_id_seq'::regclass) user_name | text | not null user_real_name | text | user_password | text | user_newpassword | text | user_newpass_time | timestamp with time zone | user_token | character(32) | user_email | text | user_email_token | character(32) | user_email_token_expires | timestamp with time zone | user_email_authenticated | timestamp with time zone | user_options | text | user_touched | timestamp with time zone | user_registration | timestamp with time zone | user_editcount | integer | Indexes: "mwuser_pkey" PRIMARY KEY, btree (user_id) "mwuser_user_name_key" UNIQUE, btree (user_name) "user_email_token_idx" btree (user_email_token)
I've been avoiding adding any tables/columns to the database. I'd like the plugin to be as non-obtrusive as possible. Preferences are thankfully easy to map back and forth. I get them from LDAP, and update the local database. When a user changes their options in the wiki, the wiki updates LDAP (this part is optional). As mentioned earlier, if I add a binary attribute to LDAP for mediawiki preferences, that'll kill most of the issues.
One attribute I desperately need is an external_id attribute in MediaWiki's user table. I'll probably try again to get this added to the schema. If I can't get this added, I'll probably make a seperate table just for that. This is needed for automatic renaming of users when a username changes in LDAP.
Thanks for the feedback!
V/r,
Ryan Lane