Sicherer Kennwortspeicher

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

In Version 8.1.0 und Version 7.1.6 und früheren Clients wurde das IBM Spectrum Protect -Kennwort 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 alle IBM Spectrum Protect -Kennwörter in den Keystores von IBM® Global Security Kit (GSKit) gespeichert. Der Importprozess für Serverzertifikate ist vereinfacht. Informationen zum Importieren von Serverzertifikaten finden Sie in IBM Spectrum Protect -Client/Server-Kommunikation mit Secure Sockets Layer konfigurieren.

Wenn Sie ein Upgrade von einem früheren Client, der die alten Kennwortpositionen verwendet, auf den IBM Spectrum Protect 8.1.2 oder höher durchführen, werden die vorhandenen Kennwörter in die folgenden Dateien im neuen Kennwortspeicher umgelagert:
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-BetriebssystemeLinux-BetriebssystemeFür Clients von Data Protection for VMware Das Verwaltungskennwort des Servers der Data Protection for VMware -GUI wird in einen Keystore migriert.

Windows-Betriebssysteme

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.

Mac OS X-BetriebssystemeOracle Solaris-BetriebssystemeLinux-BetriebssystemeAIX-Betriebssysteme

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.
Mac OS X-BetriebssystemeOracle Solaris-BetriebssystemeLinux-BetriebssystemeAIX-Betriebssysteme

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.

Windows-Betriebssysteme

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