[gelöst - eigene Dummheit] Klasse NotesIDVault:Hat die schon jemand probiert?

[Tode]

Ich wollte programmatisch IDs extrahieren aus der Vault und verwende folgende Zeilen Code:

Code

Set idVault = ses.Getidvault()
Call idVault.Getuseridfile( strIDPath, strUserName, strPassword, strServerName )

Das führt aber leider nur zu der Fehlermeldung:

Error #4823: Error accessing IDVault

Ich habe das in einem manuellen Agenten probiert.
Auf dem Server ist leider noch nicht das Fixpack installiert, das die Klasse mitgebracht hat, deshalb kann ich es nicht mit einem Serveragenten probieren.

Kann es an der alten Serverversion liegen? Auch wenn der Code im Client läuft?

Ich habe die Auditor- Rolle in der Vault und kann manuell IDs extrahieren, außerdem habe ich das Häkchen für den "Programmatischen Zugriff" für mich gesetzt (in der Vault- Verwaltung). An den Berechtigungen sollte es also nicht liegen.

Jemand ne Idee?

[DominoDancing]

Hallo Torsten,

ja, den Fehler konnte ich so, wie von Dir beschrieben, nachvollziehen. Erst als ich den Parameter UserName von Common in Abbreviate geändert habe, funktioniert das bei mir nun sauber und ohne den Fehler 'Error accessing IDVault'. Ich nutze hier den Standard-Client in der Version 9.0.1 FP9 auf einem Server mit 9.0.1 FP9 HF139.

Liebe Grüße

[Tode]

Also ich habe erstmal mit Canonical probiert, aber auch Abbreviated geht bei mir nicht... Vielleicht liegt er wirklich daran, dass der Server noch nicht FP9 ist...

[DominoDancing]

Hallo Torsten,

... denkbar, würde mich aber trotzdem wundern. Alle anderen Parameter sind auch OK? Wenn ich den Pfad der id-Datei und/oder das Kennwort manipuliere, so dass diese nicht korrekt sind, erhalte ich ebenfalls 'Error accessing IDVault'. Ich habe also weiterhin die Parameter im Verdacht. Mit anderen Serverversionen kann ich leider nicht dienen. Alle Server laufen mit 9.0.1 FP9 HF139.

Liebe Grüße
René

[Tode]

Wie kann das Kennwort „nicht korrekt“ sein? Das ist doch das NEUE Kennwort der extrahierten Datei, oder?

Trotzdem Danke fürs Feedback, dann probiere ich mal weiter...

[DominoDancing]

Hallo Torsten,

... ähm, jetzt bünnsch verwürrt : Den Fehler erhältst Du doch bei Call idVault.Getuseridfile, oder? Und Getuseridfile holt sich doch erst einmal die entsprechende id-Datei. Der Parameter Passwort steht doch dann aber für das aktuelle Nutzerpasswort der id-Datei die im Parameter idFilePath angegeben ist und NICHT für ein neu zu vergebendes Passwort. Jetzt bin ich mir nicht mehr sicher, ob nur einer von uns beiden verwirrt ist ...

Liebe Grüße
René

[Tode]

OH f.... Du hast natürlich vollkommen recht: Ich hatte nach einer Möglichkeit gesucht, das "Extract ID from Vault" programmatisch nachzubauen... Und dann habe ich nur gelesen, was ich lesen wollte und dachte (auch aus den Code- Beispielen): das ist das neu zu vergebende Passwort.

Asche auf mein Haupt. Danke fürs Augen öffnen!

[eknori]

Hier meine 2ct zu dem Thema. https://www.eknori.de/2018-09-06/accessing-the-idvault-with-lotusscript/

[maxritti]

Hallo zusammen,


irgendwie stehe ich auch nach mehrfachem lesen des Postings hier und der Beschreibung von "NotesIDVault" auf dem Schlauch.
Mein Plan ist wie der von Tode, dass wir versuchen per Skript mehrere IDs aus der Vault zu extrahieren, da diese bereitgestellt werden müssen.

Und zwar sollen die IDs mit dem gleichen Kennwort extrahiert werden, wie es in der ID in der Vault hinterlegt ist.
Manuell geht das einwandfrei. Adminclient, ID extrahieren und das gleiche Noteskennwort eingeben und extrahiert ist die ID-Datei.

Jetzt versuche ich das mit einem 10.0.1FP3 Client, auf einem Server 9.0.1FP4 HF70. Ich weiss, recht alt, ist aber leider so.

Egal ob ich den Notesnamen als Common oder Abbreviated angebe und das Kennwort wie auch immer eingebe, kommt die Meldung "Error accessing IDVault".
Das auch mit der Script Lib von Eknori.

Der gleiche Code funktioniert in einem Client 10.0.1FP4 und einem Server 10.0.1FP3.

Spielt da mein Server 9.0.1FP4 HF70 doch noch eine Rolle, dass das extrahieren nicht klappt?

Sorry dafür, dass der etwas ältere Post wieder geöffnet wird, passt aber so schön.

[Tode]

Du unterliegst genau dem selben Irrtum wie ich: Die Klasse repräsentiert NICHT die Funktion "ID aus Vault extrahieren" des Admin- Clients: Bei dieser wird das Vault- Zertifikat des Admin verwendet, um die ID zu extrahieren, und ein NEUES (Einmal)Kennwort zu vergeben.

Die Funktion braucht aber das AKTUELLE Benutzerkennwort des Benutzers: In der Vault ist immer das letzte vom Benutzer vergebene Kennwort gespeichert, kein "generisches". Du benötigst also das Kennwort des Benutzers, um mit der Klasse IDs lokal abzuspeichern und kannst kein neues / eigenes Kennwort vergeben.

[maxritti]

Danke Dir.

Das Kennwort des Benutzer ist bekannt.
Es ist so, dass bei uns Notesuser registriert werden. Das Kennwort wird in einem Safe abgelegt. Der Helpdesk konfiguriert den Notesclient mit SSO. Dann bekommt der Benutzer den Client und muss gar kein Kennwort eingeben/ändern.

Somit müsste das Vorgehen doch passen.
Ich gebe bei dem strPassword das aktuelle Kennwort des Benutzers ein.

Was mich halt wundert ist, dass extrahieren per Skript in meiner Testumgebung mit 10.0.1FP3 klappt.
Aber bei dem 9.0.1FP4 Server mit 10.0.1FP3 Client nicht.

[Tode]

MOMENT: Die Klasse gibt es doch erst seit FP9... klar funktioniert die bei einem FP4 Server nicht (wenn der Agent nicht im Client läuft, sondern auf dem Server)...

UND: WIE konfiguriert Ihr SSO? Wenn Ihr das über den "alten" Weg mit dem Dienst macht, dann wird das ID- Kennwort jedesmal geändert, wenn der User sein Windows- Kennwort ändert, das wird nämlich synchronisiert. Dann hilft Dir Dein Kennwort im Safe genau gar nix mehr. Wenn Ihr aber NSL per Policy verwendet, dann funktioniert Euer Vorgehen (zumindest theoretisch).

[maxritti]

Der Agent läuft schon auf meinem Client.
Hat ja mal so auf dem Server auch nichts zu suchen. 

SSO läuft nicht über den Dienst. Der ist nicht aktiv.
Wir nutzen NSL.

Von daher stimmst Du mir ja zu, dass es funktionieren müsste.
In der Theorie.