Topic on Extension talk:LDAPAuthorization/Archive 2

Windows Server 2012R2

MediaWiki	1.35.1
PHP	7.4.14 (cgi-fcgi)
MySQL	5.7.13-log

LDAPAuthentication2 1.0.2 (58e281c) 07:04, 7 January 2021

LDAPAuthorization 1.1.0 (e037664) 19:38, 9 July 2020

LDAPProvider 1.0.5 (ca854c1) 07:54, 14 December 2020

LDAPUserInfo 1.0.0 (39cca83) 19:58, 9 July 2020

PluggableAuth 5.7 (2a465ae) 15:07, 10 July 2020

---

LocalSettings.php:

wfLoadExtension( 'LDAPProvider' );

wfLoadExtension( 'PluggableAuth' );

wfLoadExtension( 'LDAPAuthentication2' );

wfLoadExtension( 'LDAPUserInfo' );

wfLoadExtension( 'LDAPAuthorization' );

$LDAPProviderDomainConfigProvider = function() {

$config = [

'server.ssv.ww.lcl' => [

'connection' => [

"server" => "server.ssv.ww.lcl",

"port" => "389",

"user" => "pre\\account",

"pass" => 'password',

"options" => [ "LDAP_OPT_DEREF" => 1 ],

"basedn" => "CN=containerNameHere,DC=ssv,DC=ww,DC=lcl",

"groupbasedn" => "CN=Groups,CN=containerNameHere,DC=ssv,DC=ww,DC=lcl",

"userbasedn" => "CN=Users,CN=containerNameHere,DC=ssv,DC=ww,DC=lcl",

"searchattribute" => "sAMAccountName",

"searchstring" => "pre\\USER-NAME",

"usernameattribute" => "sAMAccountName",

"realnameattribute" => "cn",

"emailattribute" => "mail",

"nestedgroups" => true,

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

# ],

# "groupsync" => [ # ],

# "userinfo" => [ ]

]

];

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

};

$LDAPAuthentication2UsernameNormalizer = 'strtolower';

---

LDAPProvider\maintenance\CheckLogin.php says "OK" to my account but running ShowUserGroups with same -u and -d input gives "C:\MediaWiki\extensions\LDAPProvider\src\Client.php: Error in LDAP search: No such object" and ShowUserGroups says "PHP Warning:  ldap_count_entries() expects parameter 2 to be resource, bool given in C:\MediaWiki\extensions\LDAPProvider\src\PlatformFunctionWrapper.php on line 295" along with the same error in Client.php as above. The line of code in Client that throws the error is this one:

if ( !$res ) { throw new MWException( "Error in LDAP search: " . $this->connection->error() ); } which is in this function: public function search( $match, $basedn = null, $attrs = [ "*" ] )

Any ideas on how I should proceed to troubleshoot this?

If a "bool" is returned this indicates that no connection to the LDAP server could be established. Try a standalone script like https://www.php.net/manual/en/function.ldap-bind.php#refsect1-function.ldap-bind-examples to verify your connection settings.

I ran that example script and it works properly. The LocalSettings.php file has the correct username/password because the CheckLogin.php script returns "OK". The problem is that the ShowUserGroups.php script is returning a lot of errors, using the same config file. It still returns that "bool" error but the other scripts I run in the maintenance directory seem to work fine. I'm stuck and don't know how to move forward with troubleshooting this problem.

Have you tried using "samaccountname" instead of "sAMAccountName"? Also you "searchtring" looks odd. It should be a DN.

Got it to work finally!!!

In the settings:

groupbasedn and userbasedn strings can only contain DN items, no CN or OU items

searchattribute and usernameattribute strings both had to be samaccountname

grouprequest string needed a leading \\ and set to ...GroupMember::factory

searchstring needed leading domain prefix followed by \\USER-NAME

enctype had to be "clear"

I may have made minor code changes in several of the modules, been working on this for months off and on so not sure. Troubleshooting sucks when it is trial and error testing. In Client.php/getUserGroups() function I added our baseDN string instead of the default empty ' ' parameter. In UserInfoRequest.php/GetUserInfo() I had to comment out the "memberof" and leave attribute as just the wildcard. In GroupMember.php instead of an empty $baseDN I set it to $this->config->get( ClientConfig::GROUP_BASE_DN ). I think that about covers it.

Thanks for sharing! Maybe you could provide me with your code? I could check if I can add it to the extension.

Basically it was those changes above, not worth a full copy-n-paste since you can see they were very minor changes. This was a very steep learning curve trying to get Active Directory under IIS working. I still do not have the automatic login working with LDAPAuthentication2 yet but at least I can manually log in and nothing throws any errors in the logs.

Okay, thanks. For SSO you will need Extension:Auth_remoteuser. In IIS it should be straight forward to enable SSO. You should only need to switch from "Anonymous" to "NLTM/Kerberos" type in the "Authentication" section of your IIS-Website.

Thank you. I installed that but it still won't auto-login when I hit the wiki page. In another place I read that I need to disable the LDAPAuthentication2 extension, so I also tried to disable that, but same thing. Do you still need to click the Login link to log in automatically? When I do that i get a message: "The supplied credentials are not associated with any user on this wiki." but I have the createaccount setting set to true, as well as the autocreateaccount. Am I missing something else?

If you don't need form based authentication, you can disable Extension:LDAPAuthentication2 completely. If Extension:Auth_remoteuser does not log you in automatically there can be three reasons:

• $_SERVER['REMOTE_USER'] is not properly set by the websever. Validate this by using a `phpinfo();` in a new file in the document root.
• $_SERVER['REMOTE_USER'] contains characters that are not allowed as MediaWiki usernames.
• Extension:LDAPAuthorization prevents the implicit login due to authorization issues. You may want to enable LDAP debugging to get more information.

Now I'm finally getting the wiki to use AD to authenticate existing users, but new users are not getting accounts created automatically. I have both of these set to true: $wgGroupPermissions['*']['autocreateaccount'] = true; and $wgGroupPermissions['*']['createaccount'] = true; but the new accounts never show up in the mySQL users table. Plus, people who are not in the database are getting website Error 500 and none of the log files are being written to, nor in the system Event log for IIS. Once more, I'm stuck again.

"Error 500" means there is an issue in the Wiki application. Are there also no outputs in the PHP error log?

The only PHP 7.4 error logged when someone goes to the MW webpage and their account is not in the MySQL user table is this:

[14-Jun-2021 21:40:26 UTC] PHP Deprecated:  Directive 'track_errors' is deprecated in Unknown on line 0

So it edited php.ini and set "track_errors" to "off" and we will see if that error goes away.

Also, here are all of the debug settings I have enabled in LocalSettings.php file:

$wgShowExceptionDetails = true;

$wgDebugLogFile = '\\temp\\wikidbg.log'; 

$wgDebugLogGroups['PluggableAuth'] = '\\temp\\PLUG.log';

$wgDebugLogGroups['LDAP'] = '\\temp\\LDAP.log';

$wgDebugLogGroups['MediaWiki\\Extension\\LDAPProvider\\Client'] = '\\temp\\LDprov.log';

$wgDebugLogGroups['LDAPGroups'] = '\\temp\\LDgrp.log';

$wgDebugLogGroups['LDAPUserInfo'] = '\\temp\\LDui.log';

$wgDebugLogGroups['LDAPAuthorization'] = '\\temp\\LDAPauthor.log';

Not a single entry anywhere, not even in Windows event log, when a non-existing user goes to the MW webpage. yet it works for everyone who is in the user table just fine. I also have both account create variables set to true...any ideas?

Here is the webpage they see when they hit the page (note that active directory is enabled and they are on the network so it should log them in automagically like it does to those users who are already in the sql user table): https://ibb.co/dj9rHnZ

Please make sure the "\\temp" directory as well as the "php_error.log" file are writeable for the webserver user (probably "IUSR" or something). Windows can be tricky when it comes to FS permissions.

They are writeable since I generated other errors in another app that uses the same php version and it wrote those errors. Plus the other log files work if I generate thrown errors. So whatever the problem is, it is not causing a loggable error.

It's acting like it is unable to create new account, no matter what I have $wgGroupPermissions[] set to. Need more thoughts on how to troubleshoot this please, none of the log files are logging any errors for when users hit the page and get the Error 500, not even the IIS event log...?! And yes, my perms are set properly for all of the log files on the server since previous problems on this long trail of tears has shown other errors being logged from the other extensions.

Can you maybe share a screenshot of that error 500 (you can use some "pastebin" like tools on the web). If possible also a screenshot that shows the "Network" panel of the browsers developer tools. You may need to redact sensitive information (like server or user names, base urls, ...)

The error 500 screen is shown in the link above. Still trying to get someone who cannot log in to get me a screenshot of the browser dev tools network tab...

The screenshot does not show an error 500. It is a regular error message in the form based authentication process, shown when there is not local user account in the database. It is not emitted by the LDAP-Stack extensions, but rather by MediaWiki core software. Can you confirm you have the "autocreateaccount" permission assigned to the group of unauthenticated users ("*")?

Here is that part of LocalSettings.php in /mediawiki directory: .

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

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

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

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

$wgGroupPermissions['write']['edit'] = true;

$wgGroupPermissions['developers']['edit'] = true;

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

$wgGroupPermissions['write']['createpage'] = true;

$wgGroupPermissions['developers']['createpage'] = true;

$wgGroupPermissions['bureaucrat']['userrights'] = true;

.

So the problem appears to be code in auth_remoteuser extension file UserNameSessionInfo.php and I had to comment out this code:

1. if ( !Hooks::run( static::HOOKNAME, [ &$filteredUserName ] ) ) {
2. $metadata[ 'filteredUserName' ] = $filteredUserName;
3. $this->logger->warning(
4. "Can't login remote user '{remoteUserName}' automatically. " .
5. "Blocked this user when applying filter to '{filteredUserName}'.",
6. $metadata
7. );
8. continue;
9. }

Not sure what it even tries to do, but it would never work properly and nobody could get authenticated via active directory and automatically logged in. When I commented this section out, everything works as expected! I manually stripped the domain from the front of the username info and allowed it to get properly stuffed into the filtered name array. Would be great if somebody would tell me what this HOOKNAME stuff is trying to do...

This hook is used by Extension:LDAPAuthorization extension to prevent auto login of users that do not match certain criterias (e.g. LDAP group membership). If you don't need that feature I recommend to disable LDAPAuthorization in general.