ADSM-L

Re: Windows NT client

1997-04-29 15:34:29
Subject: Re: Windows NT client
From: "Prather, Wanda" <PrathW1 AT CENTRAL.SSD.JHUAPL DOT EDU>
Date: Tue, 29 Apr 1997 15:34:29 -0400
No Jerry, you haven't missed anything, it's just ugly.

The password must exist 3 places - on the server, in the registry (for
the use of the Scheduling Service), and in the user's head (so he can
supply the password when prompted by the GUI).

When you do the Scheduling Service install on WinNT, dsmsvci prompts the
user for the password and encrypts it into the registry.

If the user changes the password from the GUI,  the password is only
changed on the server, not in the registry.
The Scheduling Service will not know the password to run the unattended
backup, because the password no longer matches the registry.  The user
must be told that if he changes the password in the GUI, he must ALSO
rerun dsmsvci.exe to update the registry.

If the password expires, the next time the Scheduling Service runs, the
ADSM server will generate a new password, and the Scheduling Service
will encrypt it into the registry.  SO,  now the Server and the Registry
have the new password, but the user doesn't.   So the User must run
dsmsvci.exe to DISPLAY the password from the Registry before he can use
the GUI again.

dsmsvci can be used to install, change, or display the password in the
registry.  You must be an NT administrator on the local machine before
you can run dsmsvci.exe.

The same thing happens on Win95, except you use showpw.exe and
updatepw.exe to display or change the password.  There is no security
for showpw.exe.

I got it in my head that showpw.exe and updatepw.exe are for Win95 only,
and dsmsvci.exe is for WinNT only.  If that is wrong, I would appreciate
it if someone would let me know.

Another way to update the registry is to just open a DOS window and type
DSMC SCHEDULE, and DSMC will prompt you for the password to encrypt in
the registry, if the one in the registry doesn't match the one on the
server.  I don't know if this is the "supported" way, but it seems to
work OK on both platforms.

Running dsmsvci.exe SHOULD display your password from the registry on an
NT machine.  I have had passwords expire, had new ones generated and
encrypted into the registry, and been able to display them using
dsmsvci.exe, just as advertised.

I have had 4 Win95 machines that got into a state where I could not
display the password - when I ran showpw.exe, it just displayed garbage.
 I am pretty sure that what happened on two of them was that the user
changed the ADSM NODENAME, then ran the Scheduler again.  The registry
entry is tied to the ADSM NODENAME on both Win95 and WinNT.  If you
change the nodename, I think you definitely will have problems with the
encrypted password.

We (and another site I know of) have stopped forcing ADSM to expire the
passwords, just because it is SO messy for users.  It's bad enough (and
rather inexcusable, I think) that updating the password on the server
doesn't update the registry as well, and the GUI does not use the
password in the registry on Windows platforms as it does on AIX.


 =======================================================================
=
Wanda Prather
Johns Hopkins Applied Physics Lab
301-953-6000 X8769
wanda_prather AT jhuapl DOT edu

"Intelligence has much less practical application than you'd think."
              - Scott Adams/Dilbert
 =======================================================================
=






>----------
>From:  Jerry Lawson[SMTP:jlawson AT thehartford DOT com]
>Sent:  Tuesday, April 29, 1997 7:38 AM
>To:    ADSM-L AT VM.MARIST DOT EDU
>Subject:       Re: Windows NT client
>
>---------------------------- Forwarded with Changes
>---------------------------
>From: INTERNET.OWNERAD at SNADGATE
>Date: 4/28/97 3:23PM
>To: Jerry Lawson at ASUPO
>*To: *ADSM-L at SNADGATE
>Subject: Re: Windows NT client
>-----------------------------------------------------------------------------
>--
>
>Leonard -
>
>I think I must be missing something very basic here with the NT service
>installation.  If you put passwordaccess generate in a DSM.OPT file for an NT
>machine, and install the service, as I understand it, when the password
>expires,
>the service will "know" what the new password is.  But if the password is not
>usable by the GUI interface, how does the customer know what the password is?
>
>I think I recreated the problem you stated in your note - I tried to display
>the
>password via the DSMCSVCI display password function, but received a registry
>error.  I then tried the update password function, and took an error
>(application exception - but I have Notes on my machine, and thus have QNC
>instead of DrWatson......).
>
>Jerry Lawson
>jlawson AT thehartford DOT com
>
>______________________________ Forward Header
>__________________________________
>Subject: Re: Windows NT client
>Author:  INTERNET.OWNERAD at SNADGATE
>Date:    4/28/97 3:23 PM
>
>
>On Mon, 28 Apr 1997 09:36:27 -0500 Kauffman, Tom said:
>>We're trying the Windows NT client for a couple of servers, and I've run
>>into an item I have a question about:
>>
>>We're running with password=generate in the dsm.opt; the command-line
>>dsmc seems to know this and connects to the server correctly, but the
>>gui client wants the base (original) password to be entered before it
>>connects. What did I miss here?
>
>You just missed a little doc. The password=generate only works for the
>linemode client (dsmc.exe) and the scheduler service client (dsmcsvc.exe).
>The GUI client does not use it. You can put the password in the dsm.opt
>file for the GUI client to use. But I do not believe that the password=
>generate process will update the  source line in the dsm.opt file.
>
>   There are at least two bugs with the password=generate process.
>   The first is a problem with the use of upper vs lower case node names
>   given with the dsmsvci.exe program. This is fixed with ptf 6.
>
>   There is a bug if you do not specify a nodename parm line in the dsm.opt
>   file. The password stored in the registry for the dsmc.exe file is not
>   usable with the dsmcsvc.exe program. The Password stored in the registry
>   by the dsmcsvci.exe1or updatepw.exec programs is not usable with the
>   dsmc.exe program. Although the password is good with the adsm server
>   in both cases. The adsm support folks can not reproduce this, so I
>   suspect that they will never get this one fixed. (The reason that we
>   wanted this, is that for most folks this is the only line in the dsm.opt
>   file that is unique to a pc node. If this is not in the file we could
>   just overwrite the file with an updated dsm.opt file whenever we
>   wanted a gobal change to the exclude list).
>
>>
>>Are there any 'gotchas' with the NT client under NT 4.0?
>
>With PTF 6 there is a problem if the pc has an audio cd-rom loaded.
> The adsm client (dsmc.exe, dsm.exe and dsmcsvc.exe) will die with
>a divide by zero error. This can also occur with some nfs code.
>The problem has been fixed, But the last I heard we can not order or
>fetch the fix. Rumor has it that we should get the fix with version 3
>which should be out in the aug/sept timeframe. Remember rumor only.
>This one gives
>
>You can look at the client readme files for a list of fixed and still broken
>fixes as of Jan 1997. If you have access to IBMLINK you can check out
>the list of apars for the windows 32 client. You can use the search terms
>pids/565511902 lvls/an1
>
>>
>>Tom Kauffman
>>Sr. Technical Advisor
>>NIBCO, Inc.
>
>-------------------------------------------------------------------------
>Leonard Boyle, Mainframe support            snolen AT vm.sas DOT com
>SAS Institute Inc.                          ussas4hs@ibmmail
>Room E206                                   (919) 677-8000 ext 6241
>203 SAS Campus Drive
>Cary NC 27513
>
<Prev in Thread] Current Thread [Next in Thread>