Passwort zurücksetzen mit ID Vault: Fehlermeldung

Hi,

Diesen Fehler hatt ich eigentlich nur einmal, als ich den "Haupt-Server" der ID-Vault geaendert hatte.
Nachdem ich dem Vorschlag in diesem Link IBM Lotus Notes/Domino 8.5 Forum
gefolgt bin, hatte es sich auch mit der Meldung erledigt.

Jedoch stellt sich mir bei Deiner Beschreibung folgende Frage.

Zitat

Wenn er sich in iNotes anmeldet und dort das Kennwort ändern möchte, funktioniert dies auch nicht. Es erscheint die Maske bei der das alte Kennwort und zweimal das neue Kennwort eingegeben werden müssen. Tut man dies, erscheint die Meldung, dass das "alte Kennwort" falsch ist. (obwohl er sich am iNotes gerade noch mit dem Kennwort anegemeldet hat)

Wo und wie will der User sein PW in iNotes aendern?

Das PW bei der Anmeldung in iNotes ist sein http-PW, welches nicht unbedingt etwas mit dem PW im ID-File zu tun hat.

Andreas

Hi,

tobso,
Entschuldige dass ich Dir hier weiderspreche, aber das was Dein user hier aendert, Dein Screenshot, ist NICHT das HTTP-Passwort, sondern das PW seiner ID, die in sein Mailfile
eingebunden ist.
Und dieses hat erst einmal noch rein gar nichts mit seinem HTTP-Passwort zu tun.

Sein HTTP-Passwort ist das, welches er eingeben muss, um ueberhaupt in seiniNotes zu gelangen.
Und eben dieses hat er ja schon (erfolgreich) eingegenen, ansonsten waere er ja noch nicht in der Lage sein PW fuer ein ID-File, welches im Mailfile eingebunden ist,
zu aendern.

Das diese beiden Passwoerter gleich sein koennen, ist natuerlich moeglich, was jedoch nicht sein muss.

Und auf Deine Frage zurueckzukommen, natuerlich kannst Du auch auf weitere Server die Vault-Db replizieren, dies solltest Du abe auch in der Vault bekanntgeben,

Andreas

Oh Mann,

Ich bin noch nicht munter.

In meinem letzte Post gleich mehrere Fehler.

Zum ersten -> falsche Anrede.
Bitte entschuldige Lorac.

Und zum zweiten
Wenn Dein User auf den Button "Aendern" geklickt hat, dann aendert er natuerlich sein HTTP-Passwort.
Was mich jedoch in diesem fall dann doch etwas verweundert, waere die Tatsache, dass er sich erfolgreich in iNotes anmelden kann, jedoch nicht
sein HTTP-Passwort aendern kann.

Andreas

Hi,

Wenn es mit dem 'Wiederanlegen' aber schnell gehen muss, dann loesch den User NICHT ueber den AdminP.

Loesch sein Personen-Dokument manuell aus dem Directory.
Beim Anlegen gibst Du ihm ein 'temporaeres' Mailfile und passt dieses nach dem erfolgreich Anlegen in seinem Personen-Dokument wieder an
und traegst hier sein bereits vorhandenes ein.
(wobei ich Dir jetzt nicht absolut sicher sagen kann, ob die Vault dies auch so mitmacht und sein ID-File im vorhandenen Mailfile einfach so austauscht)

Einziger grosser nachteil bei dieser Geschichte ist, dass er seine bis dato verschluesselten Mails nicht mehr lesen kann.

Andreas

Ach Ja.
Noch etwas vergessen.

Sollte sich Dein User lokale Datenbanken angelegt haben und diese verschluesselt wurden, so kann er diese ebenfalls nicht mehr verwenden.

Andreas

Es sollte im Personendokument nicht nur der Pfad zum Mailfile, sondern idealerweise auch der neuerrrechnete öffentliche Schlüssel angepasst werden.

Der AdminP lässt sich manuell dazu auffordern, die Löschungen nicht erst am WE vorzunehmen. Von daher halte ich den Rat, lieber manuell einzugreifen, nicht für den besten Ratschlag.
Egal, wie wichtig irgendetwas sein möge oder von Profischlippsträgern gemacht wird: nichts ist so wichtig, wie eine saubere und konsistente Umgebung. Und das lässt man lieber die Profis, sprich: den vielen kleinen Helferlein, die so ein Domino mitbringt, machen.

RockWilder

Zitat

... sondern idealerweise auch der neuerrrechnete öffentliche Schlüssel angepasst werden.

Das versteh ich nicht so ganz.

Warum soll der neu errechnete oeffentlich Schluessel angepasst werden.
Der User wird neu angelegt. => neues ID-File, gleicher Name.
Eintrage in den den Gruppen - Name ist gleich dem alten
namentliche Eintraege in ACL's von Datenbanken - Name ist gleich

Worin besteht hier jetzt die Notwendigkeit, den kompletten AdminP-Prozess zum Loeschen eines Benutzers zu durchlaufen?

Ich lerne gerne immer noch etwas dazu.

Andreas

