Rainer, The windows client is using computername to encrypt passwords in registry. When one changes computername, the stored passwords also become invalid. So on Windows, you should do the same , i.e. delete (or rename, just in case) the corresponding registry entries which are currently located under HKLM\SOFTWARE\IBM\ADSM\CurrentVersion\BackupClient\Nodes Unfortunately, there is no TSM command or utility for doing that.
You are right, TSM should not be using wrong encryption key. As a matter of fact, there is already an APAR - please see IC48782: http://www-1.ibm.com/support/docview.wss?uid=swg1IC48782 It was fixed on Mac in 5.3.4 and is planned to be fixed on unix, linux and windows in 5.4.0. Alexei Kojenov TSM Client Development "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> wrote on 07/31/2006 11:12:48 PM: > Alexei, > thanks a lot for your detailled explanation ! It's clearer to me now :-) > ... just only two more questions ? > What about the windows-Clients - do I then (when changing the > windows system-name) > also have to manually remove the equivalent 'TSM.PWD' entry > in the registry or elsewhere ? > if so: Is that something to be done with the windows registry-editor > or is there a tsm-windows-client function that can do for me the > renaming/refresh of the locally stored tsm-pwds on windows so I can reenter > the (same) encryption key passord once again ? > > About the 'using some garbage encryption key' : Isn't that something > where the tsm-client really should say 'NO' > stop backup and generate an error message ? > ... preventing the user to have something unrecoverable > - is there an existing apar ? > > Best regards > Rainer > > > Alexei Kojenov schrieb: > > > Rainer, > > > > Your data is always encrypted with the key generated from the password that > > you enter, regardless of the hostname. The hostname is only used to store > > the password locally. For example, > > > > 1) Let's say the hostname is 'mercury' > > 2) You run your first backup and are prompted for encryption key password. > > Let's say you enter 'secret' > > 3) The string 'secret' is encrypted with 'mercury' and is stored in TSM.PWD > > 4) The data are encrypted with 'secret'. > > 5) On the next backup, the stored password is retrieved from TSM.PWD and > > decrypted with 'mercury', and 'secret' is used for data backup. > > > > 6) Let's say you change the hostname to 'venus' and delete/rename existing > > TSM.PWD > > 7) TSM prompts you for encryption key password and you enter 'secret' > > again. > > 8) 'secret' is encrypted with 'venus' and is stored in TSM.PWD (note, > > TSM.PWD will binary differ from the one from step 3, because the key, which > > is dependent on hostname, is different) > > 9) The data are encrypted with 'secret' (the same as in step 4, regardless > > of hostname). > > 10) On the next backup, stored password is decrypted with 'venus', and the > > same password 'secret' is used for backup. > > > > So you shouldn't worry about validity of your old backups as long as you > > use the same encryption password and you deleted/renamed TSM.PWD when > > changing the hostname. > > > > The problems come when someone changes the hostname bud does not delete > > TSM.PWD. In the example above, a backup following the hostname change will > > try to decrypt stored password with 'venus' and will get an incorrect > > result (because 'secret' was originally encrypted with 'mercury'!), so the > > new backups will be using some garbage encryption key, and it would be > > really hard to restore the new data correctly if TSM.PWD is lost or if the > > restore happens on a different machine. > > > > Alexei > > > > > > "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> wrote on 07/27/2006 > > 06:31:17 AM: > > > > > >>Hi Alexei, > >> > >>thanks for your hint - now i come with a new question concerning the > >>'restore' : > >>Because nothing changes other than the 'hostname' of that linux system > > > > ... > > > >>... what about the data that has been backed up prior to the time > >>I rename the hostname and reenter the 'encryption key password' ? > >> > >>Because I stay with 'encryptkey save' what happens when (some time) > >>I may do a full restore of the '/home/' -Filespace ? > >> > >>Because this Filespace '/home/' has data backed up that is encrypted > >>with both encryption-key-usage of the old and the new 'hostname' > >>( but always the same 'tsm-Nodename' ) > >>... will I am able to restore(and decrypt) all of it ? > >> > >>... i fear to go into problems - Or do I have to start backup again > >>from 'zero' - for example : > >>by renaming the filespace on the server > >>at the time changing the hostname ? > >> > >>Thanks again for any hints ! > >>-- that is something really confusing to me :-| > >> > >>Rainer > >> > >> > >> > >>Alexei Kojenov schrieb: > >> > >> > >>>Rainer, > >>> > >>>You need to make TSM client prompt you for encryption key password on > > > > the > > > >>>next backup after you changed the hostname. The only way to do this is > > > > to > > > >>>rename/remove the existing TSM.PWD file (this is the file where TSM > > > > client > > > >>>stores its passwords). You should rename this file rather than delete > > > > it, > > > >>>in case you have problems and want to revert. > >>> > >>>Alexei > >>> > >>>----------------------- > >>> > >>>Dear TSmers, > >>> > >>>we have tsmserver 5.3.3.2 /solaris and tsm-Client 5.3.4.0 /linux. > >>> > >>>On the Client we use tsm-encryption : > >>>The 'nodename' Option is set in the dsm.sys and also the > >>>'encryptkey save' OPtion is set and 'encryptiontype AES128' is also > > > > set. > > > >>>The inclexc-File contains a line like 'include.encrypt *' > >>>So far anything runs fine :-) > >>> > >>>Problem: Next week we have to change the 'hostname' of that > > > > linux-server. > > > >>>The Question now is : - if any - what steps are to be done at the > >>>tsm-Client ? > >>>... and even at the tsm-server ? > >>>The (tsm)nodename won't be changed. > >>>Do I need the TSM-Client in a manual way give once again the > >>>encryption-key password to let the encryption-key be generated ? > >>>Or is there nothing to be done at the Client ? > >>> > >>>I have looked throgh the lists and docs and havent't found any > >>>'procedures' for that scenario - just pointers to dependancies on the > >>>system's hostname. > >>> > >>>Thanks in advance for any hints , recipe or links ... ! > >>>Rainer > >>>
