Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Login information invalid at remote node

424 views
Skip to first unread message

IanD

unread,
Jun 6, 2017, 2:59:01 AM6/6/17
to
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

unread,
Jun 6, 2017, 4:43:46 AM6/6/17
to
Can you post the real audit journal entry? That seems to be an accounting file entry.

Colin Butcher

unread,
Jun 6, 2017, 8:17:59 AM6/6/17
to
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

unread,
Jun 6, 2017, 9:39:49 AM6/6/17
to
On 2017-06-06, IanD <iloveo...@gmail.com> wrote:
>
> 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, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Stephen Hoffman

unread,
Jun 6, 2017, 11:37:59 AM6/6/17
to
On 2017-06-06 06:58:59 +0000, IanD said:

> 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

unread,
Jun 7, 2017, 2:45:12 AM6/7/17
to
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

unread,
Jun 9, 2017, 1:03:23 AM6/9/17
to
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

unread,
Jun 9, 2017, 4:18:26 PM6/9/17
to
On 2017-06-09 05:03:22 +0000, IanD said:

> 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.

> 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.

> 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)

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.

> 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.

mcle...@gmail.com

unread,
Jun 10, 2017, 7:58:54 AM6/10/17
to
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

unread,
Jun 10, 2017, 5:02:32 PM6/10/17
to
Make sure the account's LOGIN.COM isn't doing something crazy. Create a new, empty LOGIN.COM to test with.

Kerry Main

unread,
Jun 10, 2017, 5:15:04 PM6/10/17
to comp.os.vms to email gateway
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

unread,
Jun 10, 2017, 6:43:07 PM6/10/17
to
On 2017-06-10, John Reagan <xyzz...@gmail.com> wrote:
> 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.

IanD

unread,
Jun 21, 2017, 2:19:30 AM6/21/17
to
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

unread,
Jul 18, 2017, 6:14:21 AM7/18/17
to
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

unread,
Jul 18, 2017, 7:08:10 AM7/18/17
to
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

unread,
Jul 18, 2017, 11:36:19 AM7/18/17
to
On 2017-07-18 10:14:19 +0000, IanD said:

> 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.

Colin Butcher

unread,
Jul 27, 2017, 11:22:13 AM7/27/17
to
Hello Ian.

Did you try just deleting and re-adding the proxy, rather than the whole
account ?

There are two proxy databases: NETPROXY.DAT and NET$PROXY.DAT, where
NET$PROXY.DAT appeared around OpenVMS V6.2 time.

If the accounts go back that far, or perhaps if someone copied the
SYSUAF.DAT and NETPROXY.DAT files from elsewhere, but forgot the
NET$PROXY.DAT, then it may be that the entries in the two proxy datbases
aren't synchronised.

Cheers, Colin.

Stephen Hoffman

unread,
Jul 27, 2017, 11:31:56 AM7/27/17
to
That's a bug, and one that should have been obvious and inevitable
given the underlying bifurcated database design. Those two should
not be skewed, outside particularly creative or exceptional
circumstances. But then the mail database has a similar potential for
stale and skewed data, too. There's no good way with the current
design to deal with all that, particularly given some manually-added
entries may not have associated SYSUAF entries and then there's
figuring out how to manually verify the contents and the user intent.
Which means cases where stale and skewed settings can silently accrue
within the security database. Ah, well.
0 new messages