sonnenblen.de - Das unabhängige Sun User Forum
Betriebssysteme => Solaris => Thema gestartet von: claus am 21. Januar 2008, 22:57:57
-
Hallo allerseits,
hat hier irgendjemand oben genannte Konfiguration? Wir haben hier ein *kleines* Problem:
Jeder LDAP-User soll per bind auf seine eigenen Daten zugreifen können, das geht allerdings nicht, wegen "invalid credentials", auch wenn wir die globale default access control auf "jeder darf alles lesen und schreiben" gesetzt haben. Es ist sogar noch so, dass eine Aufweichung der default access control einen anonymen bind verhindert.
Weiss da jemand Rat?*
Claus
*=Nein, wir wollen und nicht um einen Service Contract herumdrücken, das riecht nach einem OpenLDAP Problem
-
Gut, da keiner Rat weiss:
Wir haben zumindest einen Teil des Problems identifiziert:
OpenLDAP möchte SHA1-Verschlüsselung, unsere bisherigen Passwörter waren Crypt.
Wenn wir die LDAP Passwörter auf SHA1 ändern, geht zumindest ein Bind mit dem User/PW, allerdings geht kein su mehr, da passwd offenbar crypt-verschlüsselte Passwörter erwartet.
- das Vorhandensein von zwei unterschiedlichen OpenSSL Packages hilft vermutlich auch nicht weiter
- OpenLDAP vom package zu installieren, hilft vermutlich auch nicht
Was tun?
Wir installieren entweder OpenLDAP neu (also selbst kompilieren)
oder
Wir versuchen passwd usw. dazu zu überreden, eine andere Verschlüsselung zu verwenden.
Hat jemand dazu eine Idee?
Zweites Problem: Unser CMS verwendet OS groups zur Zugriffsverwaltung auf Teilgebiete. Woran kann es liegen, dass ein "id -a" eines Users nicht alle Gruppen auflistet, in denen der User Mitglied ist?
Claus
-
Moin,
eins vorweg - ich habe keine Erfahrungen mit LDAP (geschweige denn OpenLDAP). Mit meinem Solaris Wissen:
1) Kann man OpenLDAP nicht auch so konfigurieren, dass es andere (nicht nur SHA1) Passwortverschluesselungen akzeptiert?
2) Auf Solaris Seite geht SHA1 in der Tat nicht. Es geht nur crypt, BSD blowfish und Sun MD5 (siehe /etc/security/crypt.conf fuer die verfuegbaren Module und /etc/security/policy.conf fuer die erlaubten und den Default). Natuerlich kann man sich hier auch noch eine SHA1 Library bauen, aber das waere hier wohl overkill....
3) Bzgl. der Gruppen braucht Soalris das Shema aus dem draft RFC 2307 (such mal nach rfc2307bis.schema), dass wohl bei OpenLDAP per Default nicht dabei ist. Ich weiss allerdings nicht ob man gleich das Shema aus dem RFC nehmen kann oder ob es dazu noch weitere Sun-spezifische Aenderungen gibt.
Tschau,
Drusus.
-
Wir versuchen passwd usw. dazu zu überreden, eine andere Verschlüsselung zu verwenden.
Hat jemand dazu eine Idee?
Ohne mich damit auszukennen würde ich mal vermuten das man mit PAM etwas in der Richtung drehen könnte (/etc/pam.conf).
Zweites Problem: Unser CMS verwendet OS groups zur Zugriffsverwaltung auf Teilgebiete. Woran kann es liegen, dass ein "id -a" eines Users nicht alle Gruppen auflistet, in denen der User Mitglied ist?
Das habe ich selbst auch schon erlebt (auf Solaris 8). Es gibt zwei verschiedene id Executables, die sich unterschiedlich verhalten. Das "normale" Solaris id und ein XPG4-kompatibles. Siehe Manpage:
/usr/xpg4/bin/id also writes the supplementary group affili-
ations of the invoking process.
Da ich z.Z. keinen Zugriff auf eine Solaris 10 Kiste habe vermute ich einfach mal das es da noch genau so ist. Probier also mal "/usr/xpg4/bin/id".
Gruß,
Andrew.
EDIT: Blöder Smiley...
-
Moin,
eins vorweg - ich habe keine Erfahrungen mit LDAP (geschweige denn OpenLDAP). Mit meinem Solaris Wissen:
1) Kann man OpenLDAP nicht auch so konfigurieren, dass es andere (nicht nur SHA1) Passwortverschluesselungen akzeptiert?
Ja, das geht natürlich, allerdings müssten wir dafür alles noch einmal platt machen und mit compilen neu machen, deswegen siehe Antwort 2.
[/quote]
2) Auf Solaris Seite geht SHA1 in der Tat nicht. Es geht nur crypt, BSD blowfish und Sun MD5 (siehe /etc/security/crypt.conf fuer die verfuegbaren Module und /etc/security/policy.conf fuer die erlaubten und den Default). Natuerlich kann man sich hier auch noch eine SHA1 Library bauen, aber das waere hier wohl overkill....
Ok, wir hatten gehofft, dass es da vielleicht einen Schalter gäbe, den man einfach umlegen müsste.
3) Bzgl. der Gruppen braucht Soalris das Shema aus dem draft RFC 2307 (such mal nach rfc2307bis.schema), dass wohl bei OpenLDAP per Default nicht dabei ist. Ich weiss allerdings nicht ob man gleich das Shema aus dem RFC nehmen kann oder ob es dazu noch weitere Sun-spezifische Aenderungen gibt.
Ach ja richtig! Genau, jetzt wo Du das Schema erwähnst machts "klick" - ich habe den bisher verwendeten LDAP Server nämlich mal vor Urzeiten mitaufgesetzt, bzw die LDAP Hierarchie kräftigst modifiziert.
Vielen vielen Dank, das wird uns alles sehr weiterhelfen.
Claus
-
Das habe ich selbst auch schon erlebt (auf Solaris 8). Es gibt zwei verschiedene id Executables, die sich unterschiedlich verhalten. Das "normale" Solaris id und ein XPG4-kompatibles. Siehe Manpage:
Da ich z.Z. keinen Zugriff auf eine Solaris 10 Kiste habe vermute ich einfach mal das es da noch genau so ist. Probier also mal "/usr/xpg4/bin/id".
Gruß,
Andrew.
EDIT: Blöder Smiley...
Ob jetzt /usr/bin/id -a oder /usr/xpg4/bin/id -g (oder-G?), macht keinen Unterschied. Aber da wir das Schema vergessen haben könnte das sehr wohl der Grund dafür sein. Woran ich mich gerade erinnere: Unter Solaris 8 gabs einen netten Bug, dass ein User manchmal nicht in all seinen Gruppen war, deswegen keinen Zugriff auf das Filesystem bekommen hat (also nicht mal ein ls <dir>), hoffentlich ist das bei Solaris 10 nicht der Fall.
Auch dir vielen Dank,
Claus
-
Okay, noch ein Schritt weiter: Wie es aussieht, ist das OpenLDAP Package ohne --enable-crypt gebaut worden. Entweder unser ISP ändert den Verschlüsselungsalgorithmus für passwd, oder wir compilen OpenLDAP selber. Da ersteres unwahrscheinlich ist, werden wir wohl letzteres machen, bzw, ich bin da gerade schon dabei.
Claus
-
Mit den Packages von Blastwave funktioniert OpenLDAP bedeutend besser - bis auf die Solaris Gruppen-Verrechtung, aber dazu mehr in einem anderen Thema.
Man sollte lediglich darauf achten, die slapd.conf Files nicht durcheinanderzuwürfeln, das Sunfreeware Package und das Blastwave Package sind wohl sehr sehr unterschiedlich gebaut worden. Auch scheint es unsaubere Abhängigkeiten zwischen OpenLDAP und BerkeleyDB zu geben, zumindest was die Versionen angeht, die miteinander funktionieren.
Dieses Thema schliesse ich hiermit und bedanke mich euere Mithilfe.
Claus