Zweiter LDAP-Server als Backup und Entlastung

,

Hallo Forum,

ich habe seit längerem neben unserem 6.2er-Server einen extern angemieteten (simpelsten) Server auf dem ein ldap-Dienst läuft. Entsprechend dem Eintrag aus dem Wiki und
diesem Forumsbeitrag wird mehrmals täglich die LDAP-Datenbank auf den externen Server geschoben, so dass er stets synchron ist und für Moodle, Webuntis, Nextcloud und Co als zweiter (oder sogar einziger) LDAP-Server eingetragen ist. Super praktisch!

Momentan stellen wir auf LMN7.1 um und ich wollte das Skript übernehmen und habe auch schon einen neuen externen Server hochgefahren. Allerdings finde ich auf dem LMN7-Server keine LDAP Konfigurationen mehr: Das Verzeichnis /etc/ldap/ ist bis auf eine dummy-Datei leer. :grimacing:

Auch z.B. der erste Befehl aus Thomas Skript (die Basis des Mechanismus) geht nicht mehr:

echo "* erzeuge ldap-dump"
/usr/sbin/slapcat -l /root/ldap.ldif

An der Schulkonsole kann man sich anmelden - wir haben Schüler und Lehrer drin - was hat sich denn von 6.2 → 7.1 hierzu geändert? Der Dienst sladp ist scheinbar auch nicht aktiv… (dkpg -s slapd meldet "nicht installiert)

Hat jemand einen Tipp für mich, wo ich schauen kann / wie ich das lösen kann?

Vielen Dank und Grüße,
Felix

Hallo Felix,

mit LMN7 ist auf das LDAP vom Samba 4 gesetzt wurden. Mit Änderung der Dienste sind die Konfigs und Werkzeuge ebenfalls geändert.

Hallo Carsten,

Danke dir!

Gibt es dort auch eine Möglichkeit einen LDAP-Dump zu machen? Am besten so, dass es ein normaler LDAP-Dienst „schluckt“? Oder muss ich einen zweiten Samba ins Netz stellen und diesen synchronisieren? Habe von Samba quasi Null Ahnung und würde das auch gerne so belassen :wink:

VG, Felix

PS: Oder ist es fast einfacher einen zweiten LMN-Server extern aufzusetzen und ihn regelmäßig mit dem Vampire-Skript zu füttern?

Hallo Felix,

eine kurze Suche ergab:

und

vielleicht hilft das.

LG

Holger

Lieber Felix,

gleichwohl ich Dir Deine Frage nicht konkret beantworten kann, so laß Dir sagen, Deine Gedanken gefallen mir!

Seit vielen Jahren bin ich mit freier Software unterwegs und natürlich auch sehr an freien Schulserverlösungen interessiert. Jedoch bin ich kein Entwickler von LMN. Ich betrachte das eher akademisch, vergleichend, gesellschaftlich, bewundernd…

Mit Aufkommen von NT-Domänen betrieb ich einst ein bewährtes Samba für Datei-/Druckdienste und parallel ein extra Samba nur als Windows-NT-4-Domain-Controller. Ich hätte auch heute gern kleine übersichtliche Dienste/ Pakete statt der großen monolithischen Ungetüme. Statt LDAP über Samba 4 umzusetzen wäre mir eine bewährte Lösung mittels OpenLDAP lieber. Toll wäre aus meiner Sicht, wenn die Nutzer und Rechte in einer PostgreSQL-Datenbank gespeichert wären (Anregung https://ogris.de/samba). Mittels einer Prozedur könnten größere Änderung wie beispielsweise beim Ein-/ Ausschalten des Klassenarbeitsmodus auch in großen Datenbeständen in kurzer Zeit bewältigt werden (das empfinde ich in MNN7 als ungünstig). Womöglich läßt sich auch das obsolete (?) Windows ebenso anders einbinden (Anregung http://pgina.org/). Vielleicht kommt das in LMN8?
Meine Welt käme auch ohne systemd und Docker aus :wink:

Grüße
Carsten

Hallo Carsten,

das freut mich :slight_smile: Mir geht es ganz ähnlich, denn ich mag auch die Philosophie von Linux für jedes Problem ein passendes Tool zu haben - und dieses dann ganz direkt auf Dateiebene konfigurieren zu können… daher hätte ich mich auch über weiterhin OpenLDAP gefreut, aber ich bin auch kein Entwickler und habe auch nicht den Überblick über die Vorteile, die solche Vereinheitlichungen mit sich bringen… daher muss ich wohl nun einen anderen Weg finden…

Viele Grüße,
Felix

PS: Docker finde ich schon beeindruckend, wie schnell man da Dinge an den Start bringen kann, aber in meiner Welt bräuchte es AppImages, Flatpack, Snap und Co nicht (da fühle ich mich wie bei Windows :scream:), aber das führt wirklich weit vom Thema ab… und auch hier gibt es bestimmt auf der Entwicklerseite Vorteile, daher will ich auch gar nicht zu arg meckern :wink:

PPS: Frohes Neues! :fireworks:

Hallo Holger,

danke dir - habe ich beide schon gelesen, aber wenn ich es richtig sehe, gehen beide noch von OpenLDAP aus und nicht von Samba :-/

Was wohl mein Problem lösen würde ist der Thread von Dorian:

Das wirkt mir aber mächtig kompliziert und ich suche daher noch nach einer einfachen Lösung, da ich ja „nur“ LDAP nach außen replizieren möchte… nicht das ganze AD…

Danke aber für’s Mitdenken und viele Grüße,
Felix

PS - Und dir auch ein Frohes Neues :slight_smile: :fireworks:

Hallo zusammen,

so weit ich weiß, kommt die Möglichkeit einer LDAP/AD-Replika mit LMN 7.2, die aktuell entwickelt wird. Da warte ich auch sehnsüchtig drauf, da mittlerweile wie schon erwähnt, viele - auch externe - Dienste eben auf die Authentifizierung mit dem LDAP angewiesen sind.

Viele Grüße,
Jochen

Hi,

die Replikation hat eigentlich nichts mit der 7.2 zutun. Man muss eben einen zweiten DomainController mit Samba aufsetzen, das wird bei der 7.2 genau gleich bleiben.

VG,
Dorian

Hi Dorian,

ich meinte irgendwo in Ask gelesen zu haben, dass das erst mit der dann neuen Samba-Version von LMN7.2 funktionieren soll?

Viele Grüße,
Jochen

Hallo Jochen,

ja, das hast du hier gelesen:

@dorian : dein im obigen Thread erwähnter Ansatz ist ja offenbar per VPN o.ä. permanent mit dem LMN-Server verbunden. Funktioniert das auch, wenn die Schule offline ist? (Das ist ja der Zweck der Geschichte…)

Als Idee: Auf einem gemieteten Server ein LMN7.1-Setup durchlaufen lassen und regelmäßig die Konfigs rüberkopieren - könnte das auch gehen? Ich will von extern ja nur LDAP benutzen…

Viele Grüße,
Felix

Hi,

Das ist Quatsch. Ich habe das seit einem Jahr ohne Probleme mit LMN7.0 und jetzt mit 7.1 im Einsatz. Das Einzige was nicht geht ist ein RODC.
Es ist nur wochtig, dass die Versionen übereinstimmen. Also muss der externe Server auch auf Ubuntu 18.04 laufen. Ich hab das Ganze in einem Docker Container.

Ja!

Ich habe den externen server per WireGuard an unser internes Netz angeschlossen. Dann muss man nur den Samba als zweiten Domaincontroller joinen und er spiegelt alles. Damit ist auch die Authentifizierung gegen diesen zweiten Samba Server möglich. Das mache ich zum Beispiel für unseren Matrix Server, damit die Kommunikation auch noch funktioniert, wenn vor Ort der Strom oder das Internet ausfällt.

Wie gesagt, das funktioniert wunderbar seit einem Jahr…

Ich muss aber dazusagen, dass ich mich nich mega gut damit auskenne und es einfach durch lesen der Dokumentation und ein bisschen trail and error hinbekommen habe. Es kann sein, dass das unerwünschte Seiteneffekte hat, von denen ich nichts weiß.

VG,
Dorian

Hallo,

Muss oder sollte man dann noch eine Konfiguration vornehmen, damit sich die Clients nicht alle versuchen am entfernten DC im externen Rechenzentrum anzumelden? Zumindest die Windows-Clients wählen den Anmeldeserver durch ein Verfahren aus, dass (in einer reinen Windows-Umgebung) über eine Kombination aus DNS-Abfrage, Gruppenrichtlinieneinstellung und AD-Konfiguration (Zuordnung zu einer Site) steuerbar ist.

MfG Buster

Hi Buster,

gute Frage. Wäre sicher gut, das zu konfigurieren, ich weiß allerdings nicht wie. Bisher hatte ich keine Probleme mit Clients, die versucht hätten, den falschen Server anzusprechen.

VG,
Dorian

Hallo,
im Grunde hast du das bereits konfiguriert.
Wenn du den Windows-Clients den 2. Samba nicht per DHCP als 2. DNS-Server eingetragen hast, dann wird der 2. Samba auch nicht als Logon-Server von den Clients verwendet.

Viele Grüße
Christian

Hallo Blair/Christian,

bist du dir da sicher? DNS-Server und Logonserver sind zwei getrennte Einstellungen. Ein Windows-Client wird seine zugewiesenen DNS-Server (egal wieviele konfiguriert sind) nach der IP zu den DNS-Einträgen _ldap._tcp.ADSitename._sites.dc._msdcs.domain.tld und _ldap._tcp.dc._msdcs.domain.tld fragen. Die Antwort nimmt er als Anmeldeserver. Da kommt es auf den Inhalt der DNS-Antwort an und nicht darauf, ob ein 2. DNS-Server konfiguriert ist. Wenn nun zwei Samba-Server als DC in die Domäne aufgenommen wurden, sollte zumindest die DNS-Antwort für _ldap._tcp.dc._msdcs.domain.tld standardmäßig alle IPs aller DC enthalten. Will man die Anmeldung an bestimmte DC präferieren/beschränken, muss man DC und Clients derselben AD-Site zuweisen. (Ich gehe davon aus, dass das mit einem Samba-Server als DC statt Windows-Server nicht anders funktioniert, sonst wäre es nicht kompatibel.)

MfG Buster

Hallo Buster,

der Beitrag bezieht sich nur auf das Setting von Dorian. Bei seiner Konfiguration und seinem Aufbau sollte der 2. Samba eigentlich nie von einem Client als Anmeldeserver genutzt werden, selbst bei einem Ausfall des 1. Samba nicht.

Edit:
Hab jetzt verstanden, was du meinst.
Wenn man den DNS Server angibt, dann wird der nicht automatisch als Anmeldeserver ausgewählt. Ohne weitere Konfiguration nimmt der Client den nahegelegensten Anmeldeserver. Dorian könnte als DNS Server seinen 2. Samba angeben, die Clients würden als Anmeldeserver trotzdem den 1. Samba nehmen, da der im gleichen Subnet liegt und damit näher ist. Außer, wenn der 1. Samba ausfällt, dann würde in dem Fall eben der 2. Samba benutzt.
Danke für den Hinweis. Hatte ich oben unglücklich formuliert.

Viele Grüße
Christian

1 „Gefällt mir“

Ja, und was nahegelegen ist, bestimmt die Konfiguration des Site-Objektes im ActiveDirectory. Standardmäßig (bei Erstinstallation eines AD) gibt es erstmal nur eine Site und der erste Domänencontroller und sein IP-Netz sind dieser zugeordnet.

Nein, die Clients wählen irgendeinen DC, der in der selben AD-Site ist, wie der Client. Das kann dasselbe IP-Subnetz sein, muss es aber nicht.

Und hier gehe ich mal davon aus, dass danach keine weitere Konfiguration der Site-Objekte und zugehöriger IP-Netze im AD gemacht wurde (weil man nun mal nicht täglich DCs in Domänen aufnimmt). Damit ist der zweite DC in die erste/einzige Site im AD gejoint und aus Sicht des AD und Windows-Clients gleicht weit entfernt.

Ob und wieviel Kommunikation es zu dem externen DC gibt, könnte man ja leicht ermitteln, indem eine Firewallregel nur protokolliert was an Pakete zu den Ports für LDAP und Kerberos zum externen DC läuft.

MfG Buster

P.S.: Zu den Hintergründen: