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,
[.... such is the way of things... ]
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
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.
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.
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.
Just a little bit of knowledge that will help new users accustomed to
PADL setup their Wiki.
Thanks again for your efforts!
~BAS
IMPORTANT: This message contains confidential information and is intended only for the
individual named. If the reader of this message is not an intended recipient (or the
individual responsible for the delivery of this message to an intended recipient), please
be advised that any re-use, dissemination, distribution or copying of this message is
prohibited. Please notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.