Hallo.
Wir haben in Zukunft eine User-Auth., die über LDAP funktionieren wird. Der LDAP-Server ist allerdings von außen nicht erreichbar, sondern befindet sich aus guten Gründen hinter einer Firewall. Meine Frage ist, ob ich dennoch die LDAP-DB irgendwie auch für Moodle benutzen kann, indem ich sie z.B. auf unseren Homepage-Server kopiere, auf dem auch moodle läuft? Kann man da was drehen? Wer weiß, wie man da vorgehen müsste?
Danke,
W.R.
Als Antwort auf M. Hagedorn
Re: vorhandene LDAP-DB zur User-Auth. benutzen?
von Visvanath Ratnaweera -
Wie wäre es die Firewall nur für LDAP-Anfragen vom Moodle-Server zu öffnen?
Als Antwort auf Visvanath Ratnaweera
Re: vorhandene LDAP-DB zur User-Auth. benutzen?
von M. Hagedorn -
Nein, besser nicht -- das Intranet soll abgeschottet bleiben. Ich könnte per Cronjob die LDAP-db nachts auf den anderen Server kopieren. Das wäre kein Problem. Die Frage ist nur, was unter Moodle mit den bereits vorhandenen Logins geschieht, wenn ich auf LDAP-DB umstelle? Kann ich die irgendwie mitnehmen oder sind sie verloren?
Da ich kein LDAP-Experte bin, frage ich mich zudem, welche Dateien Moodle sehen will...
Da ich kein LDAP-Experte bin, frage ich mich zudem, welche Dateien Moodle sehen will...
Als Antwort auf M. Hagedorn
Re: vorhandene LDAP-DB zur User-Auth. benutzen?
von Visvanath Ratnaweera -
> Die Frage ist nur, was unter Moodle mit den bereits vorhandenen Logins geschieht, wenn ich auf LDAP-DB umstelle? Kann ich die irgendwie mitnehmen oder sind sie verloren?
Die "lokalen" Konti in Moodle bleiben erhalten auch nach einer Umstellung zu LDAP, oder anders gesagt, ein Teil der Benutzer authentisieren "lokal" andere via LDAP.
Die "lokalen" Konti in Moodle bleiben erhalten auch nach einer Umstellung zu LDAP, oder anders gesagt, ein Teil der Benutzer authentisieren "lokal" andere via LDAP.
Als Antwort auf Visvanath Ratnaweera
Re: vorhandene LDAP-DB zur User-Auth. benutzen?
von Sylvio Runge -
>Die "lokalen" Konti in Moodle bleiben erhalten auch nach einer Umstellung zu LDAP, oder anders gesagt, ein Teil der Benutzer authentisieren "lokal" andere via LDAP.
Man muß dazu sagen die "alten" Accounts bleiben, die neuen kommen via LDAP hinzu. D.h. es kommt vermutlich zu doppelten nutzern (DUPes) , wenn ein Nutzer mehrfach , d.h. lokal und im LDAP vorhanden ist. Man sollte dann auch drauf achten, welchen Nutzer man dann ins Seminar einträgt (den lokalen der nicht von ldap abhaenig ist oder den anderen ). Das "könnte" Probleme verursachen; muß man von Fall zu Fall sehen....
S.
Man muß dazu sagen die "alten" Accounts bleiben, die neuen kommen via LDAP hinzu. D.h. es kommt vermutlich zu doppelten nutzern (DUPes) , wenn ein Nutzer mehrfach , d.h. lokal und im LDAP vorhanden ist. Man sollte dann auch drauf achten, welchen Nutzer man dann ins Seminar einträgt (den lokalen der nicht von ldap abhaenig ist oder den anderen ). Das "könnte" Probleme verursachen; muß man von Fall zu Fall sehen....
S.
- Die LDAP-Replikation (genau das willst du) ist keinesfalls trivial - gerade in deinem Fall kopiert man da mal nicht "eben" eine LDAP-DB. Das kann bei dir fast nur über LDIF (bist du fit in regulären Ausdrücken?) oder echte Replikation laufen, wobei die Verbindung dann von eurem Netzwerk initiiert wird.
- Das Netz kann mit einem Trick kann (fast) geschlossen bleiben - ich mache das genau so: Port 22 (SSH) ist bei uns offen. Authentifizierung erfolgt nur über unpriviligierte Accounts und über Keys (das ist immer noch einfacher als die Replikation). Den LDAP Port tunnele ich einfach verschlüsselt per SSH lokal auf meinen Server. Wenn der fällt, bekomme ich das mit. Das LDAP allein über LDAP kompromittiert wird, halte ich für relativ ausgeschlossen.
- Du stellst nicht auf LDAP um. Du ergänzt deine bestehende Moodle-DB um die LDAP-Accounts - die Warnung von Sylvio ist schon berechtigt.
- Wenn ihr keine Hardwarefirewall (ab 3000 Euro) habt, habt ihr keine Firewall. Softwarefirewalls sind in der Regel völlig sinnbefreit. Dienste die man nicht braucht, schaltet man ab (ist bei MS-Produkten manchmal aufwendig). Dienste, die man braucht, hält man auf aktuellem Patchlevel und würde man eh durch eine Firewall durchlassen. Ich greife doch keine Firewall an. Ich locke den Nutzer auf eine präparierte Seite und nutze Schwachstellen im Browser oder E-Mailclient aus. Dann bin ich im Intranet und greife von da aus an (wenn ich böse wäre...). Hat die Softwarefirewall z.B. Filtermechanismen dagegen, kann ich die Firewall selbst durch Buffer-Overflows (o.ä.) kompromittieren - ein superlohnendes Ziel - viel wertvoller als ein einzelner Dienst. Dann wird pikanterweise die Firewall (die mit oberpriviligierten Rechten läuft) zum Sicherheitsrisiko. Das ist keine Spinnerei, sondern gängige Hackerpraxis.
Gruß,
Maik
Hallo.
Hmm -- dann ist es also doch nicht so leicht. Da bei uns nicht so schrecklich viele Moodle-Logins von Jahr zu Jahr hinzukommen, könnte ich mir auch folgendes vorstellen: Kann man die bestehenden LDAP-Logins irgendwie exportieren und dann als Text-Datei unter Moodle wieder einlesen? Wenn das gängiger wäre....
Der beschriebene Weg über Keys und ssh-Tunnel scheint mir kompliziert zu sein? Was doppelte User angeht: Soooo viele sind es wie gesagt nicht. Die könnte man schon noch per Hand rausfischen...
Hmm -- dann ist es also doch nicht so leicht. Da bei uns nicht so schrecklich viele Moodle-Logins von Jahr zu Jahr hinzukommen, könnte ich mir auch folgendes vorstellen: Kann man die bestehenden LDAP-Logins irgendwie exportieren und dann als Text-Datei unter Moodle wieder einlesen? Wenn das gängiger wäre....
Der beschriebene Weg über Keys und ssh-Tunnel scheint mir kompliziert zu sein? Was doppelte User angeht: Soooo viele sind es wie gesagt nicht. Die könnte man schon noch per Hand rausfischen...
Was die Firewall angeht: Es ist ein IP-Cop (also keine Hardwarelösung). Mir sind die Argumente für und gegen Firewalls bekannt -- aber trotzdem setzen wir sie ein, denn ein Dienst wie ssh auf einem der Server soll halt von innen benutzt werden können aber von außen nicht zu sehen sein.... außerdem kann der Cop OpenVPN, URL-Filter und und und ... für eine Schule geradezu perfekt...
Aber gerade bei IPCop ist das Ganze super zu lösen. Du kannst doch den SSH in die DMZ (orange interface) umleiten und dort den lokalen LDAP-Port bereitstellen. Besser geht es doch nimmer und das Netz ist immer noch dicht.
Dafür braucht es eine alte Krücke in der DMZ, 486er reicht...
Welche LDAP-Lösung setzt ihr denn ein? Musterlösung? Arktur? Active Directory? Du solltest vor allen nicht den Effekt unterschätzen , dass die User nur ein Passwort verwalten müssen - LDAP ist dafür schon toll.
Der Tunnel ist eine Befehlszeile. Der Key im Unbedarftenstadium etwa zwei Stunden. Angeben tue ich damit schon zwei Jahre. Preis/Leistung stimmt.
Aus LDAP bekommst du nur LDIF als Exportformat. Das musst du mit VB/Perl/Scriptsprache nach Wahl noch nach csv oder MySQL umbiegen. Ist nicht wirklich einfacher.
Gruß,
Maik
Dafür braucht es eine alte Krücke in der DMZ, 486er reicht...
Welche LDAP-Lösung setzt ihr denn ein? Musterlösung? Arktur? Active Directory? Du solltest vor allen nicht den Effekt unterschätzen , dass die User nur ein Passwort verwalten müssen - LDAP ist dafür schon toll.
Der Tunnel ist eine Befehlszeile. Der Key im Unbedarftenstadium etwa zwei Stunden. Angeben tue ich damit schon zwei Jahre. Preis/Leistung stimmt.
Aus LDAP bekommst du nur LDIF als Exportformat. Das musst du mit VB/Perl/Scriptsprache nach Wahl noch nach csv oder MySQL umbiegen. Ist nicht wirklich einfacher.
Gruß,
Maik
Hallo nochmal,
das klingt nicht schlecht. Wir haben den IP-Cop mit Rot, Blau, Grün laufen (Blau ist hier aber nicht WLAN).
Der (LDAP)-Server nennt sich Slixs (www.slixs.at) und es läuft im wesentlichen ein angepasstes Debian.
Wie gehe ich denn nun weiter vor, wenn SSH nach Orange umgeleitet werden soll? Ist das eine IPCop-Einstellung?
Dass es auf diese Weise nur ein einziges Passwort für die User ist, wäre schon ganz brauchbar
das klingt nicht schlecht. Wir haben den IP-Cop mit Rot, Blau, Grün laufen (Blau ist hier aber nicht WLAN).
Der (LDAP)-Server nennt sich Slixs (www.slixs.at) und es läuft im wesentlichen ein angepasstes Debian.
Wie gehe ich denn nun weiter vor, wenn SSH nach Orange umgeleitet werden soll? Ist das eine IPCop-Einstellung?
Dass es auf diese Weise nur ein einziges Passwort für die User ist, wäre schon ganz brauchbar
ach ja : noch ein anderes Problem: ich würde ja unseren Moodle-Server upgraden, doch geht das momentan nicht, da der Provider noch auf SuSE 9.3 setzt und somit mySQL und PHP nicht auf dem Stand sind, den ein aktuelles Moodle benötigt.
Wie wäre es denn anders herum, wenn man Moodle ebenfalls auch den LDAP-Server packt und die Zugriffe, die von der Homepage von außen kommen, ebenfalls irgendwie (?) nach innen tunnelt? Machbar oder unsicher?
Wie wäre es denn anders herum, wenn man Moodle ebenfalls auch den LDAP-Server packt und die Zugriffe, die von der Homepage von außen kommen, ebenfalls irgendwie (?) nach innen tunnelt? Machbar oder unsicher?
SuSE9.3 - na hoffentlich ist das kein Rootserver, für den du selbst verantwortlich bist. Ich glaube die Sicherheitsupdates für diese Distribution sind schon ausgelaufen oder tun es bald. Provider wechseln!
Wie seid ihr angebunden? DSL? Dann vergiss dein Vorhaben. Ab einer Standleitung mit 2Mbit/s (Down- UND Upstream) könnte man darüber reden.
Erster Testschritt:
Portweiterleitung vom IPCop auf den LDAP-Server (Port 22 oder auf was der SSH halt läuft) einrichten und testen, ob du von außen auf den SSH kommst.
Später leitest du dann den LDAP-Port in die DMZ und machst dann darauf die Portweiterleitung - später.
Gruß,
Maik
Wie seid ihr angebunden? DSL? Dann vergiss dein Vorhaben. Ab einer Standleitung mit 2Mbit/s (Down- UND Upstream) könnte man darüber reden.
Erster Testschritt:
Portweiterleitung vom IPCop auf den LDAP-Server (Port 22 oder auf was der SSH halt läuft) einrichten und testen, ob du von außen auf den SSH kommst.
Später leitest du dann den LDAP-Port in die DMZ und machst dann darauf die Portweiterleitung - später.
Gruß,
Maik