203002@DHHMPI5D.BITNET (01/14/87)
--------------------------------Begin-Of-Message--------------------------------
How must the explicit DECNET-access control information field look like for
users with a secondary password (not for proxy login's)? Yust specifying the
primary one (node"user pwd1"::) produces "network partner exited", also
specifying the second one after the first (node"user pdw1 pwd2"::).
Indeed, after looking at the accounting file, the network process bombs
out with "access violation".
The INPSMB behaves different: Only the first password is checked and needed.
We are using VMS V4.5,my mail adress is (standard disclaimer)
<203002@DHHMPI5D.BITNET> or <SYSTEM@DHHMPI5D.BITNET>
Ruediger R. Kresse Climate Computing Center at
Phone +49 40 4114 294 Max-Planck-Institute for Meteorology
Room 1509 A Bundesstr. 55
D-2000 Hamburg 13
F.R. Germany
---------------------------------End-Of-Message---------------------------------carl@CITHEX.CALTECH.EDU.UUCP (01/15/87)
At present, there is no mechanism for passing a secondary password in an access control string, or at least I haven't heard anything about a solution to the problem. Maybe while DEC's in the process of rewriting DECnet anyway, they'll add something.
LEICHTER-JERRY@YALE.ARPA.UUCP (01/15/87)
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
-------