ADSM-L

Re: Another TSM mystery...

2002-06-23 11:31:39
Subject: Re: Another TSM mystery...
From: Zlatko Krastev/ACIT <acit AT ATTGLOBAL DOT NET>
Date: Sun, 23 Jun 2002 14:30:15 +0300
Client stores the password in encrypted form. Both encrypted and
unencrypted form were treated as zero-terminated string and from there
comes the bug. If encrypted form contained NULL (\0x00) character
somewhere (not necessarily as first char) it was treated as end-of-string
and the rest of password was ignored. Thus no match and authentication
problems.
Fix was to handle encrypted form as binary array (with \0x00 being
ordinary byte value) and not as string.

Zlatko Krastev
IT Consultant




Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To:     ADSM-L AT VM.MARIST DOT EDU
cc:

Subject:        Re: Another TSM mystery...

Is "passwordaccess generate" in the dsm.sys (or dsm.opt if NT) for this
client?  If so, it may be a known problem that's been discussed here
before... the client and server will generate a new password periodically,
and it is kept encrypted in a file on the client.  Occasionally, the
generated password will start with a hex '00', which causes that behavior.
I'm not sure if it must start with '00', or only contain it, and I'm not
sure if it's the encrypted or un-encrypted form that contains the '00'...
but we have had this happen, and had to reset the password at the server,
then manually run a client session and answer the password prompt with the
new password...

HTH
Robin Sharpe
Berlex Labs



                    "Hunley, Ike"
                    <Ike.Hunley@B
                    CBSFL.COM>    To:    ADSM-L AT VM.MARIST DOT EDU
                                  cc:    (bcc: Robin Sharpe/WA/USR/SHG)
                    06/17/02      Subject:
                    05:05 PM             Another TSM mystery...
                    Please
                    respond to
                    "ADSM: Dist
                    Stor Manager"







The TSM server received this message 2 weeks ago, last week and today....
ANR0424W Session 39912 for node HOC0843P12 (TDP Infmx AIX42) refused -
invalid
ANR0424W password submitted.

Each time we reset the password, issuing

     UPD NODE nodename pswd PASSEXP=0

which should make this a non- expiring password.

How does a perfectly good password, suddenly invalid(no one made changes
they cared to admit to...)?
What would make a non-expired password expire?



Blue Cross Blue Shield of Florida, Inc., and its subsidiary and
affiliate companies are not responsible for errors or omissions in this
e-mail message. Any personal comments made in this e-mail do not reflect
the views of Blue Cross Blue Shield of Florida, Inc.
<Prev in Thread] Current Thread [Next in Thread>