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

In part 1 of this series, I discussed basic password authentication for Active Directory (AD). In this article I will discuss enabling group restrictions and synchronization, and retrieving preferences for AD. I’ll first discuss group restrictions, then synchronization, then retrieving preferences.

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).

65 Comments

  1. I have been authenticating against AD ok, using $wgLdapRequiredGroups to specify a required group membership. Now I need to add a second group, where people must be in one or both of the two groups (inclusive OR). I believe that adding more groups to the $wgLdapRequireGroups array ANDs the group requirements instead. Is there any way to do what I need?

    Thanks
    Graham

    Reply

    1. This would be very interessting for me, too.
      Would be glad, if someone can post a solution. :-) TY

      Reply

  2. Hello,
    My authentication against AD is working. Requiring group membership to allow login is also working. But I would like to do more. I would like to restrict access to some areas, categories, or articles to especific groups. One group may only read, other may edit, etc…
    Is it possible?

    Thanks in advance!
    Ricardo

    Reply

    1. Fine grained read restrictions aren’t safely possible in MediaWiki. There are a number of extensions that offer it, but none of them can really be trusted. MediaWiki natively supports write restrictions for namespaces based on groups though.

      Reply

  3. Hi,

    I can authenticate fine, but I’m having an issue with the group permissions. I think the name of the group permissions is not beeing recognized and therefor they are not assigned.

    2010-03-11 09:10:55 wiki-i2_: Pulled the user’s DN: CN=Testuser,OU=Testgroup,OU=Domain users,DC=domain,DC=local
    2010-03-11 09:10:55 wiki-i2_: Entering getGroups
    2010-03-11 09:10:55 wiki-i2_: Retrieving LDAP group membership
    2010-03-11 09:10:55 wiki-i2_: Using memberOf
    2010-03-11 09:10:55 wiki-i2_: Entering checkGroups
    2010-03-11 09:10:55 wiki-i2_: Checking for (new style) group membership
    2010-03-11 09:10:55 wiki-i2_: Required groups: cn=sv – wiki,ou=services,dc=domain,dc=local
    2010-03-11 09:10:55 wiki-i2_: Checking against: cn=sv – wiki,ou=services,dc=domain,dc=local
    2010-03-11 09:10:55 wiki-i2_: Found user in a group.
    2010-03-11 09:10:55 wiki-i2_: Entering getPreferences
    2010-03-11 09:10:55 wiki-i2_: Entering synchUsername
    2010-03-11 09:10:55 wiki-i2_: Authentication passed
    2010-03-11 09:10:55 wiki-i2_: Entering updateUser
    2010-03-11 09:10:55 wiki-i2_: Setting user groups.
    2010-03-11 09:10:55 wiki-i2_: Entering setGroups.
    2010-03-11 09:10:55 wiki-i2_: Locally managed groups is unset, using defaults: bot::sysop::bureaucrat
    2010-03-11 09:10:55 wiki-i2_: Available groups are: sv – wiki::bureaucrat
    2010-03-11 09:10:55 wiki-i2_: Effective groups are: *::user::autoconfirmed
    2010-03-11 09:10:55 wiki-i2_: Checking to see if user is in: sv – wiki
    2010-03-11 09:10:55 wiki-i2_: Entering hasLDAPGroup
    2010-03-11 09:10:55 wiki-i2_: Checking to see if user is in: bureaucrat
    2010-03-11 09:10:55 wiki-i2_: Entering hasLDAPGroup
    2010-03-11 09:10:55 wiki-i2_: Saving user settings.

    $wgGroupPermissions[‘*’][‘read’] = false;
    $wgGroupPermissions[‘user’][‘read’] = false;
    $wgGroupPermissions[‘sv – wiki’][‘read’] = true;
    $wgGroupPermissions[‘sv – wiki’][‘edit’] = true;
    $wgGroupPermissions[‘sv – wiki’][‘createpage’] = true;
    $wgGroupPermissions[‘sv – wiki’][‘minoredit’] = true;
    $wgWhitelistRead = array( “Special:Userlogout”, “Special:Userlogin”);

    Could someone shed some light on why this is occurring?

    Thanks!

    Reply

  4. Hello Ryan,

    I am Brazilian, sorry for any mistake in English.

    I have a wiki site that already works with LDAP authentication and SSO, functioning normally.

    Now I need to sync the AD groups with the Wiki.

    Ie create a group in AD with an X number of users and acknowledging that the Wiki with the privileges, permissions of the AD group. Could you help me? Below is how I put the LocalSettings.php.

    ## Integracao AD

    require_once( “extensions/LdapAuthentication.php” );
    $wgAuth = new LdapAuthenticationPlugin();

    ## Configuracao AD
    $wgLDAPDomainNames = array(“domain”);
    $wgLDAPServerNames = array(“domain”=>”FQDN do servidor”);
    $wgLDAPUseLocal = true;
    $wgLDAPEncryptionType = array(“domain”=>”clear”);
    $wgLDAPSearchStrings = array(“domain”=>”BR\\USER-NAME”);
    $wgLDAPSearchAttributes = array(“domain”=>”sAMAccountName”);
    $wgLDAPBaseDNs = array(“domain”=>”DC=xxx,DC=xxxx,DC=xxxx”);
    $wgLDAPUserBaseDNs = array (“domain”=>”OU=xxx,OU=Users,OU=xxxxxxx,DC=xx,DC=xxxxx,DC=xxxx”,
    $wgLDAPUseLDAPGroups = array(“BR”=>true);
    $wgLDAPGroupNameAttribute = array( “domain”=>”group=AL-WIKICORPORATIVO-BR,OU=Groups,OU=Resources,OU=xxxxxxxxx,DC=xxxxx,DC=xxxxxx,DC=xxxxx” );
    $wgLDAPGroupsPrevail = array(“domain”=>true);
    ##$wgLDAPGroupsPrevail = array(“domain”=>true);
    #$wgLDAPDebug = 1;

    In anticipation of his return.

    Thank you.

    Reply

  5. Hello Ryan,

    thanks for your article, it made setting up LDAP authentication (restricting access to members of some LDAP groups) really easy.
    Since we’re using a setup based on posixAccount/posixGroup we really needed the plugin to deal with primary groups as well. I made a patch that pulls a users primary group from LDAP. In case somebody is interested, you can find it here:
    http://www.biotec.tu-dresden.de/~nickd/patches/mediawiki-ldap-auth.patch

    Regards, Nick

    Reply

  6. Hello Ryan,

    The plugin is working fine for restricting access to a single group. The problem I am having is getting nesting to work. I have tested a few groups who have nested groups with my membership, but setting
    $wgGroupSearchNestedGroups = array( “domain” => true );
    does nothing and the log does not show an attempt to check nested groups. Here is my LocalSettings.php config and the debug log. Any help appreciated:

    LocalSettings.php:
    require_once( “$IP/extensions/LdapAuthentication/LdapAuthentication.php” );
    $wgAuth = new LdapAuthenticationPlugin();
    $wgLDAPDomainNames = array( “domain” );
    $wgLDAPServerNames = array( “domain” => “domaindc.foo.bar” );
    $wgLDAPEncryptionType = array( “domain” => “ssl” );
    $wgMinimalPasswordLength = 1;
    $wgLDAPSearchStrings = array( “domain” => “domain\\USER-NAME” );
    $wgLDAPSearchAttributes = array( domain=> ‘sAMAccountName’ );
    $wgLDAPBaseDNs = array( ‘domain’ => ‘dc=foo,dc=bar);
    $wgLDAPRequiredGroups = array( “domain” => array(“cn=GROUP1-ALL,ou=distribution lists,ou=branch,ou=domain,ou=ad,dc=foo,dc=bar”) );
    $wgLDAPUseFullDN = array( “domain” => true );
    $wgLDAPGroupsUseMemberOf = array( “domain” => true );
    $wgLDAPLowerCaseUsername = array( “domain” => true );
    $wgLDAPGroupUseRetrievedUsername = array( “domain” => true );
    $wgLDAPGroupObjectclass = array( “domain” => “group” );
    $wgLDAPGroupAttribute = array( “domain” => “member” );
    $wgLDAPGroupNameAttribute = array( “domain” => “cn” );
    $wgLDAPGroupSearchNestedGroups = array( “domain” => true );
    $wgLDAPRetrievePrefs = array( domain=> true );
    $wgLDAPPreferences = array( “domain” => array( “email”=>”mail”,”realname”=>”displayname”,”nickname”=>”displayname” ));
    $wgLDAPDebug = 4;
    $wgDebugLogGroups[“ldap”] = “/home/me/test/ldapdebug.log”;

    Debug log:
    2010-08-16 15:51:31 test: Entering validDomain
    2010-08-16 15:51:31 test: User is using a valid domain.
    2010-08-16 15:51:31 test: Setting domain as: domain
    2010-08-16 15:51:31 test: Entering getCanonicalName
    2010-08-16 15:51:31 test: Username isn’t empty.
    2010-08-16 15:51:31 test: Munged username: Me
    2010-08-16 15:51:31 test: Entering authenticate
    2010-08-16 15:51:31 test:
    2010-08-16 15:51:31 test: Entering Connect
    2010-08-16 15:51:31 test: Using SSL
    2010-08-16 15:51:31 test: Using servers: ldaps://domaindc.foo.bar
    2010-08-16 15:51:31 test: Connected successfully
    2010-08-16 15:51:31 test: Lowercasing the username: me
    2010-08-16 15:51:31 test: Entering getSearchString
    2010-08-16 15:51:31 test: Doing a straight bind
    2010-08-16 15:51:31 test: userdn is: domain\me
    2010-08-16 15:51:31 test:
    2010-08-16 15:51:31 test: Binding as the user
    2010-08-16 15:51:31 test: Bound successfully
    2010-08-16 15:51:31 test: Entering getUserDN
    2010-08-16 15:51:31 test: Created a regular filter: (sAMAccountName=me)
    2010-08-16 15:51:31 test: Entering getBaseDN
    2010-08-16 15:51:31 test: basedn is not set for this type of entry, trying to get the default basedn.
    2010-08-16 15:51:31 test: Entering getBaseDN
    2010-08-16 15:51:31 test: basedn is dc=foo,dc=bar
    2010-08-16 15:51:31 test: Using base: dc=foo,dc=bar
    2010-08-16 15:51:31 test: Fetched username is not a string (check your hook code…). This message can be safely ignored if you do not have the SetUsernameAttributeFromLDAP hook defined.
    2010-08-16 15:51:31 test: Pulled the user’s DN: CN=me,OU=Users,OU=branch,OU=domain,OU=AD,DC=foo,DC=bar
    2010-08-16 15:51:31 test: Entering getGroups
    2010-08-16 15:51:31 test: Retrieving LDAP group membership
    2010-08-16 15:51:31 test: Using memberOf
    2010-08-16 15:51:31 test: Entering checkGroups
    2010-08-16 15:51:31 test: Checking for (new style) group membership
    2010-08-16 15:51:31 test: Required groups: cn=GROUP1-ALL,ou=distribution lists,ou=branch,ou=domain,ou=ad,dc=foo,dc=bar
    2010-08-16 15:51:31 test: Checking against: cn=GROUPA,ou=groups,ou=branch,ou=domain,ou=ad,dc=foo,dc=bar
    2010-08-16 15:51:31 test: Checking against: cn=GROUPB,ou=distribution lists,ou=branch,ou=domain,ou=ad,dc=foo,dc=bar
    2010-08-16 15:51:31 test: Couldn’t find the user in any groups.
    2010-08-16 15:51:31 test: Entering strict.
    2010-08-16 15:51:31 test: Returning true in strict().
    2010-08-16 15:51:31 test: Entering allowPasswordChange
    2010-08-16 15:51:31 test: Entering modifyUITemplate

    Reply

    1. Try unsetting these:

      $wgLDAPGroupsUseMemberOf = array( “domain” => true );
      $wgLDAPLowerCaseUsername = array( “domain” => true );

      I’d have to look at the code, but I don’t think nested group checking is done if you are using MemberOf. MemberOf is supposed to negate the need for nested searching. Also, since you are using AD, I don’t think you need to lower case the user name, as AD’s schema shouldn’t be case sensitive on any of the attributes that have to do with the username.

      Reply

      1. I commented out both lines from LocalSettings.php as you suggested. I then tried to login and on my browser got a “Page is unavailable” message after attempting to login. The ldap log (below) seems to show it stopping right before searching for group memberships. I added back the wgLDAPLowerCaseUsername but it made no difference. Getting rid of wgLDAPGroupsUseMemberOf seems to break any searching of groups.

        LDAP log:

        Entering validDomain
        User is not using a valid domain.
        Setting domain as: invaliddomain
        Entering allowPasswordChange
        Entering modifyUITemplate
        Entering validDomain
        User is using a valid domain.
        Setting domain as: domain
        Entering getCanonicalName
        Username isn’t empty.
        Munged username: Me
        Entering authenticate

        Entering Connect
        Using SSL
        Using servers: ldaps://domaindc.foo.bar
        Connected successfully
        Entering getSearchString
        Doing a straight bind
        userdn is: domain\Me

        Binding as the user
        Bound successfully
        Entering getUserDN
        Created a regular filter: (sAMAccountName=Me)
        Entering getBaseDN
        basedn is not set for this type of entry, trying to get the default basedn.
        Entering getBaseDN
        basedn is dc=foo,dc=bar
        Using base: dc=foo,dc=bar
        Fetched username is not a string (check your hook code…). This message can be safely ignored if you do not have the SetUsernameAttributeFromLDAP hook defined.
        Pulled the user’s DN: CN=me,OU=Users,OU=branch,OU=domain,OU=AD,DC=foo,DC=bar
        Entering getGroups
        Retrieving LDAP group membership
        Searching for the groups
        Entering searchGroups
        Entering getBaseDN
        basedn is not set for this type of entry, trying to get the default basedn.
        Entering getBaseDN
        basedn is dc=foo,dc=bar
        User Filter: (&(distinguishedName=Me)(objectclass=user))

        Reply

      2. I also found out that according to the httpd log there was a Segmemtation Fault.

        Reply

      3. The segfault made me realize I may have a bad extension installation. I’m running Mediawiki 1.16.0 with php 5.2.10 and mysql 5.0.84 on centos5. I had installed version 1.2c of the extension. Not sure where I got that from. I replaced it with 1.2b(alpha) from the download site and I no longer get a segfault and it appears that nested groups are being searched, but no groups are found. MemberOf is off. Here is the configuration and log. Thanks for looking into this, I seriously appreciate it.

        require_once( “$IP/extensions/LdapAuthentication/LdapAuthentication.php” );
        $wgAuth = new LdapAuthenticationPlugin();
        $wgLDAPDomainNames = array( “domain” );
        $wgLDAPServerNames = array( “domain” => “dc1.foo.bar dc2.foo.bar” );
        $wgLDAPEncryptionType = array( “domain” => “ssl” );
        $wgMinimalPasswordLength = 1;
        # LDAP Straight bind with search strings
        $wgLDAPSearchStrings = array( “domain” => “USER-NAME@foo.bar” );
        $wgLDAPSearchAttributes = array( “domain” => “sAMAccountName” );
        $wgLDAPBaseDNs = array( domain=> “dc=foo,dc=bar” );
        # Group lookup
        $wgLDAPRequiredGroups = array( “domain” => array( “CN=GROUP-ALL,OU=Distribution Lists,OU=branch,OU=domain,OU=
        AD,DC=foo,DC=bar” ) );
        $wgLDAPUseFullDN = array( “domain” => true );
        #$wgLDAPGroupsUseMemberOf = array( “domain” => true );
        $wgLDAPLowerCaseUsername = array( “domain” => true );
        $wgLDAPGroupUseRetrievedUsername = array( “domain” => true );
        $wgLDAPGroupObjectclass = array( “domain” => “group” );
        $wgLDAPGroupAttribute = array( “domain” => “member” );
        $wgLDAPGroupNameAttribute = array( “domain” => “cn” );
        $wgLDAPGroupSearchNestedGroups = array( “domain” => true );
        $wgLDAPRetrievePrefs = array( domain=> true );
        $wgLDAPPreferences = array( “domain” => array( “email”=>”mail”,”realname”=>”displayname”,”nickname”=>”displayname” ) );
        $wgLDAPDebug = 4;
        $wgDebugLogGroups[“ldap”] = “/home/me/wiki/ldapdebug.log”;

        Entering validDomain
        User is using a valid domain.
        Setting domain as: domain
        Entering getCanonicalName
        Username isn’t empty.
        Munged username: Me
        Entering authenticate

        Entering Connect
        Using SSL
        Using servers: ldaps://dc1.foo.bar ldaps://dc2.foo.bar
        Connected successfully
        Lowercasing the username: Me
        Entering getSearchString
        Doing a straight bind
        userdn is: me@foo.bar

        Binding as the user
        Bound successfully
        Entering getUserDN
        Created a regular filter: (sAMAccountName=Me)
        Entering getBaseDN
        basedn is not set for this type of entry, trying to get the default basedn.
        Entering getBaseDN
        basedn is dc=foo,dc=bar
        Using base: dc=foo,dc=bar
        Fetched username is not a string (check your hook code…). This message can be safely ignored if you do not have the SetUsernameAttributeFromLDAP hook defined.
        Pulled the user’s DN: CN=me,OU=Users,OU=branch,OU=domain,OU=AD,DC=foo,DC=bar
        Entering getGroups
        Retrieving LDAP group membership
        Searching for the groups
        Entering searchGroups
        Entering getBaseDN
        basedn is not set for this type of entry, trying to get the default basedn.
        Entering getBaseDN
        basedn is dc=foo,dc=bar
        Search string: (&(member=Me)(objectclass=group))
        Returned groups:
        Entering searchNestedGroups
        No more groups to search.
        Got the following nested groups:
        Entering checkGroups
        Checking for (new style) group membership
        Required groups: cn=group-all,ou=distribution lists,ou=branch,ou=domain,ou=ad,dc=foo,dc=bar
        Couldn’t find the user in any groups.
        Entering strict.
        Returning true in strict().
        Entering allowPasswordChange
        Entering modifyUITemplate

        Reply

        1. Notice in the output that it is searching for your cn in the member=field:

          Search string: (&(member=Me)(objectclass=group))

          It should be searching for your DN; your configuration is slightly off…

          Change: $wgLDAPUseFullDN to: $wgLDAPGroupUseFullDN

          Reply

          1. Thanks for pointing out my typo Ryan. Its working ok now. I feel like an idiot and sorry for wasting your time. I owe you a beer. No, two beers. Good beer too, not that lite stuff, and in pints like good beer was meant to be served.

          2. No worries. Glad to hear it is working for you ;).

  7. I’ve been happily using LdapAuthentication for a while. I’m using it to check membership of a staff group in active directory. Now I have a request for one of two additional types of authentication, and can’t work out whether either is possible while I still keep the group authentication:

    1. To add a single individual who is in Active Directory but NOT a member of the same staff group. This individual would have read only permission

    2. To allow login to anyone in Active Directory but not a member of the same staff group to login with read only permission from a small group of machines with fixed IP addresses.

    Any suggestions?

    Thanks
    Graham

    Reply

  8. Ryan,

    at least in my setup (described below) there is a problem with group sync with the uppercasing of the user name using getCanonicalName() before the call to getGroups().

    My setup: OpenLDAP with user DNs based on “uid” (uid=USER-NAME,ou=Team,o=Org), and group membership defined by memberUid (not member i.e., the membership list is vanilla uids, all lowercase, not DNs).

    Because of the first letter uppercasing, the LDAP search for (&(memberUid=Xyz)(……)) fails. The uppercase search does work for the user search using ‘uid’ (I suspect because it is defined in LDAP as a case insensitive field, whereas memberUid is not).

    I have a hacked up workaround in getGroups() to get past this problem, but I figured I would leave a note here for your consideration.

    Regards,
    Ravi

    Reply

    1. Indeed, it is the memberUid attribute definition in OpenLDAP that causes the first-letter uppercasing to trip up:

      attributetype ( 1.3.6.1.1.1.1.12 NAME ‘memberUid’
      EQUALITY caseExactIA5Match
      SUBSTR caseExactIA5SubstringsMatch
      SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

      I could change this in OpenLDAP, but I am looking to make a better fix in the plugin itself, perhaps through the introduction of a new config variable. I will await your response though since you might offer a more elegant solution.

      Reply

  9. Hello! Can someone help me!

    This is my LocalSettings
    # LDAP AUTENTICATION – Chamada do Aplicativo e Plugin
    require_once (“$IP/extensions/LdapAuthentication/LdapAuthentication.php”);
    $wgAuth = new LdapAuthenticationPlugin();

    #Basic Auth.
    $wgLDAPDomainNames = array( “Bellcomsys” );
    $wgLDAPServerNames = array( “Bellcomsys” => “server.bellcomsys.net” );
    $wgLDAPSearchStrings = array( “Bellcomsys” => “USER-NAME@Bellcomsys” );
    $wgLDAPEncryptionType = array( “Bellcomsys” => “clear” );

    #GROUPS
    $wgLDAPGroupUseFullDN = array( “Bellcomsys”=>true );
    $wgLDAPBaseDNs = array( ‘Bellcomsys’ => ‘dc=bellcomsys,dc=net’ );
    $wgLDAPSearchAttributes = array( ‘Bellcomsys’ => ‘sAMAccountName’ );
    $wgLDAPGroupsUseMemberOf = array( “Bellcomsys” => true );
    $wgLDAPGroupObjectclass = array( “Bellcomsys”=>”group” );
    $wgLDAPGroupAttribute = array( “Bellcomsys”=>”member” );
    $wgLDAPGroupNameAttribute = array( “Bellcomsys”=>”cn” );
    $wgLDAPRequiredGroups = array( “Acesso,Edit”=> array( “ou=wiki,ou=bellcomcorp,dc=bellcomsys,dc=net” ) );
    #$wgLDAPRequiredGroups = array( “Edit”=> array( “ou=wiki,ou=bellcomcorp,dc=bellcomsys,dc=net” ) );

    #GSync
    $wgLDAPUseLDAPGroups = array( “Bellcomsys”=>true );
    $wgLDAPGroupsPrevail = array( “Bellcomsys”=>true );

    #LOG
    $wgLDAPDebug = 99; # 3
    $wgDebugLogGroups[“ldap”] = “./debug.txt” ;

    #Permission
    # The following permissions were set based on your choice in the installer
    $wgGroupPermissions[‘*’][‘createaccount’] = false;
    $wgWhitelistRead = array( “Main Page”, “Special:Userlogin”, “-“, “MediaWiki:Monobook.css” );
    $wgGroupPermissions[‘Acesso’][‘read’] = true;
    $wgGroupPermissions[‘Edit’][‘edit’] = false;
    $wgGroupPermissions[‘*’][‘read’] = false;

    The Autentication is working fine, the Goups are Sync with the Data Base but the permissions dont work, as you can see, the group “Edit” = False but the members of this group still with the permission of edit files.

    What am i doing wrong?

    Thanks for the Help!

    Reply

  10. Pessoal, mesmo seguindo os modelos fornecidos acima, continuo nao conseguindo autenticar com o LdapAuthentication…

    Primeira vez que tou tentando fazer esse tipo de autenticação.

    Quem poderia me ajudar ??

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>