Arktur Portal

Arktur - Schulserver

:: die perfekte Serverlösung für alle Schularten :: pädagogisch durchdacht :: von Lehrern für Schulen entwickelt ::

 über Arktur
 Meldungen
 Download/Bezug
 Updates
 Mitmachen
 Mailinglisten
 Entwicklung
 Fehlermeldungen
 FAQ
 Dokumentation
 Links
 Das Team
 Logos
 Händler
 Impressum

Argumente für LDAP

Lesen Sie drei Antworten zur gleichen Frage:

Auch zu folgender Frage wird Stellung genommen:




Frage:

Ich möchte eigentlich nur wissen, was mir LDAP für Vorteile bringt, ohne daß ich erst 500 Seiten Doku lesen muß.


Antwort:

LDAP ist nicht nur das Protokoll zum Austausch von Informationen, sondern es wird auch vorgegeben, wie man auf diese Informationen zugreifen kann. anders ausgedrückt: es wird die interne Struktur praktisch impliziert (als Baum) ohne diese direkt vorzugeben.

In dieser (Baum-)Struktur können *alle* Informationen, die sonst über alle möglichen Dateien verteilt abgelegt wurden an einer zentralen Stelle genauso wie in der Registry abgelegt und damit auch verwaltet werden. Ein Vorteil ist (wie in den Bäumen üblich) der deutlich schnellere Zugriff auf einzelne Einträge. eine shadow von 20000 Einträgen zu durchsuchen dauert möglicherweise zu lange, bei 20000 Einträgen im LDAP ist das kein zeitliches Problem.

Weiter: in einem Baum können recht unproblematisch neue Informationen eingetragen werden. jedes neu installierte Windowsprogramm kann und soll seine Informationen eintragen. Es gibt (fast) keine Vorgaben und die anderen Einträge werden davon nicht betroffen. Auf den LDAP bezogen ist das genauso: die Baumstruktur ist keineswegs vorgegeben, sondern das liegt in der Hand der Entwickler der Distribution. Für uns wichtig ist, dass diese Datenbank um "beliebige" Einträge erweitert werden kann, ganz im Gegensatz zu dem starren Schema von passwd & Co.

Das bedeutet, es können eben viel filigraner die Rechte vergeben und im LDAP gespeichert werden, an das im passwd/shadow-System nie zu denken war. Konkret: So um 2002 wurde in der SN-Liste über die Probleme bei der Nutzung von E-Mail in Schulnetzen diskutiert. Zumindest waren einige der Ansicht, dass es sinnvoll sein könnte, wenn man eben jeden Schüler erst dann die Nutzung dieses Dienstes freischaltet, wenn er ein bestimmtes Alter hat oder erst, wenn die Erlaubnis der Eltern vorliegt.

Mit LDAP gibt es kein Problem, solche Rechte zu hinterlegen, nicht nur für E-mail, sondern für jedes Programm, für jeden Dienst...

Das bedeutet, LDAP hat das Zeug dazu, auch zukünftigen Anforderungen gerecht zu werden. Damit ist nicht gesagt, dass man diese Möglichkeiten jetzt schon nutzt - aber mit passwd/shadow hat man nichtmal die Chance.

Mit LDAP gibt es die Grundlagen für die Verwendung und Verwaltung des gleichen Passwortes für alle Dienste und bietet zukünftig die Grundlage für die einmalige Anmeldung am Kerberos und der Kerberos-Server übernimmt dann die Anmeldung der Dienste. Die Rechte holt der aus dem LDAP (wie oben beschrieben). Das ist dann echtes "single sign on", wie es derzeit nur in prioritären Umgebungen (Komplettlösungen) für viel Geld zu haben ist.

ein weiterer Vergleich mit der (windows-)Registry. dort gibt es natürlich die vorgegebenen Pfade, aber wo sich das Programm einträgt ist letztlich die Sache des Programms, ebenso wie es diese Daten einträgt. Das ist beim LDAP nicht so. Dort baut man den Baum aus "Komponenten" auf. Es gibt also definierte Schematas - diese sind also standardisiert - und mit Hilfe dieser "Schematas" wird der Baum zusammengebaut. Das hat für dich/uns z.B. folgende Bedeutung. Wenn die Adressen der User in einem LDAP vorgehalten werden, dann kann jedes Programm darauf zugreifen, denn es wird ja für diese Adressen ein Standard-Schema verwendet. Schau dir doch einfach mal Thunderbird an. du gehst dort auf Adressbuch > Extras > Einstellungen > Verfassen > Adress-Autovervollständigung. Damit wird dir klar, dass du normalerweise jeden x-beliebigen LDAP-Server nutzen kannst, sofern der eben die Adressen hat und du die Leserechte hast. Klar, wenn es um die Daten für Windows(98)-Rechner geht gibt es eben auch ein standardisiertes Schemata und genau deswegen lassen sich auch diese Daten problemlos von einem LDAP auf einen anderen LDAP-Server übertragen, egal ob der von SuSE, MS oder eben auf Arktur ist.

