Mediawiki & LDAP

[Ingegno]

Hier maar eens proberen:

Okay, zit nu echt met iets wat ik gewoon heb opgegeven. Heb het ook op MediaWiki gevraagd maar het is nogal dood daar. Hoop dat iemand hier mij wat verder kan helpen (aanzetten debugging zou al helpen). Wil LDAP authenticatie aanzetten op MediaWiki, wanneer ik echter probeer aan te loggen krijg ik constant de melding verkeerde gebruikersnaam/wachtwoord.

Even een copy-paste:


Installed MediaWiki on a brand new CentOS7 VM (iso 1810).
MediaWiki version 1.32.0
MariaDB10.3.14
PHP version 7.3.5

De zogenoemde LDAP extensie van de MediaWiki afgehaald, folder getiteld LdapAuth aangemaakt onder /var/www/html/extensions/


Installed php-ldap

composer install --no-dev uitgevoerd (conform de documantatie)

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.

- Zie alleen DNS-queries binnenkomen op de DC, er zitten geen ACL's oid tussen de AD-MediaWiki. Tcpdump laat ook alleen uitgaande DNS-requests zien.

- 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.
Wordt dus niks gelogd om een of andere reden, terwijl volgens de documentatie dit wel de manier is.

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

Dusja, echt uren mee bezig maar geen succes. RTFM helpt helaas niet

[JaQ]

Deze gevolgd? https://m.mediawiki.org/w...AD_Configuration_Examples

Ik zie in ieder geval 1 verschil, je mist:
$wgLDAPUseLocal=false

[Ingegno]

JaQ schreef op donderdag 9 mei 2019 @ 07:31:
Deze gevolgd? https://m.mediawiki.org/w...AD_Configuration_Examples

Ik zie in ieder geval 1 verschil, je mist:
$wgLDAPUseLocal=false

Die link inderdaad, naast een reeks aan andere HowTo's en de README bestand die wordt meegeleverd.

Ook die optie geprobeerd, maar heeft weinig effect. Is ook alleen om lokaal aanloggen toe te staan, wat wel handig is mocht je AD-omgeving niet beschikbaar zijn.

[Hero of Time]

Ga eens met ldap-utils aan de slag om te kijken of je zinvolle informatie vanaf de server kan opvragen. Dat is altijd een handige eerste stap om na te gaan of je wel op de juiste plek aan het kijken bent. Dan weet je ook of de server überhaupt kan verbinden met AD.

[Ingegno]

Gristus te paard, na heel wat klooien toch werkend gekregen. Het is knutselwerk, denk dat het toch niet met deze combinatie van CentOS/MediaWiki/Php geheel wordt ondersteunt? Anyhow, mocht iemand ooit tegen hetzelfde aanlopen, wat voor mij heeft gewerkt (en let op dat dit dus echt knutselwerk is geweest waarbij ik o.a. broncode heb aangepast):

composer require symfony/ldap (dit stond niet in de docs)
Composer update --no-dev (dit in root van wikimedia maar ook onder extensions folder)
Php maintenance/update.php (mogelijk moet je hierbij skip-external-dependencies gebruiken, op een gegeven moment werkte die script niet meer omdat ie de ldap als lastenpost ziet om wat voor reden dan ook)

Ook het volgende moeten doen:

Git clone https://github.com/Jetbrains/phpstorm-stubs.git

Want anders geeft de composer update commando aan dat dit niet lukt.

In /var/www/html/extensions/LdapAuth/src/Groups/LdapGroupSync.php:

Comment de regels om fouten te verhelpen en LDAP werkend te krijgen:
# protected function doGroupMapUsingChain ($data) {
# throw new \badMethodCallException( ' Not Yet implemented );
# }

En ook:

#if ( $isActiveDirectory ) {
# $data =$this->doGroupMapUsingChain( $data );
#}

Heel vreemd stukje code, zegt (als ik het goed heb) gewoon dat als ie AD detecteert, maar een foutmelding aan te roepen want niet geïmplementeerd....En daar zal best een goede reden voor zijn na 2 dagen klooien.

wfLoadExtension( 'LdapAuth' );

Is het enige wat ik hoefde in te laden vervolgens in de LocalSettings.php en daarna conform documenatie de regels:

$wgLdapSearchAttributes = 'sAMAccountName';
$wgLdapAuthIsActiveDirectory = true;
$wgMinimalPasswordLength = 1;

etc.etc.

