Auf BelWü gehostetes OSP per LDAPS gegen den Schulserver authentifizieren

#1

Hallo zusammen,

ich schaffe es nicht, dass sich unser bei BelWü gehostetes Openschulportfolio (Version oSP 13.03-fishlegs.2-quickfix1) per LDAPS am Linuxmuster-Server authentifiziert.
Zuvor, mit unserem alten paedML Win 2.7 Server hatte ich eine funktionierende LDAP authentifizierung mit Hilfe des OSP-Forums und Wikis hinbekommen.

Was habe ich gemacht:

Hier meine local.php:

<?php
/*
 * Dokuwiki's Main Configuration File - Local Settings 
 * Auto-generated by config plugin 
 * Run for user: schiebel
 * Date: Mon, 01 Mar 2010 15:00:09 +0100
 */


$conf['title'] = 'Schulportfolio LDAPS-Test';
$conf['schoolname'] = 'Schulname';
$conf['lang'] = 'de';
$conf['template'] = 'portfolio';
$conf['license'] = '';
$conf['recent'] = 35;
$conf['breadcrumbs'] = 0;
$conf['youarehere'] = 1;
$conf['dformat'] = '%d.%m.%Y %H:%M';
$conf['useacl'] = 1;
$conf['superuser'] = '@portfolioadm';
$conf['rememberme'] = 0;
$conf['disableactions'] = 'register,resendpwd,profile';
$conf['sneaky_index'] = 1;
$conf['autoplural'] = 1;
$conf['compress'] = 0;
$conf['plugin']['tag']['pagelist_flags'] = 'default';
$conf['plugin']['task']['datefield'] = 0;
$conf['plugin']['task']['tasks_formposition'] = 'top';
$conf['plugin']['archiveupload']['manageronly'] = 1;
$conf['plugin']['include']['showuser'] = 0;
$conf['plugin']['include']['showcomments'] = 0;
$conf['plugin']['include']['showlinkbacks'] = 0;
$conf['plugin']['include']['showtags'] = 0;
$conf['plugin']['include']['noheader'] = '1';
$conf['openregister'] = '0';

// Eine der LDAP Optionen durch entfernen der "//" 
// aktivieren - bevorzugt LDAPS zur 
// verschlüsselten Übertragung der Benutzerdaten verwenden

// ldap ssl
$conf['auth']['ldap']['server']   = 'ldaps://141.10.78.36:636';

// ldap ohne ssl
//$conf['auth']['ldap']['server']    = 'ldap://server.schule-bw.de:389';

// In den beiden folgenden Zeilen
// AENDERN an die eigene Schule anpasssen
$conf['auth']['ldap']['usertree']    = 'ou=accounts,dc=linuxmuster.net, dc=lokal';
$conf['auth']['ldap']['grouptree']   = 'ou=groups,dc=linuxmuster.net, dc=lokal';

$conf['auth']['ldap']['userfilter']  = '(&(uid=%{user})(objectClass=posixAccount))';
$conf['auth']['ldap']['groupfilter'] = '(&(objectClass=posixGroup)(|(gidNumber=%{gid})(memberUID=%{user})))';
$conf['auth']['ldap']['groupdelprefix'] = "p_";
$conf['defaultgroup'] = "users";
$conf['authtype']    = 'ldap';


// end auto-generated content
  • Ich habe die zwei Projektgruppen in der Schulkonsole eingerichtet und Mitglieder aufgenommen

  • Ich habe mir von BelWü für den Port TCP 636 eine Weiterleitung einrichten lassen

  • Ich habe auf dem IPFire die Regel #4 “LDAPS --> Server” aktiviert.

Wenn ich mich nun im OSP anmelden will

  • ist zum Einen das Layout der Seite völlig kaputt (ich habe keinen Plan von PHP, aber wenn ich die Teile aus der alten local.php, die augenscheinlich nichts mit der Authentifizierung zu tun haben, in obige local.php hineinkopiere sieht alles wieder gut aus. Dann erhalte ich aber keine Fehlermeldung mehr, also lasse ich die local.php von der OSP-Seite zunächst mal wie vorgegeben)

  • erhalte ich die Fehlermeldungen “LDAP: couldn’t connect to LDAP server” und “Nutzername oder Passwort sind falsch.” (siehe Screenshot).

Damit bin ich mit meinem Latein auch schon am Ende.

Wie kann ich das Problem eingrenzen oder erhalte wenigstens eine aussagekräftigere Fehlermeldung? Für Hilfe wäre ich echt dankbar.

Grüße
Michael

#2

Hallo Michael,

was mir auffällt: usertree und grouptree sind falsch. Der Beginn ist
noch richtig, ab dem “dc” wird es falsch.

Auf Deinem Server in der Schule findest Du in /etc/ldap/slapd.conf eine
Zeile mit “suffix”, zum Beispiel so:

