Extension talk:LDAP Authentication/Archive 4

About this board

This is the talk page for Extension:LDAP Authentication, an obsolete extension that was never properly updated for recent versions of MediaWiki but was used on Wikitech until October 2024. If you're using a different LDAP extension, use its talk page, such as Extension talk:LDAPAuthentication2, instead.

Archives

Previous page history was archived for backup purposes at Extension talk:LDAP Authentication/LQT Archive 1 on 2015-07-10.
194.176.105.41 (talkcontribs)

Hi there

We are currently running the wiki as internal site. LDAP is working great, now that the wiki is becoming more used we need to manage the administrators better.

The quickest way for us to do this is create a group on AD called wiki admins and then map this group to administrators on the wiki.

How can I do this? I did see on the options page Synchronizing LDAP groups with MediaWiki security groups but I can't seem to get the mapping to work.

Any help would be great.

Arsenii Gorkin (talkcontribs)

Hi!

"groupsync": {

     "mechanism": "mappedgroups",

     "mapping": {

       "developer": "CN=WIKI - Users,OU=GroupAccess,OU=IT,DC=example,DC=com"

     }

  }

All the users from this LDAP (AD) are mapped only as a autoconfirmed. Even if I add explicitly their group to developer group from the local admin user account, after re-login of the said LDAP user, they are again out of the developer group.

Please, help, kindly!

45.18.18.1 (talkcontribs)

Curious if you ever figured this out?

Reply to "LDAP group mapping"

[Urgent] ldap authentication not working

2
Raymond.herrera24 (talkcontribs)

Hi,

I'm using Mediawiki 1.19 and I'm trying to install LDAP but it seems not to be working(when user types his credentials it just goes in the welcome page but it didn;t display the user's name at the top right portion of the screen, in short it wasn't successful.) I've followed http://ryandlane.com/blog/2009/03/23/using-the-ldap-authentication-plugin-for-mediawiki-the-basics-part-1/ but It's still not working. The only working userID is the sysops userID which I created before installing LDAP.

Please help, this is what I've typed in localsettings.php

require_once( "$IP/extensions/LdapAuthentication/LdapAuthentication.php" );
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPDomainNames = array( "testAD" );
$wgLDAPServerNames = array( "testAD" => "**.*.***.** **.*.***.* **.*.**.* **.*.***.***" );
$wgLDAPSearchStrings = array( "testAd" => "testAD\\USER-NAME" );
$wgLDAPEncryptionType = array( "testAD" => "clear" );
$wgLDAPUseLocal = false;
$wgMinimalPasswordLength = 1;

Appreciate your help.

In addition, the only users that are successful logging in are the sysops I created before ldap (the sysops password in mediawiki and ldap server are different but is accepting the ldap password, to me i think is successful authenticating on ldap but needs to have an account in mediawiki).


Mediawiki Account (sysops):

Username: testuser

Password: 12345


Ldap:

Username:testuser

Password: 67890


End Result: Ldap password got in and not the mediawiki account Remarks: the sysops that i created are the only users that can login, it seems that you have to create users in mediawiki that are in ldap in order to login. But this is not we want to occur, we want to use the ldap as the login layer.


I've checked the debug.log and here is the only difference of the sysops account from non-existing local accounts (accounts in LDAP):

2012-07-10 07:32:31  wiki: 2.0a User has a token, setting domain in user options.
2012-07-10 07:32:31  wiki: 2.0a Saving user settings.
2012-07-10 07:32:31  wiki: 2.0a Entering getCanonicalName
2012-07-10 07:32:31  wiki: 2.0a Username is: testuser
2012-07-10 07:32:31  wiki: 2.0a Entering getDomain
2012-07-10 07:32:31  wiki: 2.0a Pulling domain from session.
2012-07-10 07:32:31  wiki: 2.0a Munged username: testuser
2012-07-10 07:32:31  wiki: 2.0a Entering getCanonicalName
2012-07-10 07:32:31  wiki: 2.0a Username is: testuser
2012-07-10 07:32:31  wiki: 2.0a Entering getDomain
2012-07-10 07:32:31  wiki: 2.0a Pulling domain from session.
2012-07-10 07:32:31  wiki: 2.0a Munged username:testuser
64.132.6.98 (talkcontribs)

Was this ever resolved?

I am having the same issue with LDAPAuthentication2

TYIA

Reply to "[Urgent] ldap authentication not working"

LDAP Using CentOS7 (Active Directory)

2
185.46.212.117 (talkcontribs)

Hello everyone,


Feel like I'm going crazy. Installed MediaWiki on a brand new CentOS7 VM (iso 1810).

MediaWiki version 1.32.0

MariaDB10.3.14

PHP version 7.3.5


Got the LDAP extension off this website, created a folder called LdapAuth under /extensions

Installed php-ldap

composer install --no-dev


Added the following settings to my LocalSettings.php (and tried countless variaties on this):


