FAQ:Arktur4/LDAPSichtUE: Unterschied zwischen den Versionen

Aus Delixs
Zur Navigation springen Zur Suche springen
K (5 Versionen)
(kat)
 
(2 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
__NOTOC__
{{Archiv}}
== LDAP aus Benutzer- und Entwicklersicht ==
== LDAP aus Benutzer- und Entwicklersicht ==


Zeile 57: Zeile 61:
----
----
<div align="right">[[FAQ:Arktur4|zurück]] | [[Hauptseite]]</div>
<div align="right">[[FAQ:Arktur4|zurück]] | [[Hauptseite]]</div>
[[Kategorie:ArchivArktur40]]

Aktuelle Version vom 16. März 2012, 13:22 Uhr


Baustelle Archiv: Dieser Artikel beschreibt nicht die Funktionalität des derzeit aktuellen delixs-Servers. Er beschreibt ältere Schulserver-Funktionen und dient dem Zweck der Archivierung.


LDAP aus Benutzer- und Entwicklersicht

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.

-- aus einer Mail von ReiKla.

Anm. d. Red.:

Unter LDAP im Administratorhandbuch finden Sie eine Kurzanleitung.



zurück | Hauptseite