Discussion:
Login information invalid at remote node
Add Reply
IanD
2017-06-06 06:58:59 UTC
Reply
Permalink
Raw Message
I searched through this but didn't really find a solution

https://groups.google.com/forum/#!msg/comp.os.vms/yrhQmEd2j1I/fOr7OOzqAAAJ

I'm having a similar issue to the problem faced by the OP in the above link

Strange thing is even using a Username/password for the given user fails

I've tried using proxies but they also fail

I'm at a loss to know what else to look into...

OPCOM Log:
%%%%%%%%%%% OPCOM 6-JUN-2017 14:44:20.28 %%%%%%%%%%%
Message from user SYSTEM on PROD1
Event: Access Control Violation from: Node LOCAL:.PROD1 Session Control,
at: 2017-06-06-14:44:20.288+10:00Iinf
NSAP Address=49::00-01:AA-00-04-00-1A-04:20,
Source=UIC = [0,0]USERNAME,
Destination=number = 17,
Destination User="",
Destination Account="",
Node Name=LOCAL:.DEV1
eventUid 9FC9DD93-4AC6-11E7-8E57-D89D67F5EC3C
entityUid 4DC6AB81-A8ED-11E6-84F8-AA0004001B04
streamUid 5C07A820-A8ED-11E6-8763-AA0004001B04


Audit log:
LOGIN FAILURE
-------------
Username: UIC: [0,0]
Account: <net> Finish time: 6-JUN-2017 14:44:20.28
Process ID: 00000000 Start time: 6-JUN-2017 14:44:20.28
Owner ID: Elapsed time: 0 00:00:00.00
Terminal name: Processor time: 0 00:00:00.00
Remote node addr: Priority: 0
Remote node name: Privilege <31-00>: 00000000
Remote ID: USERNAME Privilege <63-32>: 00000000
Remote full name: LOCAL:.DEV1
Posix UID: Posix GID:
Queue entry: 151 Final status code: 00D3803C
Queue name:
Job name:
Final status text: %LOGIN-F-NOTVALID, user authorization failure
Page faults: 0 Direct IO: 0
Page fault reads: 0 Buffered IO: 0
Peak working set: 0 Volumes mounted: 0


I have verified the username/password is correct and working (logged in locally on the destination server) but cannot get it to work remotely using either embedded username/password access string and/or proxy in the UAF

Their account works from the destination back to the source using proxies

Other accounts use proxies fine, although they were set up a long time ago. This account is new. I've also tried setting up another new account, same problem

Where to look further? (I cannot find a netserver log either, i don't think it gets created on account that it's failing before actually logging in)
GerMarsh
2017-06-06 08:43:45 UTC
Reply
Permalink
Raw Message
Post by IanD
I searched through this but didn't really find a solution
https://groups.google.com/forum/#!msg/comp.os.vms/yrhQmEd2j1I/fOr7OOzqAAAJ
I'm having a similar issue to the problem faced by the OP in the above link
Strange thing is even using a Username/password for the given user fails
I've tried using proxies but they also fail
I'm at a loss to know what else to look into...
%%%%%%%%%%% OPCOM 6-JUN-2017 14:44:20.28 %%%%%%%%%%%
Message from user SYSTEM on PROD1
Event: Access Control Violation from: Node LOCAL:.PROD1 Session Control,
at: 2017-06-06-14:44:20.288+10:00Iinf
NSAP Address=49::00-01:AA-00-04-00-1A-04:20,
Source=UIC = [0,0]USERNAME,
Destination=number = 17,
Destination User="",
Destination Account="",
Node Name=LOCAL:.DEV1
eventUid 9FC9DD93-4AC6-11E7-8E57-D89D67F5EC3C
entityUid 4DC6AB81-A8ED-11E6-84F8-AA0004001B04
streamUid 5C07A820-A8ED-11E6-8763-AA0004001B04
LOGIN FAILURE
-------------
Username: UIC: [0,0]
Account: <net> Finish time: 6-JUN-2017 14:44:20.28
Process ID: 00000000 Start time: 6-JUN-2017 14:44:20.28
Owner ID: Elapsed time: 0 00:00:00.00
Terminal name: Processor time: 0 00:00:00.00
Remote node addr: Priority: 0
Remote node name: Privilege <31-00>: 00000000
Remote ID: USERNAME Privilege <63-32>: 00000000
Remote full name: LOCAL:.DEV1
Queue entry: 151 Final status code: 00D3803C
Final status text: %LOGIN-F-NOTVALID, user authorization failure
Page faults: 0 Direct IO: 0
Page fault reads: 0 Buffered IO: 0
Peak working set: 0 Volumes mounted: 0
I have verified the username/password is correct and working (logged in locally on the destination server) but cannot get it to work remotely using either embedded username/password access string and/or proxy in the UAF
Their account works from the destination back to the source using proxies
Other accounts use proxies fine, although they were set up a long time ago. This account is new. I've also tried setting up another new account, same problem
Where to look further? (I cannot find a netserver log either, i don't think it gets created on account that it's failing before actually logging in)
Can you post the real audit journal entry? That seems to be an accounting file entry.
Colin Butcher
2017-06-06 12:17:58 UTC
Reply
Permalink
Raw Message
Hello Ian.