#added by me

require_once ('/var/log/www/html/extensions/LdapAuth/src/Auth/LdapAuthenticationRequest.php');

require_once ('includes/AuthPlugin.php');

wfLoadExtension( 'LdapAuth' );


$wgAuth = new AuthPlugin()

$wgLDAPDomainNames = array('mytest.lan');

$wgLDAPServerNames = array('mytest.lan' => 'ad01.mytest.lan');

$wgLDAPSearchAttributes = array('mytest.lan' => 'sAMAccountName');

$wgLDAPBaseDNs = array('mytest.lan' => 'dc=mytest,dc=lan');

$wgLDAPAuthEncryptionType = array('mytest.lan' => 'false');

$wgLDAPPort = array('mytest.lan' => '389');

$wgLdapAuthIsActiveDirectory = true;

$wgMinimalPasswordLength = 1;

#Debugging options

$wgShowExceptionDetails = true;

$wgLDAPDebug = 3

$wgDebugLogGroups[ 'ldap' ] = '/tmp/debug.log';


This and all kinds of variaties but to no success.


- I don't see packets incoming on the domain controller except DNS. DNS-resolving itself works fine and there are no ACL's between the two machines.

- The logging for whatever reason does not work. I turned off SELinux to make sure it isn't blocking anything but no luck. Gave the /tmp/debug.log all access for the time being but still nothing is being written to it.

- Documentation says to make sure /etc/php.d/ldap.ini has the line containing: extension=ldap.so

This is not entirely the case, this OS had: /etc/php.d/20-ldap.ini containing the line extension=ldap (so without the.so, though I changed that as well but it did not help)

- put the following line in /etc/openldap/ldap.conf: TLS_REQCERT never


Ran the maintenance/update.php after pretty much every change as well restarting the httpd (and the server itself at times).

But whenever I try to logon with a domainuser It just tells me "username or password is not correct". Truly at a loss. The same settings work fine on Zabbix => Active Directory authentication.

Jlenuff (talkcontribs)

Hi,

From a fresh CentOS 7 install too (CentOS Linux release 7.6.1810), here is what I did and it works like a charm :

Download LdapAuthentication extension :

[root@myserver ~]# wget -O downloads/LdapAuthentication-REL1_32-e2cab88.tar.gz https://extdist.wmflabs.org/dist/extensions/LdapAuthentication-REL1_32-e2cab88.tar.gz

Extract archive file in the mediawiki extensions directory :

[root@myserver ~]# tar -xzf downloads/LdapAuthentication-REL1_32-e2cab88.tar.gz -C /data/www/mediawiki/current/extensions

Add the following configuration options in the /data/www/mediawiki/current/LocalSettings.php file :

## Beginning of LDAP Authentication/AD Configuration

require_once ("$IP/extensions/LdapAuthentication/LdapAuthentication.php");

$wgAuth = new LdapAuthenticationPlugin();

$wgLDAPDomainNames = array(

  'adomainname'

);

$wgLDAPServerNames = array(

  'adomainname' => 'myADserver.mydomain.local'

);

$wgLDAPSearchStrings = array(

'adomainname' => 'USER-NAME@myreal.domain' // <== to be sure of this value, you can view a record in you AD and compare

);

$wgLDAPEncryptionType = array(

  'adomainname' => 'clear'

);

$wgLDAPUseLocal = false;

$wgMinimalPasswordLength = 1;

$wgLDAPBaseDNs = array(

  'adomainname' => 'DC=mydomain,DC=local'

);

$wgLDAPSearchAttributes = array(

  'adomainname' => 'sAMAccountName'

);

$wgLDAPRetrievePrefs = array(

  'adomainname' => true

);

$wgLDAPPreferences = array(

  'adomainname' => array(

    'email' => 'mail',

    'realname' => 'displayName',    // <== adapt with you needs

    'nickname' => 'samaccountname'

  )

);

$wgLDAPProxyAgent =  array(

  'adomainname' => 'CN=myserviceaccount,OU=serviceaccounts,DC=mydomain,DC=local'

);

$wgLDAPProxyAgentPassword = array(

  'adomainname' => 'myservicepassword'

);

$wgLDAPDisableAutoCreate = array(

  'adomainname' => true

);

$wgLDAPGroupUseFullDN = array(

  'adomainname' => true

);

$wgLDAPLowerCaseUsername = array(

  'adomainname' => true

);

$wgLDAPGroupObjectclass = array(

  'adomainname' => 'group',

);

$wgLDAPGroupAttribute = array(

  'adomainname' => 'member',

);

$wgLDAPGroupNameAttribute = array(

  'adomainname' => 'cn',

);

$wgLDAPGroupsUseMemberOf = array(

  'adomainname' => false,

);

$wgLDAPUseLDAPGroups = array(

  'adomainname' => true,

);

