Sicherer Kennwortspeicher

Ab IBM Storage Protect Version 8.1.2 und Version 7.1.8 wird die Position des IBM Storage Protect-Kennworts geändert.

In Version 8.1.0 und Version 7.1.6 und früheren Clients wurde das Kennwort IBM Storage Protect in der Windows-Registry für Windows-Clients und in der Datei TSM.PWD auf UNIX-und Linux® -Clients gespeichert.

Ab Version 8.1.2 und Version 7.1.8 werden die IBM® Global Security Kit (GSKit) Schlüsselspeicher zum Speichern aller IBM Storage Protect Passwörter verwendet. Der Importprozess für Serverzertifikate ist vereinfacht. Informationen zum Importieren von Serverzertifikaten finden Sie unter IBM Storage Protect-Client/Server-Kommunikation mit Secure Sockets Layer konfigurieren.

Wenn Sie ein Upgrade auf den Client von IBM Storage Protect 8.1.2 oder höher von einem früheren Client durchführen, der die alten Kennwortpositionen verwendet, werden die vorhandenen Kennwörter in die folgenden Dateien in dem neuen Kennwortspeicher migriert:

TSM.KDB: In dieser Datei werden die verschlüsselten Kennwörters gespeichert.
TSM.sth: In dieser Datei wird der Verschlüsselungszufallsschlüssel gespeichert, mit dem Kennwörter in der Datei TSM.KDB verschlüsselt werden. Diese Datei wird durch das Dateisystem geschützt. Diese Datei wird für automatisierte Operationen benötigt.
TSM.IDX: Eine indexierte Datei zur Protokollierung der Kennwörter in der Datei TSM.KDB.

Windows-Betriebssysteme Linux-Betriebssysteme Für Data Protection for VMware -Clients wird das Verwaltungskennwort des Data Protection for VMware -GUI-Servers in einen Keystore migriert.

Kennwortpositionen auf Windows-Clients

Auf Windows-Clients werden die Kennwörter im Registrierungsschlüssel SOFTWARE\IBM\ADSM\CurrentVersion\BackupClient\Nodes und im Registrierungsschlüssel SOFTWARE\IBM\ADSM\CurrentVersion\Nodes in den neuen Kennwortspeicher migriert.

Die Kennworteinträge in diesen Registrierungsschlüsseln werden nach der Migration gelöscht.

Die migrierten Server- und Verschlüsselungskennwörter werden in den Kennwortspeichern in separaten Unterverzeichnissen des verborgenen Verzeichnisses C:\ProgramData\Tivoli\TSM\baclient gespeichert. Durch eine derartige Trennung der Serverkennwörter ist es möglich, dass ein Administrator einem Benutzer ohne Verwaltungsaufgaben den Zugriff auf einzelne Kennwörter gewährt, ohne dass dieser Benutzer Zugriff auf alle anderen Kennwörter erhält. Die folgenden Verzeichnisse sind Beispiele für Kennwortdateipositionen:

C:\ProgramData\Tivoli\TSM\BAClient\NodeName\ServerName
C:\ProgramData\Tivoli\TSM\BAClient\(VCB)\ServerName
C:\ProgramData\Tivoli\TSM\BAClient\(DOMAIN)\ServerName
C:\ProgramData\Tivoli\TSM\BAClient\(FILER)\ServerName

Der Zugriff auf die Kennwortstashdateien (TSM.sth) ist auf den Ersteller des Schlüsselspeichers, auf Administratoren und das System beschränkt. Es ist ein Dienstprogramm (dsmcutil addace) verfügbar, mit dem Windows-Benutzer ohne großen Aufwand Zugriffssteuerungslisten für Kennwortdateien ändern können. Weitere Informationen finden Sie unter ADDACE und DELETEACE.

Kennwortpositionen auf UNIX-und Linux -Clients

Auf UNIX-und Linux -Clients werden die vorhandenen Kennwörter in den TSM.PWD -Dateien in den neuen Kennwortspeicher an derselben Position migriert. Bei Rootbenutzern lautet die Standardposition für den Kennwortspeicher /etc/adsm. Bei Benutzern ohne Rootberechtigung wird die Position des Kennwortspeichers mit der Option passworddir angegeben.

Die Datei TSM.PWD wird nach der Migration gelöscht.

Hinweis: Der neue Kennwortspeicher befindet sich in den folgenden Fällen nicht an der Standardposition (/etc/adsm):

Die Datei TSM.PWD ist im Verzeichnis /etc/adsm nicht vorhanden.
Die Optionsdatei gibt eine Option passworddir an, die auf eine andere Position zeigt.

Trusted Communication Agent nicht mehr verfügbar

Der Trusted Communications Agent (TCA), der zuvor von Nicht-Root-Benutzern in Version 8.1.0 und Version 7.1.6 und früheren Clients verwendet wurde, ist nicht mehr verfügbar. Rootbenutzer können Benutzern ohne Rootberechtigung die Verwaltung ihrer Dateien mit den folgenden Methoden ermöglichen:

Help-Desk: Bei der Help-Desk-Methode führt der Rootbenutzer alle Sicherungs- und Zurückschreibungsoperationen aus. Der Benutzer ohne Rootberechtigung muss sich an den Rootbenutzer wenden, um die Sicherung oder Zurückschreibung bestimmter Dateien anzufordern.
Berechtigter Benutzer: Bei der Methode mit einem berechtigten Benutzer erhält ein Benutzer ohne Rootberechtigung Schreib-/Lesezugriff auf den Kennwortspeicher. Hierbei wird die Option passworddir verwendet, um auf eine Kennwortposition zu zeigen, auf die der Benutzer ohne Rootberechtigung Schreib-/Lesezugriff hat. Mit dieser Methode können Benutzer ohne Rootberechtigung ihre eigenen Dateien sichern und zurückschreiben, die Verschlüsselung verwenden und ihre eigenen Kennwörter mit der Option passwordaccess generate verwalten.
Weitere Informationen finden Sie unter Benutzern ohne Rootberechtigung die Verwaltung ihrer eigenen Daten ermöglichen.

Ist keine dieser Methoden zufriedenstellend, müssen Sie die früheren Clients verwenden, die über den Trusted Communication Agent (TCA) verfügen.

Kennwortpositionen in Clusterumgebungen

Wird der Client in einer Clusterumgebung ausgeführt (CLUSTERNODE YES in der Clientoptionsdatei), werden die Kennwortdateien in einem Unterverzeichnis des Verzeichnisses der Clientoptionsdatei gespeichert. Der Name des Unterverzeichnisses lautet:

NODES\NodeName\ServerName

Verwenden Sie für die Speicherung einer verschlüsselten Kennwortdatei während der Einrichtung einer Clusterumgebung die Option clustersharedfolder, um die Verzeichnisposition anzugeben, an der die verschlüsselte Kennwortdatei gespeichert werden soll. Weitere Informationen finden Sie unter Clustersharedfolder.

In einer Clusterkonfiguration wird die Optionsdatei auf einer Clusterplatte gespeichert, damit der Übernahmeknoten auf sie zugreifen kann. Die Kennwortdateien müssen auch auf einer Clusterplatte gespeichert werden, damit das generierte Kennwort des Clients für Sichern/Archivieren dem Übernahmeknoten nach einer Störung zur Verfügung steht.

Wenn sich beispielsweise die Datei dsm.opt im Verzeichnis c:\ClusterStorage\Volume1\SPData befindet, der Knotenname Cluster-B und der Servername Bigdata lautet, ist die Position für Kennwortdateien

C:\ClusterStorage\Volume1\SPdata\Nodes\Cluster-B\Bigdata