Neue ID = neuer privater und neuer öffentlicher Teil des Schlüssels.
Wird eine neue ID gerechnet und nur das "temporäre Mailfile" angepasst (wie vorgeschlagen). stimmen die privaten und öffentlichen Teile des Schlüsselpaares nicht mehr überein.

Warum die komplette AdminP-Prozedur durchlaufen werden sollte?
Nun, einfach aus Prinzip. Bevor man manuell eingreift und möglicherweise und unbeabsichtigt etwas fehlerhaft oder unvollständig anpasst, sollte sich für mein Dafürhalten lieber ein Prozess drum kümmern, der explizit dafür vorgesehen ist. Unabhängig davon, wie trivial es ist, manuell einzugreifen.
Wie ich bereits sagte: nichts geht über eine saubere Umgebung. Schnelligkeit kann vor dem Hintergrund immer nur ein nachgelagertes Ziel sein.

RockWilder,

Das es neue oeffentliche und private Schluessel bei einer Neuanlage gibt, ist ja klar.

Womit ich lediglich ein kleines Verstaendnisproblem habe ist die folgende Aussage von Dir

Zitat

Wird eine neue ID gerechnet und nur das "temporäre Mailfile" angepasst (wie vorgeschlagen). stimmen die privaten und öffentlichen Teile des Schlüsselpaares nicht mehr überein.

Was haben denn die oeffentlichen und privaten Schluessel mit dem Mailfile zu tun?
Wie gesagt, ich lerne gern dazu.

Andreas

Wie soll denn eine Mail verschlüsselt oder ein Dokument signiert werden, wenn die Teile des Schlüsselpaares nicht zueinander passen?
Ob die Verschlüsselung überhaupt funktioniert, weiß ich zwar nicht, aber ich wage es zu bezweifeln. Bei einem signierten Dokument kann aber niemals die "Echtheit" verifiziert werden.

Deshalb muss das auch immer zuzüglich zu weiteren Anpassungen nachgezogen werden.

Also mir hat man einmal beigebracht, dass signieren und verschluesseln auf das ID-File und den Schluessel aus dem Personen-Dokument zurueckgreift.
Und wenn mir jemand eine verschluesselte Mail zusendet, dann hat er noh lange nicht auch Zugriff auf mein Mailfile. Ihm stehen dann nur die Informationen aus
'meinem' Personen-Dokument zur Verfuegung.

Und warum wird dann immer wieder der folgende Workaround von LN-Admins verwendet, damit ein User wieder in der Lage ist verschluesselte Mails zu lesen.
Schluessel aus dem ID-File exportieren und an den Admin senden -> diesen Schluessel gegen den Schluessel im Personen-Dokument austauschen.
Ab da, kann der User auch wieder verschluesselte Mails lesen, bei denen er einer der Empfaenger ist.

Und zu guter letzt.
Warum kann ich in iNotes erst dann verschluesselte Mails senden und lesen, wenn ich mein ID-File in mein Mail-File eingebunden habe.

Daher sehe ich aktuell keinen Zusammenhang zwischen dem Mailfile eines Users und dem oeffentlichen und privaten Schluessel.

Aber wie gesagt, ich lerne gerne immer noch dazu und lasse mich eines besseren belehren, wenn ich falsch liege oder nur teilweise Recht habe.

Andreas

Entschuldigung, aber das Mailfile hast du erwähnt. Du sagstest, der Pfad muss auf den alten Pfad zurück gebogen werden, wenn bei der Registrierung ein temporäres Mailfile definiert wurde. Das ist soweit auch korrekt und da habe ich auch nichts gegen gesagt. Dieser Punkt ist schon lange geklärt und gar nicht weiter Bestandteil der Diskussion.

Ich habe als Zusatz das Schlüsselpaar erwähnt. Und das hat mal so rein gar nichts mit dem Mailfile zu tun, darüber sind wir uns ja einig. Was es mit dem Schlüsselpaar auf sich hat und den Workaround, das hast du selbst beschrieben. Deshalb steh ich gerade auf dem Schlauch, wo jetzt das Vertsändnisproblem liegt.

Das was mich verwirrt sind diese beiden Saetze von Dir.

Zitat

Es sollte im Personendokument nicht nur der Pfad zum Mailfile, sondern idealerweise auch der neuerrrechnete öffentliche Schlüssel angepasst werden.

Bei der Neuanlage steht doch schon der korrekte Schluessel im Dokument und eine neue ID bekommt der User ja auch. (es wird ja ein neues Personen-Dokument erstellt.

Zitat

Womit ich lediglich ein kleines Verstaendnisproblem habe ist die folgende Aussage von Dir

Zitat
Wird eine neue ID gerechnet und nur das "temporäre Mailfile" angepasst (wie vorgeschlagen). stimmen die privaten und öffentlichen Teile des Schlüsselpaares nicht mehr überein.

Ich brauche doch nichts in Bezug auf die Schluessel anzupassen.
Der User wird doch komplett neu gerechnet und arbeitet ab diesem Zeitpunkt ja nur noch mit dem neu gerechneten ID-File.
(mit dem 'alten' kann er ja eh nicht mehr arbeiten, da er das PW ja nicht mehr kennt)

Andreas