WIE?: Netzwerkweite User-Daten-Verwaltung auf einem zentralen Server (z.B. Radius)

quarzsnoopy

[Free|Net]BSD - User
Hi Leute!
Wie der Titel schon sagt suche ich eine Lösung mit der ich in idealer Weise folgendes erreichen kann:
- alle irgendwo benötigten User-Daten in einer Datenbank (möglichst PostgreSQL) verwalten;
- es sollen sich nicht nur die User der einzelnen Clienets (die ja schon durch DHCP auf den zentr. Server angewiesen sind) über den zentr. Server Auth. sondern auch die Software wie z.B. die .htaccess-Apache-Anmeldungen (für Apache gibt es ja ein Radiusmodul);
- es soll möglichst vielseitig sein, so das ich damit auch später evtl. noch irgendwelche "blöden" Ideen verwirklichen kann;
- es muss sicher sein!!! Denn ich werde es später auch im bösen weiten Internet einsetzen (Kerberos hat da ja so einige Schwächen);

Was mir da so einfällt, sind folgende mögliche Ansätze:
- NIS
- Radius
- Kerberos
- LDAP

Allerdings habe ich keine Erfahrungen mit den genannten Software-Produkten, kann also nicht sagen: "Für mich ist die am schnellsten realisiert, weil ich die schon kenne..."


Was ich wohl gehört habe ist, das LDAP wohl auf Unix/Linux/Windows funktioniert und das es für viele gleichzeitige Verbindungen nicht geeignet ist, da ist Radius besser. NIS ist irgendwie mal von SUN entwickelt worden und auf Unix zu Hause... und Kerberos muss wegen der Sicherheit immer aktuell gehalten werden.
Mehr weiss ich davon nicht, ich würde also hiernach zwischen Radius und LDAP schwanken.
Nur sind diese Info's sehr dürftig und so frage ich Euch!
Was würdet Ihr für eine solche Aufgabe nehmen und warum?
 
Last edited:
Moin,

LDAP ist schon sehr vielseitig und lässt sich auch weitgehend konfigurieren. Das LDAP nicht für viele Verbindungen taugen soll, ist mir neu. LDAP ist aber auf das Lesen der DB getrimmt, schreiben geht langsamer. Die Auswahl der Indizes ist wichtig, damit die Suche schnell geht.

Was ich an LDAP praktisch finde, ist , dass man auch andere Konfigurationen darin Ablegen kann, wie z.B. für Sendmail. Einge daemons die eine LDAP-Schnittstelle haben sind, natürlich sendmail, dann samba, cyrus, jabber2d, apache2, das PAM-Gedöns usw.
LDAP hat auch eine funktionierende Replikation der DB und bei sehr großen Verzeichnissen können Zweige auf mehrere Maschinen verteilt werden. Das ganze sieht trotzdem wie ein Directory aus. Single-SignOn ist damit so nicht möglich. LDAP kann aber mit Kerberos kombiniert werden. Was viel anderes ist das AD von MS ja auch nicht, mal abgesehen davon, das MS typischerweise ein paar 'Änderungen' eingebaut hat.

Außer das mit Kerberos Single-SignOn möglich ist und wie es prinzipiell funktioniert, weiß nicht viel darüber. Radius ebenso, ich weiß wo es benutzt wird.

Ist NIS noch uptodate? LDAP und/oder Kerberos sind da auf jedenfall flexibler.

Noch eine Bemerkung, nicht nur zu Kerberos.
Wir halten doch alle unsere Software auf dem aktuellen Stand. Oder etwa nicht? :p

Gruß c.
 
crotchmaster said:
Moin,

LDAP ist schon sehr vielseitig und lässt sich auch weitgehend konfigurieren. Das LDAP nicht für viele Verbindungen taugen soll, ist mir neu. LDAP ist aber auf das Lesen der DB getrimmt, schreiben geht langsamer. Die Auswahl der Indizes ist wichtig, damit die Suche schnell geht.
Ja, in dem Bericht, in dem das kurz angesprochen wurde, haben die das so begründet:
Die LDAP-Datenbank besteht (wie Du ja hier auch schon gesagt hast) aus einer Verzeichnisstruktur mit vielen kleinen Dateien.
Wenn sich jetzt 100000 Leute gleichzeitig anmelden, müssen in kürzester Zeit 100000 Dateien geöfnet+gelesen werden. Das sind relativ langsamme Dateisystem-Zugriffe. Deshalb soll für derartige Zwecke Radius besser sein.
Die Stärke von LDAP soll die flexibilität sein, wie Du ja auch erwähnt hast.


