HCL Notes / Domino / Diverses > Administration & Userprobleme

Benutzer Neu registrieren: Diskussionsthread

<< < (4/4)

Joachim Römer:
So, ich fasse mal`zusammen, worum es meiner Ansicht nach geht ( "Fakt ist" werde ich nicht mehr benutzen, weil das anscheinend provokativ rüberkam   :love: ):

- Es geht darum, dass ein Nutzer keinen Zugriff mehr auf seine ID-Datei hat
- Falls der Nutzer nach dem Private / Public Key - Verfahren Mails verschlüsselt hat ( Standard in Notes ), kann man Ihn nicht neu registrieren, weil er mit der
neuen ID-Datei dann keinen Zugriff mehr auf die vormals verschlüsselten Dokumente hat, weil sich damit sein Private Key und der damit gerechnete Public Key in seinem
Personen-Dokument ändert
- es wird nun kontrovers diskutiert, ob es für einen Nutzer mit neuer ID-Datei womöglicht nicht doch funktioniert, seine ehemals verschlüsselten Mails weiterhin zu lesen

Meiner Ansicht nach sollte es eine Vorgehensweise geben, die das ermöglicht, da ich während meiner Tätigkeit als Consulter ( 1989 - 2020 ) schon solche Fälle bei Kunden hatte.

In den nächsten Tagen werde ich versuchen, aus meiner Erinnerung eine solche Vorgehensweise abzuleiten

Gruss,

Joachim

CarstenH:
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:


--- Zitat von: JayDee am 04.08.22 - 10:42:13 ---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?

--- Ende Zitat ---

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.html

Aber 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:


--- Zitat ---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.
--- Ende Zitat ---

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=KB0034191


--- Zitat von: Joachim Römer am 30.08.22 - 13:44:49 ---Wenn man bei der ID-Erstellung die Option zum Aktualisieren des aktuellen Personendokumentes wählt, geht auch das ...

--- Ende Zitat ---

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:


--- Zitat ---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.
--- Ende Zitat ---

Quelle: Customizing user registration
https://help.hcltechsw.com/domino/11.0.0/conf_customizinguserregistration_t.html

Aus 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.

Joachim Römer:

--- Zitat ---kann ich diesen Streit nicht verstehen
--- Ende Zitat ---

Ich bestehe darauf, dass es hier nicht um einen "Streit" geht, sondern nur um Know-How Austausch ...

Meine Expertise als Ergebnis der Anzahl der Jahre meiner Beschäftigung mit Notes / Domino habe ich nur angeführt,
damit nicht der Eindruck entsteht, Notes / Domino ist Neuland für mich.
Könnte ja passieren, bei den wilden Theorien, die ich hier aufstelle ...   ;D

P.S. CarstenH: Du warst nicht zufällig auch mal´ bei einem LAEC in Ettlingen beschäftigt?

CarstenH:

--- Zitat von: Joachim Römer am 03.09.22 - 21:23:25 ---Ich bestehe darauf, dass es hier nicht um einen "Streit" geht, sondern nur um Know-How Austausch ...

--- Ende Zitat ---

Gern  :)


--- Zitat von: Joachim Römer am 03.09.22 - 21:23:25 ---P.S. CarstenH: Du warst nicht zufällig auch mal´ bei einem LAEC in Ettlingen beschäftigt?

--- Ende Zitat ---

Während meiner IBM Zeit in den 90ern gehörte ich zum Bereich Global Services, da war ich aber noch kein CLI und hab ausschließlich in Projekten gearbeitet.
Mein späteres LAEC war dann in Berlin, wir wurden aber als Trainer besonders in der Boom Phase Anfang der 2000er überall hingeschickt weil es sich für viele LAEC mehr rechnete Trainer zum Festpreis einzukaufen und das eigene Personal in Projekte zu stecken. Und da ich zu den wenigen dual und später advanced zertifizierten Trainern gehörte hatte ich entsprechend volle Wochen - von Ettlingen bis Zürich war da alles dabei, ich erinnere mich aber nicht mehr wirklich an einzelne Seminare oder Teilnehmer aus der Zeit :D

Carsten

Joachim Römer:
So, sorry, es hat ein "bisschen" gedauert, bis ich Alles gecheckt hatte ....

Im Grundsatz ist die Aussage natürlich richtig, dass mit dem Private Key verschlüsselte Mails mit einer neuen ID-Datei nicht mehr lesbar sind.

ABER:

Bei den Kunden von mir, wo es anschl. doch möglich war, mit einer neuen Benutzer-ID die Mails zu lesen, lag es daran, dass die Mails vorher entschlüsselt worden waren.
Dies geschah mit einem serverbasierten Agenten ( bei aktiviertem Mailjournal und zusätzlich dem Servernamen im BCC-Feld ... )

Diese "Modifikation" hatte ich leider nicht mehr auf dem Schirm, weil das ursprünglich eine Idee und Ausführung meines Entwicklerkollegen Jochen Kunze war.

Nochmals Danke für Euer Verständnis!

@CarstenH:   Ich dachte eigentlich,  Du wärst mal`angestellter Mitarbeiter dieses LAEC in Ettlingen gewesen.  Ich war übrigens einer der ersten 7 unabhängigen CLI`s, die von LOTUS ( Uschi Bosch in Paderborn ) zertifiziert wurden ...

Navigation

[0] Themen-Index

[*] Vorherige Sete