Aus verschiedenen Gründen bin ich an meinem Arbeitsplatz zum De-facto-LDAP-Administrator geworden. Ich lerne es jetzt seit etwa einem Jahr im Job. Wenn ich also Dinge beschreibe, können Sie gerne bessere Vorgehensweisen vorschlagen.
Ich habe ein Novell eDirectory, in dem ich Mitarbeiterinformationen speichere. Es wird hauptsächlich zur Authentifizierung verschiedener Webdienste wie Moodle oder Drupal verwendet. Ich verwende es aber auch als Backend für ein neues Mitarbeiterverzeichnis. Ich sah keinen Sinn darin, die Daten noch mehr zu duplizieren, als sie bereits dupliziert wurden. Außerdem klingt ein Mitarbeiterverzeichnis genau nach der Art von Dingen, für die LDAP gemacht wurde.
Ich habe Einträge für jedes Büro erstellt und dann für jeden Benutzer ein Attribut eingerichtet, das auf den DN des Büroeintrags für sein Büro verweist. Das Problem, das ich jetzt habe, ist, dass jedes Büro wahrscheinlich seine eigene Telefonnummer hat. Daher haben Mitarbeiter, die mehr als ein Büro haben (wenn sie beispielsweise an mehr als einem Campus arbeiten), mehr als eine Telefonnummer. Da Telefonnummern dem Mitarbeiter folgen, kann ich die Nummer nicht einfach dem Büroeintrag zuweisen. Ich muss also irgendwie sagen können: „Diese Telefonnummer ist für dieses Büro.“
Wenn dies eine MySQL-Datenbank wäre, würde ich einfach eine Tabelle erstellen, die die Dinge nach meinen Wünschen abbildet.
Gibt es eine ähnliche Struktur, die ich in LDAP verwenden könnte? Oder eine gleichwertige Methode?
Um ein detailliertes Beispiel dessen zu geben, wovon ich spreche, hier ein Pseudo-LDIF eines Mitarbeitereintrags:
dn: cn=user,ou=staff,dc=college,dc=edu
officedn: cn=DC107,ou=locations,dc=college,dc=edu
officedn: cn=MAIN222,ou=locations,dc=college,dc=edu
phone: 555-555-5555
phone: 111-111-1111
departmentdn: cn=it,ou=departments,ou=groups,dc=college,dc=edu
departmentdn: cn=math,ou=departments,ou=groups,dc=college,dc=edu
title: web systems admin
title: professor of discrete math
Also, wie würde ich mich verhalten:
officedn: cn=DC107,ou=locations,dc=college,dc=eduzu phone: 555-555-5555?
Oder officedn: cn=MAIN222,ou=locations,dc=college,dc=eduzu phone: 111-111-1111?
Oder departmentdn: cn=math,ou=departments,ou=groups,dc=college,dc=eduzu title: professor of discrete math?
Und so weiter...
Einige Anmerkungen, falls sie relevant sind:
Ich habe benutzerdefinierte Attribute für die Büro- und Abteilungs-DNs mit der DN-Syntax 1.3.6.1.4.1.1466.115.121.1.12 erstellt.
Abteilungseinträge haben die ObjectClasses groupOfNames, nestedGroupAux und Top.
Büros verfügen über die Objektklassen: Eine benutzerdefinierte Objektklasse, die den benutzerdefinierten DN-Verweis auf ihren übergeordneten Campus-Eintrag, ndsLoginProperties, organizationalPerson, Person und Top enthält.
Benutzereinträge sind dieselben wie für Büros, plus PosixAccount.
Gibt es noch weitere Informationen, die ich angeben sollte?
Bearbeiten, um Probleme zu beheben, für die die Kommentare zu kurz sind:
Wenn ich einen weiteren Eintrag mit den Metainformationen erstelle, wie inhttps://serverfault.com/a/500129/99647Ich müsste einen Metaeintrag pro Telefonnummer und pro Berufsbezeichnung erstellen.
dn: cn=MAIN222,cn=user,ou=staff,dc=college,dc=edu officedn: cn=MAIN222,ou=locations,dc=college,dc=edu phone: 111-111-1111 departmentdn: cn=math,ou=departments,ou=groups,dc=college,dc=edu title: professor of discrete math departmentdn: cn=it,ou=departments,ou=groups,dc=college,dc=edu title: web systems admin
Würde nicht funktionieren, da ein Computer keine Möglichkeit hat, herauszufinden, dass die Websystemadministration nichts mit Mathematik zu tun hat, wohl aber damit.
Bevor ich die Frage gepostet habe, war die Methode, die mir eingefallen ist, so etwas wie die Erstellung einer Organisationseinheit für alle Metadaten: ou=metadata,dc=college,dc=eduDann eine Organisationseinheit für jeden Benutzer: ou=userid,ou=metadata,dc=college,dc=eduDann ein Eintrag pro Berufsbezeichnung und Telefonnummer, der sie mit ihren Abteilungen und Büros verknüpft:
``` dn: cn=Jobtitel,ou=Benutzer-ID,ou=Metadaten,dc=College,dc=edu Büro-dn: cn=DC107,ou=Standorte,dc=College,dc=edu Telefon: 555-555-5555
dn: cn=Telefonnummer,ou=Benutzer-ID,ou=Metadaten,dc=Hochschule,dc=edu Büro-dn: cn=MAIN222,ou=Standorte,dc=Hochschule,dc=edu Telefon: 111-111-1111 ```
Ich hatte gehofft, dass es einen saubereren Weg gibt, um mein Ziel zu erreichen.
Antwort1
Warum nicht einfach für jede Position ein Objekt erstellen, das die Dienststelle und zugehörige Informationen im selben Objekt enthält?
Also:
dn: cn=DC107,cn=user,ou=staff,dc=college,dc=edu
officedn: cn=DC107,ou=locations,dc=college,dc=edu
phone: 555-555-5555
departmentdn: cn=it,ou=departments,ou=groups,dc=college,dc=edu
title: web systems admin
dn: cn=MAIN222,cn=user,ou=staff,dc=college,dc=edu
officedn: cn=MAIN222,ou=locations,dc=college,dc=edu
phone: 111-111-1111
departmentdn: cn=math,ou=departments,ou=groups,dc=college,dc=edu
title: professor of discrete math
Auf diese Weise behalten Sie alle für eine einzelne Position relevanten Felder in einem Objekt, und das Objekt des Benutzers ist der Container. Dadurch wird die Suche und Verarbeitung einer beliebigen Anzahl von Positionen äußerst unkompliziert.