Group restrictions and synchronization will require you to somewhat understand the LDAP structure that your AD environment is built upon. Don’t worry, this isn’t as scary as it sounds, and I’ll explain how to find all of the information you’ll require.

Prerequisites

Before you start, you must have authentication working. See part 1 of this series to enable authentication. Don’t try to get everything working at the same time. First ensure authentication is working, then enable group restrictions, then go from there.

For this article we will use the domain configured in part 1:

$wgLDAPDomainNames = array( "TESTAD" );

Group configuration

Shared group options

Telling the plugin how to map users to group members

AD stores full Distinguished Names (DN)s like cn=Ryan Lane,dc=testad,dc=example,dc=com in groups, so we’ll need to tell the plugin to use full DNs. Also, we’ll need to tell the plugin how to get the user’s DN. Place the following in LocalSettings.php:

$wgLDAPGroupUseFullDN = array( "TESTAD"=>true );
$wgLDAPBaseDNs = array( 'TESTAD' => 'dc=testad,dc=example,dc=com' );
$wgLDAPSearchAttributes = array( 'TESTAD' => 'sAMAccountName' );

Telling the plugin how to find users in groups

For the plugin to find your groups, it needs to know how to search for them. There are two methods for doing this: The first (and easiest) way to do this is to use memberOf. The second way is to tell the plugin the attribute and objectclass used by the group, and the attribute used for member of the group.

Using memberOf

Currently, the plugin cannot find the primary group of a user using memberOf. If you need to restrict groups based on user’s primary groups, do not use memberOf. To enable memberOf for AD, put the following in LocalSettings.php:

$wgLDAPGroupsUseMemberOf = array( "TESTAD" => true );

Manually configure the search

Thankfully, most (all?) AD configurations use the same attributes and objectclasses for group membership, so this is fairly straightforward. Put the following into LocalSettings.php:

//The objectclass of the groups we want to search for
$wgLDAPGroupObjectclass = array( "TESTAD"=>"group" );

//The attribute used for group members
$wgLDAPGroupAttribute = array( "TESTAD"=>"member" );

//The naming attribute of the group
$wgLDAPGroupNameAttribute = array( "TESTAD"=>"cn" );

Group restrictions

The LDAP plugin supports two types of group restriction. The first is a list of groups a user is required to be a member of (required groups), the second is a list of groups a user cannot be a member of (excluded groups). Both types of restrictions can be used simultaneously.

Required groups

To require a user to be a member of a group (such as cn=wiki-users,ou=groups,dc=testad,dc=example,dc=com), put the following into LocalSettings.php:

$wgLDAPRequiredGroups = array( "TESTAD"=> array( "cn=wiki-users,ou=groups,dc=testad,dc=example,dc=com" ) );

Excluded groups

To require a user to not be a member of a specific group (such as cn=excluded-wiki-users,ou=groups,dc=testad,dc=example,dc=com), put the following into LocalSettings.php:

$wgLDAPExcludedGroups = array( "TESTAD"=> array( "cn=excluded-wiki-users,ou=groups,dc=testad,dc=example,dc=com" ) );

Group synchronization

Group synchronization allows you to manage MediaWiki authorization using groups defined in your AD server. To enable synchronization, simply add the following to LocalSettings.php:

$wgLDAPUseLDAPGroups = array( "TESTAD"=>true );

To use LDAP groups, you’ll have to define their permissions; say for instance you have a group called “wiki-users”, you could enable edit permissions for users in that group by adding the following to LocalSettings.php:

$wgGroupPermissions['wiki-users']['edit'] = true;

If you’d like to add sysop permissions to a group called “wiki-admins”, you could put the following into LocalSettings.php:

$wgGroupPermissions['wiki-admin'] = $wgGroupPermissions['sysop'];

Overall, group synchronization is far more powerful than group restriction. See MediaWiki’s user rights documentation for more information on controlling access.

Retrieving preferences

The LDAP plugin can pull certain attributes from AD, and assign them to MediaWiki user preferences. The MediaWiki attributes currently available are email, realname, nickname, and language. You can configure which MediaWiki preference maps to which AD attribute; put the following in your LocalSettings.php to retrieve preferences:

$wgLDAPPreferences = array( "TESTAD"=>array( "email"=>"mail","realname"=>"cn","nickname"=>"sAMAccountName","language"=>"preferredLanguage") );

Finding user and group DNs, and object attributes

To find the DN of a user in an AD group for use in any options mentioned above, use the dsquery command:

dsquery group -name "wiki-users"
"cn=wiki-users,ou=groups,dc=testad,dc=example,dc=com"

To get the value of specific attributes, use the dsquery command in conjunction with the dsget command:

dsquery user -name "test-user"
"cn=test-user,ou=Domain Users,dc=testad,dc=example,dc=com"
dsget "cn=test-user,ou=Domain Users,dc=testad,dc=example,dc=com" -upn
  upn
  test-user@TESTAD.EXAMPLE.COM

You can get a lot of information with these commands; to find out what else you can find, see the help documentation using dsquery /?.

Test your configuration by logging in with an LDAP user

If you are doing group synchronization, you should ensure users are being correctly added and removed from MediaWiki groups when they are being added and removed from your AD groups. If you are retrieving preferences, you should ensure they are being updated when you log in.

If you have any questions, you should post them on the discussion page for the plugin on mediawiki.org, or leave me a comment (the former is preferred).

Share:

Related posts:

1. Using the LDAP Authentication Plugin for MediaWiki – The Basics (Part 1)
2. Using the LDAP Authentication Plugin for MediaWiki – The Basics (Part 2)
3. Semi-anonymous users in MediaWiki using the LDAP Authentication extension

So, if you wanted to have a wiki, like a wiki for polls, that needed some form of anonymity for users to trust using it, using the LDAP Authentication extension in a clever way can allow you to do this.

Enable the extension and test authentication

First and foremost, you should ensure that LDAP authentication is configured and working properly; see part 1 and part 2 of the series of articles for using the LDAP plugin for MediaWiki.

Configure the SetUsernameAttributeFromLDAP hook

The LDAP extension has a configuration hook that allows you to set the username used in MediaWiki to any of the user’s attributes in LDAP. We’ll use this to create a semi-anonymous username based off one of the user’s attributes.

Notice that I am saying semi-anonymous for a reason. Unless you want to create a new user for someone every time they log in, you have to create the username in such a way that it is the same every time. Put the following into the bottom of LocalSettings.php:

// This hook is called by the LdapAuthentication plugin. It is a configuration hook. Here we
// are specifying what attibute we want to use for a username in the wiki.
// The hook calls the function defined below.
$wgHooks['SetUsernameAttributeFromLDAP'][] = 'SetUsernameAttribute';

// This function allows you to get the username from LDAP however you need to do it.
function SetUsernameAttribute(&$LDAPUsername, $info) {
    $LDAPUsername = $info[0]['cn'][0];
    $LDAPUsername = $LDAPUsername . "MySuperSecretAppendedString0230932740982738khewfjkshd";
    // How usernames are created should not be disclosed, otherwise
    // the psuedo-anonymity will be lost.
    $LDAPUsername = 'pseudo.' . md5($LDAPUsername);
    // All hooks have to return a boolean in MediaWiki
    return true;
}

You should change the attribute pulled, the “MySuperSecret…” string, and (possibly) the hashing function to something else. You should probably leave the “pseudo.” string alone. Notice that it is important that whatever hash function you use creates a username that is allowed by MediaWiki; I am using md5 above for this reason.

As you can see, the wiki system administrator, and anyone else that knows how you are hashing the usernames, can figure out who anonymous users are. It is important to keep this information secret.

Test login to ensure the username gets hashed

When you log in, you should have a semi-anonymous username. Log out and log in again; you should have the same semi-anonymous username; if not, your hashing function isn’t working properly.

Give your semi-anonymous user admin privileges

Notice that every user, including your admin user, is now semi-anonymous. Unfortunately, this means you are no longer an admin. To fix this:

1. Log out
2. Disable the semi-anonymous configuration
3. Log in as your admin user
4. Give admin privileges to your new semi-anonymous user
5. (Optionally) merge your old admin user with your new semi-anonymous user

I should probably mention that your admin user will likely no longer be anonymous after giving yourself admin privileges (after all, most people probably know who the wiki admin is).

An alternative to these steps is to not hash your admin’s username in the above function.

Feedback

Let me know if this is or isn’t working for you, or if you have a better way of making users anonymous.

Update (06/29/2009): Looks like this isn’t working right now unless you are using auto-authentication. I’ll try to have an update for the LDAP extension soon that’ll address this.

Share:

Related posts:

1. Using the LDAP Authentication Plugin for MediaWiki – The Basics (Part 3)
2. Using the LDAP Authentication Plugin for MediaWiki – The Basics (Part 1)
3. Using the LDAP Authentication Plugin for MediaWiki – The Basics (Part 2)

Three types of scripts are available: helpers, preprocessors. and plotters. The script types are loaded in that order so that helpers can be used in preprocessors and plotters, and so that data can be preprocesed before it is plotted.

Wiki editors can use these scripts by using the plot parser function, or tag:

{{#plot:
|renderer=plotkit
|name=<uniquename>
|width=300
|height=300
|script=<scriptname>
|scriptarguments=arg1,arg2,...
|preprocessors=<preprocessorname1>,<preprocessorname2>,...
|preprocessorarguments=<preprocessor1argument1>,<preprocessor1argument2>,...:preprocessor2argument1>,<preprocessor2argument2>,...:...,...
|labels=label1,label2
|datasep=,
|tableclass=wikitable
|data=1,2
2,4}}

or a simpler example:

{{#plot:
|renderer=plotkit
|script=bar
|labels=label1,label2
|data=1,2
2,4}}

Only scripts used in pages are loaded; so, download sizes should be reasonable. ExplorerCanvas is always included for IE support. If javascript is disabled, a table is shown with the raw data; the CSS class that is used for the table can be user defined with the tableclass argument.

Administrators can add and remove available renderers and javascript via configuration options. By default, the plotkit renderer is defined. A default generic renderer is always available that simply outputs a canvas element.

See the Plotters extension page on mediawiki.org for more information. See my sandbox for examples. Bug reports can be placed on the extension’s discussion page, posted as a comment on this blog, or sent to me via email. Post all support questions on the extension’s discussion page.

Share:

Related posts:

1. Semi-anonymous users in MediaWiki using the LDAP Authentication extension