1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen
  2. Unsere jährliche Weihnachts-Banner-Aktion hat begonnen! Wir freuen uns auf viele, viele kreative Vorschläge.
    Mehr dazu könnt Ihr hier nachlesen: Weihnachtsbanner 2016

    Information ausblenden

OS X-Server: Benutzer-Ident. LDAP "extern"

Dieses Thema im Forum "macOS & OS X Server" wurde erstellt von michaelbach, 06.12.05.

  1. michaelbach

    michaelbach Roter Seeapfel

    Dabei seit:
    05.01.04
    Beiträge:
    2.109
    Liebe Apfelplauderer:

    Seit Jahren läuft in meinem Bereich ein OSX Server, so gut dass ich mich nie länger mit der Doku beschäftigen musste :). Nun will ich beim Wechsel auf OSX10.4-Server ein "externes" LDAP-System nutzen. Im ganzen Klinikum gibt es ein LDAP-System, in dem die Benutzer eh bekannt sind. Ich möchte nun, dass sich die (wenigen) Benutzer in meinem Bereich über ihr LDAP-ID und Kennwort anmelden.

    Problem: der Klinikums-Server ist (natürlich) nicht OSX, und es sind einige Felder, die mein Server braucht, da nicht drin. Eigentlich will ich nur folgendes: die Benutzer-Daten (z.B. wo ist Home) liegen in einer Datenbank auf meinem Server, aber beim Anmelden fragt der Server unser LDAP-System ab ob dort der Benutzer mit diesem Kennwort bekannnt ist.

    Ich weiß aber nicht wie das geht [trotz Handbuchstudium]. Muss ich dazu den Server als "Open Directory Master" einstellen? Dann weiß ich nicht wie er über das "externe" LDAP authentifiziert. Oder ist er "Connected to a directory system"? Ja, dann sieht er alle Benutzer im Klinikum, aber ich kann keine Accounts anlegen weil dann Fehlermeldung über fehlende Felder in der LDAP-Datenbank kommt.

    Habe ich mein Problem verständlich erklärt? Weiß jemand ob das überhaupt geht, und wenn ja dann wie? Wo kann ich noch fragen?

    Vielen Dank für Eure Hilfe!
     
  2. G5_Dual

    G5_Dual Melrose

    Dabei seit:
    31.05.04
    Beiträge:
    2.476
  3. michaelbach

    michaelbach Roter Seeapfel

    Dabei seit:
    05.01.04
    Beiträge:
    2.109
    vielen Dank, aber das hat leider nicht weitergeholfen (diese Antwort ist nur ein Trick das Fädchen zu aktualisieren ;)). Aber _echt_ vielen Dank!
     
  4. commander

    commander Baldwins roter Pepping

    Dabei seit:
    25.02.04
    Beiträge:
    3.210
    LDAP Synchronisierungen / Authentifizierungen sind Schwerter wo User Pflugscharen haben wollen ;)

    Am besten lässt Du Dich bei den Admins beraten (die wie üblich keine Ahnung haben) und probierst dann rum.

    Es gibt leider keinen (echten) Standard für LDAP verwaltete hierarchische Systeme (neben den syntaktischen).

    Das ist nicht sehr tröstlich, aber leider Realität! :-C

    Gruß,

    .commander
     
  5. stk

    stk Grünapfel

    Dabei seit:
    05.01.04
    Beiträge:
    7.141
    Moin,

    unter 10.4 gibt's die Möglichkeiten den LDAP-Server als Master, Client oder Replik einzustellen. Ohne es ausprobiert zu haben, würde ich sagen das letzteres hilfreich sein könnte: das externe Verzeichnis replizieren und dann ggf. lokal aufpumpen. Dürfte aber mit etwas cronjob Arbeit verbunden sein.

    Gruß Stefan
     
  6. michaelbach

    michaelbach Roter Seeapfel

    Dabei seit:
    05.01.04
    Beiträge:
    2.109
    vielen Dank für Eure Tipps -- an Commander für das Mitgefühl ;) und an stk: "replizieren", leider ineffizient und nicht dynamisch.
     
  7. tjp

    tjp Baldwins roter Pepping

    Dabei seit:
    07.07.04
    Beiträge:
    3.245
    Ein paar einleitende Worte zu Directory-Server. Es gibt historisch bedingt verschiedene Directory-Server: NIS+, X.500, LDAP. LDAP wurde als Middleware entwickelt, damit man nicht das fürchterliche X.500 Protokoll benutzen mußte. Das heißt man hat mittels LDAP mit einer Middleware kommuniziert und diese hat als Backend einen X.500 Server benutzt.

    Da man recht schnell eingesehen hat, daß X.500 nicht der große Wurf ist, hat man kurzer hand Middleware und Backend zusammengefaßt, so daß es Server gibt, die nativ LDAP verstehen. Apples OpenDirectory, MS ActiveDirectory, ... basieren alle auf LDAP.

    LDAP und alles dazu notwendige wird in diversen RFCs definiert (über RFCs Sunsite DK kann man bequem suchen). Das ist einerseits LDAPv3, das eigentliche Protokoll, was im Netzwerk benutzt wird, dann kommt ein mindest Umfang an Objectklassen, Attributen und Regeln für das Schema.

    Jeder Anbieter hat die Möglichkeit das Schema über den standarisierten Umfang zu erweitern! Bis auf die Regeln, die man üblicherweise als Programmcode in den LDAP-Server einbaut oder nachlädt, kann man das Schema leicht erweitern. D.h. wenn Objektklassen fehlen, kann man diese meistens leicht ergänzen. Wie hängt allerdings vom verwendeten LDAP-Server ab. Beim OpenLDAP Server muß man leider eine Datei auf dem Server plazieren und beim Starten des Server laden lassen. Für Schemaerweiterungen ist leider ein Restart des Servers notwendig.

    Beim SUN One Directory Server kann man per LDAP-Editor die Klassen hinzufügen. Wie steht im betreffenden Handbuch von SUN. Beim Tivoli Directory Server soll es genauso funktionieren, aber genauso wie mit dem ActiveDirectory Server hatte ich mit diesem Server noch nichts zu tun.

    Nein, der Master ist der Haus interne Directory Server, Du hängst Deinen Xserve nur als Client ran.
    Er wird in irgend einer Form RFC2307 bzw. RFC2307bis NIS Mappings für LDAP oder eine von Apple erweiterte Form benutzen. Das heißt, wenn sich jemand an dem Mac anzumelden versucht wird eine Anfrage an den LDAP-Server geschickt.
    (Da ich es mit MacOS X nocht nicht probiert habe sondern bisher nur mit einigen UNICES bezieht sich die nachfolgenden Beschreibung auf den allgemeinen UNIX Fall.)
    Der Client schickt eine Suche an den LDAP-Server (%s steht für den namen)
    (&(objectclass=posixAccount)(uid=%s))
    wichtig ist, daß das Ergebnis eindeutig ist. Ist die Anzahl der gefunden Einträge ungleich 1, scheitert das Einloggen. Ist die Abfrage erfolgreich, versucht der Client mit den Credentials des Nutzers sich am LDAP-Server anzumelden. Gelingt das, dann ist der Benutzer erfolgreich authentifiziert und das System kann die Session starten.

    Du brauchst Schreibrechte auf dem LDAP-Server und dieser muß wie am Anfang beschrieben auch die entsprechenden Objektklassen, Attribute und Regeln kennen. Und Du mußt natürlich alle notwendigen Attribute einer Objektklasse mitliefern. Anderfalls legt der LDAP-Server keine Einträge an.
     
    #7 tjp, 23.12.05
    Zuletzt bearbeitet: 23.12.05
  8. Wikinator

    Wikinator Adams Parmäne

    Dabei seit:
    21.08.04
    Beiträge:
    1.297
    vielleicht eine blöde Idee, aber wäre es nicht möglich, wenn sich das Problem als unlösbar rausstellt, einfach den selben LDAP-Dienst auf dem Xserve zu verwendet, wie auf dem Hauptserver. Natürlich nur, wenn er nicht mit Windows läuft o_O
     
  9. stk

    stk Grünapfel

    Dabei seit:
    05.01.04
    Beiträge:
    7.141
    Moin,
    Schon klar - das war's was ich mit cronjobbing meinte. Alles was dir der Master an eigenen Einstellungen mit der nächsten Replizierung überfährt, mußt Du dann händisch oder eben zeitgesteuert automatisiert wieder nacharbeiten (lassen). Elegant ist freilich was anderes.

    Aber wo wir hier schon mal LDAP-Wissen versammelt haben (wow - tjp!) ich hab da auch noch 'ne offene Position: wie muß ein Schema aussehen, das via LDAP lediglich das Adressbuch füllt, aber keine Benutzereinträge enthält? Und wie schaffe ich es, dieses Schema aus einer FileMaker-Datei zu extrahieren (ggf. auch über Umwege wie z.B. TabText zum Adressbuch und von dort via Addressbook2LDAP in den Server)?

    Gruß Stefan
     
  10. tjp

    tjp Baldwins roter Pepping

    Dabei seit:
    07.07.04
    Beiträge:
    3.245
    Zu 1)
    Echte LDAP Replikation funktioniert so, daß auf dem Master Server alle Slave Server eingetragen werden. Desweiteren wird ein Replikationsaccount definiert, da dieser Account das Recht haben muß, alle Daten im DIT (Directory Information Tree, so nennt man die Information, die im Directory-Server abgelegt sind) schreiben zu dürfen. Die Slave-Server erlauben nur noch diesem Replikationsaccount den DIT zu ändern. Versucht das irgend ein anderer berechtigter Nutzer bekommt er einen LDAP Referal zurück, in dem die Info enthalten ist, wie er seine Änderung auf dem Master schreiben kann.

    Ergo, kann man keine Replikation eines LDAP-Servers machen, wenn man keinen Vollzugriff auf den Server hat, hat man diesen kann man gleich den eingebauten Replikationsmechanismus benutzen.

    Zu 2)
    Ich glaube ich muß weiter ausholen. Das Schema definiert die Struktur möglicher Einträge im DIT, es ist aber nicht der DIT selbst. Der DIT ist natürlich auch strukturiert und nicht ohne Grund taucht der Begriff Tree (Baum) auf. Ein DIT hat immer eine Baumstruktur, sollte dies aus was für einen Grund nicht ausreichend sein, kann man mittels Alias Objekte diese starre Struktur durchbrechen und eine Netzstruktur indirekt erzeugen, in dem von bestimmten Stelle im Baum auf andere Stellen verwiesen wird.

    Das Schema entspricht in etwa einer Tabellendefinition in einem RDBMS. Etwas Vergleichbares zu dem DIT gibt es in einem RDBMS nicht, da sind alle Tabellen flach und eben nicht strukturiert wie im DIT.

    Was Du zum Anlegen eines Telephonverzeichnisses brauchst ist erstmal eine geeignete Objektklasse (d.h. sie erlaubt das Speicher der relevanten Informationen) aus dem Schema. Üblicherweise nimmt man die Objektklasse inetOrgPerson für diesen Zweck. Da es sich um eine der Standardklassen handelt, sollte sie auf jedem aktuellen Server vorhanden sein. Jeder inetOrgPerson Eintrag muß die Einträge cn, sn und objectclass enthalten (diese Anforderungen werden von organizationalPerson geerbt).

    Nachdem klar ist welche Objektklasse(n) Du verwenden kannst, taucht die Frage auf wie lautet der Root-Eintrag Deines LDAP-Servers?
    Wenn Du noch keinen hast, dann mußt Du Dir überlegen wie der DIT strukturiert werden soll. Üblich sind Strukturen wie "o=meine Firma" oder "c=DE", "dc=de" oder "dc=meineDomain,dc=de" oder oder oder der Phantasie sind da keinerlei Grenzen gesetzt. Man versucht meist eine Firmenstruktur oder Domainstruktur nachzubilden, da dies das Leben erleichtert, wenn man bestimmte Services mit LDAP zusammenbenutzen will.

    Als einfach Bespiel nehme ich jetzt einfach "c=DE". Man definiert das beim Anlegen des DITs das so, wie das im einzelnen geht ist abhängig vom LDAP-Server.

    Nehmen wir weiter an, Du willst die Telephonkontakte im DIT ablegen und diese z.B. nach privaten und geschäftlichen Kontakten aufteilen.

    Dann legst Du als erstes eine Struktur unterhalb des Roots an (üblicherweise nimmt man dafür die Objektklasse organizationlUnit). Die Beschreibung des DITs erfolgt als LDIF Datei.

    Code:
    dn: ou=Telefon privat,c=DE
    objectclass: top
    objectclass: organizationalUnit
    ou: Telefon privat
    
    dn: ou=Telefon geschäftlich,c=DE
    objectclass: top
    objectclass: organizationalUnit
    ou: Telefon geschäftlich
    
    Damit hast Du erstmal die Grundstruktur angelegt. Jetzt kann man beide Verzeichnisse mit Daten befüllen.

    Code:
    dn: cn=Hans Mustermann,ou=Telefon privat,c=DE
    objectclass: top
    objectclass: person
    objectclass: organizationalPerson
    objectclass: inetOrgPerson
    cn: Hans Mustermann
    sn: Mustermann
    mail: mustermann@nowhere.noland
    postalAddress: Musterstraße 1
    postalCode: 12345 Musterstadt
    telephoneNumber: +49 XX XXXXXXXX
    ...
    
    Das Spielchen treibt man solange bis man alle Einträge für den LDAP-Server definiert hat. Wichtig ist hierbei, wenn Du Objekt unter geschäftlich und privat einsortieren willst, immer den DN des Eintrages entsprechend zu gestalten. Desweiteren muß für einen gültigen Eintrag im DIT, der RDN (d.h. der neue Teil in diesem Fall cn=Hans Mustermann) des Eintrages mit demselben Attribut des Eintrages übereinstimmen (d.h. RDN cn=Hans Mustermann und das Attribut cn=Hans Mustermann müssen übereinstimmen).

    Wenn Du nun Daten aus Filemaker exportieren willst, muß Du eine LDIF-Datei erzeugen und diese in den DIT importieren. Für neue Einträge auf dem LDAP-Server empfehle ich so Tools wie den LDAP-Editor JXplorer. Damit kann man komfortabel Einträge auf dem LDAP-Server generieren. Bei Fehler weist der Editor einem auch gleich darauf hin.

    Ergänzung:
    Leider darf man in einem LDIF-keine Umlaute direkt reinschreiben, diese müssen speziell kodiert sein. D.h. sie meinen Beitrag nur als lesbares Beispiel wie man es in einem Editor eintippen würde. Wenn man das LDIF wirklich mit Umlauten schreiben will, muß das betreffende Feld erst UTF-8 und dann Base64 kodiert sein. Damit das beim Parsen erkannt wird folgt nach dem obligatorischen Namen und ":" ein weiterer ":".
    Also statt
    Code:
    ou: Telefon geschäftlich
    ou:: IrgendEineBase64Buchstabensuppe
    
     
    #10 tjp, 23.12.05
    Zuletzt bearbeitet: 23.12.05
  11. stk

    stk Grünapfel

    Dabei seit:
    05.01.04
    Beiträge:
    7.141
    Moin,

    schon wieder: wow - das muß ich erstmal in Ruhe verdauen, aber schon der Link zum JXplorer alleine macht die Antwort wertvoll. Bisher hab ich mit phpmyldap rumgemacht und das ist nicht sehr komfortabel.

    Nebenbei: FileMaker zu LDIF ist noch eine echte Marktlücke o_O. Wenn ich mal verstanden habe, wie ich mit den XSLT zu machen ist, werd ich sie schliessen :oops: ;).

    Gruß Stefan
     
  12. michaelbach

    michaelbach Roter Seeapfel

    Dabei seit:
    05.01.04
    Beiträge:
    2.109
    Ist ja toll & vielen Dank was sich jezt hier an Wissen angesammelt hat! Der entscheidende Punkt, den ich auch schon befürchtet habe, ist dass ich dafür Schreibrechte auf den zentralen LDAP-Server brauche. Das ist hier im Klinikum natürlich schwierig, aber die Leute im Rechenzentrum sind doch sehr kooperativ und das werde ich dann mal verfolgen. Klappt es, dann schreibe ich Euch auch ne Rückmeldung!
    Ansonsten: fröhlichen Weihnachtsmann!
     
  13. stk

    stk Grünapfel

    Dabei seit:
    05.01.04
    Beiträge:
    7.141
    Moin,

    vielen Dank an der Stelle noch mal an tjp! Das letzte Post hat mich immens weitergebracht ... zu neuen Fragen ;).

    Nein, nicht nur, daher erstmal ein Update auf meinen jetzigen Stand:

    Mit Hilfe von Alex Hartner und seiner Software Adressbook4LDAP hab ich jetzt die Verbindung zum OS X Serververzeichnis geschafft und kann dort Adressen aus einem lokalen Adressbuch ins LDAP-Verzeichnis unter "people" einstellen. Umgekehrt kann ich mit dem Adressbuch den LDAP-Server unter Verzeichnisdienste ansprechen und Adressen von dort übernehmen. Schon mal nicht schlecht.

    Jetzt kommen die Abers und die Fragen.

    Die Suche vom lokalen Adressbuch auf den LDAP-Server liefert Ergebnisse aus "users" und aus "people", scheint aber im wesentlichen auf das Schema von "users" zugeschnitten zu sein. "users" liefert mir z.B. auch Angaben zum Land und zu Chatkontakten mit, die es im inetOrgPerson-Schema von "people" nicht gibt. Kann man und falls ja wie das inetOrgPerson-Schema von "people" entsprechend anpassen/erweitern/modifizieren ohne dabei in den Wald zu geraten? Nett wären neben dem erwähnten "c" für's Land, "apple-imhandle" für die Chateinträge auch noch "picture" für das Benutzerbild (wobei das lediglich ein Pfad auf eine Datei auf dem Server, nicht das Bild selbst ist), von den Tonnen an Infos die das AppleAdressbuch ansonsten im Stande ist aufzunehmen ganz zu schweigen.

    Weiter: beim Publizieren über AB4LDAP werden sowohl Privat- als auch Firmenadresse übermittelt. Die kompletten Adressen werden dazu in je ein Array "postalAddress", bzw. "homePostalAddress" gepackt. Beide werden in der Abfrage des Adressbuchs aber nicht berücksichtigt. Lediglich Teile der Firmenadresse - die, für die separate Felder wie "street", "postalCode", "st" (für state = Bundesstaat/Provinz) und "l" (für location = Ort) vorhanden sind - werden ans Adressbuch rückübermittelt.

    Kann man die Abfrage des Adressbuchs modifizieren um hier mehr Honig zu saugen? Meine bisherigen Überlegungen zielen auf einen manuelle Konfigurationseintrag in den Adressbuch-Einstellungen unter LDAP. Allerdings ist's mir bislang nicht gelungen dort auch nur einen gültigen Standardeintrag zu kreieren. Die Angabe, die das Dienstprogramm "Verzeichnisdienste" übermittelt funktioniert wie oben beschrieben, läßt sich allerdings bisher bei mir nicht nachbauen. Auch da wären mir sachdienliche Hinweise auf die Syntax schon sehr recht. Gelöst: in der Syntax für den Suchbereich sind unüblicherweise die Einträge mit einem zusätzlichen Leerschritt zu trennen. Also
    Code:
    cn=people, dc=mydomain, dc=com
    statt
    Code:
    cn=people,dc=mydomain,dc=com
    o_O

    Die Abfrage des Adressbuchs läuft ausschliesslich auf das Namensfeld (vermutlich "cn") und die eMail ("mail", wohl wegen der Einbindung in Apple Mail, die ebenfalls zum jetzigen Zeitpunkt gegeben ist). Auch da wäre es hilfreich ein paar mehr Suchmöglichkeiten zu haben: z.B.: suche mir alle Adressen aus Ort XYZ ("l", "postalCode") oder suche alle Mitarbeiter der Firma 0815 ("o"). Auch da wäre eine Modifikation des Adressbuchs nett. Um das immerhin hilfreiche LDapper ersetzen zu können. Aber vielmehr als zur Suche taugt es halt nicht.

    Ein weiteres Mysterium bliebe zu klären: der Haken in den LDAP-Einstellungen von Adressbuch und das einschlägige Apple-Marketing Gewäsch (das von allen immer gerne abgeschrieben wird - google ist voll davon, wenn man was zu "ldap auto update" sucht - nur getestet hat das offenbar keiner o_O) suggeriert ein automatisches Update von Visitenkarten, die vom LDAP-Server stammen und per Drag 'n Drop ins lokale Adressbuch übernommen werden. Meine praktische Erfahrung schaut da bisher ganz anders aus :oops:.

    Nach welchen Regeln (Zeitintervall, nächste Abfrage nach Aktualisierung, ...) erfolgt das Update? Ich habe an ein paar Testeinträgen Änderungen vorgenommen auf den LDAP-Server veröffentlich und dieser stellt diese auch bereit - nur von Automatik keine Spur. Ohne eine erneutes Drag 'n Drop verharrt die Visitenkarte auf dem zweiten Rechner bisher beim alten Stand der Daten :(.

    Gruß Stefan
     
    #13 stk, 20.02.06
    Zuletzt bearbeitet: 21.02.06

Diese Seite empfehlen