Proxies stopped working

[John Harper (Barbour)]

Good morning all,

We have an alpha cluster in the UK and standalone alphas in the USA, Germany and France connected via a VPN.

Users log on the the remote machines with a simple telnet command with the IP address. We can also transfer files with simple copy commands, either specifying node name or IP address.

The remote machines are running VMS 7.3-2 (awaiting upgrade to 8.3).

About the time we upgraded the UK cluster to 8.3 we found we were unable to copy files to the USA system. We can still log on and can still copy files from USA to UK.

The machines in France and Germany are fine and we can copy files to them.

When copying to USA we get :

-RMS-E-CRE, ACP file create failed
-SYSTEM-F-INVLOGIN, login information invalid at remote node

Suspecting that there was a problem with proxies I checked the remote node and received the following error :

UAF> show/proxy *::*
%SECSRV-E-BADNODENAMELEN, remote node name length is out of range

Looking through the help I found the /old switch and this allos me to see the proxies

UAF> show/proxy *::*/old

Default proxies are flagged with (D)

*::SYSTEM
SYSTEM (D)

*::JOHNH
JOHNH (D)

etc.

I'm now somewhat confused. Have I accidentally turned off proxy processing(is this possible ?).

Apologies for the length of this post, but better to give too much information than too little.

John

[Duncan Morris]

Hi John,

the fact that show /proxy *::* /old
works, suggests that netproxy is fine, but you seem to have an issue with net$proxy.

Can you check the definition of net$proxy at the remote (USA) node? You might also want to confirm that the security server has the correct file open!

Try to locate a copy of the file and use anal/rms to confirm the file's integrity.

Duncan

[John Harper (Barbour)]

Hello Duncan,

Thought you had it there. NET$PROXY wasn't defined. However, when I assigned it to SYS$SYSTEM:NET$PROXY.DAT it made no difference.

I also checked to see whether this file was in use and it was :

$ PIPE SHOW DEV/FILES DKA0: | SEAR SYS$PIPE: NET$PROXY
SECURITY_SERVER 0000020D [SYS0.SYSEXE]NET$PROXY.DAT;1

I copied the file using backup and tried ANAL/RMS but the file looks OK.

The logical isn't defined at any of our remote sites, and in the UK it points to the cluster common file.


Thanks for a good try.

John

[Joseph Huber_1]

To see if the problem is a loss of entries (caused by whatever circumstances), look if the problem go away after a security server restart:
SET SERVER SECURITY /RESTART

[DECxchange]

Welcome to OpenVMS (TM) Alpha Operating System, Version V8.3

$ set def sys$system
$ run convert_proxy
%SECSRV-I-CONVERT, converting proxy database to new format

Does this solve the problem for you?

[John Gillings]

John,

I'm confused... You say connections are by TELNET and the COPY uses IP addresses, but then you're looking a DECnet proxies. I can only assume you're using DECnet over IP.

I'm also a bit alarmed at your default proxies *::anything (*especially* SYSTEM) means your system is wide open. Anyone who can attach an OpenVMS system onto your network and start DECnet owns your system. When the systems are in different countries, there are numerous potential places to access your network.

For the INVLOGIN error, first thing to do is enable login and login failure auditing for all classes:

$ SET AUDIT/ALARM/ENABLE=(LOGIN=ALL,LOGFAIL=ALL)

If you want a permanent record, also enable audits:

$ SET AUDIT/AUDIT/ENABLE=

Now repeat your failing command while observing a REPLY/ENABLE=SECURITY terminal on the target system. This should tell you what account the login attempt is trying to login to, and the *perceived* source host name/address. This is important because firewalls, proxies and DNS hosts can make the apparent host different from what you thought it was.

Perhaps you want to look at IP proxies so you can use RSH and RCP? Even better, maybe use one on of the SSH mechanisms?

[John Harper (Barbour)]

Many thanks for all your suggestions.

At present the USA machine is unavailable due to a power outage affecting comms, and as it't a holiday over there I can't get anyone to sort it.

Once it's back online I will try all your suggestions and come back with the results.

John

[John Harper (Barbour)]

