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
I have found, that, for the moment it would be best to use locally administered groups instead of LDAP groups since:
- As you said, no LDAP Schema is yet defined to keep the
user_options array found in SQL in LDAP instead
Groups are handled seperately from user_options. The plugin does update group membership in the local database.
My POSIX group membership wont be 1:1 with my MediaWiki group membership, so I'm going to have to log in as a local admin to adjust group membership anyway.
I'll definitely probably take the time to set a new ou=wikiGroups once prefs can be stored in LDAP, but that's not really high-priority for me ATM.
You can make new posix groups that are meant for the wiki, or you can use something other than posix groups.
I did notice that when you populate the UID in SQL from an LDAP user, you are not utilizing the posixAccount objectClass value "uidNumber", which would be nice (maybe a feature in the future). The database schema defaults an Index auto-incrementing, but it doesn't require it.
My plugin doesn't create the users in the local database, MediaWiki's core software does.
I wouldn't want the software to mess with the local database's userid, especially since I'd want to be able to store things other than numbers in it. Active Directory, for instance, uses SUIDs and GUIDs, which are non-numeric. Having an external id column in the table would suffice though. Honestly what you *really* want to store in the database is something that uniquely describes your user. If you have multiple domains (like an OpenLDAP, and an Active Directory domain), the uidNumber attribute may not be unique. In this case you may want to store something like "employeeNumber".
This becomes even more important when you start thinking about smartcards, and other auto-login technologies. Your smartcard may not have your username, but may instead have your name+employeeNumber, or name+someOtherUniqueID.
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)
Yea, I figured that out. One thing I did notice (This is a behavioral note) :
In PALD (PAM or NSS), the way a groups works is that it is an object-class "posixGroup", with a CN= like:
cn=Wiki,ou=appAccess,o=foo,dc=collaborativefusion,dc=com
Then, there will be a "multi-value" attribute such as:
memberUid
memberUID will contain the Fully Qualified DNs/names of users such:
cn=Joe Blow,ou=People,o=foo,dc=collaborativefusion,dc=com cn=John Brown,ou=People,o=foo,dc=collaborativefusion,dc=com
Where as, when LDAPRequiredGroups runs a query, it searches:
"(&(memberUid=[seklecki])(objectclass=posixGroup))"
- ObjectClass of course is configurable which is nice
- memberUID is only being passed the "uid=value" section of a full CN previously searched by the Proxy User
As an example debugging output, you might see:
[ ... log excerpt ... ] Doing a proxy bind Using base: ou=People,o=foo,dc=collaborativefusion,dc=com
userdn is: cn=Brian \ Seklecki,ou=People,o=foo,dc=collaborativefusion,dc=com
Search string: (&(memberUid=seklecki)(objectclass=posixGroup))
[ ... end ... ]
So it's just just chopping an the value of attribute "uid=" out of the 1st matched proxy search result and using that as the search string when checking group membership
... where we differ here from PADL is that they search for entire DN= string previously matched. So here memberUid just contains an itemized list of UIDs.
You aren't using the regular posix way ;). Normally the openLDAP client is setup to search for the uid attribute in memberUid, not the full DN. If you need to use the full DN, you need to use this option:
$wgLDAPGroupUseFullDN
Notice this is the way Active Directory holds group members as well.
V/r,
Ryan Lane