$wgLDAPRequiredGroups = array(

  'adomainname' => array(

    'CN=MyReserverGroup,OU=IT,OU=Users,DC=mydomain,DC=local',

)

);

$wgLDAPGroupsPrevail = array(

  'adomainname' => true,

);

$wgLDAPGroupSearchNestedGroups = array(

  'adomainname' => true,

);

$wgLDAPActiveDirectory = array(

  'adomainname' => true,

);

$wgLDAPAuthAttribute = array(

  'adomainname' => '!(userAccountControl:1.2.840.113556.1.4.803:=2)',

);

$wgHooks['SetUsernameAttributeFromLDAP'][] = 'SetUsernameAttribute';

function SetUsernameAttribute(&$LDAPUsername, $info) {

        $LDAPUsername = $info[0]['samaccountname'][0];

        return true;

}

$wgLDAPDebug = 1; //for debugging LDAP

## End of LDAP Authentication/AD Configuration

Go to your mediawiki instalaltion directory and run the following command in order to adapt you BDD to this new extension :

[root@myserver ~]# cd /data/www/mediawiki/current/

[root@myserver current]# php7 maintenance/update.php

MediaWiki 1.32.0 Updater

Your composer.lock file is up to date with current dependencies!

Going to run database updates for mediawiki_db

Depending on the size of your database this may take a while!

..................................

Attempted to insert 0 IP revisions, 0 actually done.

Purging caches...done.

Done in 2.7 s.
Reply to "LDAP Using CentOS7 (Active Directory)"

The supplied credentials could not be authenticated.

3
Laujc (talkcontribs)

I keep getting this message when trying to login. There is no errors generate in the log. I'm using LDAPAuthentication2 version 1.0.1, LDAPProvider version 1.0.5, PluggableAuth version 6.1, MediaWiki version 1.39, and PHP 7.4.33.

By the way it was working perfectly fine under MediaWiki 1.38.4. The issue starts when I upgraded to MediaWiki 1.39.


Below is my LocalSetting.


wfLoadExtensions([ 'PluggableAuth', 'LDAPProvider', 'LDAPAuthentication2', 'WikiEditor', 'UserMerge' ]);

$LDAPProviderDomainConfigProvider = function() {

$config = [

'domain.gov' => [

'connection' => [

"server" => "ldap.domain.gov",

"port" => 636,

"user" => "cn=LDAPWIKI,ou=ldap,ou=other,ou=domain users,dc=domain,dc=gov",

"pass" => "password",

"enctype" => "ssl",

"options" => [

"LDAP_OPT_DEREF" => 1

],

"basedn" => "dc=domain,dc=gov",

"groupbasedn" => "ou=domain groups,dc=domain,dc=gov",

"userbasedn" => "dc=domain,dc=gov",

"searchattribute" => "samaccountname",

"searchstring" => "USER-NAME@domain.gov",

"usernameattribute" => "cn",

"realnameattribute" => "cn",

"emailattribute" => "mail",

"grouprequest" => "MediaWiki\\Extension\\LDAPProvider\\UserGroupsRequest\\UserMemberOf::factory"

],

'groupsync' => [

"cn=LDAPWIKI,ou=ldap,ou=other,ou=domain users,dc=domain,dc=gov"

],

'userinfo' => [

"email" => "mail",

"realname" => "cn",

"properties.gender" => "gender"

],

'authorization' => [

'rules' => [

'groups' => [

'required' => ["CN=GRP.EMP,OU=GRP,OU=DA,OU=domain Groups,DC=domain,DC=gov","CN=GRP.STAFF,OU=Auto,OU=domain Groups,DC=domain,DC=gov"]

],

],

],

]

];

return new \MediaWiki\Extension\LDAPProvider\DomainConfigProvider\InlinePHPArray( $config );

};

$wgDebugLogGroups['PluggableAuth'] = 'C:\log\pluggableauth-dev.log';

$wgLDAPDebug = 3;

$wgDebugLogGroups['LDAP'] = 'C:\log\ldap-dev.log';

$wgDebugLogGroups['MediaWiki\\Extension\\LDAPProvider\\Client'] = 'C:\log\ldapprovider-dev.log';

$wgDebugLogGroups['LDAPGroups'] = 'C:\log\ldapgroups-dev.log';

$wgDebugLogGroups['LDAPUserInfo'] = 'C:\log\ldapusers-dev.log';

$wgDebugLogGroups['LDAPAuthorization'] = 'C:\log\ldapauthorization-dev.log';

$wgDebugLogGroups['LDAPAuthentication2'] = 'C:\log\LDAPAuthentication2-dev.log';

Pppery (talkcontribs)

You should post this at Extension talk:LDAPAuthentication2 instead. This is the talk page for an obsolete extension, and it is not being monitored (and I only found this by pure chance when doing an unrelated bit of cleanup).

Laujc (talkcontribs)

Thank you so much. I'll definitely post there.

