Mit dem Tool „rfrusrcert“ (refresh user certificates) können Sie die Zertifikate eines oder mehrerer Benutzer aktualisieren.
Zielgruppe
- Administratoren
- Technische Berater
Beschreibung
Das Tool dient zum Aktualisieren der Zertifikate eines oder mehrerer nicht deaktivierten Benutzer. Nach dem das Tool aufgerufen wird, werden die neuen Benutzerzertifikate zu den angegebenen Benutzern zugeordnet und als CER-Datei gespeichert. Abgesehen davon wird auch eine Script-Datei als SCL-Datei erzeugt, die die Aufrufe des Tools „chgusr“ beinhaltet. Dadurch besteht die Möglichkeit, die Benutzerzertifikate in eine andere Konfigurationsdatenbank zu importieren, falls die ausgewählten Benutzer in dieser weiteren Datenbank vorhanden sind.
Befehl
Nachfolgend finden Sie den Befehl inklusive aller möglichen Parameter.
| rfrusrcert | -user:<id-1> … -user:<id-n>*
-rootCertificate:<id> [-sendCertificateMail] [-fullFileName:<text>] -certificateExportDirectory:<text> -importDirectory:<text> |
Parameter
Die Parameter des Befehls werden in der folgenden Tabelle erläutert. Die in eckigen Klammern gesetzten Parameter sind optional, die anderen hingegen sind Pflichtparameter. Für einige Parameter kann ein Stern (*) als Platzhalter angegeben werden, um damit alle möglichen Werte ausgeben zu können. Nicht alle Parameter können mehrfach genannt werden; nur die, die folgenden Zusatz an den Parametervariablen aufweisen, sind für die Mehrfachnennung zugelassen: „<str-1> … <str–n>“.
| Parameter | Erläuterung |
| -user:<str-1> …
-user:<str-n>* |
Name des Benutzers, dessen Zertifikat aktualisiert wird. |
| -rootCertificate:<id> | Aussteller, d. h. die Zertifizierungsstelle, die das zu erzeugende Zertifikat ausstellt. |
| [-sendCertificateMail] | Gibt an, ob ein Benutzerzertifikat per E-Mail an einen Benutzer zugeschickt werden muss. Hinweis: Ein Benutzerzertifikat ist per E-Mail erst dann zustellbar, wenn die entsprechende Aktivitätsdefinition aktiviert ist. Nähere Informationen finden Sie unter dem Dokument „Zertifikate erzeugen“. |
| [-fullFileName:<text>] | Name der zu erstellenden Skript-Datei als SCL-Datei, die sowohl im Dateisystem als auch im Knowledge Store an-gelegt werden kann. Die unterstützten Schemata für den Dateinamen sind “file:///C:/file.scl” und “kstore://XYZ12000/file.scl”. |
| -certificateExportDirectory:<text> | Ordner, in das Sie das Zertifikat als CER-Datei exportieren möchten. Geben Sie den vollständigen Pfad des Ordners mit dem Schema file:/// oder kstore:// an. |
| -importDirectory:<text> | Ordner, der als Wert für den Parameter „addCertificate“ des Tools „Benutzer ändern (chgusr)“ verwendet wird. |
Berechtigungen
Das Berechtigungskonzept sowie die generellen anwendungsbezogenen und Entity-bezogenen Berechtigungen können Sie in der Technischen Dokumentation im Dokument „Berechtigungen“ nachlesen.
Für diese Anwendung ist das folgende Business Entity relevant:
com.cisag.sys.configuration.obj.User
Beispiel
Ausgangsituation
Nehmen wir an, dass auf der Konfigurationsdatenbank CONF1 unter anderem die folgenden Benutzer erfasst sind: USER1A, USER2B und USER3C. Die Benutzer mit den gleichen Namen existieren auf der weiteren Konfigurationsdatenbank CONF2.
Mithilfe des Tools „Konfigurationsdaten prüfen (chkcnf)“ wurde festgestellt, dass die Zertifikate für die Benutzer USER1A, USER2B und USER3C bald ablaufen.
Mögliche Lösung
Es wird eine Zertifizierungsstelle angelegt namens CA2020, deren Gültigkeit ausreichend ist. Der Tool-Aufruf könnte wie folgt aussehen:
rfrusrcert –user:USE* -rootCertificate:CA2020 -sendCertificateMail -certificateExportDirectory:file:///c:/tmp
-importDirectory:file:///d:/tempcrt
-fullFileName:file:///c:/tmp/test.scl
In diesem Fall werden die Benutzerzertifikate den Benutzern, die der Maske genügen, zugeordnet und per E-Mail des Benutzers gesandt, dann wird eine Datei „test.scl“ angelegt, die folgende Aufrufe beinhaltet:
chgusr -user:USER1A -addCertificate:file:///d:/tempcrt/USER1A.cer
chgusr -user:USER2B -addCertificate:file:///d:/tempcrt/USER2B.cer
chgusr -user:USER3C -addCertificate:file:///d:/tempcrt/USER3C.cer
Diese Datei können wir später im ToolShell des Application-Servers, der die Verbindung zur der Konfigurationsdatenbank CONF2 hat, mittels des Kommandos „call“ aufrufen. Dabei muss noch beachtet werden, dass die CER-Dateien unter „d:/tempcrt“ tatsächlich liegen und den Application-Server darauf den Zugriff hat. Dieser Application-Server kann natürlich auf den ganz anderen Rechner laufen als der Application-Server, auf dem die SCL-Datei erzeugt wurde.