OpenLDAP
Autor: ThomasF
Also hier versuche ich jetzt mal eine Anleitung nach dem Motto "Quick and Dirty" zu erstellen.
Ich bin der Ansicht, das man am besten mehr über die Materie lernt wenn man sie auch praktisch anwendet.
Dies bedeutet aber, das man sich diesen LDAP Server am besten in einer Testumgebung aufsetzt, da hier am Anfang noch keine Absicherung der Verbindungen, ACLs usw. eingesetzt werden muss.
Inhaltsverzeichnis
Theorie
LDAP ist ein Verzeichnisdienst, eine Datenbank in der wir alle möglichen Daten speichern können.
Ein LDAP Verzeichnis ist für lesenden Zugriff optimiert, somit sollten sich die Daten nicht so häufig ändern müssen.
Typische Anwendungen sind z.B. ein Adressbuch oder auch die Benutzerauthentifizierung.
Die Struktur in einem LDAP Verzeichnis ist eine hierarchische Struktur, also eine Art Baum, der in einem Punkt beginnt (Wurzelverzeichnis) und sich von hier aus immer weiter verzweigt.
Ein Beispiel das hier zum Beispiel jeder kennen sollte, ist das Filesystem auf einer Festplatte, die Festplatte oder eine Partition auf dieser hat einen Mountpoint oder Laufwerksbuchstaben, dies stellt das Wurzelverzeichnis dar. Unterhalb der Wurzel können nun Dateien und Ordner existieren. In den Ordnern können nun wiederum Dateien und Ordner existieren und so weiter und so fort ....
Ein weiterer Vergleich ist zum Beispiel eine Internet Domain, denn bei einer Domain wird die vollständige Adresse von rechts nach links gebildet. Ganz rechts steht die Länderdomain, links davor der Domainname und noch davor dann der Zielrechner oder eine beliebige weitere Unterteilung.
Auch ein LDAP Verzeichnis baut sich so auf, es gibt Container-Objekte (Ordner) und es gibt Blattobjekte (Dateien), wobei Containerobjekte weitere Container-Objekte oder Blattobjekte enthalten können.
Das Ziel ist es nun die Struktur eines Unternehmens oder einfach eines Netzwerkes in dem LDAP Verzeichnis abzubilden und so eine sehr übersichtliche Form zu erhalten in der die Daten abgespeichert werden können.
Diese Daten können nun alles mögliche sein, angefangen von Adressen oder Telefonnummern bishin zu Passwörtern und sogar Binärdaten wie z.B Fotos.
Daten können jedoch nicht beliebig irgendwo hin gespeichert werden, sie müssen wie in jeder Datenbank mit einem Begriff verbunden sein der den Inhalt dieser Speicherstelle sozusagen beschreibt und auch eindeutig identifiziert.
Diese Beschreibung zusammen nennt man bei LDAP Attribut. Attribute müssen bevor man sie zur Speicherung verwenden kann erst einmal definiert werden. Bei der Definition werden mehrere Attribute die man später erfahrungsgemäß auch zusammen verwendet, in sogenannten Objektklassen zusammen gefasst. Die Objektklassen wiederum werden, je nach ihrem Einsatzzweck, auch wieder zusammen gefasst in sogenannten Schemen.
Sowohl Schemen, Objektklassen als auch Attribute haben in LDAP meist aussagekräftige Bezeichnungen, so das man im LDAP Verzeichnis schnell auf die gesuchten Daten zugreifen kann.
| Hinweis: |
|
Keine Bange vor den Abkürzungen und Fachausdrücken, wenn man erst ein wenig Übung im Umgang mit diesen entwickelt hat, benutzt man diese wie selbstverständlich. |
Beispiele für Containerobjekte :
c : Country o : Organization ou : Organizational Unit
Diese Container bauen aufeinander auf, will heißen das das County Objekt nur direkt unter dem Root-Verzeichnis vorkommen kann, aber nicht unterhalb von o oder ou.
In der Realität z. B. in einem Unternehmen bedeutet dies, das direkt unter dem Root-Container, dem Startpunkt des Verzeichnisses sich die Länder Objekte befinden, da ein großes internationales Unternehmen durchaus Firmen in verschiedenen Länder besitzen kann die in einem einzigen Verzeichnis verwaltet werden sollen. Es macht im Normalfall jedoch keinen Sinn zuerst das Verzeichnis in Organizations zu unterteilen und dann erst Firmenstandorte in verschieden Ländern zu organisieren.
Genauso sieht es mit den Organization Objekt aus, dieses kann nur unterhalb eines Country Objekts vorkommen, falls dieses nicht existiert unterhalb des Root-Objekts, aber niemals unterhalb eines ou Objekts.
Auch dies macht in der Praxis Sinn, da in einem Unternehmen ja durchaus mehrere Abteilungen existieren können (Organizational Unit / Verwaltungseinheit) aber unterhalb einer Abteilung liegt im Normalfall keine Organisation, da diese ja viel sinnvoller parallel zu den anderen Organizations angelegt werden kann.
Und schließlich das Organizational Unit Objekt das nur unterhalb eines Organization Objekts vorkommen kann aber beliebig viele weitere Organizational Unit Objekte enthalten kann.
Das Organzational Unit Objekt ist also nun das Container Objekt mit dem ein Unternehmen beliebig weiter verschachtelt werden kann
Beispiele für Blattobjekte :
cn : Common Name uid: UserID ...
Beispiele für Attribute:
userPassword homeDirectory loginShell telephoneNumber ...
Zu den Blatt Objekten soll vielleicht noch gesagt sein, das darunter auch wieder Organizational Units angelegt werden könnten , um z.B. Adressen von einem speziellen User verwalten zu können. Dies sollte aber vermieden werden, da dies schnell unübersichtlich werden kann und nicht dem Standard entspricht, auch wenn es praktisch funktioniert.
Mit diesem Wissen können wir nun anfangen unseren ersten Verzeichnisbaum zu planen.
Welche Objektklassen und Attribute es alles gibt ist zur Zeit noch nicht so wichtig, da man diese mit der Zeit und je nach Einsatzzweck des Verzeichnisses kennen lernen wird.
Planung
Die Planung will gut überdacht sein da dieser sich nachträglich nur ändern lässt indem man den ganzen Baum neu aufbaut, also je nach Größe des Verzeichnisses ist das sehr viel Arbeit.
Als erstes brauchen wir ein Root-Verzeichnis. Hierfür bietet sich der Name des Unternehmens an, Privatpersonen oder Betreiber kleiner SOHO Netze können aber praktisch den Namen frei wählen.
Ich wähle hier jetzt die allgemeine Form meineFirma und gehe davon aus das wir hier in Deutschland bleiben.
| Hinweis: |
|
Anstatt o=meineFirma,c=de sollte jeder für sich eine entsprechende Bezeichnung für das Root-Objekt wählen und dann bei dieser auch bleiben ! Jeder spätere Eintrag im Verzeichnis endet immer mit diesem Root-Objekt. Selbst die kleinste Abweichung in der Schreibweise wird dann einen Fehler erzeugen, der schwer zu finden ist! |
Das obige Beispiel mit der Festplatte ist hier nicht ganz passend da die Wurzel ja immer ganz links steht. In diesem Fall ist der gesamte Ausdruck "o=meineFirma ,c=de" die Wurzel (basedn)
Besser passt in diesem Fall der Vergleich mit einer Internet-Domain. Wenn man eine Domain registriert die z.B. meineFirma.de heißt, kann man in dieser Domain sozusagen machen was man will, solange die richtige Domain am Ende steht. Würde man hier einen Schreibfehler machen wäre das so, als wolle man auf die Domain von jemand anderen zugreifen um dort etwas zu verändern.
Gut, also das Root-Objekt hat also in unserem Beispiel die Form :
dn: o=meineFirma, c=de
Wenn man schon andere Doku gelesen hat findet man evtl. auch die Form : dc=meineFirma,dc=de
dc steht für Domain Component und will damit aussagen das diese Firma auch eine Domain mit diesem Namen besitzt. Wenn jemand jedoch plant seine DNS oder DHCP Einträge für sein Netz auch in LDAP zu speichern ist unter Umständen die Schreibweise mit dc zu verwenden.
Diese Einsatzmöglichkeit ist für uns hier noch uninteressant und selbst wenn es auch mit dc geht, ist es meiner Meinung nach übersichtlicher mit den Attributen c, o, ou usw. zu arbeiten. Zumal auch ohne Verwendung von "dc" der Aufbau eines DNS über LDAP möglich ist.
Der nächste Schritt ist zu überlegen welche Daten gespeichert werden sollen. Die meisten Linux-User werden wie zu Anfang erwähnt, LDAP zur Benutzerauthentifizierung nutzen wollen. Und in diesem Zusammenhang wahrscheinlich sowohl Linux- und Samba-User.
Um die Übersicht zu bewahren, speichert man deshalb nach dem Motto "Gleich und gleich gesellt sich gerne".
Die erste Frage lautet also kann man die User in verschiedene Gruppen teilen die Organisatorisch zusammen gehören ?
Ein Beispiel hierfür wäre die Unterteilung in Einkauf, Verkauf und Versand. Dieser Schritt macht in den meisten Fällen jedoch nur ab einer bestimmen Unternehmensgröße Sinn, sodass wir hier diesen Fall nicht berücksichtigen.
Die nächste Unterteilung könnte dann sinnvollerweise in Users, Groups und Workstations gemacht werden.
Hierfür würden wir drei ou Containerobjekte anlegen in denen dann später die jeweiligen Daten gespeichert werden :
ou = Users ou = Groups ou = Workstations
Aufsetzen eines Openldap-Servers
Wenn alle benötigten Pakete installiert sind (openldap2 und openldap2-Client und alle abhängigen) kann man sich an die Arbeit machen das gelernte in die Tat umzusetzen.
Die Konfigurationsdatei für den Server ist die /etc/openldap/slapd.conf , die bei der Installation schon einige Einträge und Kommentare enthält.
Alle Möglichkeiten kann man in der Manpage von slapd.conf nachlesen.
Da nur root im Normalfall Schreibrechte auf Konfigurationsdateien hat sollte man zum bearbeiten dann auch root-Rechte besitzen.
Zum Bearbeiten der Konfigurationsdateien selbst kann man unter Linux jeden beliebigen Editor verwenden, bzw. den der einem persönlich am besten gefällt, auf der Konsole z.B vim, joe ... und unter KDE kate, kwrite usw.
Wir öffnen nun die /etc/openldap/slapd.conf mit einem beliebigen Editor z.B auf einer root-Konsole und schauen uns ein wenig um.
| Wichtig: |
|
Um das LDAP Verzeichnis später gegen Missbrauch oder ähnlichem abzusichern gibt es in openldap z.B die Möglichkeit den Zugriff auf das Verzeichnis mit ACL' s einzuschränken (access ...) |
Diese Funktionen sind für die grundsätzliche Funktion nicht notwendig !!! Dort verstecken sich einfach nur weitere Fehlerquellen die gerade zu Anfang einen Neuling in Sachen LDAP nur verwirren.
Also sollten wir grundsätzlich erstmal nur Optionen aktivieren die für den Betrieb unbedingt notwendig sind, unser Server wird ja noch nicht produktiv eingesetzt.
Als erstes müssen wir uns nun um die eingebundenen Schemas kümmern. In den Schema Dateien finden wir die Definitionen der Objektklassen und der Attribute die wir brauchen um später überhaupt Daten speichern zu können.
| Wichtig: |
|
Hier ist darauf zu achten die richtige Reihenfolge für die Schema Dateien einzuhalten, da es vorkommen kann das ein Schema ein Attribut hinzufügen will, das eine bestimme ObjectClass erwartet, die aber nicht im gleichen Schema definiert ist. Dieses Schema muß also vorher schon eingebunden worden sein. |
Für unseren Zweck brauchen wir also erstmal die folgenden Schema-Dateien :
core.schema cosine.schema nis.schema inetorgperson.schema samba.schema (oder samba3.schema) misc.schema
Ein Beispiel für die slapd.conf wäre nun:
include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/samba.schema include /etc/openldap/schema/misc.schema
| Hinweis: |
|
Die hier aufgeführten Schema Dateien z.B samba.schema nehmen das Thema Anbindung von Samba an LDAP schon ein wenig vorweg. Wer aber Samba noch nicht installiert haben sollte, kann auch vorerst das samba.schema raus lassen, da sich diese Datei im samba-doc Paket befindet und auch zu einem späteren Zeitpunkt eingebunden werden kann. |
Eine ausführlicher Abhandlung über die Schema Dateien können wir uns auch für später aufheben wenn wir uns schon ein wenig mit den Funktionen von Openldap beschäftigt haben.
Die nächste Stelle an der wir eingreifen müssen ist der Eintrag "suffix" Suffix stellt das Root-Verzeichnis dar bei dem unser LDAP Sever beginnen soll sein Verzeichnis aufzubauen. Nach unserer Vorüberlegung weiter oben soll dies für unseren Fall also :
suffix "o=meineFirma, c=de"
sein. Dies wird auch der Punkt sein den wir später unserem LDAP-Client mitteilen müssen damit er das LDAP Verzeichnis finden kann.
Als nächstes müssen wir einen Benutzer anlegen der in jeder Situation alle Rechte auf dieses Verzeichnis besitzt also immer schreibend auf unser Verzeichnis zugreifen kann. Dies passiert bei dem Punkt "rootdn"
Bitte beachten : Dieser User mit der rootdn hat wirklich "immer" alle Rechte im Verzeichnis, selbst mit ACLs kann man dies nicht beeinflussen. Selbst wenn man später einen gleich lautenden Eintrag im Verzeichnis erstellt und dort ein anderes Passwort setzt bleibt das rootpw immer noch gültig. Das macht auch Sinn da man zu Anfang ja auch erstmal Daten in das Verzeichniss bekommen muß.
Wir wählen also hier eine Kurzform die später nicht so viel Tiparbeit erfordert :
rootdn "cn=admin, o=meineFirma, c=de"
Es folgt nun das rootpw, dies ist das Passwort des Users das wir mit dem Eintrag rootdn festgelegt haben.
Rein theoretisch könnten wir hier auch ein Klartextpasswort einsetzten doch so etwas sollte man gar nicht erst anfangen.
Um nun ein verschlüsseltes Passwort zu erstellen, bedienen wir uns am einfachsten slappasswd
Die Syntax ist recht einfach, hier ein Beispiel, das man auf der Konsole eingibt.
slappasswd >> passwort.txt
Der Inhalt dieser Datei, passwort.txt enthält nach der zweimaligen Eingabe des passworters auf der Console nun z.B für das Passwort "test" folgendes :
{SSHA}w31rbfsjdOHw/2SJFGnQyVrcE5MKOS1C
| Hinweis: |
|
Das ... >> ... leitet die Ausgabe des Komandos slappasswd in die Datei passwort.txt um die vorher nicht existieren muß. Dieser doppelte Pfeil hängt die Daten hinten an die Datei an und belässt die Datei ansonsten so wie sie vorher war. |
Vergisst man aber einen Pfeil ( ... > ... ) dann wird die Datei, wenn sie vorhanden ist vollständig gelehrt bzw. gelöscht und dann neu angelegt !!! Das heißt, es ist auch möglich die Ausgabe von slappasswd direkt in die slapd.conf umzuleiten. Bevor man diesen Befehl jedoch eingibt sollte man erst eine Sicherhietskopie der slapd.conf anlegen und dreimal hinschauen das man auch wirklich ...>> ...dort stehen hat !!!
Und egal ob wir das Passwort auf der Konsole kodiert haben oder die Ausgabe in eine Datei oder direkt in die /etc/openldap/slapd.conf umgeleitet haben ,mit dem Vorsatz rootpw und dem erzeugten Hash dahinter sollte diese Zeile :
rootpw {SSHA}w31rbfsjdOHw/2SJFGnQyVrcE5MKOS1C
nun in unserer /etc/openldap/slapd.conf stehen und haben damit nun eine grundsätzlich funktionierende Konfiguration erzeugt und können die Datei nun abspeichern und den LDAP Server starten.
rcldap start
Eventuell muß man nun noch einen Schreibfehler korrigieren aber wenn der Server läuft können wir beginnen das Verzeichnis mit Daten zu füllen.
Die slapd.conf erlaubt es uns allerdings noch eine ganze Reihe von Feintunning vorzunehmen (siehe -> man slapd.conf )
Also finalen Test ob LDAP läuft überprüft man erstens mit rcldap status ... dort sollte ein grünes "running" auftauchen.
Auch kann man mit :
nmap localhost
testen ob der Port 389 in Benutzung ist.
Wenn man auf dem Rechner auf dem der Server läuft auch schon den Client eingerichtet hat (siehe unten -> Einrichten eines LDAP Client ) kann man auch mit ldapsearch -x die Verbindung mit dem LDAP Server testen.
Wenn der Server nach den ersten beiden Punkten den Anschein macht zu laufen aber die Verbindung mit ldapsearch nicht klappt, sollte man erstens nachschauen ob die SuSEfirewall2 läuft und diese im Zweifel erst mal abschalten. Hilft dies auch nicht sind die Einträge in der ldap.conf wohl falsch gesetzt (siehe unten -> Einrichten eines LDAP Client )
Um diese Einstellungen erst einmal zu übergehen kann man ldapsearch ertsmal alle notwendigen Parameter mit auf den Weg geben:
ldapsearch -x -h localhost -b o=meineFirma,c=de
... bzw.
ldapsearch -x -h localhost -D cn=admin,o=meineFirma,c=de -W
Bevor man weitergeht sollten zumindest die beiden ersten Test positiv laufen.
Linux Authentifikation
Um den LDAP-Tree nun mit Daten zu füttern können wir entweder ein Grafisches Frontend benutzen (z.B GQ ) oder wir erstellen eine Datei im ldif Format ( man ldif ) um die Daten z.B. mit dem Befehl ldapadd auf der Konsole in das Verzeichnis zu laden.
Die beliebteste Variante ist es zurzeit, LDAP dazu zu benutzen, User sich an der LDAP Datenbank anmelden zu lassen, und dies sowohl für die Linux User als auch Windows User über Samba.
Wir beginnen mit der Anmeldung an einem Linux System. Hierzu schauen wir uns als erstes an welche Informationen Linux braucht um einen User zu authentifizieren.
Auf einem System ohne LDAP werden diese Informationen in normalen Dateien gespeichert und zwar in der /etc/passwd und der /etc/shadow sowie die Gruppeninformationen aus der
/etc/group.
Schauen wir uns so einen Eintrag in der passwd am Beispiel von root einmal an:
root:x:0:0:root:/root:/bin/bash
Wir haben hier den Usernamen(root), uid(0), gid(0), Homedirectory(/root) und die LoginShell (/bin/bash). Das x hinter dem Usernamen bedeutet das das Passwort in der /etc/shadow zu finden ist. Aus der shadow brauchen wir dann auch nur das Passwort.
Um nun alle diese Informationen in der LDAP Datenbank speichern zu können müssen bestimmte Attribute dort vorhanden sein. Hierfür benötigen wir die Objektklasse "posixaccount" welche im nis.schema definiert ist.
Bevor wir also weiter machen kontrollieren wir in der /etc/openldap/slapd.conf die eingetragenen Schemas, dies sollte dann so aussehen :
include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/samba.schema include /etc/openldap/schema/misc.schema
Hinweis Das samba.schema sollte auch wirklich von der aktuell verwendeten Samba Version stammen, sonst kann es zu merkwürdigen Problemen kommen. Die findet man auf SuSE Systemen unter :
/usr/share/doc/packages/samba/examples/LDAP/samba.schema
Und sollte dann nach /etc/openldap/schema kopiert werden.
Damit wären erst einmal die Grundvoraussetzung erfüllt ...
| Hinweis: |
|
Da es jede Menge Anleitungen gibt wie man mittels der LDIF Dateien sein Verzeichnis befüllen kann, spare ich mir dies hier und zeige das man auch ohne diese Dateien auskommt. Dennoch sollte sich jeder der sich mit diesem Thema beschäftigt auch die Variante mittels LDIF beherrschen da nicht immer eine grafische Oberfläche zur Verfügung steht. |
Wir bedienen uns z.B. des Programms GQ ( http://gq-project.org/ ) welches geraume Zeit SuSE als RPM beiliegt.
Im "Browse" Reiter sollte man seinen Server sehen, und darunter wenn man diesen anklickt auch die dazu gehörende basedn (also den Eintrag der als suffix in der slapd.conf steht) sehen können.
Der nächste Schritt ist das Anlegen von Templates, dies geschieht wieder unter Einstellungen, diesmal unter dem Reiter "Muster" Dort suchen wir für den Fall das man mehrere Server angegeben hat den Server aus für den wir die Templates erstellen möchten und klicken dann auf "Neu".
In dem Fenster das sich nun öffnet können wir auf der linken Seite die benötigten Objektklassen auswählen und mit dem kleinen schwarzen Pfeil nach rechts, in den Bereich der aktuellen Vorlage bringen. Unten links müssen wir dann noch einen aussagekräftigen Namen für das Template erstellen und fertig.
Um nun alle erforderlichen Einträge in unserem Verzeichnis erstellen zu können brauchen wir mehrere Templates:
o (Organization) ou (Organizational Unit) posixAccount (Userdaten für Linux User) posixGroup (Gruppeninformationen für Linux)
Bei jedem Template muß als erstes immer die ObjectClass top vorhanden sein. Für o oder ou brauchen wir ansonsten nur die Objektklassen organization bzw. organizational Unit. Für den User Account benötigen wir neben dem posixAccount noch die ObjectClass shadowAccount und inetOrgPerson. Das Template posixGroup benötigt wiederum nur die ObjectClass posixGroup.
Mit diesen vier Templates können wir nun beginnen unserem LDAP-Baum eine Struktur zu geben.
Hierzu begeben wir uns wieder in die Browse Ansicht und markieren den dort sichtbaren Eintrag der basedn und wählen mit dem Menü das durch klicken der rechten Maustaste auftaucht den Punkt "New" aus. Dort sieht man dann die Templates die schon erstellt wurden. Für diesen ersten Eintrag wählen wir nun die Organization aus die ja in unserem Fall mit der rootdn übereinstimmt.
In dem folgenden Fenster das sich für den neuen Eintrag öffnet sieht man nun eine Liste mit allen möglichen Attributen die in der im Template festgelegten Objektklassen. In neueren Versionen von GQ , wie die die SuSE mitliefert, werden die Attribute die zwingend notwendig sind blau angezeigt.
In diesem Fall ist das außer dem Eintrag dn noch das Attribut o. Da wir uns im ersten Teil des Quick Start mit o=meineFirma,c=de umschrieben haben nehmen wir hier das gleiche Beispiel.
Da wir hier die basedn als Ziel beim einfügen ausgewählt haben stimmt die dn schon fast, das Komma das GQ vor der basedn erzeugt müssen wir in diesem Fall entfernen. In der Zeile von o können wir nun nochmals meineFirma einfügen, fertig.
Weitere Attribute die nicht blau markiert sind können optional ausgefüllt werden, dienen aber keinem Zweck bei der Authentifizierung.
Als nächstes erstellen wir mindestens zwei "Ordner" (organizationalUnits) auf die gleiche Weise, nur diesmal jeweils mit dem Template für ou und nennen diese dann einmal "users" und einmal "groups"
Nach diesem Prinzip können später dann auch andere "Ordner" z.B für Samba MaschinenAccounts erstellt werden.
Bevor wir nun anfangen User oder Gruppen anzulegen sollten wir einen kurzen Moment überlegen in welchem Bereich die UserIDs und GruppenIDs liegen sollen ....
Für dieses Beispiel nehme ich für die userIDs den Bereich zwischen 1000 - 1499 und für die groupIDs den Bereich zwischen 1500 - 1999.
Beginnen wir mit einer Gruppe: Wir markieren den Ordner "groups" und erstellen aus dem Template posixGroup einen neuen Eintrag der dann ungefähr so aussieht:
dn: cn=user,ou=groups,o=meineFirma,c=de cn: user gidNumber: 1500
Ähnlich sieht es bei dem Anlegen eines Users aus:
dn: uid=test, ou=users, o=meineFirma, c=de
sn: test
cn: test
uidNumber: 1000
gidNumber: 1500
loginShell: /bin/bash
homeDirectory: /home/test
userPassword: {SSHA}xyz1234567abc
Das Passwort kann GQ erzeugen, jedoch mit dem Nachteil das es erst einmal im Klartext zu lesen ist (der algorytmus kann im Pulldown Menü eingestellt werden)
Beim Speichern wird das Passwort dann gecrypted.
Um dies im Zweifel nicht zu einem Risiko zu machen könnte man hier erst einmal ein Dummy-Passwort eintragen (z.B test) und dieses dann später auf der Konsole mit "passwd test" zu ändern.
Da nun sowohl der User als auch seine primäre Gruppe in LDAP existiert kann sich dieser nun über LDAP authentifizieren ...
Will man einen bestehenden Userstamm aus NIS oder der /etc/passwd einfach nur in LDAP übernehmen gibt es die Möglichkeit diese Arbeit von Migrations-Tools ausführen zu lassen. Siehe z.B :
Einrichten eines LDAP Client
siehe: LDAP-Client
LDAP und SAMBA
siehe: Samba mit LDAP