Reply to "The supplied credentials could not be authenticated."

LDAP Authentication (Active Directory)

1
74.218.59.41 (talkcontribs)

Hello everyone,

I feel like I am very close to getting LDAP working within Mediawiki, but may need a second set of eyes to see what I might be missing.


Mediawiki version 1.38.2 (Docker)

MySQL 8.0.30

PHP version 7.4.30


Using the latest versions available of:

LDAPAuthentication2

LDAPAuthorization

LDAPGroups

LDAPProvider

LDAPUserInfo

PluggableAuth


So far, it seems authentication is working with no issue. I can use the test scripts located at extensions/LDAPProvider/maintenance/:

CheckLogon.php returns OK

ShowUserGroups.php returns relevant information for any user I specify

ShowUserInfo.php returns relevant information for any user I specify


Where I think I am having issues is with groupsync. Despite being able to run the tests mentioned above successfully, attempting to login with any account contained in the groupsync section of my ldap.json file returns "Incorrect username or password entered." Seems to me that the groups are not syncing. I have triple checked my ldap.json config to ensure that my DN's are set correctly, but still have had no luck.


My ldap.json file:

{

        "domain.local": {

                "connection": {

                        "server": "10.10.0.2",

                        "user": "cn=ldap-services,ou=Zone0,ou=Zones,ou=Site,dc=creps,dc=local",

                        "pass": "password",

                        "options": {

                                "LDAP_OPT_DEREF": 1

                        },

                        "basedn": "dc=domain,dc=local",

                        "groupbasedn": "ou=Groups,ou=Site,dc=domain,dc=local",

                        "userbasedn": "ou=Zones,ou=Site,dc=domain,dc=local",

                        "searchattribute": "samaccountname",

                        "usernameattribute": "cn",

                        "realnameattribute": "cn",

                        "emailattribute": "mail",

                        "grouprequest": "MediaWiki\\Extension\\LDAPProvider\\UserGroupsRequest\\GroupMember::factory"

                },

                "userinfo": {

                        "attributes-map": {

                                "email": "mail",

                                "realname": "cn",

                                "nickname": "uid",

                                "language": "preferredlanguage"

                        }

                },

                "authorization": [],

                "groupsync": {

                        "mapping": {

                                "Administrators": "cn=MediaWiki_Administrators,ou=Groups,ou=Site,dc=domain,dc=local"

                        }

                }

        }

}


LocalSettings.php contains the following for LDAP:


wfLoadExtension( 'PluggableAuth' );

wfLoadExtension( 'LDAPProvider' );

wfLoadExtension( 'LDAPAuthentication2' );

wfLoadExtension( 'LDAPUserInfo' );

wfLoadExtension( 'LDAPGroups' );

//wfLoadExtension( 'LDAPAuthorization' );

$LDAPProviderDomainConfigs = "/var/www/html/ldap.json";

$LDAPProviderDefaultDomain = "domain.local";

$LDAPAuthentication2AllowLocalLogin = true;

$wgPluggableAuth_ButtonLabel = "Log In";

$wgPluggableAuth_EnableLocalLogin = true;


I have also confirmed that the AD user I am attempting to login with is a member of the MediaWiki_Administrators group I specified in the groupsync mapping section. Any idea what I could be missing?

Reply to "LDAP Authentication (Active Directory)"

Local account creation for non LDAP users

1
Makeaweliweli (talkcontribs)

The LDAP auth works great for my wiki. However, we also need to support local account creation for users that aren't in LDAP.

Is there a way for users to create local accounts that aren't bound to LDAP?

Here's the installation versioning:

Product Version
MediaWiki 1.37.1
LDAPAuthentication2 1.0.3
LDAPAuthorization 1.1.0
LDAPProvider 1.0.4
LDAPUserInfo 1.0.0
PluggableAuth 5.7
Reply to "Local account creation for non LDAP users"

How to get user's profile picture from AD?

1
192.82.77.143 (talkcontribs)
Reply to "How to get user's profile picture from AD?"

Auto-creation of a local account failed: You have not specified a valid username.

1
Capino1980 (talkcontribs)

We have multiple MediaWiki sites. Some of them are using LDAP authentication.

Now I created a new site and used the following json.


{

    "local.domain": {

        "connection": {

            "server": "ldap.local.domain",

            "enctype": "ssl",

            "port": 636,

        "options": {

                "LDAP_OPT_DEREF": 1

        },

            "user": "cn=ldap,ou=users,dc=local,dc=domain",

            "pass": "password",

            "basedn": "dc=local,dc=domain",

            "userbasedn": "dc=local,dc=domain",

            "groupbasedn": "dc=local,dc=domain",

            "searchattribute": "samaccountname",

            "usernameattribute": "samaccountname",

            "realnameattribute": "cn",

            "emailattribute": "mail",

            "grouprequest": "MediaWiki\\Extension\\LDAPProvider\\UserGroupsRequest\\GroupMember::factory",

            "nestedgroups": "true"

        },

        "authorization": {

            "rules": {

                "groups": {

                    "required": [

                        "CN=wikigroup,OU=Distribution list,DC=local,DC=domain"

                    ]

                }

            }

        }

    }

}


