LDAPS freigeben

Per LDAPS können externe Systeme, beispielsweise eine cloud gehostete Moodle-Instanz, an die logodidact interne Benutzerverwaltung über eine SSL/TLS gesicherte Verbindung gekoppelt werden, um Benutzer, Gruppen und Passwörter abzugleichen. Somit entfällt die manuelle Pflege eigener Benutzerdaten auf der externen Instanz.

Die Freischaltung von LDAPS von extern durch den rproxy-ext unterscheidet sich im wesentlichen kaum von anderen LD-Diensten.

Falls die Komponenten zur Freischaltung von LD-Diensten noch nicht eingerichtet worden sind, befolgen Sie bitte zunächst die Anweisungen aus diesem Artikel: LD-Dienste freigeben

LDAPS extern im rproxy-ext freischalten

Das Protokoll mit dem vordefinierten Schlüsselwort ldaps im LXC-Container rproxy-ext freischalten. Dazu im selbigen Verzeichnis eine neue Datei anlegen oder aber falls bereits vorhanden, dieselbe nutzen & ergänzen.

Info

Weiterführende Informationen finden sich in der manpage unter man features.ldap.

root@ldhost:~ # ssh puppeteer-g3
root@puppeteer-g3:~ # vi /etc/logodidact/hiera/custom.d/rproxy-ext.yaml

ld_rproxy2::access: [..., ldaps]

SSL-Zertifikat beantragen

Für eine gesicherte Verbindung wird natürlich auch ein Zertifikat benötigt. In der Umgebung zur Verwaltung von Let's Encrypt Zertifikaten im puppeteer-g3 ein entsprechendes Zertifikat für ldaps beantragen.

root@ldhost:~ # ssh puppeteer-g3
root@puppeteer-g3:~ # sle
le-acme@puppeteer-g3:~ $ issue ldaps.shortName.logoip.de

Info

Falls die Beantragung des Zertifikates fehlschlägt, müssen unter Umständen noch die Webports 80/HTTP und 443/HTTPS in der Shorewall des ldhost geöffnet werden.

Warnung

Falls eigene Zertifikate verwendet werden, also kein Let's Encrypt, befolgen Sie die Anweisungen aus diesem Artikel: Eigene Zertifikate verwenden

TLS erzwingen

Nun sollte die Verbindung noch über das TLS Protokoll abgesichert werden. Standardmäßig ist die TLS-Verbindungssicherheit für LDAPS noch nicht gegeben, wenn die Verbindung über den HAProxy getunnelt wird. Um TLS zu aktivieren, benötigt man eine weitere YAML-Konfigurationsdatei, welche die entsprechenden Parameter setzt, sowie eine weitere Konfigurationsdatei, welche explizit die unverschlüsselte Datenübertragung verwehrt.

Im puppeteer-g3 hierzu folgende Ordner und Dateien anlegen:

mkdir /etc/logodidact/feature.d/ldap
echo "active: yes" > /etc/logodidact/feature.d/ldap/tls.yaml
echo "active: no" > /etc/logodidact/feature.d/ldap/plain.yaml

Schlussendlich die getätigten Änderungen ins GIT übertragen und nun im ldhost und rproxy-ext nacheinander einen prun* starten.

root@puppeteer-g3:~/etc/logodidact/ # git add .
root@puppeteer-g3:~/etc/logodidact/ # git commit -am "(Kuerzel): LDAPS freigeschaltet"

root@ldhost:~ # prun; ssh rproxy-ext
root@rproxy-ext:~ # prun

LDAPS in der Shorewall freigeben

Schlussendlich benötigt man noch die Freigabe des Ports 636 (LDAPS) auf dem ldhost, da dieser die externen Anfragen entgegennimmt und mittels HAProxy-Software an den rproxy-ext weiterreicht.

root@ldhost:~ # vi /etc/shorewall/rules

Die folgende Firewall-Regel in der Liste hinzufügen:

LDAPS(ACCEPT)   ext   $FW

Nun das Regelwerk der Shorewall prüfen und neu starten:

root@ldhost:~ # shorewall check
root@ldhost:~ # shorewall restart

Warnung

Der TCP-Port 636 muss zwingend auch am vorgeschalteten Router/Gateway geöffnet sein und auf den LogoDIDACT Server weitergeleitet werden.

Testen der Verbindung

Vorausgesetzt, dass keine weitere Firewall den Zugriff verhindert und der Router mit den Portweiterleitungen richtig konfiguriert ist, kann der sichere Zugriff auf LDAP von außen getestet werden.

