Hallo, Leute!
Ich habe einen Server mit Ubuntu Lucid und Samba installiert. Nun habe ich einigen Nutzer auf dem Server, die Samba nutzen sollen.
Leider jetzt muß ich immer mit tdbedit die Nutzer in Samba importieren (und die Leute müssen immer zu mir kommen und ihr Passwort eintippen).
Gibt es keine Möglichkeit, Samba zu überreden, die Systemnutzer zu nutzen, also kein extra DB?
Danke Luca Bertoncello (lucabert@lucabert.de)
Luca Bertoncello lucabert@lucabert.de (Fr 10 Sep 2010 07:23:34 CEST):
Hallo, Leute!
Ich habe einen Server mit Ubuntu Lucid und Samba installiert. Nun habe ich einigen Nutzer auf dem Server, die Samba nutzen sollen.
Leider jetzt muß ich immer mit tdbedit die Nutzer in Samba importieren (und die Leute müssen immer zu mir kommen und ihr Passwort eintippen).
Gibt es keine Möglichkeit, Samba zu überreden, die Systemnutzer zu nutzen, also kein extra DB?
Nein. Meines Wissens geht das nicht. Du könntest LDAP nehmen, aber auch dort gibt es dann ein Passwort und ein SMB-Passwort-Hash. SMB schickt die Passworte als Hash durch die Leitung, somit gehen die gängigen Verfahren (z.B. Authentifizierung gegen einen LDAP) nicht. Du wirst also immer zwei Passwort-DBs brauchen, die Du bestenfalls syncron halten könntest („unix password sync“ im Samba, und vielleicht gibt es ein pam-Modul, das auch das SMB-Passwort setzen könnte, wenn jemand „passwd” aufruft).
Am Freitag 10 September 2010, 10:14:41 schrieb Heiko Schlittermann:
Gibt es keine Möglichkeit, Samba zu überreden, die Systemnutzer zu nutzen, also kein extra DB?
Nein. Meines Wissens geht das nicht.
Geht doch.
Du könntest LDAP nehmen, aber auch dort gibt es dann ein Passwort und ein SMB-Passwort-Hash.
Soweit korrekt. LDAP sollte man spätestens in gemischten Umgebungen auf dem Samba-PDC immer als Backend haben.
unix password sync
Diese Option in smb.conf sorgt dafür, daß, wenn mit smbpasswd oder mit Windows-Bordmitteln das Samba-Passwort geändert wird, dieses auch gleich für PAM-Gebrauch mit gehasht wird (==> LDAP-Attribut "userPassword").
SMB schickt die Passworte als Hash durch die Leitung, somit gehen die gängigen Verfahren (z.B. Authentifizierung gegen einen LDAP) nicht.
Bei Passwortänderungen wird das neue Passwort auf verschlüsseltem Weg dem Domaincontroller zum Hashen übergeben. Dort setzt dann "unix password sync" an.
Du wirst also immer zwei Passwort-DBs brauchen,
Richtig, aber die halten sich von alleine in sync, s.u.
die Du bestenfalls syncron halten könntest („unix password sync“ im Samba, und vielleicht gibt es ein pam-Modul, das auch das SMB-Passwort setzen könnte, wenn jemand „passwd” aufruft).
Genau das macht pam_smbpass. Es hasht das von "passwd" übergebene Klartextpasswort für den Samba-PDC (LDAP-Attribut "sambaNTPassword").
Selbstverständlich ist es nicht vorgesehen, die verschiedenartigen Hashes ineinander umzurechnen. Deshalb bedarf es einem initialen "passwd", "smbpasswd" oder "Alt-Strg-Entf" für jeden Nutzer, um beide Hashes gleichzuziehen.
Also: - Linux/UNIX-Maschinen gegen LDAP authentifizieren - Samba-PDC mit LDAP-Backend - Windows-Rechner zu Domänenmitgliedern machen - LDAP-Inhalt regelmäßig sichern - zurücklehnen ;-)
Wenn Konfigurationsbeispiel gewünscht ==> Elektronenpost an Liste.
Am 14.09.2010 17:02, schrieb William Epler:
Am Freitag 10 September 2010, 10:14:41 schrieb Heiko Schlittermann:
Gibt es keine Möglichkeit, Samba zu überreden, die Systemnutzer zu nutzen, also kein extra DB?
Nein. Meines Wissens geht das nicht.
Geht doch.
Du könntest LDAP nehmen, aber auch dort gibt es dann ein Passwort und ein SMB-Passwort-Hash.
Soweit korrekt. LDAP sollte man spätestens in gemischten Umgebungen auf dem Samba-PDC immer als Backend haben.
unix password sync
Diese Option in smb.conf sorgt dafür, daß, wenn mit smbpasswd oder mit Windows-Bordmitteln das Samba-Passwort geändert wird, dieses auch gleich für PAM-Gebrauch mit gehasht wird (==> LDAP-Attribut "userPassword").
SMB schickt die Passworte als Hash durch die Leitung, somit gehen die gängigen Verfahren (z.B. Authentifizierung gegen einen LDAP) nicht.
Bei Passwortänderungen wird das neue Passwort auf verschlüsseltem Weg dem Domaincontroller zum Hashen übergeben. Dort setzt dann "unix password sync" an.
Du wirst also immer zwei Passwort-DBs brauchen,
Richtig, aber die halten sich von alleine in sync, s.u.
die Du bestenfalls syncron halten könntest („unix password sync“ im Samba, und vielleicht gibt es ein pam-Modul, das auch das SMB-Passwort setzen könnte, wenn jemand „passwd” aufruft).
Genau das macht pam_smbpass. Es hasht das von "passwd" übergebene Klartextpasswort für den Samba-PDC (LDAP-Attribut "sambaNTPassword").
Selbstverständlich ist es nicht vorgesehen, die verschiedenartigen Hashes ineinander umzurechnen. Deshalb bedarf es einem initialen "passwd", "smbpasswd" oder "Alt-Strg-Entf" für jeden Nutzer, um beide Hashes gleichzuziehen.
Also:
- Linux/UNIX-Maschinen gegen LDAP authentifizieren
- Samba-PDC mit LDAP-Backend
- Windows-Rechner zu Domänenmitgliedern machen
- LDAP-Inhalt regelmäßig sichern
- zurücklehnen ;-)
Wenn Konfigurationsbeispiel gewünscht ==> Elektronenpost an Liste.
Hallo,
viel besser hätte ich das auch nicht darstellen können. ;-)
Ein wichtiges "buzzword" zu dem Thema ist unbedingt: "ldapsam:editposix"!
Alles im allem keine Lösung die man sich gerade mal so schnell aus dem Ärmel schüttelt - ;-)
Bei Bedarf gibts auch von mir noch weiteres blabla, Literaturhinweise usw...
Gruß
Gunter
Am Donnerstag 16 September 2010, 10:05:36 schrieb Konrad Rosenbaum:
Bitte weiteres Blabla. Oder zumindest Links zu Howtos.
Da werde ich doch mal Konfiguration+LDAP-Beispielnutzer aus einer Produktivumgebung herauskramen. Vielleicht wird da auch ein Stammtisch-Vortrag draus.
Am Mittwoch 15 September 2010, 21:59:57 schrieb Gunter Miegel:
viel besser hätte ich das auch nicht darstellen können. ;-)
Danke für die Blumen.
Ein wichtiges "buzzword" zu dem Thema ist unbedingt: "ldapsam:editposix"!
Und noch eins: smbldap
Alles im allem keine Lösung die man sich gerade mal so schnell aus dem Ärmel schüttelt - ;-)
Schon richtig. Aber einmal aufgesetzt und man - hat Ruhe vor den Nutzern: Für die geht es so, wie sie es erwarten - kann sich darauf verlassen: LDAP ist hochverfügbar by Design, dort liegen die einzigen "beweglichen" Daten, die in diesem Zusammenhang recht einfach regelmäßig zu sichern und bei Bedarf genauso einfach wieder herstellbar sind
William Epler william.epler@globalfoundries.com (Fr 17 Sep 2010 09:23:49 CEST): (…)
Ein wichtiges "buzzword" zu dem Thema ist unbedingt: "ldapsam:editposix"!
Und noch eins: smbldap
Moment, wenn ich das mal alles richtig verstanden hatte, dann ging es dem OP darum, nur ein Passwort speichern zu müssen. Auch bei smbldap hast Du zwei, den Windows-Passworthash und dann etwas, was LDAP für ldapauth nutzt oder einen Unix-Passworthash.
Wenn beides sync verändert wird, gibt das natürlich nach außen der Eindruck, es handelele sich um etwas Singuläres.
BTW: ldapauth muß ja nicht mal etwas zwingend mit Passworten zu tun haben.
Alles im allem keine Lösung die man sich gerade mal so schnell aus dem Ärmel schüttelt - ;-)
Schon richtig. Aber einmal aufgesetzt und man
- hat Ruhe vor den Nutzern: Für die geht es so, wie sie es erwarten
- kann sich darauf verlassen: LDAP ist hochverfügbar by Design, dort liegen die einzigen "beweglichen" Daten, die in diesem Zusammenhang recht einfach regelmäßig zu sichern und bei Bedarf genauso einfach wieder herstellbar sind
Das müsstes Du mal bitte besser erklären. Backup impliziert noch kein HA. Und wo LDAP HA by Design ist, kann ich auch nicht erkennen.
Du brauchst Master und Slaves und eine gescheite Replikation - die Openldap bietet. Aber das hat mit LDAP an sich nichts zu tun, denke ich.
Und Du must den Clients beibringen, daß es nicht nur einen LDAP-Server gibt und daß sie im Notfall mehrere probieren sollen, oder zu Krücken wie DNS-Round-Robin greifen (was wieder mit HA nichts zu tun hat, außer Du änderst die DNS-Einträge je nach Situation) …
Hallo!
Am Samstag 18 September 2010 schrieb Heiko Schlittermann:
Das müsstes Du mal bitte besser erklären. Backup impliziert noch kein HA. Und wo LDAP HA by Design ist, kann ich auch nicht erkennen.
Du brauchst Master und Slaves und eine gescheite Replikation - die Openldap bietet. Aber das hat mit LDAP an sich nichts zu tun, denke ich.
Und Du must den Clients beibringen, daß es nicht nur einen LDAP-Server gibt und daß sie im Notfall mehrere probieren sollen, oder zu Krücken wie DNS-Round-Robin greifen (was wieder mit HA nichts zu tun hat, außer Du änderst die DNS-Einträge je nach Situation) …
Was du noch vergessen hast: Diese Einträge unterscheiden sich noch mal grundlegend für Linux und Windows. Bind 9 unterstützt auch die von M$ eingeführten "Service"-Einträge im DNS. Diese nutzen die Clients ab Vista, um die Dienste-Server zu finden. Damit ist es bei mir z.B. möglich, die Rechner an eine Samba-Domäne anzubinden, den KMS-Server aber auf einem Windows2008-Server zu belassen. Diesen Einträgen lassen sich (analog zu E-Mail-Servern) auch Prioritäten zuordnen. Damit ist den Clients schnell klar, wer in welcher Reihenfolge zu fragen ist.
Gruss Reiner
Am Samstag 18 September 2010, 20:58:45 schrieb Heiko Schlittermann:
Das müsstes Du mal bitte besser erklären. Backup impliziert noch kein HA.
Das war auch nicht als HA gemeint. Vielmehr können die per ldapsearch oder slapcat entstehenden ASCII-Dateien sehr schön gesichert/versioniert/wasauchimmer und für LDAP-Migrationen oder im DisasterRecovery-Fall zum Neuaufsetzen des/der LDAP-Provider-Server genutzt werden. Die Konfigurationsdateien (/etc/openldap/...) liegen ja sowieso in einem Versionskontrollsystem, oder? ;-)
Und wo LDAP HA by Design ist, kann ich auch nicht erkennen.
s.u.
Du brauchst Master und Slaves und eine gescheite Replikation - die Openldap bietet. Aber das hat mit LDAP an sich nichts zu tun, denke ich.
s/master/provider/g s/slave/consumer/g Das Ganze heißt bei OpenLDAP syncrepl, ist in rfc4533 spezifiziert und funktioniert hier(TM) in einer größeren, weltweiten Produktivumgebung ohne Probleme. slurpd (das wo der Master per push die Slaves zu aktualisieren versucht) ist abgekündigt und zumindestens im Debian 5 auch nicht mehr dabei.
Und Du must den Clients beibringen, daß es nicht nur einen LDAP-Server gibt und daß sie im Notfall mehrere probieren sollen
Genau das ist es: Die Clienten haben immer _mindestens_ zwei LDAP-Server konfiguriert, die abgefragt werden können. Ausfall von LDAP-Servern haben keinen Einfluß auf die ordnungsgemäße Funktion der Clients, solange davon mindestens ein LDAP-Server erreichbar ist und antwortet. Desweiteren wird so die Last (=LDAP-Abfragen) auf alle konfigurierte LDAP-Server verteilt, was in größeren Umgebungen von Vorteil ist.
, oder zu Krücken wie DNS-Round-Robin greifen (was wieder mit HA nichts zu tun hat, außer Du änderst die DNS-Einträge je nach Situation) …
Das will man nicht wirklich und braucht es bei LDAP auch nicht.
William Epler william.epler@globalfoundries.com (Mo 20 Sep 2010 10:10:12 CEST):
Am Samstag 18 September 2010, 20:58:45 schrieb Heiko Schlittermann:
Das müsstes Du mal bitte besser erklären. Backup impliziert noch kein HA.
Das war auch nicht als HA gemeint. Vielmehr können die per ldapsearch oder slapcat entstehenden ASCII-Dateien sehr schön gesichert/versioniert/wasauchimmer und für LDAP-Migrationen oder im DisasterRecovery-Fall zum Neuaufsetzen des/der LDAP-Provider-Server genutzt werden. Die Konfigurationsdateien (/etc/openldap/...) liegen ja sowieso in einem Versionskontrollsystem, oder? ;-)
Oder im LDAP selbst.
Und wo LDAP HA by Design ist, kann ich auch nicht erkennen.
s.u.
Du brauchst Master und Slaves und eine gescheite Replikation - die Openldap bietet. Aber das hat mit LDAP an sich nichts zu tun, denke ich.
s/master/provider/g s/slave/consumer/g
(…) … das ist schon klar.
Das was Du hier beschreibst, ist aber nicht HA by Design im LDAP, sondern im OpenLDAP.
Und Du must den Clients beibringen, daß es nicht nur einen LDAP-Server gibt und daß sie im Notfall mehrere probieren sollen
Genau das ist es: Die Clienten haben immer _mindestens_ zwei LDAP-Server konfiguriert, die abgefragt werden können. Ausfall von LDAP-Servern haben keinen Einfluß auf die ordnungsgemäße Funktion der Clients, solange davon mindestens ein LDAP-Server erreichbar ist und antwortet. Desweiteren wird so die Last (=LDAP-Abfragen) auf alle konfigurierte LDAP-Server verteilt, was in größeren Umgebungen von Vorteil ist.
Ja, ich würde aber auch hier behaupten, daß das nichts mit by Design zu tun hat. Aber sicher ist das nun von mir Krümelkackerei. ☺ Ob allerdings die Last verteilt wird, würde ich anzweifeln, oder bist Du sicher, daß die Clients auf die konfigurierten LDAP-Server round-robin zugreifen? Ich würde das eher verneinen, habe es aber zugegebnermaßen auch nicht geprüft. Ich glaube, mich zu erinnern, daß in nss/pam-ldap z.B. nach master- und slave-LDAP unterschieden wird. An den Slave gehen die „read“-Queries, an den master die „write“-Queries.
Am Dienstag 21 September 2010, 22:56:11 schrieb Heiko Schlittermann:
genutzt werden. Die Konfigurationsdateien (/etc/openldap/...) liegen ja sowieso in einem Versionskontrollsystem, oder? ;-)
Oder im LDAP selbst.
Die initiale /etc/ldap.conf, /etc/openldap/slapd.conf, /etc/samba/smb.conf usw. braucht es schon im Dateisystem.
Ob allerdings die Last verteilt wird, würde ich anzweifeln, oder bist Du sicher, daß die Clients auf die konfigurierten LDAP-Server round-robin zugreifen?
Sauber implementierte LDAP Clients _sollten_ sich einen der konfigurierten LDAP-Server zufällig auswählen. Erfahrung aus der Produktivumgebung mit hunderten Maschinen zeigt aber, daß es nicht schaden kann, die Reihenfolge der LDAP-Server in den Client-Konfigurationen zu mischen.
Ich würde das eher verneinen, habe es aber zugegebnermaßen auch nicht geprüft. Ich glaube, mich zu erinnern, daß in nss/pam-ldap z.B. nach master- und slave-LDAP unterschieden wird. An den Slave gehen die „read“-Queries, an den master die „write“-Queries.
Das geht anders: - Den Clients sind mindestens zwei LDAP-Server per Konfiguration bekannt - Client hat einen LDAP-Consumer erwischt (oder hat nur LDAP-Consumers konfiguriert) und versucht, dort zu schreiben - Das klappt nicht - Dafür bekommt Client vom LDAP-Consumer gesagt, auf welchem LDAP-Provider statt dessen geschrieben werden darf. Dies steht in der "referral" Option der /etc/openldap/slapd.conf des LDAP-Consumer-Servers - Client schreibt auf auf den zugewiesenen LDAP-Provider - LDAP-Consumer übernehmen diese Änderung vom LDAP-Provider
Praktisch passieren bei LDAP wesentlich weniger Schreib- als Lesezugriffe, da LDAP-Schreibzugriffe durch den "gemeinen Nutzer" üblicherweise auf Passwortwechsel beschränkt sind, während LDAP-Lesezugriffe bei jedem "ls" dabei sind. Deshalb sollte auf funktionierende nscd geachtet werden. Heißt umgekehrt, daß bei abgebrannten LDAP-Provider das Leben erstmal weitergeht und ein neuer LDAP-Provider mit den Daten eines Consumers aufgesetzt wird.
Schöne Zusammenfassung: http://kris.koehntopp.de/artikel/dir-vs-rel/sld005.htm
Gruß
Hi!
Am 10.09.2010 um 07:23 schrieb Luca Bertoncello:
Gibt es keine Möglichkeit, Samba zu überreden, die Systemnutzer zu nutzen, also kein extra DB?
Meines Wissens nach hilft da nur kerberos. Probiert habe ich es nicht, der Aufwand war mir zu hoch.
MfG Sebastian -- Jeder ist notwendigerweise der Held seiner eigenen Lebensgeschichte.
lug-dd@mailman.schlittermann.de
-
Gunter Miegel -
Heiko Schlittermann -
Konrad Rosenbaum -
Luca Bertoncello -
Reiner Klaproth -
Sebastian Hegler -
William Epler