But in de debug log, I see a weird notification: [authentication] Auto-creating 192.168.1.100 on login

Reply to "Auto-creation of a local account failed: You have not specified a valid username."

LDAP-Authentication is slow

2
134.147.28.232 (talkcontribs)

The login takes up to 2 minutes or longer, if group restriction is enabled. A look in the debug log (log level: 3) shows, that the user is searched in every group to authenticate it. This step takes a lot of time, because there are over 100.000 users and many groups. Is there a way to improve the speed or a workaround, like just checking if the user is in the required group? The Mediawiki version is: 1.20.2 Configuration and log are below:

require_once( 'extensions/Ldap-Authentification/LdapAuthentication.php' );
$wgAuth = new LdapAuthenticationPlugin();
$wgUseLDAP = true;

#SERVER
$wgLDAPDomainNames = array(
'groupname'
 );
 
$wgLDAPServerNames = array(
'groupname' => 'server'
 );

$wgLDAPUseLocal = false;

$wgLDAPEncryptionType = array(
'groupname' => "clear"
 );


#PROXY
$wgLDAPProxyAgent = array(
'groupname' => "cn=,ou=,dc=,dc=de"
 );
   
$wgLDAPProxyAgentPassword = array(
'groupname' => "password"
 );

$wgLDAPSearchAttributes = array(
'groupname' => "uid"
 );

$wgLDAPBaseDNs = array(
'groupname' => "dc=,dc=de"
 );
   
$wgLDAPGroupBaseDNs = array(
'groupname' => "ou=groups,dc=,dc=de"
 );

$wgLDAPUserBaseDNs = array(
'groupname' => "ou=users,dc=,dc=de"
 );


#GROUPS
$wgLDAPGroupUseFullDN = array(
'groupname' => true
 );

$wgLDAPLowerCaseUsername = array(
'groupname' => true
 );

$wgLDAPGroupObjectclass = array(
'groupname' => "groupOfUniqueNames"
 );
$wgLDAPGroupAttribute = array(
'groupname' => "uniqueMember"
 );

$wgLDAPGroupNameAttribute = array(
'groupname' => "cn"
 );

$wgLDAPRequiredGroups = array(
'groupname' =>  array("cn=groupname,ou=groups,dc=,dc=de")
 );

2013-11-12 12:50:51  : 2.0f Entering validDomain
2013-11-12 12:50:51  : 2.0f User is not using a valid domain ().
2013-11-12 12:50:51  : 2.0f Entering getDomain
2013-11-12 12:50:51  : 2.0f Setting domain as: domain
2013-11-12 12:50:51  : 2.0f Entering allowPasswordChange
2013-11-12 12:50:51  : 2.0f Entering getDomain
2013-11-12 12:50:51  : 2.0f Entering getDomain
2013-11-12 12:50:51  : 2.0f Entering modifyUITemplate
2013-11-12 12:50:51  : 2.0f Entering getDomain
2013-11-12 12:50:51  : 2.0f Entering getDomain
2013-11-12 12:50:51  : 2.0f Entering getDomain
2013-11-12 12:50:52  : 2.0f Entering validDomain
2013-11-12 12:50:52  : 2.0f User is not using a valid domain ().
2013-11-12 12:50:52  : 2.0f Entering getDomain
2013-11-12 12:50:52  : 2.0f Setting domain as: domain
2013-11-12 12:50:52  : 2.0f Entering allowPasswordChange
2013-11-12 12:50:52  : 2.0f Entering getDomain
2013-11-12 12:50:52  : 2.0f Entering getDomain
2013-11-12 12:50:52  : 2.0f Entering modifyUITemplate
2013-11-12 12:50:52  : 2.0f Entering getDomain
2013-11-12 12:50:52  : 2.0f Entering getDomain
2013-11-12 12:50:52  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Entering validDomain
2013-11-12 12:50:56  : 2.0f User is using a valid domain (domain).
2013-11-12 12:50:56  : 2.0f Setting domain as: domain
2013-11-12 12:50:56  : 2.0f Entering getCanonicalName
2013-11-12 12:50:56  : 2.0f Username is: login
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Munged username: login
2013-11-12 12:50:56  : 2.0f Entering authenticate for username login
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Entering Connect
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Using TLS or not using encryption.
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Using servers:  ldap://server:389
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f PHP's LDAP connect method returned true (note, this does not imply it connected to the server).
2013-11-12 12:50:56  : 2.0f Entering getSearchString
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Entering getUserDN
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Doing a proxy bind
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Created a regular filter: (uid=login)
2013-11-12 12:50:56  : 2.0f Entering getBaseDN
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f basedn is ou=users,dc=,dc=de
2013-11-12 12:50:56  : 2.0f Using base: ou=users,dc=,dc=de
2013-11-12 12:50:56  : 2.0f Setting the LDAPUsername based on fetched wgLDAPSearchAttributes: login
2013-11-12 12:50:56  : 2.0f userdn is: uid=login,ou=users,dc=,dc=de
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Binding as the user
2013-11-12 12:50:56  : 2.0f Bound successfully
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Entering getGroups
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Retrieving LDAP group membership
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Searching for the groups
2013-11-12 12:50:56  : 2.0f Entering searchGroups
2013-11-12 12:50:56  : 2.0f Entering getBaseDN
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f basedn is ou=groups,dc=,dc=de
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Binding as the proxyagent
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Entering getDomain
2013-11-12 12:50:56  : 2.0f Search string: (&(uniqueMember=uid=login,ou=users,dc=,dc=de)(objectclass=groupOfUniqueNames))
2013-11-12 12:52:59  : 2.0f Returned groups: cn=group1,ou=groups,dc=,dc=de::cn=group2,ou=groups,dc=,dc=de::cn=group3,ou=groups,dc=,dc=de::cn=group4,ou=groups,dc=,dc=de::cn=sgroup5,ou=groups,dc=,dc=de::cn=group6,ou=groups,dc=,dc=de::cn=group7,ou=groups,dc=,dc=de::cn=group8,ou=groups,dc=,dc=de::cn=group9,ou=groups,dc=,dc=de::cn=group10,ou=groups,dc=,dc=de::cn=group11,ou=groups,dc=,dc=de
2013-11-12 12:52:59  : 2.0f Entering getDomain
2013-11-12 12:52:59  : 2.0f Entering getDomain
2013-11-12 12:52:59  : 2.0f Entering checkGroups
2013-11-12 12:52:59  : 2.0f Entering getDomain
2013-11-12 12:52:59  : 2.0f Entering getDomain
2013-11-12 12:52:59  : 2.0f Checking for (new style) group membership
2013-11-12 12:52:59  : 2.0f Required groups: cn=group9,ou=groups,dc=,dc=de
2013-11-12 12:52:59  : 2.0f Checking against: cn=group1,ou=groups,dc=,dc=de
2013-11-12 12:52:59  : 2.0f Checking against: cn=group2,ou=groups,dc=,dc=de
2013-11-12 12:52:59  : 2.0f Checking against: cn=group3,ou=groups,dc=,dc=de
2013-11-12 12:52:59  : 2.0f Checking against: cn=group4,ou=groups,dc=,dc=de
2013-11-12 12:52:59  : 2.0f Checking against: cn=group5,ou=groups,dc=,dc=de
2013-11-12 12:52:59  : 2.0f Checking against: cn=group6,ou=groups,dc=,dc=de
2013-11-12 12:52:59  : 2.0f Checking against: cn=group7,ou=groups,dc=,dc=de
2013-11-12 12:52:59  : 2.0f Checking against: cn=group8,ou=groups,dc=,dc=de
2013-11-12 12:52:59  : 2.0f Checking against: cn=group9,ou=groups,dc=,dc=de
2013-11-12 12:52:59  : 2.0f Found user in a group.
2013-11-12 12:52:59  : 2.0f Entering getPreferences
2013-11-12 12:52:59  : 2.0f Entering getDomain
2013-11-12 12:52:59  : 2.0f Authentication passed
2013-11-12 12:52:59  : 2.0f Entering updateUser
2013-11-12 12:52:59  : 2.0f Entering getDomain
2013-11-12 12:52:59  : 2.0f Entering getDomain
2013-11-12 12:52:59  : 2.0f User has a token, setting domain in user options.
2013-11-12 12:52:59  : 2.0f Saving user settings.
198.181.18.21 (talkcontribs)

This problem is still present in the plugin. Users with a large number of groups are very slow to login because of the poor implementation for searching the groups.

Reply to "LDAP-Authentication is slow"

Automatic account creation is not allowed

20
TroySettle (talkcontribs)

extension for mediawiki 1.28

I'm getting closer to figuring this out, but stuck on automatically creating accounts. Here's my current (sanitized) configuration. I can authenticate, but I then get the message:

Auto-creation of a local account failed: Automatic account creation is not allowed.

require_once ("$IP/extensions/LdapAuthentication/LdapAuthentication.php");
$wgAuth = new LdapAuthenticationPlugin();
$wgLDAPUseLocal = true;

$wgLDAPDebug = 3;
$wgDebugLogGroups['ldap'] = '/tmp/debug.log';

$wgLDAPDomainNames       = array('LOCAL');
$wgLDAPServerNames       = array('LOCAL' => 'local-dc2.local.domain');
$wgLDAPEncryptionType    = array('LOCAL' => 'clear');
$wgMinimalPasswordLength = 1;
$wgLDAPBaseDNs           = array('LOCAL' => 'ou=Users,ou=LOCAL,dc=domain,dc=local');

