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