Moin Poldy,
Es geht nicht um die Personen, die eine Recovery durchführen dürfen, sondern um die Adresse an die eine Sicherungskopie der neu erstellten ID geschickt wird.
Da ist ein kleines Feld und da stand eine Gruppe drin, in diesem Fall. Man kann aber das Feld nicht direkt bearbeiten, also die Gruppe nicht daraus entfernen.
...
Ziel war, es sollte keine Sicherungskopie der ID verschickt werden, jetzt wird keine mehr an andere Kollegen geschickt, nur an die registrierende Person, aber richtig schön ist das noch nicht!
wieso willst du Personen zur Kennwort-Recovery berechtigen ohne die dafür benötigten IDs automatisch zu sichern?
Oder liegen die IDs schön sortiert auf irgendwelchen Netzlaufwerken bei euch?
Zur Erklärung, warum ich so "doof" frage: es gibt ja (bzw. gab) drei Möglichkeiten, einem Nutzer, der seinen PC verloren oder nur sein Notes-PW vergessen hat seine ID wieder zugänglich zu machen bzw. sein Kennwort zurückzusetzen.
a) Escrow Agent (eigentlich nur Release 4.x)
Wenn im öffentlichen Adressbuch (das hieß damals ja noch so) der reservierte Name (oder Alias) "Escrow Agent" vorhanden war wurde bei der Registrierung automatisch eine Mail mit der Kopie jeder neu (!) registrierten user.id mit Klartextpasswort (!) an diese Adresse versendet.
Die in vielen Firmen (teils bis heute) praktizierte Alternative lautete ja: wir legen alle ID's auf Netzlaufwerken ab und alle haben entweder das gleiche Einheitspasswort oder "sichern" das in irgendeiner Exceldatei. Jajaaa, sowas macht doch keiner....
b) Kennwort Recovery (ab Release 5)
Hierbei wurde jeder user.id für alle zur Kennwortwiederherstellung angegebenen Personen mit deren Public Key gesichert unsichtbar ein Recovery-Key hinzugefügt und eine Kopie dieser ID an die angegebene Adresse (üblicherweise eine Mail-In) versendet.
Für die Wiederherstellung braucht der Admin die jeweilige ID und muss natürlich zum Zeitpunkt der ID-Erstellung auch in der Liste der berechtigten Personen gestanden haben. Das regulär vergebene Startkennwort des Notesnutzers fehlt übrigens in dieser ID, man kann die ID also ausschließlich zum Auslesen der Recovery-PW und der anschließenden Verwendung der PW vergessen Funktion am Benutzerclient einsetzen.
Das ist (meines Wissens nach) übrigens die einzige PW Rücksetzfunktion am Markt, die komplett ohne digitalen Kontakt zwischen Nutzer und Admin auskommt. Der Admin könnte dem Nutzer das Recovery-PW auch per Brieftaube oder Rauchzeichen übermitteln und der Nutzer muss nicht mal online sein dafür.
c) ID-Vault (ab Release 8.5)
Vereinfacht dargestellte Grundidee ist hier, dass Kopien der Benutzer-Zertifikate (aka user.id) verschlüsselt in einer Datenbank abgelegt und aktuell (!) gehalten werden. Umbenennung oder Rezertifizierung ist hier daher kein Thema. Clients holen sich in Kombination mit weiteren Daten aus dem Domino Verzeichnis bei jedem Start automatisch ihre IDs oder Updates (z.B. PW Reset) von dort.
Restliche Beschreibung spare ich mir mal, da das hier gerade irrelevant ist, kann man ja bei HCL und diversen Foren nachlesen.
Man will heutzutage natürlich c) aber es spricht m.E. nichts dagegen, wenn man für Notfälle und Kollegen ohne Internet b) parallel noch mitbenutzt. Solange sie nicht umbenannt oder rezertifiziert wurden
Jetzt zurück zu dir Poldy, du nutzt Variante b) und damit braucht ein Admin zum Abrufen der Recovery-PW zwingend Zugriff auf eine ID des Nutzers um den es geht.
Wenn du die ID aber weder per a), b) oder c) gesichert hast - wie soll der Admin dann an die Information kommen?
Doch wieder per Filesystemkopie? Oder schickt der Nutzer dem Admin bei Bedarf seine ID per Signal oder Telegram?
Und was ist, wenn dem Nutzer sein Laptop mit der einzigen Kopie der user.id abhanden gekommen oder runtergefallen ist und er jetzt auf einem neuen Laptop Notes installiert hat und seine ID braucht?
Da ist (ohne ID-Vault) die Mail-In-Datenbank deutlich besser geschützt und auch ggf. von überall aus im Zugriff.
Und bei der funktioniert im Gegensatz zur Filesystemkopie auch nicht mehr das evtl. kompromittierte Startkennwort.
Lediglich wenn man b) und c) gleichzeitig benutzt bräuchte man die Kopie aus b) nicht - aber das macht höchstens für das beschriebene Offline-Szenario Sinn. Und selbst dann dürfen die Nutzer inzwischen weder umbenannt noch (mehrmals) rezertifiziert worden sein. Von dadurch verloren gehenden Geheimschlüsseln fange ich gar nicht erst an zu reden.
Die Berechtigten für das Rücksetzen der PW werden beim ID-Vault auch an völlig anderer Stelle konfiguriert, der ganze Austausch in der ID läuft hier anders.
HTH
Carsten
PS: sorry, ist etwas länger geworden
Thema: Mailversandt eine Sicherungkopie der ID eines neuangelegten Users (Gelesen 686 mal)