Aber es kommt noch besser: es könnte ja sein, dass eben doch ein Feld fehlt. Dann können neue Schemata abgeleitet werden, heißt: es gibt dort auch die Möglichkeit der Vererbung. Aber selbst dann ist der Datenaustausch möglich, denn dann werden eben nur die Daten übernommen, die übernommen werden können (eben der Standard).

Für mich ist es so: ich weiss, dass etliche der aktuellen Probleme mit passwd/shadow im normalen Schulnetz nicht umgesetzt werden können. Mit LDAP ist das Potential da. Es muss einfach der Standard werden.

Ich habe als Admin noch nie an der shadow selbst manipulieren müssen, warum soll ich das bei LDAP tun müssen? Aber ich will doch ein System, was auch in Zukunft den Anforderungen gerecht werden kann.

Wenn der LDAP-Baum richtig aufgebaut ist, dann wird das in zweierlei Hinsicht "korrigiert": erstens sollten alle Informationen in diesen Baum, sofern man es mit zentraler Datenhaltung ernst meint und zweitens ist wegen der Verwendung standardisierter Schemata eben der Austausch dieser Informationen auch über verschiedene LDAP-Server möglich.

Schon diese letzte Frage sollte dich zu einem glühenden Verfechter von LDAP werden lassen. (meine persönliche Meinung)

Vergleich LDAP - Telefonbuch

Ich will das mal so verdeutlichen: Ein LDAP ist ein Verzeichnisdienst.

Ein bekanntes Verzeichnis ist das Telefonbuch. Du kannst in diesem Telefonbuch sehr schnell eine Telefonnummer finden. Aber du wirst nicht so ohne weiteres und schon gar nicht sehr schnell eine neue Nummer in das Telefonbuch bekommen oder einen Eintrag löschen können (alle halbe Jahre?)

Anders ausgedrückt: Ein Telefonbuch ist ein *Verzeichnis*, das heißt es ist leseoptimiert, aber nicht schreiboptimiert.

Ein LDAP ist ebenfalls ein Verzeichnis, welches leseoptimiert ist. Schreib (und Löschzugriff) sind deutlich langsamer und viel aufwendiger. (ist ja auch logisch: in einem Baum ein Element zu finden ist trivial. Aber versuche mal ein Element einzufügen, was kein Blatt ist oder ein Element zu löschen.)

Bedeutet: Es kommen nur Daten in den LDAP, die gelesen werden. Das sind z.B. feste IPs. Da kann man auch gleich noch andere Informationen dazu ablegen z.B. den Raum. Feste IPs werden sich nicht laufend ändern, also werden diese "nur" gelesen.

 

Frage:

Ich möchte eigentlich nur wissen, was mir LDAP für Vorteile bringt, ohne daß ich erst 500 Seiten Doku lesen muß.


Antwort:

Kurzform: Es gibt EINE Stelle, in der ALLE Nutzerinformationen stehen und in der die maßgeblichen RECHTE vereint sind. Du kannst also alle Nutzer dort finden und wesentlich schneller suchen als in der passwd-Datei. Du kannst mehr Informationen speichern, also als Adressbuch nutzen (sogar jpg-Bildchen lassen sich ablegen).

Ein übliches Problem: Lehrer X will das Passwort von Schüler Y ändern, weil der das vergessen hat. Bislang benötigte man dazu root-Rechte, denn nur root darf die /etc/shadow schreiben und zudem die /etc/samba/smbpasswd. Das Passwort liegt also an ZWEI stellen und muss selbst synchron gehalten werden. Hat das Script einen Fehler, kann man mit den root-Rechten noch ganz andere Sachen machen. Zudem ist der hash-Algorithmus in der /etc/shadow bekanntermaßen schwach.

