Hello,
is there any roadmap about implementation of this LDAP Hub and replacemente of Extension:LDAP Authentication ?
Talk:LDAP hub
Unfortunately not. There has some progress been made, but there is no official release yet. On the upcoming Wikimedia Hackathon 2018 in Barcelona I plan to coordinate with the other project members. Hopefully there is more to say after this event.
@osnard Did anything happen at the Hackathon? I'm just getting going but will have to roll back to 1.27 for better LDAP support.
@Osnard: Anything new to report after the hackathon? Perhaps an estimate of percentage feature-completeness for an alpha, or description of the progress made?
Any sort of road-map would help us as we decide what to do with our aging ldap-using wiki.
Unfortunately I did not make the progress I planned. What are your requirements? Maybe they are already met by the current feature set of the stack.
@Osnard: So far, we've been using the extension for ldap authentication against Active Directory, with lookups restricted to a particular group/OU, and are quite happy. We're just worried about upgrading to 1.27+.
Beyond that, we've assigned elevated rights where needed within mediawiki. It would be nice if we could easily map mediawiki groups to particular ldap groups/OUs (regular user vs bureaucrat vs admin), but we haven't looked that hard at that possibility, and it isn't a dealbreaker for us, obviously.
Really, we're just looking for something that claims to work with the latest versions of mediawiki without a lot of little patches here and there. Maybe just some more clarity on what does and does not work in 1.27+ would help? If auto-auth doesn't work, does the rest generally work without hacks? I can't make heads or tails of what's in the extensions's pages as to what is working vs broken, which makes it hard to address the sysadmin's concerns. In particular, there's a lot of activity in the ldap extension talk area, and then this hub.What's the community's goal -- repair or replace?
@Osnard for me it's more the problem of already built on 1.30 and wanting to auth against AD and have groups given access there. I have not spent much time working with older versions as I was hoping to not have to roll back to get it working. I do have a test of bluespice up just to see how it works, but it seems a bit bloated compared to the 1.30 install I currently have.
I was hoping for a clean AD connection after the event. Do you know if I can get any Authentication working with the 1.30 install through AD?
Thanks
@Namtr0 You should now be able to use the stack. See LDAP hub, LDAP Stack and maybe Extension:LDAPAuthentication2
I cannot get authorized to the wiki, although it seems the ldap is authenticating my login account. We have our 1.23 version with the old LdapAuthentication set to private with only the specific ldap group configured to have login access. Here is my LocalSettings.php stanza for 1.31:
wfLoadExtension("PluggableAuth");
wfLoadExtension("LDAPProvider");
wfLoadExtension("LDAPGroups");
wfLoadExtension("LDAPAuthentication2");
wfLoadExtension("LDAPAuthorization");
$LDAPProviderDomainConfigProvider = function() {
$config = [
"LDAP" => [
"connection" => [
"server" => "ldap.domain.org",
"port" => "636",
"user" => "cn=authaccount,dc=domain,dc=org",
"pass" => "password-auth",
"basedn" => "ou=People,dc=domain,dc=org",
"groupbasedn" => "ou=Groups,dc=domain,dc=org",
"userbasedn" => "ou=People,dc=domain,dc=org",
"searchattribute" => "uid",
"searchstring" => "",
"usernameattribute" => "uid",
"realnameattribute" => "cn",
"emailattribute" => "Email"
],
"groupsync" => [
"cn=wiki_editors,ou=Groups,dc=domain,dc=org"
],
"userinfo" => [
]
]
];
return new \MediaWiki\Extension\LDAPProvider\DomainConfigProvider\InlinePHPArray( $config );
};
This gives me a login prompt which accepts my username password combo and then returns an error "Fatal exception of type MWException". When I check the ldap logs, I see the following:
Apr 16 14:47:43 pastrami slapd[4356]: conn=2275506 fd=24 ACCEPT from IP=x.y.z.34:58576 (IP=0.0.0.0:636)
Apr 16 14:47:43 pastrami slapd[4356]: conn=2275506 fd=24 TLS established tls_ssf=256 ssf=256
Apr 16 14:47:43 pastrami slapd[4356]: conn=2275506 op=0 BIND dn="cn=authaccount,dc=domain,dc=org" method=128
Apr 16 14:47:43 pastrami slapd[4356]: conn=2275506 op=0 BIND dn="cn=authaccount,dc=domain,dc=org" mech=SIMPLE ssf=0
Apr 16 14:47:43 pastrami slapd[4356]: conn=2275506 op=0 RESULT tag=97 err=0 text=
Apr 16 14:47:43 pastrami slapd[4356]: conn=2275506 op=1 SRCH base="ou=People,dc=domain,dc=org" scope=2 deref=0 filter="(uid=username)"
Apr 16 14:47:43 pastrami slapd[4356]: conn=2275506 op=1 SRCH attr=* memberof
Apr 16 14:47:43 pastrami slapd[4356]: conn=2275506 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Apr 16 14:47:43 pastrami slapd[4356]: conn=2275506 op=2 BIND anonymous mech=implicit ssf=0
Apr 16 14:47:43 pastrami slapd[4356]: conn=2275506 op=2 BIND dn="uid=username,ou=People,dc=domain,dc=org" method=128
Apr 16 14:47:43 pastrami slapd[4356]: conn=2275506 op=2 BIND dn="uid=username,ou=People,dc=domain,dc=org" mech=SIMPLE ssf=0
Apr 16 14:47:43 pastrami slapd[4356]: conn=2275506 op=2 RESULT tag=97 err=0 text=
Apr 16 14:47:43 pastrami slapd[4356]: conn=2275506 op=3 BIND anonymous mech=implicit ssf=0
Apr 16 14:47:43 pastrami slapd[4356]: conn=2275506 op=3 BIND dn="cn=authaccount,dc=domain,dc=org" method=128
Apr 16 14:47:43 pastrami slapd[4356]: conn=2275506 op=3 BIND dn="cn=authaccount,dc=domain,dc=org" mech=SIMPLE ssf=0
Apr 16 14:47:43 pastrami slapd[4356]: conn=2275506 op=3 RESULT tag=97 err=0 text=
Apr 16 14:47:43 pastrami slapd[4356]: conn=2275506 op=4 SRCH base="ou=People,dc=domain,dc=org" scope=2 deref=0 filter="(uid=username)"
Apr 16 14:47:43 pastrami slapd[4356]: conn=2275506 op=4 SRCH attr=* memberof
Apr 16 14:47:43 pastrami slapd[4356]: conn=2275506 op=4 SEARCH RESULT tag=101 err=0 nentries=1 text=
Apr 16 14:47:43 pastrami slapd[4356]: conn=2275506 op=5 UNBIND
Apr 16 14:47:43 pastrami slapd[4356]: conn=2275506 fd=24 closed
For the record, this is what the successful login looks like on the same ldap server with the old 1.23 wiki, with the old LdapAuthentication:
Apr 16 09:27:45 pastrami slapd[4356]: conn=2275479 fd=24 ACCEPT from IP=x.y.z.14:43293 (IP=0.0.0.0:636)
Apr 16 09:27:45 pastrami slapd[4356]: conn=2275479 fd=24 TLS established tls_ssf=256 ssf=256
Apr 16 09:27:45 pastrami slapd[4356]: conn=2275479 op=0 BIND dn="cn=authaccount,dc=domain,dc=org" method=128
Apr 16 09:27:45 pastrami slapd[4356]: conn=2275479 op=0 BIND dn="cn=authaccount,dc=domain,dc=org" mech=SIMPLE ssf=0
Apr 16 09:27:45 pastrami slapd[4356]: conn=2275479 op=0 RESULT tag=97 err=0 text=
Apr 16 09:27:45 pastrami slapd[4356]: conn=2275479 op=1 SRCH base="ou=People,dc=domain,dc=org" scope=2 deref=0 filter="(uid=username)"
Apr 16 09:27:45 pastrami slapd[4356]: conn=2275479 op=1 SRCH attr=* memberof
Apr 16 09:27:45 pastrami slapd[4356]: conn=2275479 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Apr 16 09:27:45 pastrami slapd[4356]: conn=2275479 op=2 BIND anonymous mech=implicit ssf=0
Apr 16 09:27:45 pastrami slapd[4356]: conn=2275479 op=2 BIND dn="uid=username,ou=People,dc=domain,dc=org" method=128
Apr 16 09:27:45 pastrami slapd[4356]: conn=2275479 op=2 BIND dn="uid=username,ou=People,dc=domain,dc=org" mech=SIMPLE ssf=0
Apr 16 09:27:45 pastrami slapd[4356]: conn=2275479 op=2 RESULT tag=97 err=0 text=
Apr 16 09:27:45 pastrami slapd[4356]: conn=2275479 op=3 SRCH base="uid=username,ou=People,dc=domain,dc=org" scope=0 deref=0 filter="(objectClass=posixAccount)"
Apr 16 09:27:45 pastrami slapd[4356]: conn=2275479 op=3 SRCH attr=dn
Apr 16 09:27:45 pastrami slapd[4356]: conn=2275479 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text=
Apr 16 09:27:45 pastrami slapd[4356]: conn=2275479 op=4 BIND anonymous mech=implicit ssf=0
Apr 16 09:27:45 pastrami slapd[4356]: conn=2275479 op=4 BIND dn="cn=authaccount,dc=domain,dc=org" method=128
Apr 16 09:27:45 pastrami slapd[4356]: conn=2275479 op=4 BIND dn="cn=authaccount,dc=domain,dc=org" mech=SIMPLE ssf=0
Apr 16 09:27:45 pastrami slapd[4356]: conn=2275479 op=4 RESULT tag=97 err=0 text=
Apr 16 09:27:45 pastrami slapd[4356]: conn=2275479 op=5 SRCH base="dc=domain,dc=org" scope=2 deref=0 filter="(&(member=uid=username,ou=people,dc=domain,dc=org)(objectClass=\
groupOfNames))"
Apr 16 09:27:45 pastrami slapd[4356]: <= bdb_equality_candidates: (member) not indexed
Apr 16 09:27:45 pastrami slapd[4356]: conn=2275479 op=5 SEARCH RESULT tag=101 err=0 nentries=18 text=
Apr 16 09:27:45 pastrami slapd[4356]: conn=2275479 op=6 UNBIND
Apr 16 09:27:45 pastrami slapd[4356]: conn=2275479 fd=24 closed
I've tried adding the following to the LocalSettings.php file, above the groupsync section, but when I add this the wiki refuses to load and I only get a blank screen:
"authorization" => {
"rules" => {
"groups" => {
"required" => [
"cn=wiki_editors,ou=Groups,dc=domain,dc=org"
],
"excluded" => [
]
}
}
},
Forgot to mention RHEL6, with apache 2.4, php7.0, mariadb5.5
The "groupsync" section seems to be configured wrong. Please check the documentation on this. Also it looks like you are not using Extension:LDAPAuthorization, so you might as well disable it.
Hi,
And I am able to authenticate users and I am being logged in, but the login process returns an error (even though I am logged in):
[aa7620161bb77e16aef3c615] /w/intcomsB/index.php?title=Special:UserLogin&returnto=Special%3AUserLogin ConfigException from line 53 of /var/www/www-mediawiki/mediawiki-1.33.0/includes/config/GlobalVarConfig.php: GlobalVarConfig::get: undefined option: 'LDAPUserInfoModifierRegistry'
I can not see any reference to 'LDAPUserInfoModifierRegistry' does anyone know what I have missed?
Thanks
Joe
Config:
wfLoadExtensions( [
'PluggableAuth',
'LDAPProvider',
'LDAPAuthentication2',
'LDAPAuthorization',
'LDAPUserInfo'
] );
$LDAPProviderCacheTime = 1;
$LDAPAuthentication2UsernameNormalizer = 'strtolower';
$LDAPAuthentication2AllowLocalLogin = false;
$wgPluggableAuth_EnableAutoLogin = false;
$wgPluggableAuth_EnableLocalLogin = false;
$wgPluggableAuth_EnableLocalProperties = true;
$wgPluggableAuth_ButtonLabel = "Log in";
$wgAuthRemoteuserUserName = function() {
$user = '';
if( isset( $_SERVER['REMOTE_USER'] ) ) {
$user = strtolower( $_SERVER['REMOTE_USER'] );
}
return $user;
};
$LDAPProviderDomainConfigProvider = function() {
$config = [
'DOMAINNAME' => [
'connection' => [
"server" => "name.example.org.uk",
"options" => [
"LDAP_OPT_DEREF" => 1
],
"port" => 389,
"enctype" => "clear",
"user" => "DOMAINNAME\SPECIALUSER",
"pass" => "THE PASSWORD",
"basedn" => "dc=example,dc=org,dc=uk",
"groupbasedn" => "dc=example,dc=org,dc=uk",
"userbasedn" => "dc=example,dc=org,dc=uk",
"searchattribute" => "samaccountname",
"searchstring" => "DOMAINNAME\\USER-NAME",
"usernameattribute" => "samaccountname",
"realnameattribute" => "displayname",
"emailattribute" => "mail",
"grouprequest" => "MediaWiki\\Extension\\LDAPProvider\\UserGroupsRequest\\UserMemberOf::factory"
],
'authorization' => [
'rules' => [
]
] ,
'userinfo' => [
'attributes-map' => [
'email' => 'mail',
'realname' => 'displayname'
]
]
]
];
return new \MediaWiki\Extension\LDAPProvider\DomainConfigProvider\InlinePHPArray( $config );
};
"user" => "DOMAINNAME\SPECIALUSER", should be "DOMAINNAME\\SPECIALUSER"
It seems the error was related to the 'LDAPUserInfo' and the 'userinfo' array - I did not really need them at this time so I could get everything working by just removing them. More experimentation will be needed later in I do start to need them.
Thanks.
This is strange. The variable $LDAPUserInfoModifierRegistry gets defined by Extension:LDAPUserInfo itself and should therefore never be missing. What PHP version are you using?
I´m implementing an connect to a German windows ad. ShowUserInfo and ShowUserGroups are working. When I try CheckLogin, it is asking for the password. After typing in the correct user-password (shown on terminal) the check is FAILED. It should just check if the user is member of domain-users and of course if password OK?
LDAP.log
2019-10-21 14:52:17 wikisrv.company.local naviwiki: ldap_connect( $hostname = 'ldap://dc1.company.local:389', $port = 389 ); 2019-10-21 14:52:17 wikisrv.company.local naviwiki: # __METHOD__ returns Resource id #192 2019-10-21 14:52:17 wikisrv.company.local naviwiki: ldap_set_option( $linkID, $option = 17, $newval = 3 ); 2019-10-21 14:52:17 wikisrv.company.local naviwiki: # returns 1 2019-10-21 14:52:17 wikisrv.company.local naviwiki: ldap_set_option( $linkID, $option = 8, $newval = 0 ); 2019-10-21 14:52:17 wikisrv.company.local naviwiki: # returns 1 2019-10-21 14:52:17 wikisrv.company.local naviwiki: ldap_set_option( $linkID, $option = 2, $newval = 1 ); 2019-10-21 14:52:17 wikisrv.company.local naviwiki: # returns 1 2019-10-21 14:52:17 wikisrv.company.local naviwiki: ldap_bind( $linkID, $bindRDN = 'cn=Administrator,cn=Users,dc=company,dc=local', $bindPassword = 'XXXX' ); 2019-10-21 14:52:17 wikisrv.company.local naviwiki: # returns 1 2019-10-21 14:52:17 wikisrv.company.local naviwiki: ldap_bind( $linkID, $bindRDN = 'uid=Mueller,cn=Domänen-Benutzer,cn=Users,dc=company,dc=local', $bindPassword = 'XXXX' ); 2019-10-21 14:52:17 wikisrv.company.local naviwiki: # returns
Thanks for helping
So this just says that the server could not bind with the user 'uid=Mueller,cn=Domänen-Benutzer,cn=Users,dc=company,dc=local' and the given password. Can you confirm that the User-DN was assembles correctly from the given username? Maybe the UserBaseDN is not set correctly. Is the password definitively correct?
I don't think that the Umlaut in "Domänen-Benutzer" is an issue.
Hi,
I recently installed Bluespice Free 3.1 and tried to get LDAP Authentication working against an Active Directory.
So far I am able to log in using the account I created at installation, but with the password from AD (Account names are the same).
However, when I try to login with another account, the login form says (in German):
"Auto-creation of a local account failed:
Automatic account creation is not allowed"
Here is my config (relevant parts)
$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['*']['autocreateaccount'] = true;
wfLoadExtension( 'PluggableAuth' );
wfLoadExtension( 'LDAPProvider' );
wfLoadExtension( 'LDAPAuthentication2' );
wfLoadExtension( 'LDAPAuthorization' );
$LDAPProviderCacheTime = "1";
$LDAPProviderDomainConfigProvider = function() {
$config = [
'mydomain.com' => [
'connection' => [
"server" => "dc.mydomain.com",
"user" => "binduser@mydomain.com",
"pass" => "password",
"options" => [
"LDAP_OPT_DEREF" => 1
],
"basedn" => "DC=mydomain,DC=com",
"enctype" => "clear",
"port" => "389",
"groupbasedn" => "DC=mydomain,DC=com",
"userbasedn" => "DC=mydomain,DC=com",
"searchattribute" => "samaccountname",
"grouprequest" => "MediaWiki\\Extension\\LDAPProvider\\UserGroupsRequest\\GroupMember::factory",
"searchstring" => "USER-NAME@mydomain.com",
"usernameattribute" => "samaccountname",
"realnameattribute" => "cn",
"emailattribute" => "mail"
],
"authorization" => [
"rules" => [
"groups" => [
"required" => [ "CN=requiredgroup,OU=3,OU=2,OU=1,DC=mydomain,DC=com" ]
]
]
]
]
];
return new \MediaWiki\Extension\LDAPProvider\DomainConfigProvider\InlinePHPArray( $config );
};
$wgDebugLogFile = "/var/www/bluespice/debug-{$wgDBname}.log";
$wgShowExceptionDetails = true;
$wgGroupPermissions['(all)']['autocreateaccount'] = true;
$wgDebugLogGroups['PluggableAuth'] =
$wgDebugLogGroups['LDAP'] =
$wgDebugLogGroups['MediaWiki\\Extension\\LDAPProvider\\Client'] =
$wgDebugLogGroups['LDAPGroups'] =
$wgDebugLogGroups['LDAPUserInfo'] =
$wgDebugLogGroups['LDAPAuthorization'] = '/tmp/LDAP.log';
I would like to emphasize that $wgGroupPermissions['*']['autocreateaccount'] = true; is set and thus auto-account creation to group (all) should be set. However, when checking the "Special:ListGroupRights" page on my wiki, it says group (all) has no rights whatsoever. Is this a peculiarity of BlueSpice?
Also, I can't really seem to get the debug logs for the extensions working somehow (despite setting valid file paths in the wgDebugLogGroups variables, so a pointer on how to set them up to deliver necessary information to debug this would be awesome.
Thanks for reading and your help!
~ Pi
This is probably due to the BlueSpice "role-permission-system". You might need to add
$GLOBALS['bsgPermissionConfig']['autocreateaccount'] = [ 'type' => 'global', "roles" => [ 'autocreateaccount' ] ]; $GLOBALS['bsgGroupRoles']['*']['autocreateaccount'] = true;
to your LocalSettings.php file.
That was exactly it :)
Thank you very much!
Hello,
Following the Manual:Active_Directory_Integration documentation I connected the mediawiki to my LDAP
The user connection works but I can't do:
- Restriction on groups (to allow a group of persons)
- Manage rights by groups
My users is :
- wiki_admin is in the group : grpwikiadmin
- wiki_utilisateur is in the group : grpwikiutilisateur
- wiki_interdit have no group
My groups :
- Grpwikiadmin : I want them to be admin
- Grpwikiutilisateur : I want basic user rights on wiki
Grpwikiutilisateur have the member : Grpwikiadmin and wiki_utilisateur
how to do it?
Thank you for your help
The LDAP connexion don't work if the options "authorization => "rules" => "groups" => "required" is présent
My domain is test.local and my groups and users is in the OU=test,DC=test,DC=local
################### ldap.json ###################
{
"test.local": {
"connection": {
"server": "192.168.1.50",
"port": "3268",
"user": "CN=svc_wiki,OU=test,DC=test,DC=local",
"pass": "MYpassword",
"enctype": "clear",
"options": {
"LDAP_OPT_DEREF": 1
},
"basedn": "DC=test,DC=local",
"userbasedn": "DC=test,DC=local",
"groupbasedn": "DC=test,DC=local",
"searchattribute": "samaccountname",
"searchstring": "USER-NAME@test.local",
"usernameattribute": "samaccountname",
"realnameattribute": "cn",
"emailattribute": "mail",
"grouprequest": "MediaWiki\\Extension\\LDAPProvider\\UserGroupsRequest\\UserMemberOf::factory",
"presearchusernamemodifiers": [ "spacestounderscores", "lowercase" ]
},
"userinfo": [],
"authorization": {
"rules": {
"groups": {
"required": ["CN=grpwikiutilisateur,OU=test,DC=test,DC=local"]
}
}
}
},
"groupsync": {
"mapping": {
"engineering": "CN=grpwikiutilisateur,OU=test,DC=test,DC=local",
"bureaucrat": "CN=grpwikiadmin,OU=test,DC=test,DC=local",
"interface-admin": "CN=grpwikiadmin,OU=test,DC=test,DC=local",
"sysop": "CN=grpwikiadmin,OU=test,DC=test,DC=local"
}
}
}
}
################### localconfig.php ###################
// Safe IP or not (for bypassing external login via AD)
$safeIPs = array('127.0.0.1','localhost');
$ipsVars = array('HTTP_X_FORWARDED_FOR','HTTP_X_REAL_IP','REMOTE_ADDR');
foreach ($ipsVars as $ipsVar) {
if (isset($_SERVER[$ipsVar]) && mb_strlen($_SERVER[$ipsVar]) > 3 ) { $wikiRequestIP = $_SERVER[$ipsVar]; break; }
}
$wikiRequestSafe = (isset($wikiRequestIP) && ( in_array($wikiRequestIP,$safeIPs) ));
// Create Wiki-Group 'engineering' from default user group
$wgGroupPermissions['engineering'] = $wgGroupPermissions['user'];
// Privatisation du Wiki
$wgEmailConfirmToEdit = false;
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['read'] = false;
$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['sysop']['createaccount'] = false;
$wgGroupPermissions['*']['autocreateaccount'] = true;
$wgBlockDisablesLogin = true;
// Chargement du fichier Json si il existe sans erreur
$ldapJsonFile = "$IP/ldap.json";
$ldapConfig = false;
if (is_file($ldapJsonFile) && is_dir("$IP/extensions/LDAPProvider")) {
$testJson = @json_decode(file_get_contents($ldapJsonFile),true);
if (is_array($testJson)) {
$ldapConfig = true;
} else {
error_log("Found invalid JSON in file: $IP/ldap.json");
}
}
//////////// Active l'extension
if ( $ldapConfig ) {
wfLoadExtension( 'PluggableAuth' );
wfLoadExtension( 'LDAPProvider' );
wfLoadExtension( 'LDAPAuthentication2' );
wfLoadExtension( 'LDAPAuthorization' );
wfLoadExtension( 'LDAPUserInfo' );
wfLoadExtension( 'LDAPGroups' );
$LDAPProviderDomainConfigs = $ldapJsonFile;
$wgPluggableAuth_ButtonLabel = "Connexion LDAP";
if ($wikiRequestSafe) { $LDAPAuthentication2AllowLocalLogin = true; }
}
################### My configuration ###################
Mediawiki : 1.34
PHP7.3.14-1~deb10u1 (apache2handler)
DAPAuthentication2 1.0.1 (4836429) 20 mars 2020 à 07:29
LDAPAuthorization 1.1.0 (c7d1c50) 18 mars 2020 à 22:23
LDAPGroups 1.0.2 (d8f8e90) 18 mars 2020 à 22:24
LDAPProvider 1.0.3 (ecf3c2d) 18 mars 2020 à 22:37
LDAPUserInfo 1.0.0 (ea18199) 18 mars 2020 à 22:38
PluggableAuth 5.7 (17fb1ea) 13 septembre 2019 à 10:20
Can you please provide the output of LDAPProvider/maintenance/ShowUserGroups.php?
Hello,
php extensions/LDAPProvider/maintenance/ShowUserInfo.php --domain test.local --username wiki_admin
samaccountname => wiki_admin
samaccounttype => 805306368
userprincipalname => wiki_admin@test.local
objectcategory => CN=Person,CN=Schema,CN=Configuration,DC=test,DC=local
PuTTYPuTTYdscorepropagationdata => 16010101000000.0Z
lastlogontimestamp => 132302933033589595
mail => wiki_admin@domain.test
dn => CN=wiki_admin,OU=test,DC=test,DC=local
php extensions/LDAPProvider/maintenance/ShowUserGroups.php --domain test.local --username wiki_admin
Full DNs:
PHP Warning: Invalid argument supplied for foreach() in /var/www/html/wikidsi/extensions/LDAPProvider/maintenance/ShowUserGroups.php on line 60
Short names:
PHP Warning: Invalid argument supplied for foreach() in /var/www/html/wikidsi/extensions/LDAPProvider/src/GroupList.php on line 52
I have errors but I can't find any information about them
Please try to configure a different "groupsrequest". E.g. MediaWiki\\Extension\\LDAPProvider\\UserGroupsRequest\\GroupMember::factory
Hello, i create a group named "Factory", it's work !
root@wiki:/var/www/html/wikidsi# php extensions/LDAPProvider/maintenance/ShowUserGroups.php --domain test.local --username wiki_admin
Full DNs:
CN=factory,OU=test,DC=test,DC=local
CN=grpwikiadmin,OU=test,DC=test,DC=local
Short names:
factory
grpwikiadmin
i don't understand this function. My error is the group name of "UserGroupsRequest\\GroupMember::" ?
Hello,
everything is working !!!! :-D (access right and group)
my mistakes were:
- grouprequest: you had to put: GroupMember :: factory
- the mechanism was missing
My ldap.json :
{
"test.local": {
"connection": {
"server": "192.168.1.50",
"port": "3268",
"user": "CN=svc_wiki,OU=test,DC=test,DC=local",
"pass": "Not24get",
"enctype": "clear",
"options": {
"LDAP_OPT_DEREF": 1
},
"basedn": "DC=test,DC=local",
"userbasedn": "DC=test,DC=local",
"groupbasedn": "DC=test,DC=local",
"searchattribute": "samaccountname",
"usernameattribute": "samaccountname",
"realnameattribute": "cn",
"emailattribute": "mail",
"grouprequest": "MediaWiki\\Extension\\LDAPProvider\\UserGroupsRequest\\GroupMember::factory",
"presearchusernamemodifiers": [ "spacestounderscores", "lowercase" ]
},
"userinfo": [],
"authorization": {
"rules": {
"groups": {
"required":[ "CN=grpwikiutilisateur,OU=test,DC=test,DC=local","CN=grpwikiadmin,OU=test,DC=test,DC=local" ]
}
}
},
"groupsync": {
"mechanism": "mappedgroups",
"mapping": {
"engineering": "CN=grpwikiutilisateur,OU=test,DC=test,DC=local",
"bureaucrat": "CN=grpwikiadmin,OU=test,DC=test,DC=local",
"sysop": "CN=grpwikiadmin,OU=test,DC=test,DC=local"
}
},
"userinfo": {
"email": "mail",
"realname": "cn",
"properties.gender": "gender"
}
}
}
I just switched from LDAPAuthentication (which seems broken on 1.33) to this LDAP stack (LDAPProvider, LDAPAuthentication2, and LDAPUserInfo which seems mandatory), but now in the user preferences my users can't edit their email address and such. I was using the wiki as the main front-end to modify user data, since it's the primary component of my website. Is there any way to let MediaWiki write back to LDAP, so users can modify their Real Name, Email, etc. in the User Preferences?
No, unfortunately writing back into the LDAP resource as it was possible with the old Extension:LDAP Authentication is not implemented in the new stack yet.
https://www.mediawiki.org/wiki/Talk:LDAP_hub
I installed e configured:
LDAPAuthentication2
LDAPAuthorization
LDAPGroups
LDAPProvider
LDAPUserInfo
PluggableAuth
I can run with success the following scripts under extensions/LDAPProvider/maintenance/:
ShowUserInfo.php, ShowUserGroups.php, CheckLogin.php.
But when I try to login I get:
Could not authenticate credentials against domain "mydomain"
So I enabled debug log with:
$wgDebugLogGroups['PluggableAuth'] =
$wgDebugLogGroups['LDAP'] =
$wgDebugLogGroups['MediaWiki\\Extension\\LDAPProvider\\Client'] =
$wgDebugLogGroups['LDAPGroups'] =
$wgDebugLogGroups['LDAPUserInfo'] =
$wgDebugLogGroups['LDAPAuthentication2'] =
$wgDebugLogGroups['LDAPAuthorization'] = '/tmp/LDAP.log';
But I get no log. Nothing... /tmp/ can be written by anyone.. What can I investigate?
You can try to set up the general debug log as described on Manual:$wgDebugLogFile
I did:
$wgDebugLogFile = "/tmp/debug-ldap.log";
But it is populated only by maintenance jobs.
This is probably a file system permission issue. The CLI user that runs maintenance/runJobs.php hat permissions to write this file, but the webserver doesn't.
Alternatively the LDAP extensions are just not invoked in the CLI call. It there some bailout statement checking for PHP_SAPI?
After upgrading 1.37 to 1.39 , the login screen does not have data entry boxes for name , password and domain.
we authenticate to a openldap server.
I ran these tests from command line and they work okay:
php /var/www/git-v139/mediawiki/extensions/LDAPProvider/maintenance/ShowUserInfo.php --username rob --domain redacted.com
php /var/www/git-v139/mediawiki/extensions/LDAPProvider/maintenance/ShowUserGroups.php --username rob --domain redacted.com
also CheckLogin.php worked. I was prompted for a password and OK was returned.
If I set the following , there are places to do a local login with :
$wgPluggableAuth_EnableLocalLogin = true ;
any suggestions to fix this?
in the mean time I'll continue to look around for the solution.
@RobFantinidid you get a fix for this ? ii am facing the same issue
I have not been able to fix this.
Do you happen to know where I could file a bug report?
I have the same problem. After upgrading from 1.35 to 1.39.1, mediawiki does not display the login box. Ldap seems to work, according to the maintenance php script.
When you upgraded MediaWiki to version 1.39, did you upgrade PluggableAuth and the LDAP extensions as well? If so, what versions are you using? Note that LDAPAuthentication2 is not yet compatible with version 6.x of PluggableAuth. You will need to stick with version 5.7 of PluggableAuth for now.
Hello Cindy, Downgrading to version 5.7 of PluggableAuth fixed the issue for us. I am not sure which version we were using before that. I had used the following to install PluggableAuth for the 1.39 wiki :
git clone https://gerrit.wikimedia.org/r/mediawiki/extensions/PluggableAuth --branch REL1_39
Thank You.
Yes, the release branch has the most recent version of PluggableAuth. The issue is that LDAPAuthentication2 is not yet compatible with the most recent version of PluggableAuth. However, a new version of LDAPAuthentication2 should hopefully be available soon.
Hello Cindy.
It looks like this issue may be fixed? I was reading 'Migration from PluggableAuth 5' at https://www.mediawiki.org/wiki/Extension:LDAPAuthentication2 , and it looks like the issue is solved.
Yes, LDAPAuthentication2 version 2.0.0 is compatible with PluggableAuth 7.0.0.
As others here, I'm facing the issue that LDAP authentication doesn't work with the current versions of PluggableAuth and LDAPAuthencation2, giving the following error message:
The supplied credentials could not be authenticated.
But I realized that rolling back to version REL1_35 for PluggableAuth actually works fine on MediaWiki 1.39.
Note that other extensions should not be rolled back. In particular, LDAPProvider must be updated to REL1_39, or you'll face another error while logging in.
For LDAPAuthentication2 and LDAPUserInfo, either version seems to be working fine, so it's probably best to use the newer REL1_39.
We are currently working on a MW 1.39 and PluggableAuth 6.0 compatible version of the LDAP-Stack extensions. Please stay tuned.