ADSM-L

Re: cleint passwd

2003-07-24 13:39:29
Subject: Re: cleint passwd
From: Muthyam Reddy <MREDDY AT JOY DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 24 Jul 2003 13:38:43 -0400
** High Priority **

thanks a lot.....

>>> rogerd AT UIC DOT EDU 07/24/03 01:58AM >>>
One basic question, with PASSWORDACCESS GENERATE in effect, how could
the password become forgotten? That cannot happen. With PASSWORDACCESS
GENERATE in effect, the end-user does not need to remember their
password at all, except in the rare case of restore from a hard drive
failure or some other reason for a complete reinstall of the Client
Program. That's the whole point.

But regardless, sometimes passwords just do get out of sync with
PASSWORDACCESS GENERATE. Here's how to recover from that problem:

1. UPDATE NODE nodename newpassword FORCEPWRESET=YES

Why do I use FORCEPWRESET=YES? Basic Good Security Practices. Once a
password has been transmitted in an email message, which is the note
from me to them advising them what this new password is, it is "rancid"
and needs to be thrown out as soon as possible. I know that any plea,
"Please change it soon!" will go ignored.

2. Tell the client end-user the password you just set for them. (It's
only good for one use, so you do not need to be especially careful about
security. It's OK to send it in email or tell it over the phone. If Step
3 below works, you can be sure it was not stolen in transit, because
Step 3 changes it to something else.)

3. Have them start the regular manual Backup Archive GUI client.
   3a. They will get an error message about an invalid password. They
       should ignore this message and click "OK".
   3b. They will be prompted for that new password you just set for them
   3c. A somewhat surprising popup will appear saying that the password
       has been changed (even though nobody asked for it to be changed
       and nobody typed in any new password.)

What has just happened is that the old password which was stored
(encrypted) in the Registry or some other secret place by the TSM client
was found not to match by the server. That's because you just changed it
on the server. So it prompted for a password, and the end-user typed in
the same one that you just set on the server and they matched - so they
got logged in OK. That password was then found to have expired, because
of the FORCEPWRESET=YES parameter that you specified, so the client and
the server made up a completely new random password, set it on the
server, and encrypted it and stored it back in the top secret place on
the client.

4. All those messages in 3 above will look bad. Very bad. Expect the
end-user to panic and call you on the phone. It is misleading - actually
now everything is very good, and will soon be working completely
normally again. All of this is working as designed and intended; it's
just that the messages make it look bad.

5. It should now be possible to close the Backup Archive GUI Client
program and reopen it again without typing in the password -
PASSWORDACCESS GENERATE should now be working again just fine. If the
end-user now wants to set a password that they know, they should set
that at this point while in the Backup Archive GUI Client, however
this step is strictly optional.

6. If they are using the Client Scheduler, have the end-user reboot
their machine. The Client Scheduler should now come up normally and
resume its workings just fine. Check it by examining the bottom of file
dsmsched.log.

I've got two very confused end-users I'm trying to lead through this
process right now. There ought to be some way to make it more
straightforward. I've got a PMR open right now against the messages,
even though the Client and Server programs are all ultimately working as
they should. There is an interaction between PASSWORDACCESS GENERATE,
FORCEPWRESET=YES, and the Client Scheduler Program that is complex and
not easily understood. (It's taken me two days of fiddling.) There is no
need to turn off authentication, not even temporarily, and you can
maintain Good Security Practices. It's just a bit complicated, and
inelegantly documented by the messages that occur in the process.

P.S. The Client Scheduler appears to require PASSWORDACCESS GENERATE.
I am still researching this, and it may be platform-dependent.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu 


On Wed, 23 Jul 2003, Muthyam Reddy wrote:

>** High Priority **
>
>Hi everyone,
>
>What is the recommended way to set a client's password after it is
>forgotten without turning off authentication?  I can't seem to find
>this in any of the docs.
>
>when I set UPDATE NODE <nodename> <password>, sever scheduled backups failing.
>
>FYI: in dsm.sys of every client I have [asswordaccess generate]
>
>thanks
>/muthyam
>
>
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>This electronic mail transmission contains information from Joy Mining 
>Machinery
>which is confidential, and is intended only for the use of the proper 
>addressee.
>If you are not the intended recipient, please notify us immediately at the 
>return
>address on this transmission, or by telephone at (724) 779-4500, and delete
>this message and any attachments from your system.  Unauthorized use, copying,
>disclosing, distributing, or taking any action in reliance on the contents of
>this transmission is strictly prohibited and may be unlawful.
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
><<privacy>>
>

<Prev in Thread] Current Thread [Next in Thread>