Hij zoekt naar de mail-attribuut en deze staat onder AD default leeg. Gevolg is dat je foutmelding krijgt en niet inloggen. Heb geprobeerd ook deze check eruit te slopen maar dit werkte om een of andere reden niet. Vervolgens geprobeerd 'm zover te krijgen dat ie zou kijken naar de userPrincipalName attribuut (deze bevat wel gewoon <user>@<domein>.<extensie> dus in de vorm van mail) maar ook dit slikte ie niet Maar besloten het erin te laten en gewoon die attribuut te vullen voor de gewenste gebruikers. Zullen het vast vrij makkelijk kunnen scripten.

Nog andere kleine foutjes die ik nog eruit moet slopen maar het werkt wel in ieder geval.

[vso]

ik heb het ook een aantal keer gedaan (vanaf win2k tot heden) .. het is inderdaad wat puzzelwerk om het aan de praat te krijgen. en volgende is "graven in geheugen"

AD LDAP
- niet alle OU's zijn OU (maar ook container)
- hoofdletter gevoelig

- LDAP = niet AD dus daar zit probleem 1
- tijd mag niet meer dan 5 minuten verschillen met AD
- zit er SSL ertussen ? (poort X of Y .. zeg maar. )
- spaties en andere "tekens" die je moet escapen in querie(s)
- user die authenticeert (binding user)
- user die je "zoekt"


De laatste 2 punten deed ik via een ldapquery tool op cmd line, vanuit windows is het wel erg prettig dat je in recente versies de attribute editor(tabblad) voor AD objecten hebt en dus het LDAP pad kan copy& pasten

Wat ik vaak deed is eerst een OU uitlezen (waar de objecten zijn die je zoekt) en dan verder hunten.
wat erg helpt is ook in een niet actieve DC de log files bekijken (als dat kan) of filteren op de host waarvandaan je connect. (audit rules)

ps wees trouwens bewust dat je niet op 1 DC inhomed .. want dat ding "uitzetten" is killer voor de authenticatie

[Hero of Time]

Is je MediaWiki al volledig in gebruik of ben je nog vrij om te veranderen van Wiki platform? Want deze aanpassingen staan natuurlijk een update in de weg. Zelf heb ik goede ervaringen met DokuWiki. Het maakt geen gebruik van een database als backend (misschien wel mogelijk ondertussen), maar plain tekst bestanden. De LDAP/AD authenticatie is daarmee kinderlijk eenvoudig en staat netjes op de site uitgelegd.

Beetje mosterd na de maaltijd, maar je moet wel aan updates denken voor de toekomst.

[Ingegno]

vso schreef op donderdag 9 mei 2019 @ 17:27:
ik heb het ook een aantal keer gedaan (vanaf win2k tot heden) .. het is inderdaad wat puzzelwerk om het aan de praat te krijgen. en volgende is "graven in geheugen"

AD LDAP
- niet alle OU's zijn OU (maar ook container)
- hoofdletter gevoelig

- LDAP = niet AD dus daar zit probleem 1
- tijd mag niet meer dan 5 minuten verschillen met AD
- zit er SSL ertussen ? (poort X of Y .. zeg maar. )
- spaties en andere "tekens" die je moet escapen in querie(s)
- user die authenticeert (binding user)
- user die je "zoekt"


De laatste 2 punten deed ik via een ldapquery tool op cmd line, vanuit windows is het wel erg prettig dat je in recente versies de attribute editor(tabblad) voor AD objecten hebt en dus het LDAP pad kan copy& pasten

Wat ik vaak deed is eerst een OU uitlezen (waar de objecten zijn die je zoekt) en dan verder hunten.
wat erg helpt is ook in een niet actieve DC de log files bekijken (als dat kan) of filteren op de host waarvandaan je connect. (audit rules)

ps wees trouwens bewust dat je niet op 1 DC inhomed .. want dat ding "uitzetten" is killer voor de authenticatie

Zal deze punten tbv kennis sowieso noteren voor in de toekomst, zie 1 bericht boven. Is gelukkig verholpen

Hero of Time schreef op donderdag 9 mei 2019 @ 18:59:
Is je MediaWiki al volledig in gebruik of ben je nog vrij om te veranderen van Wiki platform? Want deze aanpassingen staan natuurlijk een update in de weg. Zelf heb ik goede ervaringen met DokuWiki. Het maakt geen gebruik van een database als backend (misschien wel mogelijk ondertussen), maar plain tekst bestanden. De LDAP/AD authenticatie is daarmee kinderlijk eenvoudig en staat netjes op de site uitgelegd.

