Lion Server... Zzzzz

Damals unter Steve wäre das nicht passiert!

peinlich!

tja, das kommt dabei raus, wenn etwas auf Biegen und Brechen veröffentlichen will und es nicht richtig testet.

Viel übler find ich dass ich bei SMB-mounts das Passwort mit Grossbuchstaben eingeben muss.

Hat mich viel Arbeit, Nerven gekostet,

Lion Server ist wirklich praktisch unbenutzbar!

Ich sage das unter Schmerzen: ja, leider hast Du recht. *heul*

Ganz grober Schnitzer, vor allem dass das nicht bereits gefixt ist. Ist ja lange genug bekannt...

der Heise Artikel ist ja 2 Tage alt, kam mir wohl deshalb bekannt vor :o
so amcht man News...
egal, danke MTN.

Wie mal MTN wieder keine Ahnung hat und nichtmal lesen kann.
Jeder ordentliche Journalist, der von einem Thema nicht umfassend Ahnung hat, fragt jemand, der mehr weiss, bevor er quatsch schreibt. MTN mal wieder nicht.
Das ist kein Lion Server spezifisches Problem (sondern Lion allgemein) und auch nicht in der LDAP (Server) Implementierung von OS X Server.
Wenn man den Artikel liest, entsteht für den Laie ein falscher Eindruck - nämlich dass sich an einem Lion Server einfach jeder anmelden könnte. Das ist in 99% der Fälle nicht so.

Wer Seine User-accounts in OS X Server in OD oder in einem MS Server in AD hat, ist davon überhaupt nicht betroffen.
Nur wenn der Server mittels der Verzichnisdienste an einen 3rd Party LDAP Server angebunden ist, dort die User liegen und weder ein Kerberos, noch ein SASL-Kennwortserver vorhanden, DANN trifft dieser Bug zu.
Ich bin seit 13 Jahren als Server-Consultant im Apple Bereich tätig und die Anzahl der Kunden, die das so einsetzen ist meiner Erfahrung nach sehr gering.

Wenn es z.b. um den Login am Client geht - mit einem Network Home, versucht das Login Window nacheinander folgendes:
- es liest aus dem LDAP das "Authentication Authority Feld", das angibt, wie authentifiziert werden kann (Kerberos Principal und SASL ID bei OD). In einem RFC 2307 LDAP (3rd Party) ist dieses Feld meistens nicht da. Dann wird weiter gesucht:
- ein sog. "Educated guess" des Kerberos Principals (der in 95% der Fälle eines *nix Servers, der Kerberos hat und richtig aufgesetzt ist, das richtige Principal findet)
- Erst dann wird mittels Username und eingegebenem Kennwort ein authenticated LDAP bind versucht, der bei Erfolg als gültige Anmeldung dient. Und das ist das, was hier kaputt ist und offensichtlich immer geht.

Fazit: Der Artikel ist unklar und falsch.
Wer (Lion) Server als OD Master verwendet (und DNS richtig macht) hat kein Problem. Wer ein Active Directory verwendet, hat kein Problem. Wer Open LDAP und Kerberos verwendet, hat kein Problem.
Ich vermute stark, dass von den leuten hier im Forum kein einziger einen RFC 2307 ohne Kerberos als Verzeichnisdienst für einen OS X Server einsetzt ...

Also: Apple sollte diesen Bug schnellstens flicken, aber wirklich kritisch ist er in den wenigsten Fällen.

Heißt das nicht LAPD?

Andi Schenk

Danke - Danke - Endlich mal jemand der weiß von was er redet.

asdakloek

Nein - Das heißt NYPD

Andi Schenk: Danke für die Klarstellung.

Aber auch wenn dieses Problem nur wenige betrifft, so bleibt Lion Server in 10.7.1 ein Großbaustelle mit vielen Fehlern, die durchaus viele betreffen. So gibt es z.B. ein Problem das verhindert, dass Clients per SSL an den Verzeichnisserver anbinden. Dann klappt der Profile Manager fast noch gar nicht. Mal liegt an PostgreSQL, das in manchem Umfeld nicht startet, mal können Einstellungen nicht gelesen werden usw. Dann werden Benutzerordner für mobile Benutzer teils nicht angelegt oder nicht synchronisiert. Usw, usw.

