Inter-nodal FAL/Proxy Problem (Clearer definition of DECnet Network Access Control concept requi

[Mark_Corcoran]

I'm having a problem trying to get my head around a problem with proxy access, and I wondered if anyone might be able to explain the "hierarchy" of Access Control in DECnet better than the "DECnet for OpenVMS Networking Manual" (AA-PV60A-TK, May 1993) - or whether or not what I am seeing isn't documented unless you've got the source code...

I have 3 nodes, all of which are standalone, all running OpenVMS VAX v6.2 (yes, yes, I know), and all running DECnet Phase IV only.

Two nodes are CharonVAX-ised (let's call them NODE1 and NODE2), and the third is real iron - a MicroVax 4000-400 (let's call it NODE3).

I can copy files from NODE1 to NODE2 and vice versa (via FAL) quite happily, but very occasionally, I would like to copy a file from NODE1 or NODE2 to NODE3 (NODE1/NODE2 have poor man's session logging via SET HOST /LOG, so I'd rather the password wasn't recorded in it).

Proxies have been added long before I was here:

On NODE1
NODE2::* * (D)

On Node2
NODE1::* * (D)

If I add a proxy on NODE3 for my account on NODE1:

NODE3$ MC AUTHORIZE ADD /PROXY NODE1::NODE1USER NODE3USER /DEFAULT

then from NODE1 attempt to do DIR NODE3::*, an audit event is raised, for user DECNET
on NODE3, saying that the account is disabled (indeed, it has the DISUSER flag).

Likewise, if I reverse the process, and create a proxy on NODE1 for my account on NODE3:

NODE1$ MC AUTHORIZE ADD /PROXY NODE3::NODE3USER NODE1USER /DEFAULT

I still get the same audit event (DECNET account disabled) if on NODE3 I try DIR NODE1::*

The FAL object is declared on all 3 nodes as object number 17, and has no "additional" parameters (such as PROXY INCOMING / OUTGOING /BOTH, or OUTGOING CONNECT PRIVILEGES):

The FAL object is declared on all 3 nodes as object number 17, and has no "additional" parameters (such as PROXY INCOMING / OUTGOING /BOTH, or OUTGOING CONNECT PRIVILEGES):

$ MC NCP SHOW OBJECT FAL CHARACTERISTICS

Object Volatile Characteristics as of 27-MAR-2017 19:41:56

Object = FAL

Number = 17
File id = FAL.EXE

Trying to interpolate figure 2-4 on page 2-31 (of "DECnet for OpenVMS Networking Manual" (AA-PV60A-TK, May 1993)):

For NODE3, doing a DIR NODE1::*

Outbound Connection
Explicit null access used?
NO (DIR NODE1::*, not DIR NODE1""::*)
Object of the connection requires privileges other than TMPMBX and NETMBX?
NO (MC NCP SHOW OBJECT FAL CHARACTERISTICS shows no OUTGOING CONNECT PRIVILEGES having been configured)
==>DECnet sends default nonprivileged information for remote node if this information exists (on NODE3, it doesn't, so it won't be sent)
Outgoing proxy enabled for the object?
NO (MC NCP SHOW OBJECT FAL CHARACTERISTICS shows no PROXY INCOMING / OUTGOING /BOTH value)

Inbound Connection
Explicit access control information received?
NO (well, that's my guess, I haven't seen what DECnet is doing under the hood)
Proxy for the object requested, enabled and present?
NO (on the basis of the MC NCP SHOW OBJECT FAL CHARACTERISTICS showing no proxy settings)
[I'm uncertain about this;  the way the text is written in the flowchart - certainly for the outgoing connection, implies that it is only to do with NCP OBJECT PROXY settings, whereas I get the impression that for inbound connections, it might take into account whether or not EXECUTOR INCOMING PROXY is also enabled???]

Object database contains default inbound access control information?
NO (MC NCP SHOW OBJECT FAL CHARACTERISTICS shows no USER or PASSWORD set)
Default nonprivileged information associated with executor node?
YES (MC NCP SHOW EXECUTOR CHARACTERISTICS on NODE1 and NODE2 have a nonprivileged user id of DECNET, and different nonprivileged passwords between NODE1 and NODE2 (NODE3 has no non-privileged user or password))
==>LOGINOUT (on NODE1/NODE2) uses it.

To me, this would explain why the DECNET account/username was being used on inbound connections on NODE1/NODE2 to NODE3 and also vice versa.

[On an outbound connection from NODE1/NODE2, the "Object of the connection requires privileges other than TMPMBX and NETMBX" still has an answer of NO, but this time, default nonprivileged information *IS* defined on NODE1/NODE2, so it should be sent (and it is configured as user DECNET)]

What I can't get my head around is why none of this seems to happen with inter-nodal file access between NODE1 and NODE2...

If I do DIR NODE2::* from NODE1 (and suitable proxies exist), the contents of my login directory on NODE2 ARE listed, rather than barfing because the DECNET account is disabled (DISUSERed) on NODE2 (and the resulting process on NODE2 that is running NETSERVER, is running under my account, not DECNET).

However, if from NODE1, I do DIR NODE2""::* then I get a login failure due to the DECNET account being disabled (DISUSERed) - I think this is down to the final question diamon on the inbound connection in figure 2-4 of previously mentioned DECnet manual.

Curiously, on the test systems that are supposed to be a duplicate of the NODE1/NODE2 "pair", they don't have nonprivileged user id or password set (but DIR othernode""::* still fails because the DECNET account is DISUSERed;  I can't work out how DECnet (on NODE1? or on NODE2?) is deciding to use the DECNET account under those circumstances.

I'd like to get this straight in my head before I think about raising a change to clear the nonprivileged user id or password from the live systems, because it doesn't seem to be providing any benefit (given that the password is different between NODE1 and NODE2).

I've come to realise that I don't understand the precedence in which proxies appear to be being used by DECnet, depending on what you're accessing, what the executor and object proxy access is set to on both nodes.

Does anyone have an idea if it is more clearly defined in a truth table or bigger/more recent flowchart somewhere? or at least, have an idea what is going on with the NODE1<-->NODE2 inter-nodal file access via FAL that for some reason isn't (or doesn't appear to be) using the DECnet account (unless & until you specify a NULL access string).

If I could understand that, I might have a better idea of what's wrong and why (I was at the point of getting our network team to mirror the network traffic from the port that one of the test systems is connected to, so I could look at the frames in Wireshark, to see what is actually being sent (in the NCB?) when a DIR NODE2::* is performed on NODE1.

Mark

[Bob Blunt]

Mark, you list three nodes:

NODE1, NODE2 and NODE3 with NODE3 being a real, physical system.  Are NODE1 and NODE2 emulators on the same system or separate?  First I'd look at

• Make triple sure that ALL nodes have the correct names AND addresses as expected in the remote node database.
• Make sure that any accounts and passwords for DECnet objects match in the DECnet databases AND the UAF
• Make sure that you have proxies that match accounts.  If you want to use SYSTEM on NODE1 make sure that there's also a SYSTEM on the other two nodes and that it's enabled.

Those are the first three things I'd check.

bob

[Mark_Corcoran]

Hi Bob, thanks for your reply.

>Are NODE1 and NODE2 emulators on the same system or separate?

Two separate systems, running on two different IBM Blade-type server PCs (they only have the Windows Server software (and any associated bloatware), and CharonVAX, with just the single instance of a Charon-ised system running on each server.

>Make triple sure that ALL nodes have the correct names AND addresses as expected in the remote node database.

:-) That was one of the first things done;  the executor node name & address of each node is defined correctly in the DECnet databases of each of the other two nodes (otherwise, the inbound connection wouldn't be received and trigger a login failure due to the DECNET account being DISUSERed).

>Make sure that any accounts and passwords for DECnet objects match in the DECnet databases AND the UAF

I will reconfirm that when I get into work, but from the notes I made yesterday, there are no usernames or passwords set for the FAL object on any of the three nodes.

FWIW, the FAL$SERVER account does not exist on any of the 3 nodes either.

>Make sure that you have proxies that match accounts.  If you want to use SYSTEM on NODE1 make sure that there's also a SYSTEM on the other two nodes and that it's enabled.

I might be over-analysing what you've written, but surely it's not the case that USER1 on NODE1 can only access (via proxy) USER1 on NODE3, and that you can define (on NODE3) a proxy for NODE1::USER1 to any account that exists on NODE3 (and is not DISUSERed and has sufficient privs (in the scenarios I am having problems with, the accounts being used all have full privileges authorised & default).

One thing that might be of concern, is that when I was reading up on proxies, was mention of NETPROXY.DAT vs NET$PROXY.DAT ...

"The primary proxy database that the system uses is the NET$PROXY.DAT file. NETPROXY.DAT is maintained for:

o Use by DECnet for OpenVMS

o Backward compatibility"

When I add a proxy in AUTHORIZE, it only appears to be being updated in NET$PROXY.DAT (it appears as plain-ish text in the records in the file (i.e. you can SEARCH the file for it, and you can also see it if you DUMP the file)) - if I DUMP NETPROXY.DAT, the proxy either doesn't exist, or it is encoded in a manner that doesn't make it readily visible as plain text.

I have seen references to the logical name NETPROXY, but I got the impression that this only needed to be defined if it was in a location other than the default (e.g. on a cluster-common disk).

Could this be the source of the problem?

The other thing (I may already have mentioned - difficult to see my original post whilst replying to yours) is that if on NODE3 I add the following proxy:

$ MC AUTHORIZE ADD /PROXY NODE3::NODE3USER NODE3USER /DEFAULT

then try (whilst logged on to NODE3 as NODE3USER - fully privileged account) to do DIR NODE3""::* I get an audit alarm because FAL/DECnet is trying to use DECNET as the account to log in with (NODE3 has no NONPRIVILEGED USER ID or PASSWORD defined in EXECUTOR CHARACTERISTICS, so I can't reconcile how/why DECNET is being chosen).

Any other suggestions or other items to check gratefully received.

[In my first job 28 years ago, proxies were set up by someone else.

At my second job, I no longer recall the configuration of proxies, executor characteristics, or NCP objects;  I do remember that on most of the systems (VAX then Alpha clusters) we were using DECnet Phase IV and Phase V/OSI/Plus, so we had to define proxies as REMOTENODE::REMOTEUSERNAME and LOCAL:.REMOTENODE::REMOTEUSERNAME

I have a vague recollection that on the LAVC that was on OpenVMS/VAX v5.5-2H4, the EXECUTOR DEFAULT ACCESS was not INCOMING and OUTGOING, and we had to explicitly add INCOMING/OUTGOING access on a per-node basis, but that's not the case here - all 3 nodes have INCOMING and OUTGOING PROXY enabled and also have DEFAULT ACCESS INCOMING and OUTGOING.

In short, I've probably over-relied on other folk to set things up in the past, leading to a less-than-desirable understanding now, of how it is supposed to be configured]

[Ian Miller.]

The NET$PROXY file was introduced with DECnet/OSI and contains the longer form of proxies

e.g.

LOCAL:.NODENAME::USERNAME OTHERLUSER

The NETPROXY file contains the older DECnet/IV proxies

 NODENAME::USERNAME OTHERLUSER

These should be maintained in parallel by AUTHORIZE. You should have logical names referring to their location (see examples in recent SYS$STARTUP:SYLOGICALS.TEMPLATE ) but by default these files are expected to be found in SYS$SYSTEM:

There is a utility which converts the old file to the new file (SYS$SYSTEM:CONVERT_PROXY.EXE).

Looking up proxies requires the node names to be defined as VMS will attempt to do a reverse lookup on the incoming connection DECnet address and use the result. Do check the node names are consistantly defined.

[Mark_Corcoran · Accepted solution]

I found the cause of the problem on Thursday...

The frequency with which I add proxies in a year could probably be counted with zero fingers on either hand...

However, I am regularly in the habit of needing to look at account settings (or last login date/times) or reset passwords in AUTHORIZE, and for that reason, I have SYSUAF defined /PROCESS in my LOGIN.COM to point to SYS$SYSTEM:SYSUAF.DAT (and don't like having to SET DEFAULT to SYS$SYSTEM, then forget that that's my current default and end up creating termporary files in something other than my own directory tree).

When I had mentioned that AUTHORIZE didn't appear to be adding the proxy to NETPROXY.DAT, I had (on a test system) used SET WATCH FILE /CLASS=ALL before attempting to add a proxy, and on scrolling back on the terminal session, I thought that I hadn't seen any attempt to access NETPROXY.DAT, only NET$PROXY.DAT

For some reason, I tried again with SET WATCH, and ADD /PROXY, scrolled back and did notice an attempt to access NETPROXY.DAT, with the message "%XQP, Thread #0, Access  (0,0,0) Status: 00000910".

Hmm, that looks like bit 0 is not set, i.e. a non-success status.

$ EXIT %X910
%SYSTEM-W-NOSUCHFILE, no such file

I then deleted the proxy that was added (to NET$PROXY.DAT only), SET DEFAULT to SYS$SYSTEM and added the proxy again - this time it was in NETPROXY.DAT

So basically, AUTHORIZE was silently failing to find NETPROXY.DAT in my current default (and with no NETPROXY logical name defined) but it did add it to SYS$SYSTEM:NET$PROXY.DAT (with no logical name pointing to it, AFAICT).

Given that AUTHORIZE complains if it can't find SYSUAF.DAT, the behaviour in accessing NETPROXY.DAT (explicitly looks in current default if no logical name defined, but doesn't complain if it doesn't find it) versus NET$PROXY.DAT (explicitly looks in SYS$SYSTEM)  seems to be less than desirable.

So, root cause = mea culpa, user error;  I'll now add a definition of the NETPROXY logical to my LOGIN.COM too.