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:
1) 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.
2) 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