What are the actual proxy entries in the UAF on the destination node ?

You appear to be using DECnet-plus, which back-translates the source
node information before adding it to the proxy database, so you can end
up with proxy database entries that look OK, but which don't actually
work as you expect.

A quick hack to check for it being a back-translated nodename issue is
to change the proxy entry to be "*" for the node part of the proxy
database entry.

I'd like to see it do the back-translate of the nodename portion at
login time, not at the time when you add the proxy database entry.

Cheers, Colin.
Simon Clubley
2017-06-06 13:36:12 UTC
Reply
Permalink
Raw Message
Post by IanD
I have verified the username/password is correct and working (logged in
locally on the destination server) but cannot get it to work remotely using
either embedded username/password access string and/or proxy in the UAF
I assume there are no remote access constraints in the UAF entry ?

Have you checked to make sure that the intrusion database on the
destination box is clear for the remote access source in question ?

Do site security policies allow you to packet trace the connection
attempt to see what is actually going on ?

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Stephen Hoffman
2017-06-06 15:37:55 UTC
Reply
Permalink
Raw Message
Post by IanD
I searched through this but didn't really find a solution
https://groups.google.com/forum/#!msg/comp.os.vms/yrhQmEd2j1I/fOr7OOzqAAAJ
....
Other accounts use proxies fine, although they were set up a long time
ago. This account is new. I've also tried setting up another new
account, same problem
Where to look further? (I cannot find a netserver log either, i don't
think it gets created on account that it's failing before actually
logging in)
Confirm that all of the steps in section 7.3 of
http://h20565.www2.hpe.com/hpsc/doc/public/display?docId=emr_na-c04623084
have been followed.

Confirm that all of the debugging and diagnostic steps used earlier
have been followed; the suggestions and comments from the
previously-cited comp.os.vms thread.

