Zum aktuellsten Beitrag
LDAP Schema
  • verfasst: 07.12.2005, 11:08
     
    Forenrang:
    Skolelinux Admin Skolelinux Admin
    registriert:
     Dezember 2005
    Status:
    offline
    letzter Besuch:
    01.11.06
    Beiträge:
    3
    Man sollte sich vermutlich zunächstmal auf die notwendigen Features des ldap-backends einigen, da die das LDAP schema mitbestimmen.

    Debian-Edu (aka Skolelinux) hat folgende grundsätzliche Forderungen:

    - sicherheit (und daraus resultierend das prinzip der minimalen Privilegien)
    - upgradebar
    - robust

    Ausserdem wollen wir in der Lage sein, user zu Admins zu machen (also gewisse, eingegrenzte vorgänge mit root-rechten anstossen zu können) und mini/junior-Admins zum passwort-ändern anderer zu ermächtigen.

    Dazu benutzen wir die ACLs auf slapd Niveau. Die wiederum erfordern gewisse objectclasses um benutzt werden zu können.

    Gibt es noch andere grundlegende anforderungen?
  • verfasst: 09.12.2005, 11:47
       
    Lars
    Forenrang:
    Site Admin Site Admin
    registriert:
     November 2003
    Status:
    offline
    letzter Besuch:
    27.11.09
    Beiträge:
    526
    stockholm- sicherheit (und daraus resultierend das prinzip der minimalen Privilegien)
    - upgradebar
    - robust

    ACK icon_wink

    stockholmAusserdem wollen wir in der Lage sein, user zu Admins zu machen (also gewisse, eingegrenzte vorgänge mit root-rechten anstossen zu können) und mini/junior-Admins zum passwort-ändern anderer zu ermächtigen.


    Das ist doch im OSS realisiert. Peter wird da sicherlich ein paar Informationen beisteuern können.

    stockholmGibt es noch andere grundlegende anforderungen?


    Sicher. Ich denke da z.B. an eine "eigene" Schema Datei für Schulen. Ich nehm z.B. mal die Datei (openschool-server.schema) vom OSS, wo verschiedene attributetypes definiert sind. Wenn solche attributetypes vereinheitlicht werden, dann kann man entsprechende Skripte einfacher halten. Z.B. gibt es hier halt attributetypes für:
    * loginDisabled
    * internetDisabled
    * clientMustUpdate
    * clientUpdatePath
    * clientInstalledOS
    * ...
    ...über deren Inhalt man sich ebenfalls Gedanken machen kann. Wenn dann später ein Skript z.B. überprüfen möchte, ob ein Nutzer überhaupt ins Internet darf, dann braucht eben nur das Attribut "internetDisabled" überprüft bzw. gesetzt werden.
  • verfasst: 09.12.2005, 14:41
     
    Forenrang:
    Skolelinux Admin Skolelinux Admin
    registriert:
     Dezember 2005
    Status:
    offline
    letzter Besuch:
    01.11.06
    Beiträge:
    3
    Lars
    stockholmAusserdem wollen wir in der Lage sein, user zu Admins zu machen (also gewisse, eingegrenzte vorgänge mit root-rechten anstossen zu können) und mini/junior-Admins zum passwort-ändern anderer zu ermächtigen.


    Das ist doch im OSS realisiert. Peter wird da sicherlich ein paar Informationen beisteuern können.


    Da kommen wir schon zu implementationstechnischen Details die vermutlich eng mit dem zugrundeliegenden Schema verflochten sind. Wollen wir da gleich weitermachen? Das geht dann gleich tiefer in die Sicherheitsthematik.

    Wir möchten gerne mit sgid Scripten arbeiten die genau die sudo Privilegien haben die sie maximal brauchen (z.B. chown zum Anlegen von Homeverzeichnissen).

    Wir hatten auch über Job-queues die Cron-gesteuert abgearbeitet werden nachgedacht. Allerdings fügt das eine zusätzliche unnötige Abstraktionsebene hinzu, man verliert die Interaktivität und gewinnt nichts hinzu.

    Daemonen mit root Rechten kamen für uns wegen des Prinzips der minimalen Privilegien nicht in Frage.

    Lars
    Ich denke da z.B. an eine "eigene" Schema Datei für Schulen. Ich nehm z.B. mal die Datei (openschool-server.schema) vom OSS, wo verschiedene attributetypes definiert sind. Wenn solche attributetypes vereinheitlicht werden, dann kann man entsprechende Skripte einfacher halten. Z.B. gibt es hier halt attributetypes für:
    * loginDisabled
    * internetDisabled
    * clientMustUpdate
    * clientUpdatePath
    * clientInstalledOS
    * ...


    Wir haben auch eine eigene Schema Datei (wie wohl jeder der sowas implementiert hat; mit dem standard shadow Schema kommt man ja nicht so weit. ACLs kann man da schon gleich vergessen.).

    wie habt Ihr das mit den Accessattributen denn dann weiter implementiert? LDAP support (z.B. in Squid) ist meistens besser für Gruppen (in diesem Falle netgroups) als für einzelne Nutzer (werden die in z.B. Squid überhaupt unterstützt?). Darum fügen wir Benutzer die ins Netzt dürfen zur Gruppe "internet" hinzu. Auf diese Weise hat man auch einfachere Schemas und weniger Attribute.
  • verfasst: 12.12.2005, 11:00
     
    Forenrang:
    OSS Admin OSS Admin
    registriert:
     Februar 2005
    Status:
    offline
    letzter Besuch:
    03.05.07
    Beiträge:
    42
  • verfasst: 13.12.2005, 20:27
     
    Forenrang:
    Skolelinux Admin Skolelinux Admin
    registriert:
     Dezember 2005
    Status:
    offline
    letzter Besuch:
    01.11.06
    Beiträge:
    3
    varkolyZu Deiner Squid Frage:
    Wir haben das auf Benutzer ebene gamacht. Das Ergebniss ist das selbe. Grundsetzlich darf jeder, es sei den bei ihm ist das Attribut internetDisabled auf tur gesetzt.
    In der Schulserver gibt es schon sowieso so viele Gruppen, dass ich gesagt habe nur für die Rollen werde ich Gruppen machen, die wirklich mit irgendwelchen Systemrechten zutun haben. Allerdings muss so eine gruppe kein posixGroup sein. Ich sehe schon, dieses Treffen wird sehr interresant icon_wink


    Die Anzahl der Gruppen pro user ist tatsächlich ein Problem (aber das wird nicht von solchen PrivilegienGruppen (so nennen wir sie) hervorgerufen). Das Problem liegt in der NFSv2(?) Implementation, die nur 16 Gruppen pro user verwalten kann. Das läst sich mit Kerberos und NFSv3 oder einem anderen Netzwerkfilesystem beheben. (Wir zielen auf OpenAFS.) Sonst sind ist die Anzahl der Gruppen kein Flaschenhals für uns. Warum ist sie für Euch ein Problem?

    varkoly
    Allgemein:
    Das ist eben das worüber wir us Gedanken machen wollen. Jeder von uns hat schon seine Schulserverschema entworfen, und damit seine Erfarungen gesammelt. Wir wissen was gut ist, was haben evtl. falsch implementiert und was uns noch fehlt.


    Wow, das geht aber ziemlich weit.

    Da gibts ja viele Themen über die man sich unterhalten kann:
    - Locking (Apropos, wie lockt Ihr, und was? wie vermeidet Ihr Raceconditions?)
    - Upgrade Tools
    - Alternativen zu LDAP (wie PostgreSQL)

    varkoly
    Wir benutzen acl-s sowohl auf der slapd-Seite als auch über OpenLDAPaci. Das zweite ist eine Erbe von SLOX. Ob das auf einem Schulserver sinn macht ist natürlich fraglich, da man in einer Schule die Rollen bzw. Rechte Gruppenweise ziemlich gut in Griff haben kann.


    Ja, ACIs haben wir geprüft aber die haben weder unsere Probleme gelöst noch sind die LDAP Götter zufrieden mit ihrer gegenwärtigen Implementation.

    varkoly
    Wir haben zZeit folgende Ziele:
    Da es in LDAP alles so gut funktioniert; man kann inm nu Rechte, Eigenschaften, Verbindungen usw. geben und nehmen; wir versuchen alles in LDAP zu puschen, und alles über LDAP zu regeln.


    Wir versuchen auch so zentral wie möglich administrierbar zu sein, packen aber nur in LDAP hinein was für uns Sinn macht. Z.B. lassen wir DNS aus LDAP heraus (und Kerberos vermutlich auch), weil das die Betriebssicherheit einschränkt. Wir überlegen ob DHCP in LDAP sinn macht und werden es vermutlich einfach mal ausprobieren. Das hängt bei uns mit der Netzwerkarchitektur zusammen: DHCP läuft auf den Terminalservern, und es wäre schön wenn man die "stateless" machen könnte, so dass man keine informationen lokal auf ihnen speichert und sie im Schadensfall einfach gegen eine neuinstallierte Maschine austauschen kann.

    Was habt ihr denn noch alles im LDAP drin?

    varkoly
    1. Die Struktur der LDAP-Schema bzw. des LDAP-Baumes soweit zu optimieren, dass man mit Hilfe einfacher LDAP-Filter alle Informationen erhalten kann. Dazu müssen wir wissen welche Informationen man gebrauchen könnte.


    Uh, ich glaube das geht bei uns. Beispiel?

    varkoly
    2. OpenLDAP bietet über Overlays/Plugins tolle Werkzeuge. Diese möchten wir ausnutzen, um Systemzugriffe zu vermeiden. Das heisst ein ldapadd .... erzeugt alle notwendige LDAP-einträge, Home- bzw. Profileverzeichnis, ggf. Mailbox ...


    Das kenne ich nochgarnicht. Was gewinnt man mit solchen hooks? Laufen die dann alle mit root Rechten?

    varkoly
    3. Auf Grund einiger ausstehender Projekte müssen wir Gedanken über die zentralisierung der LDAP-Datenbanken machen. Wie erreicht man die Eindeutigkeit der Einträge in allen Subbäumen usw.


    da kommt es ja drauf an ob die verschiedenen subbäume auf den gleichen rechnern laufen sollen. dann müssen uid/gid/login eindeutig sein. Das stellen wir sicher durch atomic uid/gid Inkrementierung und durch checken der Usernamen vor dem Anlegen in der Datenbank.

 Suchen:


 Umfrage

(Nur für angemeldete Benutzer)

Was wird hier am meisten vermisst?

[ Ergebnis | Umfragen ]

Stimmen: 621
Kommentare: 0

 Zitate

This driver conforms to Linus Confidence Level 2:
It looks right
X It builds
It works
It passes stress tests

-- Jeff Garzik on linux-kernel