Beetje mosterd na de maaltijd, maar je moet wel aan updates denken voor de toekomst.

Paar dingen m.b.t. omgeving:

- Afgeschermd, niet gekoppeld aan internet;
- Ze hadden een MediaWiki draaien op een Win2008 bak, ook een Zabbix die al wat langer meegaat. Is dus niet echt een omgeving waar vaak van zulke updates worden gedaan, wel security/WSUS/anti-virus maar als de 'applicatie' draait voor hen geen reden om het aan te passen. Tenzij een toekomstige release natuurlijk changes meebrengt die grote gaten oid dicht;

-Weet niet of plain tekst gewenst is, staat toch wel wat gevoelige informatie op (vandaar ook de wens te werken met rollen e.d. via AD);
-Krijg ook maar x-aantal uren om die overgang te realiseren, nou heeft dit wat tijd gekost en daarnaast het overpompen van de content (artikelen/images) wat ook niet even lukte vanwege de verschillen tussen Mediawiki versies en Windows/Linux. Zijn blij (ik ook ) dat het nu draait en doen het gewoon hiermee. Iig bedankt voor het meedenken.

[Hero of Time]

DokuWiki slaat pagina's op in platte tekst op de server. Je moet om die in te zien dus alsnog toegang tot de server hebben. Met MediaWiki, die in de database de pagina's opslaat, is dat net zo. Als je toegang tot de database hebt, kan je ook zo de pagina's lezen, want het is niet meer dan een regel in een tabel.

Daarbij, als ze al zo laks zijn met updaten is veiligheid van de data blijkbaar geen aandachtspunt. Hoe 'afgeschermd' het ook mag zijn.

[vso]

Ingegno schreef op donderdag 9 mei 2019 @ 20:02:
[...]


Zal deze punten tbv kennis sowieso noteren voor in de toekomst, zie 1 bericht boven. Is gelukkig verholpen

Daarom mosterd na de maaltijd opmerking

[...]


Paar dingen m.b.t. omgeving:

- Afgeschermd, niet gekoppeld aan internet;
- Ze hadden een MediaWiki draaien op een Win2008 bak, ook een Zabbix die al wat langer meegaat. Is dus niet echt een omgeving waar vaak van zulke updates worden gedaan, wel security/WSUS/anti-virus maar als de 'applicatie' draait voor hen geen reden om het aan te passen. Tenzij een toekomstige release natuurlijk changes meebrengt die grote gaten oid dicht;

-Weet niet of plain tekst gewenst is, staat toch wel wat gevoelige informatie op (vandaar ook de wens te werken met rollen e.d. via AD);
-Krijg ook maar x-aantal uren om die overgang te realiseren, nou heeft dit wat tijd gekost en daarnaast het overpompen van de content (artikelen/images) wat ook niet even lukte vanwege de verschillen tussen Mediawiki versies en Windows/Linux. Zijn blij (ik ook ) dat het nu draait en doen het gewoon hiermee. Iig bedankt voor het meedenken.

Tja erhm zoals ik het lees is dit wel een "sales" moment.. als ze denken dat het in minder tijd kan dan spendeer ik de tijd en ga daarna bij de manager aangeven dat ik meer tijd nodig om het op te lossen.. (ook een les) dit soort "custom" meuk is een leidens weg.

Als IT-er vind ik het leuk en besteed ik rustig 200 uur laat de verkoper van "doen we even" maar het recht breien ..

het probleem van linux + windows is niet dat het "onmogelijk" is der zijn 101 manieren of 1001 en ga jij maar 1 vinden die duidelijk en simpel is toe te passen .. zonder AD of het product aan te passen. (wat je gedaan hebt) er is in deze ook geen goed of fout ..

mijn les is in deze (ook aan jou) schrijf goed op wat start en einddoel is... werk met klein mogelijke tussen stapjes en controle punten ..
- het loont ook de moeite om te kijken welke mogelijkheden er zijn.

En RBAC is helemaal drama want een rol is niet een functie (en die fout word vaak gemaakt) o en je hebt het nog over explicitiete toegang op bepaalde informatie .. helemaal feest .. dan eindig je met pech met 6000 AD objecten voor ACL's

Maar goed het is je gelukt en dat is een leuke schouderklop voorjezelf