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.