Hallo zusammen,
ich habe nachtraeglich ID-Recovery über ein Rezertifizieren in die IDs meiner Anwender gedrückt... nur scheint das nur mit dem 7er-Client zu funktionieren, da ich aus dem Standort, wo 6.5.4 genutzt wird, keine IDs bekomme.
Ich habe daraufhin einen Test mit einem Anwender gemacht und beim manuellen zufügen der Recovery-Infos folgende Meldung bekommen :
"Fehlende oder ungültige Wiederherstellungsinformationen"
Was isn das ?
Vermutlich hast du beim Rezertifizieren die Schlüssellänge geändert, so daß die 6er Clients damit nichts mehr anfangen können
Hi,
die User-ID hat eine Schlüsselstärke von 512 bit und einen Verschlüsselungsgrad von 64 bit.
Die OU1 hat eine eine Schlüsselstärke von 512 bit und einen Verschlüsselungsgrad von 64 bit.
Die O hat eine Schlüsselstärke von von 512 bit und einen Verschlüsselungsgrad von 64 bit...
hat der Client 6.5.4 eventuell ein anderes Problem ?
a) Wie sieht es bei dem/den Nutzer/n aus, die als Recovery-User eingetragen wurden? Welche Schlüsselstärken verwenden diese?
b) Wie wurde die Recovery-Info manuell versucht aufzunehmen? Auf dem herkömmlichen Weg per Mail und dem Verwenden der entsprechenden Aktion innerhalb der geöffneten Mail?
c) Wenn b)=ja, wurde das einmal mit ein und der selben ID (und dazu passender Arbeitsumgebung!) von jeweils einem 6er und einem 7er Client versucht?
Moin,
zu a) die User-ID hat eine Schlüsselstärke von 512 bit und einen Verschlüsselungsgrad von 64 bit.
zu b) ja
zu c) ja.. am 6.5.4-Client kam die Eröffnungspost beschriebene Meldung, im 7.02 Client wurde das Zertifikat angenommen.
d) ... eigentlich sollte das Rezertifizieren der Anwender mit der OU1-Cert inkl. neuer Recovery-Informationen schon ausreichen.. das tut es ja auch bei den Anwendern mit Notes 7 Client.
Moinmoin =)
zu a) Wie genau hast du das jetzt geprüft? Über die ID-Eigenschaften deines Recovery-Benutzers? Die physikalische ID der Recovery-User ist hier unerheblich, es zählt das Zertifikat im Domino Directory, da sich die Clients von dort während der Recovery-Aktion den öffentlichen Schlüssel der Recovery-User abholen und mit diesem verschlüsselt das Notfall-Kennwort live in ihre eigene aktive ID zurückschreiben.
zu b) Gut, wie sieht die Arbeitsumgebung des Nutzers während dieser Aktion aus? Bitte mal die Arbeitsumgebungen des nicht funktionierenden 6er und des funktionierenden 7er vergleichen. Wie weiter oben beschrieben braucht der Client während der Aktion Zugriff auf den/die öffentlichen Schlüssel der Recovery-Nutzer. Weiterhin muß zwingend sichergestellt sein, daß sich die Recoverynutzer in der gleichen Domäne wie der Endnutzer befinden (sonst ginge das mit dem Live-Abholen nicht).
zu c) Wenn meine Anmerkungen von a) und b) beachtet wurden werde ich das mal versuchen in einer Testumgebung nachzustellen, allerdings schaffe ich das just for fun nicht mehr vor dem EntwicklerCamp. Ein konkretes vergleichbares Problem bei meinen Kunden liegt mir nicht vor.
zu d) Völlig korrekt. Einzige Bedingung, die manchmal vergessen wird, ist das Gültigkeitsdatum, das beim Rezertifizieren immer nach dem zuletzt gültigen Datum liegen muß. Das wird gern von Admins übersehen, die Nutzer gleich für ein paar 100 Jahre gültig machen. Davon gehe ich aber hier (hoffentlich) nicht aus.
Kontrolle, ob hier wirklich nur die Recovery-Info ein Problem darstellt: hat sich nach dem Rezertifizieren wenigstens die Gültigkeit in den 6er ID's geändert oder nimmt der Client gar nichts an von seinem neuen Zertifikat?