Hello everyone. We've got our USA system back up and I tried everything you suggested.

Joseph,

Thanks - tried that but no good. Even a reboot makes no difference

DECxchange - never knew that was there. You learn something every day.
Tried, and it ran OK but made no difference.

John - you're not the only one confused. We sort of "fell in" to this odd mixed
DECNet/TCPIP thing when we decommissioned X25 some years ago. You could probably put it down to laziness. TELNET seems the easiest way to log on to the remote sites. As far as COPY is concerned, the result is the same whether using DECNET node names or IP addresses.

I do however take your point about proxies. I "inherited" the network side of the system a while ago (I'm a developer) and really will have to tighten up on the security side of things. Again this was probably due to laziness.

I set audits and when I tried to copy a file I got the following :

$
%%%%%%%%%%% OPCOM 22-JAN-2008 10:23:04.51 %%%%%%%%%%%
Message from user SYSTEM on NICKEL
%SECSRV-I-INVALIDTERMNAME, received invalid terminal name for intruder/suspect
%SYSTEM-F-IVDEVNAM, invalid device name

$
%%%%%%%%%%% OPCOM 22-JAN-2008 10:23:04.51 %%%%%%%%%%%
Message from user SYSTEM on NICKEL
%SECSRV-I-INVALIDTERMNAME, received invalid terminal name for intruder/suspect
%SYSTEM-F-IVDEVNAM, invalid device name

$
%%%%%%%%%%% OPCOM 22-JAN-2008 10:23:04.57 %%%%%%%%%%%
Message from user SYSTEM on NICKEL
Event: Access Control Violation from: Node LOCAL:.NICKEL Session Control,
at: 2008-01-22-10:23:04.571+00:00Iinf
NSAP Address=/AC140170,
Source=UIC = [0,0]JOHNH,
Destination=number = 17,
Destination User="",
Destination Account="",
Node Name=
eventUid 04571A1E-C8D4-11DC-B7CF-4E49434B454C
entityUid 04DDB578-C8CC-11DC-8155-AA000400C408
streamUid 214C3EE5-C8CC-11DC-81B9-AA000400C408

What stands out to me is that the Destination User and Destination Account
have a value of "" and the Node Name is also blank.

The same command on our machine in Germany simply gives :

%%%%%%%%%%% OPCOM 22-JAN-2008 16:54:37.30 %%%%%%%%%%%
Message from user AUDIT$SERVER on BRASS
Security alarm (SECURITY) and security audit (SECURITY) on BRASS, system id: 2247
Auditable event: Network login
Event time: 22-JAN-2008 16:54:37.30
PID: 00003F00
Process name: FAL_1409004B
Username: JOHNH
Process owner: [ITDEPT,JOHNH]
Image name: BRASS$DKA0:[SYS0.SYSCOMMON.][SYSEXE]LOGINOUT.EXE
Remote node fullname: IP$172.20.01.112
Remote username: JOHNH
Posix UID: -2
Posix GID: -2 (%XFFFFFFFE)

Finally you can put it down to ignorance, but I wasn't aware of IP proxies
until you mentioned them.

Once again, many thanks for all your suggestions.

John

[John Gillings]

John,

TCPIP proxies work with the RSH and RCP commands. They won't work for ordinary DCL COPY, so if you need to retain existing code, you may have to persevere with getting your DECnet proxies working. Make sure all nodes are configured with DECnet+ and with DECnet over IP correctly setup.

The incorrect (blank) fields on the incoming request are what's causing your problem. There's definitely something wrong with the way DECnet is configured. Try logging in with SET HOST and look at your SYS$REM* logical names.

On the other hand, if you can change code to use alternate mechanisms for transferring files, I'd recommend going with one of the SSH mechanisms. They are much more secure than any proxy mechanism. They're a fiddle to get working (generating and distributing keys), but once they're up they work well. The key is in small steps, make it work for simple, interactive cases first, before integrating it into your procedures.

[Joseph Huber_1]

There are more serious problems probably...
the DE example shows
Remote node fullname: IP$172.20.01.112
and this indicates a bind/hostname lookup problem.
Verify: TCPIP SHOW NAME