crotchmaster said:
Was ich an LDAP praktisch finde, ist , dass man auch andere Konfigurationen darin Ablegen kann, wie z.B. für Sendmail. Einge daemons die eine LDAP-Schnittstelle haben sind, natürlich sendmail, dann samba, cyrus, jabber2d, apache2, das PAM-Gedöns usw.
LDAP hat auch eine funktionierende Replikation der DB und bei sehr großen Verzeichnissen können Zweige auf mehrere Maschinen verteilt werden. Das ganze sieht trotzdem wie ein Directory aus. Single-SignOn ist damit so nicht möglich. LDAP kann aber mit Kerberos kombiniert werden. Was viel anderes ist das AD von MS ja auch nicht, mal abgesehen davon, das MS typischerweise ein paar 'Änderungen' eingebaut hat.
Ja, das man auch Konfigurationen darin speichern kann ist natürlich klasse!


crotchmaster said:
Außer das mit Kerberos Single-SignOn möglich ist und wie es prinzipiell funktioniert, weiß nicht viel darüber. Radius ebenso, ich weiß wo es benutzt wird.

Ist NIS noch uptodate? LDAP und/oder Kerberos sind da auf jedenfall flexibler.

Noch eine Bemerkung, nicht nur zu Kerberos.
Wir halten doch alle unsere Software auf dem aktuellen Stand. Oder etwa nicht? :p

Gruß c.
Was macht denn eigentlich Kerberos dabei? Wozu ist denn das noch da?
Kerberos kann doch das gleiche wie Radius, nur stärker verschlüsselt (mit anderer Verschlüsselung), denke ich...?
Aber das kann doch LDAP auch, oder kann LDAP keine Verschlüsselung?
Wozu kombiniert man die beiden?

Ich hab gelesen, das man Radius auch mit SSH kombiniert. Ist Radius nicht schon von Hause aus verschlüsselt?
 
quarzsnoopy said:
Ja, in dem Bericht, in dem das kurz angesprochen wurde, haben die das so begründet:
Die LDAP-Datenbank besteht (wie Du ja hier auch schon gesagt hast) aus einer Verzeichnisstruktur mit vielen kleinen Dateien.
Wenn sich jetzt 100000 Leute gleichzeitig anmelden, müssen in kürzester Zeit 100000 Dateien geöfnet+gelesen werden. Das sind relativ langsamme Dateisystem-Zugriffe.
Das stimmt so nicht. Ich will nicht meine Hand dafür ins Feuer legen, aber die LDAP Server die ich betreibe, alles OpenLDAP unter Net- u. FreeBSD, die setzen eine Berkeley DB voraus, in Version 3.x bzw. 4.x, je nach der OpenLDAP Version. Ich habe sie immer aus den Ports installiert.
Ah, jetzt geht mir noch ein Licht auf. Du darfst das LDAP-Verzeichnis nicht mit einem Verz. im Filesystem verwechseln, gleichsetzen oder wie auch immer. Das LDAP-Verz. hat eine Baumstruktur, ähnlich einem Unix-FS. Die Daten liegen aber nicht in der im LDAP-Verz. hinterlegten Struktur in einem FS, sondern in der Berkeley DB. Wenn man so einen Server aufsetzt, dann sieht man auch mehrere DB-Files und zusätzlich ein DB-File für jeden erstellten Index.