Dafür wird das Tool LdapAdmin verwendet. Die Konfiguration ist denkbar einfach und erfordert lediglich die Angabe des Hosts, in unserem Beispiel ldaps.sbe-bfh-cloud07.logoip.de und das Häkchen bei SSL, sodass automatisch der Port auf 636 gesetzt wird.

Über die Schaltfläche Fetch DNS werden dann bereits die Werte für Base automatisch ausgefüllt und im Standardfall auf dc=schule,dc=local gesetzt. Über die Schaltfläche Test Connection kann zunächst die Verbindung auf technischer Ebene explizit getestet werden.

Für den Zugriff auf Daten im LDAP-Verzeichnis sind im nächsten Schritt Benutzerdaten einzutragen. Dazu besteht der Benutzer ldap-ro. Dieser hat explizit nur lesenden Zugriff. Das Passwort für diesen speziellen User ist im Container logosrv zu finden.

LDAP-User: cn=ldap-ro,ou=services,dc=schule,dc=local Passwort: /etc/ldap.ro.secret

Danach lässt sich dann die LDAP-Verzeichnisstruktur und ein minimaler Satz an den wichtigsten Attributen lesend abfragen.

Optional - Zugriff von extern beschränken

Der Zugriff auf die LDAP-Verzeichnisstruktur ermöglicht selbst in der nur lesenden Variante die Abfrage vieler personenbezogener Daten, wie Vor- und Nachname aller Benutzer und die Zugehörigkeit zur jeweiligen Klasse oder auch der Gruppe Lehrer. Um den Zugriff auf diese Daten einzuschränken, sollte in jedem Fall die Firewall diesen Zugriff auf Quell-IP-Ebene zusätzlich absichern. Wenngleich auch dieser Schutz mit genügend Wissen und krimineller Energie umgangen werden kann, ist diese Absicherung sinnvoll und dringend anzuraten.

Öffnen Sie dazu nochmal die Shorewall-Datei rules mit einem Editor Ihrer Wahl und ergänzen Sie den Parameter ext um die IP-Adresse des Servers oder Dienstes, der von außen auf LDAP zugreifen möchte.

Im Beispiel unten, ist die IP-Adresse eines Webuntis-Servers angegeben, der ausschießlich auf das LDAP des LogoDIDACT zugreifen darf:

# Shorewall version 4.0
#
# For information about entries in this file, type "man shorewall-rules"
####################################################################################################################
#ACTION         SOURCE          DEST            PROTO   DEST    SOURCE          ORIGINAL        RATE            
#                                                       PORT    PORT(S)         DEST            LIMIT           GROUP
#SECTION ALL
#SECTION ESTABLISHED
#SECTION RELATED
#SECTION INVALID
#SECTION UNTRACKED
?SECTION NEW
HTTP(ACCEPT) ext $FW
HTTPS(ACCEPT) ext $FW
LDAPS(ACCEPT) ext:92.66.88.190  $FW

Spezielle LDAP-Benutzer und Attribute

Wie in den vorherigen Abschnitten erwähnt, ist der anonyme Zugriff auf LDAP gesperrt. Für den lesenden Zugriff gibt es den Benutzer ldap-ro, der auf einen eingeschränkten Satz an Attributen zugreifen kann.

LDAP-Benutzer	Zugriff auf folgende Objekte und Atribute
ldap-ro	lesender Zugriff: entry, cn, displayName, gidnumber, givenName, mail, member, memberOf, memberUid,objectClass, ou, sn, title, uid, uidnumber, uniqueMember, ldObjectType, ldRole
ldap-admin	schreibender Zugriff auf nahezu alle Attribute (minimale Einschränkungen). Primär für interne Zwecke im logosrv notwendig

Die Zugriffsrechte bzw. ACLs finden sich im Container logosrv in der Datei /etc/ldap/slapd.puppet.conf, die durch Puppet automatisch aufgebaut wird. Nicht notwendige Objektklassen (objectclasses) werden versteckt und im Detail festgelegt, welcher der obigen LDAP-Benutzer auf welche Informationen zugreifen kann.

Sind für die Anbindung eines externen Systems weitere LDAP-Attribute notwendig, können diese im Container puppeteer-g3 in der Datei ldhost.yaml freigegeben werden.

Das diese Parameter in die ldhost.yaml eingetragen werden, obwohl sie für den Container logosrv bestimmt sind, hängt damit zusammen, dass im logosrv kein puppet-Agent läuft und der Container vom ldhost aus verwaltet wird.

Muss aus einem speziellen Grund z.B. das Geburtsdatum ldBirthday und das Geschlecht ldGender im externen System verfügbar sein, sieht die ldhost.yaml exemplarisch so aus:

ld_legacy::ldap::ldap_ro_atts:
- ldBirtday
- ldGender