LDAP verwaltet alle Passwort-Einträge als Attribute des Objekts (uid=schülerY). Der Lehrer X bekommt das Recht, diese Attribute zu verändern (aber nicht alle beliebigen!). Arktur benutzt wie üblich sha1 als hash-Algorithmus, der als deutlich sicherer gilt.

Nehmen wir zudem Windows-Attribute: Der LDAP kann diese Aufnehmen, weil die Plätze definitert sind: Mit sambaUserWorkstations lassen sich die Rechner angeben, an denen sich dieser Nutzer anmelden darf. Bislang war es ein Problem, dass sich der Platznutzer "pc1" wirklich nur an PC1 anmelden darf. Mit sambaLogonScript lässt sich für diesen Nutzer ein eigenes Logon-Script vereinbaren, das Vorrang vor dem System-Script hat. Es gibt von viele weitere Attribute, die Samba auswertet. (LogonHours, Password-Länge und Gültigkeitsdauer, Komplexität, ...)

Als besonderen Vorteil habe ich gesehen, dass die Gruppen und die Gruppenzugehörigkeit an die Arbeitsplätze übertragen werden. So kannst Du ein Projekt "Video" anlegen und auf der lokalen Platte einen Bereich dieser Gruppe übertragen, damit dieser Platz für Videoschnitt zur Verfügung steht, aber nicht für alle Nutzer.

Nicht zuletzt sammelt LDAP alle Systemdaten. So greift der DHCP-Server auf die LDAP-Einträge zurück. Du kannst den Eintrag ändern und der DHCP-Server weiß sofort Bescheid. In Firmen werden auch DNS-Daten, Mail-Aliases usw. dort verwaltet.

Ein großer Vorteil ergibt sich dabei bei größeren Netzen mit mehreren Servern. Die teilen sich dabei die Nutzerinformationen besser auf. Wenn Du also Windows-Dienste auf zwei oder mehr Server verteilst, sorgt LDAP für identische Nutzerinformationen. Dann kann man auch eine Replikation des Master-LDAP auf dem zweiten Server laufen lassen.

Wenn Du Linux-Clients nutzt, war das NIS/YP-Protokoll eine der größten Schwachstellen, denn man hat die Nutzerauthentifizierung komplett der Arbeitsstation überlassen. War die korrumpiert, war der Server im Grunde schutzlos. Das macht LDAP wesentlich besser.

Ich lasse zum Beispiel die Proxy-Zugriffe ins Internet nur mit Authentifizierung zu, ohne deshalb alle Nutzer auf dem Proxy-Server noch mal führen zu müssen - und ohne das die sich auf diesem Rechner anmelden könnten.

Frage:

Wenn LDAP zu einem nicht beherrschbaren und undokumentierten Monster à la Windows Registry führt, kann ich darin keinen Vorteil erkennen.

Antwort:

LDAP ist im Gegensatz zur Registry gut dokumentiert und sehr logisch. Alles ist den Schema-Dateien zu entnehmen, die auch über den LDAP abrufbar sind (ich kann alle zu einem Objekt gehörenden Schema-Einträge direkt abrufen).

Frage:

Behebt LDAP den Geburtsfeler von Linux, daß nämlich die zu einem Dienst gehörigen Informationen z. T. über den gesamten Dateibaum verstreut sind (Paradebeispiel: mysql-Datenbanken)?

Antwort:

Nein. Was Du als Geburtsfehler bezeichnest, hat ja seine Gründe. Normalerweise sollte /usr schreibgeschützt sein, /etc nur auf einer Art RAM-Disk liegen und auschließlich in /var ein Schreibbereich sein, abgesehen von /home für die Homeverzeichnisse. Alle Pakete, die nicht zum Standard gehören, kommen in /opt usw.

Richtige UNIX-Systeme hatten Plattenstapel, daher diese Aufteilung. Sie hilft aber bei der Backup-Planung sehr.

 

Frage:

Ich möchte eigentlich nur wissen, was mir LDAP für Vorteile bringt, ohne daß ich erst 500 Seiten Doku lesen muß.


Antwort:

Ob ein System (hier Arktur) mit oder ohne Verzeichnisdienst läuft, ist fuer die Benutzer (hier Schueler und Lehrer) völlig egal. Beides funktioniert.

LDAP ist nur ein Protokoll zum Datenaustausch zwischen Rechnern, Anwendungen und Benutzern in Netzwerkumgebungen. Meistens merken Benutzer nichts vom LDAP, weil die Admins versus Entwickler dies gern verstecken.

