Hallo zusammen,
ich mag auch mitmachen in der Runde - ich möchte einleitend erwähnen, dass wir von der ursprünglichen Frage inzwischen weit, weit entfernt sind. Die lautete:
Problem: Mit einem adminstrativen Passwort-Reset konnte ich die Situation nicht lösen, der wurde am Server zwar erfolgreich durchgeführt, kam aber beim Nutzer nicht an. (hatte in der Vrgangenheit dutzendemale problemlos geklappt)
Wie würde man denn üblicherweise diese Situation auflösen, damit der Nutzer nicht erst am nächsten Tag wieder mit Notes arbeiten kann?
Eine Lösung, unter Beibehaltung aller Keys, ist die ID aus dem Vault zu extrahieren und dem Nutzer direkt zukommen zu lassen. Dabei gibt man gezielt auch ein neues PW an. Der Downloadzähler sollte für den Vault Admin/Auditor hier keine Auswirkung haben. Eventuell muss das PW Digest im Personendokument manuell beseitigt werden wenn der PW Check aktiv ist:
Vorgehen: Extracting an ID file from a vault
https://help.hcltechsw.com/domino/10.0.1/conf_extractinganidfilefromavault_t.htmlAber jetzt zum zweiten Teil der Diskussion - was passiert eigentlich beim Neuanlegen einer ID als "Lösung" für obiges Problem?
Kurzfassung: der Private Key steht nur an einer einzigen Stelle - das ist die User-ID selbst.
Neue ID = neues Schlüsselpaar = alter Schlüssel unwiderruflich verloren = kein Zugriff auf mit dem bisherigen Schlüssel verschlüsselte Felder/Dokumente/Datenbanken.
Langfassung (da hier Lebenslauf und Anzahl der EDV-Jahre in die Waagschale geworfen werden bin ich dabei):
Ich habe in meiner Ausbildung 1984 noch mit Lochstreifen und später sogar den total moderneren Magnetkarten angefangen. Zählt das?
Seit 1986 arbeitete ich dann als Operator im RZ, später in IT-Abteilungen und Schulungszentren, mindestens 25+ Jahre Erfahrung mit Notes als Entwickler, Admin und Consultant, davon über 20 als Instructor (CLI) u.a. viele Jahre auch bei und für IBM.
Auch ich hatte im Laufe der Zeit mehr als ausreichend Fälle dieser Art (PW vergessen, ID auf Diskette kaputt oder verloren etc) und unabhängig davon haben ich das in etlichen Kursen immer wieder mit Schulungsteilnehmern durchexerziert und ehrlich gesagt kann ich diesen Streit nicht verstehen. Die Verschlüsselungsstärke und die verwendeten Algorithmen haben sich sich im Laufe der Zeit vielleicht geändert - die zugrunde liegende Technik der asynchronen Verschlüsselung und welche Schlüssel-Teile sich wo befinden aber nicht.
Insbesondere in der frühen Zeit (R3 bis R4.x) vor ID-Vault und CA hatten viele Admins leider nicht einmal den simplen, alten ESCROW Agent Mechanismus aktiv, der wurde allerdings auch nicht in den offiziellen Unterlagen gelehrt - höchstens in einem Nebensatz in den Yellow Books erwähnt ohne die Funktion zu beschreiben. Dieser sorgte nämlich in der alten Zeit dafür, dass von jeder ID automatisch eine Sicherheitskopie samt Klartext-PW (aber zumindest als verschlüsselte Mail) an den Agenten verschickt wurde und machte diese leidige Speicherung von Kopien im Dateisystem mit Excel Passwortlisten oder immer gleichen Standard-PW für alle bereits damals völlig unnötig.
Selbst ohne ESCROW gab es spätestens ab R5 die Möglichkeit der ID-Wiederherstellung ohne das original PW zu kennen, die auch Bestandteil der offiziellen Unterlagen und Kurse war und die den Erhalt des Public/Private-Key-Paares sicherte.
Und seit es den ID-Vault gibt habe ich keine einzige Nutzer-ID im regulären Betrieb mehr "ausgehändigt" oder im Dominoverzeichnis gespeichert.
Zusammengefasst: Mit ESCROW Agent, ID Recovery und ID Vault standen schon immer (mindestens seit R3, ältere Versionen habe ich nicht produktiv eingesetzt) Mechanismen zur Rettung der ID ohne eine neue unter Verlust des Keypaars erzeugen zu müssen zur Verfügung. Wer es dennoch gemacht hat oder immer noch macht handelt grob fahrlässig, dem waren/sind die dahinter laufenden Prozesse unklar oder die dadurch verlorenen Daten der User/Unternehmen egal. Damit meine ich nicht zwingend die Admins selbst sondern die, die die Prozesse in den jeweiligen Firmen zu verantworten hatten/haben.
Jetzt die offizielle Aussage zu der Thematik "neue ID für existierenden User", die wichtigste Aussage daraus lautet:
Re-creating a user's ID file should only be considered as a last resort. If the user ID file must be recreated, you should make the user aware that any documents or database previously encrypted will be inaccessible after the new ID is created.
Quelle: How to recreate an ID file for a Notes user when the original file or password cannot be recovered:
https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0034191Wenn man bei der ID-Erstellung die Option zum Aktualisieren des aktuellen Personendokumentes wählt, geht auch das ...
Leider nicht wirklich, was auf den ersten Blick wie die Lösung aussieht ist vielmehr lediglich eine Erleichterung des oben verlinkten Prozesses aus der Knowledge Base indem einem Admin erspart wird das alte Personendokument vorher zu löschen. Der Rest, inklusive dem unschönen Ergebnis der verlorenen Schlüsselpaare bleibt gleich.
Der Inhalt des Personendokuments wird dabei nämlich weder gemerged noch wirklich aktualisiert sondern vielmehr komplett ersetzt und muss hinterher wie im KB Artikel beschrieben, glattgezogen werden (habe ich erst vor ein paar Wochen für einen Kunden machen müssen). Auch darauf wird explizit hingewiesen:
Don't prompt for a duplicate person:
If you enable this option, these additional options appear. Choose one:
- Skip the person registration -- Skips the user registration for both short name and full name single matches.
- Update the existing address book entry -- Overwrites the existing user if the single match found is on the full name. Short name uniqueness is then required.
The default is to prompt for duplicate users.
Quelle: Customizing user registration
https://help.hcltechsw.com/domino/11.0.0/conf_customizinguserregistration_t.htmlAus der Praxis weiß ich, dass in vielen Firmen die Notes Verschlüsselung eher selten aktiv von normalen Nutzern verwendet wird. Insbesondere wenn Vertreterregelungen oder Teammailboxen ins Spiel kommen ist eine aktiv gelebte Grund-Verschlüsselung vieler Mails hinderlich bis tödlich für den Workflow. Die gezielte Verschlüsselung einzelner Felder über die oben erwähnten Secret Keys in echten Workflows oder bei Mails zwischen einzelnen Personen um gezielt das Mitlesen Dritter zu unterbinden schon eher aber in Zeiten von WhatsApp & Co. verlagert sich derartige Kommunikation eher hin zu anderen Plattformen. Damit merkt man in der Praxis wahrscheinlich eher selten etwas von den evtl. verlorenen Mails wenn man nicht gezielt danach sucht. In einem größeren Projekt vor vielen, vielen Jahren haben wir Nutzer vor einem zentralen ID-Tausch die aktive Entschlüsselung aller verschlüsselten Mails per Agent durchführen lassen, mit Kontrolle und Log ob die Leute drauf geklickt haben um keine Verluste zu erleben.
HTH - und ein schönes Wochenende
Carsten
PS: mit Ausnahme des Absatzes über Lochstreifen und 80er Jahre habe ich mich bemüht alles auf der technischen Ebene zu belassen. Die verlinkten HCL Seiten sollen lediglich dazu dienen die offizielle Dokumentation aufzuzeigen unabhängig davon, dass sie meinen praktischen Erfahrungen entspricht.
Thema: Benutzer Neu registrieren: Diskussionsthread (Gelesen 2233 mal)