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 AT VM.MARIST DOT 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 AT VM.MARIST DOT 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
> >>>
|