So ein offenes Protokoll wie LDAP wurde viele Jahre lang von den Nutzern von Computern gefordert. Nun ist es seit Jahren da und hat sich inzwischen zum Standard gemausert. Es spricht nichts dagegen, LDAP in Arktur zu benutzen.

Zum Thema NDS und ADS:

Sowohl Novell als auch Microsoft sind kommerzielle Firmen. Sie gehören zu den reichsten der Welt. Deshalb sprechen sowohl NDS und ADS das LDAP-Protokoll mit eigenen Erweiterungen. Selbst der NDS-Server und der ADS-Server benutzen intern LDAP (mit eigenen Erweiterungen).

Arktur4 benutzt den freien LDAP Server "OpenLDAP". Der kann Dank LDAP-Protokoll direkt Daten mit NDS- und ADS-Servern austauschen/replizieren.

Alle Microsoft, Novell, Arktur und sonstige Anwendungen die das LDAP-Protokoll sprechen, kooperieren mit jedem LDAP-Server.

Die Frage welchen LDAP-Server jemand benutzen will, bleibt ihm also selbst überlassen. Sofern er denn einen benutzen will.

Frage:

Ich habe mal gehört, dass Windows-LDAP nicht ganz kompatibel wäre, und es deshalb problematisch ist, wenn im Zusammenspiel Arktur, Win-Server der Win-Server LDAP führt.

Kann man dazu etwas Konkretes sagen?

Antwort:

Das ist im Prinzip richtig: ADS beruht auf einem aufgebohrten LDAP-Protokoll. Allerdings verwendet Microsoft eigene Schema-Daten, die zum offiziellen Standard nicht wirklich kompatibel sind.

Hintergrund: Alle Objekte und Attribute erhalten eine interne Nummer. Diese Nummern vergibt offiziell die IANA, die auch für IP-Adressen zuständig ist. Microsoft hat eigene Nummern vergeben und diese nicht mit der IANA abgestimmt.

Was bedeutet das konkret: Normale Tools (z.B. PHP-Scripte) können zu einem ADS-Server mit LDAP V2-Protokoll Kontakt aufnehmen und die Anfragen normal stellen, wie sie auch Arktur beantworten könnte. Die M$-eigenen Tools können nur mit einem ADS-Server umgehen, nicht mit einem normalen LDAP.

Für Arktur bedeutet das zweierlei:

  1. Ein direkter Kontakt zum ADS-Server per LDAP bringt nichts, weil die Attribute nicht stimmen. Alle Posix/Linux-Attribute fehlen, erst die kosten- pflichtigen Erweiterungen für Unix-Systeme ergänzen diese.
  2. Eine Authentifizierung ist über das Windows-Protokoll möglich, entweder per winbind oder per ntlm-auth

In der Praxis empfiehlt sich eine Art Mittelweg: Der Windows-Server wird "trusted" in eine Domäne eingebunden. Das ist folgendermaßen zu verstehen: Der Windows 2000-Server hat eine Domäne "Sonne", in der die Nutzer eingetragen sind. Nun soll Arktur dazu kommen und diese Nutzer mit übernehmen. Später soll vielleicht der Windows-Server verschwinden.

  1. Arktur bekommt die Domäne "Schule".

Die Arbeitsstationen werden in die neue Domäne "Schule" normal eingebunden. Nur wie soll sich ein Nutzer, der in der Domäne "Sonne" ist, nun anmelden? Dazu muss Arktur vermitteln. Er hängt den Server der Domäne "Sonne" als "trusted" in seine Domäne ein (dazu dient ein net-Befehl, bitte nachschlagen). Arktur führt eine ID-MAP, die alle Objekte von Sonne auf eine eigene ID in "Schule" mappt. Windows erkennt Objekte anhand ihrer SID. Dieses Mapping wird im LDAP geführt - ist also nachvollziehbar. Zudem muss der winbind-Daemon die Authentifizierung übernehmen. Der kann wenn gewünscht den Datenverkehr mitschneiden, so dass:

  1. Jeder Nutzer, der sich über diesen Weg angemeldet hat, einen Eintrag
    im LDAP bekommt mit Nutzername und Passwort
  2. Für diesen Nutzer ein Homeverzeichnis erstellt wird und das Profil beim
    zurückschreiben statt auf dem Windows-Server nun auf dem Linux-Server
    liegt.

Diesen Weg gehen viele Firmen zur "sanften Migration".

Ich hoffe das reicht als Erklärung.


(us; letzte Änderung 01.02.2007)