Hashen oder Absichern des Bind-PWs für den AD-Connector

[hoez]

Hallo Liebe UCS Community,

@Grandjean habe gelesen das man hier Sie Taggen darf.

Frage & Feedback für Folgende Situation:

Für die Nutzung eines Moodle Servers soll ein „Common Directory“ eingerichtet werden. Wo aus verschiedenen Gesellschaften und Schulen die User die dort Schulungen erhalten sollen sich über Moodle gegen UCS OpenLDAP sowie respektive gegen das eigene AD Authentifizieren können/sollen.

Mit dem AD-Connector kann man bequem die erste AD einer Gesellschaft unidirektional vom Windows AD Richtung UCS OpenLDAP problemlos synchen.

Doch die Anbindung eines zweiten ADs zum OpenLDAP ist nicht ohne weiteres möglich, es sei denn man richtet ein zweites Connector ein. Dazu gibt es auch Anleitungen. Allerdings erfolgt die Anbinung des ADs mühsam über die Konsole.

Erste Frage/Feedback für ein Improvement oder ein Change Request für UCS5:

Kann man die Graphische (GUI basierte) AD-Connector Sync Einrichtung so umprogrammieren das man mehrere ADs Synchronisieren kann und dieser legt automatisch Connector0 Connector1 Connector2 Connector3 etc.?

Mit den jeweiligen Root-CA Zertifikat
Mit den jeweiligen AD-Sync User (binduser)
Mit den jeweiligen AD-Sync Password (bindpw)
Und allen weiteren Settings.

Zweiter Punkt.

AD Connector benötigt einen Sync User aus den jeweiligen ADs der mitglied der Domain Admins ist. Dies ist Voraussetzung dafür das PW Hashes gelesen und Synchronisiert werden können daher ist es verständlich.

Aber das Bind PW (bindpw) wird unter AD-Connector im Klartext in eine Datei gespeichert.

d.H. der jenige der Root Zugriff erlangt/hat hätte dadurch einen Admin Zugang zu allen ADs die an das UCS OpenLDAP angebundenen Gesellschaften und Schulen.

FRAGE

Ist es möglich das bindpw eines externen ADs zu hashen und nicht im klartext zu speichern oder zu verschlüsseln?

Perfekt wäre das AD Connector bei der ersten Einrichtung über die GUI den User und PW des ADs abfragt und diese nicht im Klartext sondern Sicher für den jeweiligen Connector abspeichert.

Dritter Punkt

Das Synchen der Quell Domains über LDAPS Port 636 funktioniert nicht. MS will bald auf LDAPS umstellen, wäre es möglich die AD-Connector so einzurichten das dieser über LDAPS Synchronisiert?

Standardmäßig ist LDAP Port 389 für den Connector eingerichtet sobald man auf LDAPS umstellt funktioniert die Sychronisation nicht.

Gerne kann ich all diese Punkte in meinem Test Lab einmal vorführen.

In meinem Fall kann ich keine Erfolgsstory erzählen, weil ich derzeit kein solches OpenLDAP Common Directory realisieren kann, da die IT-Abteilungen der jeweiligen Gesellschaften und Schulen damit ein massives Problem haben und große Bedenken bzgl. Security.

Über mögliche Lösungsansätze oder Workarrounds würde ich mich sehr freuen.

Viele Grüße,
HOEZ

[Steuwer]

Hallo,

danke für das ausführliche Feedback!

Ein paar Anmerkungen / Antworten:

1. GUI für Multi-Connector Konfiguration

Die Implementierung einer solchen GUI ist natürlich technisch möglich, bisher haben wir aber noch keine Pläne dafür.

2. Speicherung der Zugangsdaten zum AD

Der Connector benötigt Zugangsdaten, mit denen er sich gegenüber dem LDAP und “RPC” an einem AD DC authentifizieren kann. Hier wird in irgend einer Form ein “Klartext Credential” vom Connector benötigt. Ein Hash ist für eine Speicherung des Passworts unter UCS daher nicht möglich, da Hashes nicht wieder in ein Klartext-Passwort zurück überführt werden können.
Denkbar ist eine Speicherung in einem verschleiernden Format oder in einem Vault, letztendlich wird aber keine dieser Implementierungen etwas daran ändern das eine Person mit administrativem Zugriff auf das UCS auch Zugriff auf die Zugangsdaten des ADs haben wird. Daher empfehlen wir, den AD Connector nur auf UCS Instanzen zu betreiben, die von den gleichen Personen betreut werden wir das AD. Ergänzend kann abhängig vom Einsatzszenario der verwendete Account im AD mit weniger Rechten versehen werden – leider ist für das Lesen der Passwort-Hashes aus dem AD eine Beschränkung der Rechte im AD nur bedingt möglich. Wenn ich hier etwas übersehe / es andere Wege gibt bin ich für Hinweise dankbar.

