Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!decvax!ucbvax!YALE.ARPA!LEICHTER-JERRY From: LEICHTER-JERRY@YALE.ARPA.UUCP Newsgroups: mod.computers.vax Subject: Re: Access Control Information with Secondary Password Message-ID: <8701151147.AA17776@ucbvax.Berkeley.EDU> Date: Thu, 15-Jan-87 06:47:17 EST Article-I.D.: ucbvax.8701151147.AA17776 Posted: Thu Jan 15 06:47:17 1987 Date-Received: Thu, 15-Jan-87 23:53:28 EST Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Organization: The ARPA Internet Lines: 55 Approved: info-vax@sri-kl.arpa How must the explicit DECNET-access control information field look like for users with a secondary password (not for proxy login's)? Just specify- ing the primary one (node"user pwd1"::) produces "network partner exited", also specifying the second one after the first (node"user pwd1 pwd2"::). Indeed, after looking at the accounting file, the network process bombs out with "access violation". The DECnet protocols provide no mechanism for passing multiple passwords. The form NODE"USER PWD1 PWD2":: is actually a misreading of the DECnet syntax NODE"USERNAME PASSWORD ACCOUNT"::, where the "ACCOUNT" field is intended to specify something like an account to charge to. VMS has no such concept; in fact, I think only TOPS-20 ever used that field with the intended meaning. For incoming access, VMS generally ignores "account" information. It's become customary to use the "account" information as a secondary password for systems that use THAT concept. This has mainly been RSTS systems (though I'm not sure secondary passwords have ever been a supported part of RSTS, as opposed to an ad hoc addition that many sites made - easy to do since the RSTS LOGIN program was shipped - is still shipped? - as (BASIC) source code). It would be natural for VMS to use the account field in the same way, but I can't find anything in the documentation that claims it does. I experimented a bit as follows. Consider account TEST, with password A, secondary password B. Then: DIR 0"TEST X B":: Login information invalid at remote node DIR 0"TEST A B":: Network partner exited DIR 0"TEST X":: Login information invalid at remote node DIR 0"TEST A":: Network partner exited This makes it look as if LOGINOUT is validating the primary password, and then exiting when it can't get hold of the secondary. (This is on VMS V4.5, BTW.) So, I suspect that the answer is that an account with a secondary password cannot be accessed via DECnet, using explicit access control. Note that secondary passwords are meant for special circumstances - for example, accounts that require the presence of two people for access (similar to checks that must be signed by two people). There is no point in an account with two passwords, both known by the same people. Given the nature of a remote file specification, it would require some special programming to use two passwords without revealing both to one person. (I suppose it could be done by a program or command file that prompts for the two passwords, then builds the remote file spec, never displaying it to anyone.) A better solu- tion would be to provide proxy access to an account on the remote machine that itself had a secondary password. The INPSMB behaves different: Only the first password is checked and needed. This sounds like a bug - and a potentially serious one, as it allows the holder of just one of the passwords access to the account. You should submit an SPR. -- Jerry -------