suffix “dc=linuxmuster,dc=net,dc=lokal”

Dann wäre richtig:

$conf[‘auth’][‘ldap’][‘usertree’] =
‘ou=accounts,dc=linuxmuster,dc=net,dc=lokal’;

Und analog für grouptree.

Sonst sieht alles auf den ersten Blick richtig aus.

Viele Grüße

Jörg

#3

Hallo Jörg,

auf unserem Server steht in der Datei in dem Teil, den ich für zuständig halte:

#######################################################################
# Specific Directives for database #1, of type sql:
# Database specific directives apply to this databasse until another
# 'database' directive occurs
database        hdb

#LDAP Suffix
suffix          "dc=linuxmuster-net,dc=lokal"

#LDAP Admin
rootdn          "cn=admin,dc=linuxmuster-net,dc=lokal"
rootpw          xxxxxxxxxxxxxxxxxxx

# Where the database file are physically stored for database #1
directory       "/var/lib/ldap"

Ha! Jetzt sehe ich meinen Fehler. Gleich mal ausprobieren.

Danke.
LG

#4

Hallo,

verwenden // ldap ssl $conf[‘auth’][‘ldap’][‘server’] =
‘ldaps://141.10.78.36:636’; // ldap ohne ssl

nimm mal
ldap://141.10.78.36:636
statt
ldaps://141.10.78.36:636

LG

Holger

#5

Hallo Holger, hallo Jörg,

bei beiden Änderungen bleibt die Fehlermeldung bestehen.

$conf['auth']['ldap']['usertree']    = 'ou=accounts,dc=linuxmuster-net,dc=lokal';
$conf['auth']['ldap']['grouptree']   = 'ou=groups,dc=linuxmuster-net,dc=lokal';

Das lasse ich mal so, die zweite Änderung habe ich wieder auf “ldaps://141…” zurückgesetzt.

Irgendeine Idee, wie ich testen kann, ob unser Server überhaupt per ldaps erreichbar ist bzw. ob er auf Anfragen reagiert?

LG
Michael

#6

Hallo Michael,

Irgendeine Idee, wie ich testen kann, ob unser Server überhaupt per
ldaps erreichbar ist bzw. ob er auf Anfragen reagiert?

natürlich muß die 636 im IPFire an den Server weitergeleitet werden und
im BelWü Router muss der Port freigegeben sein.

LG

Holger

#7

Hallo Michael,

erfahrungsgemäß sind es immer wieder dieselben drei Punkte, wenn es mit LDAPS klemmt:

  • Fehler in der local.php
  • Router/Firewall spielen nicht mit
  • Selbstsignierte Zertifikate

Bei Deiner Domäne hast Du bestimmt ein selbstsigniertes Zertifikat im Einsatz. Du musst dann dem LDAP-Client bei Belwü sagen, dass er das akzeptieren soll. Entweder, indem Du das Zertifikat dort installierst, oder, indem Du die Überprüfung der Zertifikate abschaltest.

Ansonsten hilft es, in die Logs zu schauen. Das wäre /var/log/syslog auf dem Server. Oft sieht man auch erst was, wenn man das Loglevel hochsetzt - da muss bei LDAP eine ziemlich große Zahl hin, ich schaue das auch immer nach.

Viele Grüße

Jörg

#8

Hallo Michael,
dc=linuxmuster-net,dc=lokal ist natürlich nur richtig, wenn das auf deinem Server auch so ist… Schau mal nach (am linuxmuster.net Server):

~# smbldap-usershow pgmadmin | head -n1

dn: uid=pgmadmin,ou=accounts,dc=linuxmuster-net,dc=lokal

da siehst du dann, was rein muss :slight_smile:

LG Jesko

#9

Hallo,

ich habe das Problem mittlerweile gelöst. Jörg hatte Recht. Fehler in der local.php. Der für LDAPS zuständige Teil sieht mittlerweile so aus:

// ldap ssl
$conf['auth']['ldap']['server']   = 'ldaps://141.10.78.36:636';
$conf['auth']['ldap']['version'] = '3';

$conf['auth']['ldap']['usertree']    = 'ou=accounts,dc=linuxmuster-net,dc=lokal';
$conf['auth']['ldap']['grouptree']   = 'ou=groups,dc=linuxmuster-net,dc=lokal';

$conf['auth']['ldap']['userfilter']  = '(&(uid=%{user})(objectClass=posixAccount))';
$conf['auth']['ldap']['groupfilter'] = '(&(objectClass=posixGroup)(|(gidNumber=%{gid})(memberUID=%{user})))';
$conf['auth']['ldap']['groupdelprefix'] = "p_";

gefehlt hat bei mir das hier: $conf['auth']['ldap']['version'] = '3';

Vielen Dank für die Tipps.

Michael