Aus meiner Sicht hätte nur die Meldung eher so lauten müssen: Lion Server hat weiter zahlreiche Fehler.

Hoffen wir auf ein baldiges 10.7.2 mit Abhilfe. Aber optimistisch bin ich nach so viel Frust eigentlich nicht mehr.

@Kinged: Ja, 10.7. Server hat einige Bugs. Da muss Apple noch einiges machen. Aber der Ansatz ist durchaus richtig.

Betr. Dir. Services mit SSL (hab ich noch nicht getestet) - hast Du mal geschaut, ob die verwendeten Zertifikate im Trust-Chain sind? Lion Server erstellt ja eine Root und Intermediate CA - die sollte dein Client natürlich "mögen", sonst darf es nicht gehen. Ausserdem muss DNS stimmen, sonst schlägt die Zertifikatsprüfung auch fehl.
Und zu guter letzt - warum überhaupt Dir. Services mit SSL? Mach authenticated Binds und der gesamte Dir. Services Datenverkehr ist auch verschlüsselt. Das ist - meiner Erfahrung nach - deutlich einfacher zu bekommen (weil man meistens auch wegen MCX die authenticated Binds will) und klappt dann zuverlässig. Oder hast Du einen Grund für unauthenticated binds und LDAPS?

@Andi
Ich lese seit ca 2 Jahren auf dieser Seite mit und freue mich, dass so ein Thema in den Kommentaren besprochen wird - und ist auch der Grund mich hier heute zu registrieren..

@kinged
bei welcher Konfiguration des Servers gab es das Problem mit den mobilen Benutzerordnern ?

Ich arbeite zur Zeit an einem MacMini Server der leider mit Lion Server geliefert wurde - keine Chance auf SL Server. Der SoftwareUpdate Dienst kränkelte lange vor sich hin bis einer der OD Lion Clients ein Update angeboten bekam. Ob der SUS mit SL und Leopard spielt konnte ich noch nicht testen.

@Andi Schenk: Habe jetzt nochmals getestet und muss mich korrigieren. Es klappt durchaus per authenticated binding. Offenbar hatte ich versehentlich beides eingestellt, auth. Binding und LDAPS. Bei der Anbindung per "Benutzer" Systemeinstellung schlägt der Client während dem erstellen des authenticated Bind auch vor, dem Server zu vertrauen. Das schlägt dann aber fehl

Außerdem listet Apple noch selbst das Problem, dass Zerfikatete nicht korrekt übertragen werden, wenn man eine Anbindung eines Servers an ein Lion OD Directory über die Server.app hergestellt wird

@stoneman: Dieses Problem hatte ich selbst nicht, aber viel dazu in diesen Hilfeforen gelesen. Scheinbar wird der Benutzerordner nicht immer erstellt wenn der mobile Benutzer das erste Mal einloggt.

Meine Probleme habe ich nun hauptsächlich mit dem Profile Manager. Der hängt sich in der Server.app teils komplett auf. Nach dem Löschen von Usern hatte ich in der Profilverwaltung (in Safari per Admin eingeloggt) teils Einträge als (Null) stehen, die ich nicht entfernen konnte. Dann wiederum scheint PostgreSQL nicht zu starten, wenn die Einstellung so aktiviert ist, dass die Systemressourcen für Serverdienste präferieret werden. Und was ich noch gar nicht hinbekommen habe, ist dass im Wiki ein Kalender angezeigt wird. Hier Sagt Safari entweder, dass ein Fehler aufgetreten ist (Link auf den Kalender in Hauptmenü) oder der leere Kalender erscheint mit einem sich ewig drehenden Rädchen für die Abfrage des Kalenders (direkt in Wiki). Der Kalender existiert aber natürlich und kann auch per CalDav abgefragt werden.