ADSM-L

Re: Better passwords in TSM

2003-04-10 09:37:39
Subject: Re: Better passwords in TSM
From: Andrew Raibeck <storman AT US.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 10 Apr 2003 06:36:48 -0700
> A. Does the TSM client (all of them: GUI, web, and linemode
> backup/archive, and Administrative) send the password to the TSM server
> in an encrypted form, or in clear text?

See http://msgs.adsm.org/cgi-bin/get/adsm0302/707.html for additional
information.



> B. Is there a way to enforce password strength rules? How can I tailor
> those rules?

Use SET MINPWLENGTH on the server to set a minimum password length.



> D. If a client node has been using Password Generate, why does its
> Password Change Date show up as a long time ago. Shouldn't it be the
> date of last use, since Password Generate sets a new password with each
> use?

PASSWORDACCESS GENERATE does not cause a new password to be created every
time the user connects. See the PASSWORDACCESS option in the client manual
for more info on what this option does.



> F. If a client node has been using Password Generate, and I change its
> Password Expiration interval to something shorter than it was, which is
> shorter than its Last Password Change date, what will happen? Hopefully
> nothing at all - Password Generate will simply continue to operate.

Yes. When the password expires, PASSWORDACCESS GENERATE will cause a new
password to be created.



> G. How secure is Password Generate - really?

MY PERSONAL OPINION - and note that I am not an expert on security
matters: For the most part, PASSWORDACCESS GENERATE is as secure as your
workstation/workstation login account (and I believe this is a key
element). PASSWORDACCESS PROMPT is arguably more secure since a user has
to know the password to get in (as long as they don't do something foolish
like write it down somewhere, or stick it in a file on their computer).
With PROMPT, if someone hacks your registry, hard drive, or login account,
they still can't get to your TSM data. The drawback to this is loss of
convenience, as automated TSM functions rely on being able to get the
password without prompting the user. Also use caution in granting access
(via SET ACCESS) to other TSM users to restore your data.



> H. Is there any way to enforce the auditor's rules for Administrative
> Clients?

Not all of them, no. The minimum password length can be handled; the
at-least-annual expiration can be handled; and when passwords are
exchanged, they are not in clear text.

Note: if you use UPDATE NODE FORCEPWRESET, be sure to reset both the node
AND the corresponding admin account in order to ensure that the password
is changed. See IC34975 for more info on this.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.eyebm DOT com (change eye to i to reply)

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.




Remco Post <r.post AT SARA DOT NL>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
04/10/2003 06:00
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: Better passwords in TSM



On Wed, 9 Apr 2003 18:30:58 -0500
Roger Deschner <rogerd AT UIC DOT EDU> wrote:

> A. Does the TSM client (all of them: GUI, web, and linemode
> backup/archive, and Administrative) send the password to the TSM server
> in an encrypted form, or in clear text?
>

encrypted.

> B. Is there a way to enforce password strength rules? How can I tailor
> those rules?
>

Nope, (LART the user if he/she does it wrong)

> C. If not, is there a way to require all TSM clients to use Password
> Generate? (The auditors seem to like what Password Generate does.)
>

Nope.

> D. If a client node has been using Password Generate, why does its
> Password Change Date show up as a long time ago. Shouldn't it be the
> date of last use, since Password Generate sets a new password with each
> use?
>
> E. Is there a way I can tell if a client uses Password Generate?
>

nope

> F. If a client node has been using Password Generate, and I change its
> Password Expiration interval to something shorter than it was, which is
> shorter than its Last Password Change date, what will happen? Hopefully
> nothing at all - Password Generate will simply continue to operate.
>
> G. How secure is Password Generate - really?
>
> H. Is there any way to enforce the auditor's rules for Administrative
> Clients?
>

help set passexp

> I'm trying to avoid having all 1,000 clients call me on the telephone on
> one day to complain that their passwords are no longer valid, while
> still making the auditors happy.
>
> Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT 
> edu
> ======= Warning: The Surgeon General has found that smoking may ========
> ======== cause some individuals to ignore the Surgeon General. =========


--
Met vriendelijke groeten,

Remco Post

SARA - Stichting Academisch Rekencentrum Amsterdam    http://www.sara.nl
High Performance Computing  Tel. +31 20 592 8008    Fax. +31 20 668 3167

"I really didn't foresee the Internet. But then, neither did the computer
industry. Not that that tells us very much of course - the computer
industry
didn't even foresee that the century was going to end." -- Douglas Adams

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