Denkbar ist ein Betrieb eines UCS mit Connector je AD im Kontext des AD mit anschließendem “push” der relevanten Nutzerdaten in ein zentrales UCS über den UCS@school ID Connector - ich empfehle für den Einsatz aber das Hinzuziehen des Univention Professional Service.

3. LDAPS

Grundsätzlich nutzt der AD Connector eine verschlüsselte Verbindung zum AD über Port 389. Eine Umstellung auf LDAPS sollte möglich sein, wobei ich das nicht verifiziert habe. Wie war hier das Vorgehen / das Fehlerbild?
Um hier nicht den Überblick zu verlieren schlage ich vor, daraus einen eigenen Thread zu machen.

Allgemein würde ich empfehlen, bei Projekten dieser Komplexität Kontakt mit unserem Professional Service aufzunehmen. Beispielsweise muss geklärt werden, wie aus den per AD Connector übernommenen Accounts Konten mit den von UCS@school erwarteten Eigenschaften werden.

Viele Grüße
Ingo Steuwer

[hoez]

Hallo @Steuwer

Vielen Dank für die ausführliche Antwort.

Gerne kann ich aus dem LDAPS Thematik einen neuen Thread machen.

In dem o.g. Fall wissen wir das der AD-Connector User Domain Admin Rechte benötigt. Damit hätten die Gesellschaften auch keinen Problem.

Das Multi-AD-Connect, dieser ist jetzt schon möglich, eröffnet neue sowie zentralisierte Authentifizierungsmöglichkeiten via UCS. Daran würde ich evtl arbeiten, den bestehenden GUI so umzuprogrammieren dass dieser mehrere Instanzen anlegt müsste einfach sein, da das meiste an Codes dafür bereits vorhanden ist.

Das Größte Problem derzeit bei dem Vorhaben ist das die bindpw in Klartext gespeichert wird. Jeder Admin blockiert hier dann die Umsetzung Aufgrund Sicherheitstechnische Untragbarkeit.

Verschleierndes Verfahren Password Vault

Das würde Stand jetzt reichen um ein solches Projekt zu realisieren. Es geht denen nur darum das die selbst den Bind-User und das Passwort auf dem UCS hinterlegen dürfen ohne dass der Root User das Passwort einlesen darf bzw. kann.

FRAGE: Gebe es hier einen Workarround eine Lösung was man schnell umsetzen könnte?

Damit könnte ich schon mal einen Common Directory aufbauen. Die Organisatorischen & Management Entscheidungen sowie die politischen Fragen wären sofort geklärt.

Wenn unsere Tests erfolgreich wären würden die Gesellschaften auch den entsprechenden Lizenz & Support bei Univention in Anspruch nehmen.

OpenID oder SAML wollen die Gesellschaften auch testen. Aber in Zeiten von Corona spielen auch leider ältere Auth möglichkeiten wie LDAP noch eine Rolle.

Eine Lösung zum Thema ad-connector bindpw in ClearText würde enorm weiterhelfen.

Würde mich freuen wenn jemand vom UCS-Community dazu was beisteuern könnte.

Viele Grüße,
HOEZ

[Steuwer]

Hallo,

das Speichern / Lesen das Passworts aus einem Vault ist kein großer Implementierungsaufwand, gerade im Vergleich zu einem grafischen Assistenten für die Multi-Connector-Inbetriebnahme. Sie können gerne Patches über github einreichen.

Ich möchte aber nochmal darauf hinweisen, das ein solcher Vault nicht automatisch verhindert, das “root” das Passwort lesen kann. Da der AD Connector in der Lage sein muss, die Credentials zu lesen, wird auch jeder “root” die Zugriffsrechte haben dies zu tun.

Viele Grüße
Ingo Steuwer

[hoez]

Hallo @Steuwer

Vielen Dank dass Sie auf meine Fragen eingegangen sind.

Dann wäre dies über einen externen Password Vault zu tun auch keine große Hilfe.

Schade. Ich gebe das dann an die Entscheider so weiter.

Vielen lieben Dank & viele Grüße.
HOEZ