Ich möchte die Installation sehen, die 100000 User gleichzeitig bedient. In einer der letzten IX, ich glaube das war die 11/2005, hat jemand einen Artikel über die Migration des Bundestags-Netzwerks von Windows zu Linux geschrieben, die Probleme die es beim ersten Anlauf gab und wie diese gelöst wurden.
Da war weniger OpenLDAP das Problem. 100000 User hätte man sicher nicht an einem Standort, sondern auf mehrere verteilt. Also müssen es sowieso mehrere LDAP-Server sein, zw. denen eine Replikation läuft.
Und durch die Struktur des Baumes kannst du das auch beinflussen. 100000 User legst du ja nicht auf einer Ebene an, sondern da gibt Kontinente, Länder, Standorte, Zweigstellen, Abteilungen, Arbeitsgruppen usw. Wenn du da geschickt die LDAP-Server plazierst, das referal einrichtest und die Suchanfragen auf den Clients richtig konfigurierst, dann muss nicht der ganze Baum von der Wurzel an abgeklappert werden, weil sich Hans Wurst der 1-Mann Dependance in Kleinkleckersdorf anmeldet.

Ja, das man auch Konfigurationen darin speichern kann ist natürlich klasse!
Ich habe gerade gesehen, das es auch für den Apachen 2 ein Modul gibt, mit dem man die Konfigurationen für virtuelle Hosts in einem LDAP-Directory ablegen kann. Freu.

Was macht denn eigentlich Kerberos dabei? Wozu ist denn das noch da?
Kerberos kann doch das gleiche wie Radius, nur stärker verschlüsselt (mit anderer Verschlüsselung), denke ich...?
Aber das kann doch LDAP auch, oder kann LDAP keine Verschlüsselung?
Bei LDAP ist es ja so: Wenn ein Dienst eine User/Passwort-Kombination haben will, dann gibst du diese ein, und der Dienst schaut im LDAP nach, ob das so korrekt ist. Diese Verbindung kann natürlich SSL/TLS-verschlüsselt sein. Du hast also eine zentrale Stelle, wo alle Dienste nachsehen können.
Kerberos können andere besser erklären, z.B. http://www.dfn-cert.de/infoserv/dib/dib-2002-02-Kerberos5/doc.html

Bei Radius empfehle ich dir, danach zu googlen. Wie gesagt, ich weiß nicht viel darüber und bevor ich was falsches erzählen, verweise ich auf Google.

Gruß c.
 
Last edited:
Also egal wie, aber LDAP ist schon interessant! Nicht nur wegen der Flexibilität sondern auch wegen der allgemeinen Akzeptanz und Verbreitung.

Wie kann man die Daten vom LDAP-Server denn sichern? BDB ist ja ohne dieses User-Interface (z.B. SQL-Schnittstelle) ausgestattet? wie sieht das mit nem Update aus?

Für Radius gibt es für NetBSD eine Version, die mit PostgreSQL arbeitet. Das gefällt mir!
 
quarzsnoopy said:
Wie kann man die Daten vom LDAP-Server denn sichern? BDB ist ja ohne dieses User-Interface (z.B. SQL-Schnittstelle) ausgestattet? wie sieht das mit nem Update aus?
Es reicht, die DB files im data-Verzeichnis zu sichern, bei NetBSD ist das /var/openldap/openldap-data.

So kannst du auch die Daten auf einen zweiten LDAP-Server rüberkopieren, bevor du die Replikation in Betrieb nimmst. Alle Server stoppen, das Verzeichnis rüberkopieren, dann slaves und anschließend den master starten. Bedingung für diesen 'kurzen' Weg ist aber, das auf den Servern die gleiche Berkeley DB installiert ist. Bei der Version 3.x weiß ich es nicht genau, aber bei der Version 4.x musst du auch auf die korrekte minor-Version achten, das weiß ich aus eigener, bitterer Erfahrung. ;'( Der cyrus imapd verwendet ebenfalls Berkeley DBs.
Hast du unterschiedliche BDBs, kannst du mit slapcat (slapd auf master muss stehen) den Inhalt in ein LDIF-File exportieren und mit ldapadd auf dem slave importieren, dabei muss der slapd auf dem slave laufen. Oder du verwendest die Kommandozeilentools der BDB, bei NetBSD heißen die dbX_dump, dbX_restore usw., wobei X für die major-Version der BDB steht.
 
Danke für Deine Ausführlichen Info's! ;)

So, jetzt muss nur noch einer seine Radius- und Kerberos-Erfahrungen äussern.