Confirm that the cluster (if it's a cluster) has all of the cluster
logical names required by the unfortunately-hacked-together "design" of
clustering.

Confirm that the proxy is marked as /DEFAULT, if you're not planning to
specify it on each connection.

In the context of the system that's failing to accept the login, make
sure that the target directory ownership associated with the
newly-added or newly-proxied username matches the user UIC. Also add
a simple LOGIN.COM ($ EXIT is enough) and make sure that any
system-wide SYLOGIN is readable by the newly-created user, too.

Make sure that the newly-added or newly-proxied login works locally.

Check to see if the newly-added or newly-proxied user is marked DISUSER
or otherwise blocked from network access.

See if flushing the cache works:

NCL> flush session control naming cache entry "*"

Make sure both nodes have had the host name of the other node
registered in DECnet; see the DECNET_REGISTER command. (That's
probably already the case, if other entries are using the host name and
not the address, and are working.)

Check patches, etc.

Use ssh or some other secure connection. Or if you're intentonally
running completely insecure networking and don't otherwise need a Phase
V feature, upgrade from DECnet Phase V to Phase IV.
--
Pure Personal Opinion | HoffmanLabs LLC
IanD
2017-06-07 06:45:11 UTC
Reply
Permalink
Raw Message
Thanks all - just been extremely busy and only getting back to this now

I'll dig through all the suggestions / diag. tips and come back :-)
IanD
2017-06-09 05:03:22 UTC
Reply
Permalink
Raw Message
Only just getting back to this after some disks failed and I had my attention focused on that

Couple of strange things...

When attempting to perform a simple directory from source system to target node, I get:

From Source System
------------------
dir prod1::login.com;
Error opening PROD1::LOGIN.COM; as input
ACP file or directory lookup failed
Login information invalid at remote node

On Target system
----------------
LOGIN.COM is correctly mapped in UAF
File ownership correct in login directory and path exists
File permission allows owner read/write

This account is an exact replicate of other accounts that are working. the only difference is of course the usual stuff, like difference member UIC's etc

The other big difference, is the older accounts pre-date cluster configuration changes, but the old accounts still work, untouched. The new account doesn't

On the Target system (PROD1), there is no security audit entry generated, despite the invalid login message on the source node. The audit log is capturing security events, just nothing for this user! hmmmm

I suspect this means that the account being logged into (or attempted to be logged into) must be something else

BUT... The intrusion audit server on the Target node, registers an invalid login attempt!

NETWORK SUSPECT 2 9-JUN-2017 15:01:56.09 LOCAL:.DEV1::<username>

Why the discrepancy here I wonder? why no audit log entry yet a registered suspect entry is generated

As for Proxies, they are configured exactly the same as for other users (that work) and in this particular case, is as follows:

On Target System
----------------
LOCAL:.DEV1::<username>
<username> (D)

I did find something else, there is a catch all generic UIC proxy mapping on the Target system, as in:

LOCAL:.DEV1::[<UIC-GROUP>,*]
<username-other>

I would suspect this account could be interfering BUT why do the older account not also get caught up with this generic proxy account (which has been added well and truly after the old accounts)

I am very reluctant to remove the catch-all proxy entry in case when i attempt to add it back again, it befalls the same fate as the new account i am trying to add - I'd rather solve why the new account doesn't work first

There must be some other mechanism VMS is using under the covers other than just the proxy stuff surely, otherwise why does the old accounts keep working but only new stuff doesn't?

I posted the above in case it triggers someone to pin-point why. I'm still making my way through the other suggestions
Stephen Hoffman
2017-06-09 20:18:23 UTC
Reply
Permalink
Raw Message
Post by IanD
On the Target system (PROD1), there is no security audit entry
generated, despite the invalid login message on the source node. The
audit log is capturing security events, just nothing for this user!
hmmmm
Make sure that the SOURCE host has the right DECnet address for the
PROD1 host. Lest your connections be routed to some other host.

SHOW AUDIT on the target server, and have a look at what's enabled and
what's not enabled.

If this is a cluster or if the core security and configuration files
are not at their respective default locations, make sure the fleet of
~20 logical names that are required are all aimed at the appropriate
files on each of the hosts involved.

Rule of thumb with troubleshooting access errors within a cluster: one
or more of that idiotic fleet of ~20 logical names are incorrect, or
entirely missing.
Post by IanD
BUT... The intrusion audit server on the Target node, registers an invalid login attempt!
NETWORK SUSPECT 2 9-JUN-2017 15:01:56.09 LOCAL:.DEV1::<username>
Why the discrepancy here I wonder? why no audit log entry yet a
registered suspect entry is generated
Check that the target username is permitted to login. Not disusered,
not disallowed access from remote sources, not outside the access
hours, etc. But I'd expect an audit, so a look at SHOW AUDIT to see
all of what is enabled is appropriate.
Post by IanD
As for Proxies, they are configured exactly the same as for other users
On Target System
----------------
LOCAL:.DEV1::<username>
<username> (D)
I did find something else, there is a catch all generic UIC proxy
LOCAL:.DEV1::[<UIC-GROUP>,*]
<username-other>
I would suspect this account could be interfering BUT why do the older
account not also get caught up with this generic proxy account (which
has been added well and truly after the old accounts)
What other proxies are in use on the target system? I'd look
specifically for the ones that are being used. (I'd not tend to
expect to see a UIC group proxy used all that often. That's for
DECnet connections not originating from OpenVMS; from PDP-11 or such.
Quoth the docs: "For systems that are not OpenVMS and that implement
DECnet, specifies the UIC of a user at a remote node."

The default entry is used when no username is specified. See if
specifying the target username in the connection works.

Flush the DECnet cache, as mentioned in my earlier reply.

Check patches, too.
Post by IanD
I am very reluctant to remove the catch-all proxy entry in case when i
attempt to add it back again, it befalls the same fate as the new
account i am trying to add - I'd rather solve why the new account
doesn't work first
There must be some other mechanism VMS is using under the covers other
than just the proxy stuff surely, otherwise why does the old accounts
keep working but only new stuff doesn't?
I posted the above in case it triggers someone to pin-point why. I'm
still making my way through the other suggestions
Unless I needed DECnet over IP or other such, I'd upgrade from Phase V
to Phase IV, or would migrate to ssh and sftp and avoid the whole mess.
--
Pure Personal Opinion | HoffmanLabs LLC
m***@gmail.com
2017-06-10 11:58:52 UTC
Reply
Permalink
Raw Message
Ian,

Is there a logical name on the target system that is somehow interfering with your login?

I vaguely remember this happening at some point in my distant past.
John Reagan
2017-06-10 21:02:31 UTC
Reply
Permalink
Raw Message
Make sure the account's LOGIN.COM isn't doing something crazy. Create a new, empty LOGIN.COM to test with.
Kerry Main
2017-06-10 21:12:49 UTC
Reply
Permalink
Raw Message
-----Original Message-----
Reagan via Info-vax
Sent: June 10, 2017 5:03 PM
Subject: Re: [Info-vax] Login information invalid at remote node
Make sure the account's LOGIN.COM isn't doing something crazy. Create
a new, empty LOGIN.COM to test with.
Or add "$ exit" to the 1st line of login.com (and syslogin.com?)

😊


Regards,

Kerry Main
Kerry dot main at starkgaming dot com
Simon Clubley
2017-06-10 22:39:31 UTC
Reply
Permalink
Raw Message
Post by John Reagan
Make sure the account's LOGIN.COM isn't doing something crazy. Create a new,
empty LOGIN.COM to test with.
I'd still like to know if Ian's site security policies allow him to
packet trace a connection attempt. That might reveal some clues about
what is going on.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
IanD
2017-06-21 06:19:27 UTC
Reply
Permalink
Raw Message
Sorry all, I have been stupidly busy with other stuff

I went through a number of the suggestions and tried some but alas, they didn't work

In the end we removed the account, recreated it again and the proxies and it worked! go figure!!!

Everything looks identical

I don't like it when things just start working and you don't know why they broke in the first place

I'll just have to put this one down to Gremlins :-(

Thanks heaps for all the advice - much appreciated
IanD
2017-07-18 10:14:19 UTC
Reply
Permalink
Raw Message
Ok, this is interesting

It seems to be associated with old accounts on the system set up before the network up changed

Had another example of this error when I tried to use an old account

In the end, I deleted the account and added it again with exactly the same UIC etc and it worked first attempt after being recreated

I don't have time to try and nut out why when a simple fix of delete/add the account works as a work around

But I would still like to know what's hiding under the hood in VMS that causes this, it's something beyond the face value of the uaf/proxy information obviously
Henry Crun
2017-07-18 11:05:35 UTC
Reply
Permalink
Raw Message
Post by IanD
Ok, this is interesting
It seems to be associated with old accounts on the system set up before the network up changed
Had another example of this error when I tried to use an old account
In the end, I deleted the account and added it again with exactly the same UIC etc and it worked first attempt after being recreated
I don't have time to try and nut out why when a simple fix of delete/add the account works as a work around
But I would still like to know what's hiding under the hood in VMS that causes this, it's something beyond the face value of the uaf/proxy information obviously
could it be that accounts were defined in NETPROXY.DAT and not in NET$PROXY.DAT?
--
No Micro$oft products were used in the URLs above, or in preparing this message.
Recommended reading: http://www.catb.org/~esr/faqs/smart-questions.html#before
and: http://alpha.mike-r.com/jargon/T/top-post.html
Stephen Hoffman
2017-07-18 15:36:11 UTC
Reply
Permalink
Raw Message
Post by IanD
But I would still like to know what's hiding under the hood in VMS that
causes this, it's something beyond the face value of the uaf/proxy
information obviously
DECnet Phase V caching has has occasionally gotten confused. I've
long recommended upgrading to DECnet Phase IV (technically IV+) absent
specific requirements for V, and particularly to migrate to ssh and
sftp or other more modern connections given the near-deprecated and
completely-insecure status of DECnet.
--
Pure Personal Opinion | HoffmanLabs LLC
Loading...