$wgLDAPSearchStrings     = array('LOCAL' => 'LOCAL\\USER-NAME');
$wgLDAPSearchAttributes  = array('LOCAL' => 'sAMAccountName' );

$wgLDAPDisableAutoCreate = array('LOCAL' => false);

Any help would be greatly appreciated!

Tz1971 (talkcontribs)

currently I am using Centos 7.3, MySql 5.7 and PHP 7.1 LDAP TLS

LdapAuthentication: REL1_28 2016-11-18T19:08:52 770c89e

in /etc/openldap/ldap.conf

I add

TLS_REQCERT allow    

TLS hard

and LocalSettings.php setting

$wgLDAPEncryptionType  = array('domain.com' => 'tls');

at this point cannot authenticate

so i tweak and change some code in LdapAuthenticationPlugin at line 547

if ( !ldap_start_tls( $this->ldapconn ) ) {

add @

if ( !@ldap_start_tls( $this->ldapconn ) ) {

for autocreation, I stuck at /includes/auth/AuthManager.php between line 1612 and 1626

// Is the IP user able to create accounts?

$anon = new User;

/*

if ( !$anon->isAllowedAny( 'createaccount', 'autocreateaccount' ) ) {

.....

}

*/

comment out this block, now working. (need better solution rather than comment out)

for group permission

# Implicit group for all visitors

$wgGroupPermissions['*']['createaccount'] = false; // ??? not working

$wgGroupPermissions['*']['autocreateaccount'] = false;  // ???

$wgGroupPermissions['*']['read'] = false;

$wgGroupPermissions['*']['edit'] = false;

$wgGroupPermissions['*']['createpage'] = false;

$wgGroupPermissions['*']['createtalk'] = false;

$wgGroupPermissions['*']['writeapi'] = false;

Aarango1 (talkcontribs)

Same here. Any help is appreciated. My config:

require_once( "$IP/extensions/LdapAuthentication/LdapAuthentication.php" );

$wgAuth = new LdapAuthenticationPlugin();

$wgLDAPDomainNames = array("iRedMail");

$wgLDAPServerNames = array("iRedMail" => "192.168.XX.XX");

$wgLDAPPort = array("iRedMail" => 389);

$wgLDAPEncryptionType = array( "iRedMail" => "clear");

$wgLDAPBaseDNs = array( "iRedMail"=>"o=domains,dc=example,dc=com");

$wgLDAPProxyAgent = array("iRedMail"=>"cn=vmail,dc=example,dc=com");

$wgLDAPProxyAgentPassword = array( "iRedMail"=>"*****");

$wgLDAPUserBaseDNs = array( "iRedMail"=>"o=domains,dc=example,dc=com");

$wgLDAPSearchAttributes = array( "iRedMail" => "mail");

$wgLDAPLowerCaseUsername = array( "iRedMail"=>true);

$wgLDAPUseLocal = true;

$wgLDAPDebug = 3;

$wgDebugLogGroups['ldap'] = '/tmp/debug.log';

Legaulph (talkcontribs)

Same issue

TroySettle (talkcontribs)

FWIW, I finally got it working. Not sure what the difference is here... the $wgGroupPermissions item is not listed on the LDAP extension instructions, but I think this is what did it.

require_once ("$IP/extensions/LdapAuthentication/LdapAuthentication.php");
$wgAuth = new LdapAuthenticationPlugin();
#$wgLDAPUseLocal = true;
$wgLDAPDomainNames       = array('LOCAL');
$wgLDAPServerNames       = array('LOCAL' => 'local-dc2.mydomain.local');
$wgLDAPEncryptionType    = array('LOCAL' => 'clear');
$wgMinimalPasswordLength = 1;
$wgLDAPBaseDNs           = array('LOCAL' => 'ou=Users,ou=LOCAL,dc=mydomain,dc=local');
$wgLDAPSearchStrings     = array('LOCAL' => 'LOCAL\\USER-NAME');
$wgLDAPSearchAttributes  = array('LOCAL' => 'sAMAccountName' );
$wgLDAPRetrievePrefs     = array('LOCAL' => true );
$wgGroupPermissions['*']['autocreateaccount'] = true;
Aarango1 (talkcontribs)

I tried with that TroySettle but not luck. I receive same fails, what versions do you have installed? (Mediawiki and LDAP please) Thanks.

Did you create Wiki as Open? private?

NOTE: I solved using wiki 1.23 version.

Legaulph (talkcontribs)

I had to set $wgGroupPermissions['*']['createaccount'] = true;

130.219.8.234 (talkcontribs)

That still did not work for me.

My other anonymous permissions are set to false.

$wgGroupPermissions['*']['edit'] = false; $wgGroupPermissions['*']['read'] = false;

I want this to be a private wiki.

130.219.8.234 (talkcontribs)

It would seem I had to clear all session data and remove cookies from previous logon attempts with my test user as well as comment out self::saveDomain( $user, $_SESSION['wsDomain'] ); from one of the extension's configuration files. It now works.

153.96.128.5 (talkcontribs)

I had this problem, too. In my case, the solution was the one that has already been mentioned above:

1. switch back to local auth in LocalSettings.php; then login with a *local* admin/bureaucrat account (the one you set up when installing the wiki).

2. create a local user with the same name as one that exists in LDAP (give him a bullsh*t password, no need to match the LDAP one). Not mandatory, but if you are smart, this user should be a bureaucrat as you need at least one LDAP-based bureaucrat anyways. Lets call this user "Ldapboss".

3. switch again to LDAP auth in LocalSettings.php; then login with the user Ldapboss you just created. Of course you need to use the user's actual LDAP password this time. Btw, your local admin is now locked out of the system (unless you set wgLDAPUseLocal to true). This is why you need an LDAP-based bureaucrat.

From this point on, weirdly enough, auto account creation works. It's like, you need at least one successful login to make it work. Not sure why, doesn't make sense.

Ask a colleague to log on, or alternatively, rename your Ldapboss user to Ldapboss_Trash (Renameuser extension) and logout. Then login again with Ldapboss using again the LDAP credentials. Now, you Ldapboss is auto-created (this time as a simple user, as it should).

Actually, on Ryan D Lane (creator and ex-maintainer of the plugin) has this written on a 2009 blog post --- Quote:

"Before enabling the plugin, you should create a user in the local wiki database that exists in AD, and promote that user to sysop. After the plugin is enabled, you will not be able to log in as any user who does not exist in AD."

Brain wang (talkcontribs)

Hi,

While I executed step 3, then use Ldapboss login with LDAP password, I got the following error:

[WMFhIqwRAAIAABOptNUAAAAG] 2017-03-09 14:05:24: Fatal exception of type "DBQueryError"

Is it normal?

But it looks I have already logged in.

223.166.93.186 (talkcontribs)

Hi,

Any news on Brain Wang's problem? I experience the same issue. The user seems to be logged in, however logging in with an other user from LDAP still fails.

195.212.29.162 (talkcontribs)

Today I ran into the same issue, and found that the LDAP plugin does not have the right to autocreate users, despite the allowed autocreateaccount Group Permission setting. Then I found that the referred table (ldap_domains) did not exist in the database (and thus throwing the authmanager-autocreate-noperm errors). Creating the table in the right database based on the extensions/LdapAuthentication/schema/ldap-mysql.sql seems to fixed the issue:

# mysql -u root -p

Enter password:

mysql> use my_wiki

Reading table information for completion of table and column names

You can turn off this feature to get a quicker startup with -A

Database changed

mysql> CREATE TABLE ldap_domains (domain_id int not null primary key auto_increment,domain varchar(255) binary not null,user_id int not null);

Query OK, 0 rows affected (0.00 sec)

85.220.204.126 (talkcontribs)

This worked for me. Thanks

145.109.211.76 (talkcontribs)

I am running a private Wiki

$wgGroupPermissions['*']['autocreateaccount'] = true;

fixed it for me. If you read the changelog of 1.27:

* MediaWiki will now auto-create users as necessary, removing the need for

  extensions to do so. An 'autocreateaccount' right is added to allow

  auto-creation when 'createaccount' is not granted to all users.

31.221.114.66 (talkcontribs)

I resolved the problem by setting the $wgGroupPermissions['*']['autocreateaccount'] = true but also assigning CHMOD permissions to all .php files in /mediawiki to 777 for the local account I was using.

70.67.200.45 (talkcontribs)

For anyone else with this error:

Do set $wgGroupPermissions['*']['autocreateaccount'] = true;

Then delete your session cookie and reload the page to get a new session before trying again. Your session gets added to an account auto-creation blacklist when it fails the first time, which happens to give the exact same error message.

213.33.64.46 (talkcontribs)

This exact method worked for me too, thanks! Removing the session-cookie was the one thing I missed after unsuccessfully adding the configuration-option

73.44.250.189 (talkcontribs)

I had the same issue - I did not need to add any particular wgGroupPermissions, I just followed responses from:

153.96.128.5

and 195.212.29.162


Was racking my brain as to why it wasn't working, thanks for your help.

This comes up quite high on the search for issue, so I thought I'd add my 2 cents.

I am running on mediaWiki 1.29 due to legacy php/database and other things related - we're not in a position to do much upgrades and were stuck in using this, which is fine for us, thanks.

187.41.31.85 (talkcontribs)

It worked for me. -> 153.96.128.5

Reply to "Automatic account creation is not allowed"
Return to "LDAP Authentication/Archive 4" page.