Wie sieht das eigentlich mit der Systemanmeldung aus? Wie kann man ein NetBSD (und/oder Linux) an einen LDAP-Server ankorken, so das man nur noch root auf der Kiste hat und alle anderen liegen auf dem LDAP-Server?
Wird das über PAM gemacht oder andern und welche Config-Dateien sind zu bearbeiten?
 
quarzsnoopy said:
Wie sieht das eigentlich mit der Systemanmeldung aus? Wie kann man ein NetBSD (und/oder Linux) an einen LDAP-Server ankorken, so das man nur noch root auf der Kiste hat und alle anderen liegen auf dem LDAP-Server?
Wird das über PAM gemacht oder andern und welche Config-Dateien sind zu bearbeiten?
Da lautet das Stichwort PAM. Das soll ja bei NetBSD 3 sein, wenn ich mich nicht irre.
PAM mit LDAP verwende ich deshalb bisher nur bei FreeBSD 5 und Solaris >=7.

Gruß c.
 
crotchmaster said:
Da lautet das Stichwort PAM. Das soll ja bei NetBSD 3 sein, wenn ich mich nicht irre.
PAM mit LDAP verwende ich deshalb bisher nur bei FreeBSD 5 und Solaris >=7.

Gruß c.
Das habe ich auch schon von einem Kolegen gehört, kannst Du mir freundlicherweise auch noch sagen welche Conf-Datei das managed oder wo eine Anleitung dazu zu finden ist?
Danke! :D
 
Last edited:
quarzsnoopy said:
Das habe ich auch schon von einem Kolegen gehört, kannst Du mir freundlicherweise auch noch sagen welche Conf-Datei das managed oder wo eine Anleitung dazu zu finden ist?
Danke! :D
Ich bin so freundlich. :cool:

Aus den Ports nss_ldap und pam_ldap installieren, dann die Datei /etc/pam.d/login bearbeiten:
Code:
# PAM configuration for the "login" service
#

# auth
auth            required        pam_nologin.so          no_warn
auth            sufficient      /usr/local/lib/pam_ldap.so      no_warn use_first_pass
auth            sufficient      pam_self.so             no_warn
auth            include         system

# account
account         requisite       pam_securetty.so
account         include         system

# session
session         include         system

# password
password        include         system

anschließend /etc/nsswitch.conf
Code:
group: files ldap
hosts: files dns
networks: files
passwd: files ldap
shells: files ldap

und natürlich nicht die Datei /usr/(local|pkg)/etc/openldap/ldap.conf vergessen, also BASE und URI an deine Konfiguration anpassen.

Gruß c.
 
Vielen Dank!
Sobald ich meinen Infrastruktur wieder ordnungsgemäss am laufen habe (durch plötzliches Plattensterben ist noch alles recht chaotisch), werd ich das machen.

Ich setze jetzt nur noch 24/7-Platten im RAID ein, muss aber errstmal alles neu aufgesetzt werden....
;-)
 
Hallo zusammen,

ich hab mich auch daran versucht, pam_ldap in Zusammenarbeit mit NetBSD (3.0) zum laufen zu bringen.

Die Crux: Anleitungen für NetBSD im speziellen sind sehr dünne gesäht und ich finde den Fehler nicht ;)

Ich bin nunmehr soweit, dass der Login geht, wenn der User lokal existiert.
(nur der User selbst in der /etc/passwd, das Passwort wird schön aus dem LDAP gezogen)

Existiert der User nicht lokal, so bekomme ich den berüchtigten "bind to LDAP-Server failed, invalid credentials"-Fehler.

Für FreeBSD bestand bei irgendwem die Lösung darin, einen Link von /usr/local/etc/openldap/ldap.conf nach /etc/ldap.conf zu legen.

Wäre Jemand so nett, nochmal für Dummies zu erklären, was man en Detail auf dem NetBSD anstellen muss?


Dankeee..... :)

Ich habe:
  • pam_ldap installiert
  • nss_ldap installiert
  • /etc/pam.d/{system,sshd} mit pam_ldap Eintrag versehen. (sufficient)
  • /etc/nsswitch.conf um NIS reduziert und ldap hinzugefügt
  • ldap.conf mit search base und uri versehen

Irgendwas, was ich übersehen habe?
Symbolic Links?
Obskure Optionen, die nur NetBSD verlangt?
 
Back
Top