topic Re: Access Control Violation in Operating System - OpenVMS

Access Control Violation

Accullise — Tue, 11 Nov 2008 05:23:38 GMT

Hi friends,

we have four alpha servers in cluster and last week we have upgraded our systems from openVMS7.3-2 to 8.3.After upgradation one of my server has been giving a following error in operator log continuously.

Message from user SYSTEM on xxxx
Event: Access Control Violation from: Node LOCAL:.xxxx Session Control,
at: 2008-11-10-09:05:42.840+00:00Iinf
NSAP Address=49::00-28:AA-00-04-00-66-A0:20,
Source=UIC = [0,0]yyyy,
Destination=number = 17,
Destination User="yyyy",
Destination Account="",
Node Name=LOCAL:.zzzz
eventUid C0AFD1EC-AF06-11DD-A972-00062B02953D
entityUid 2E368BEA-A947-11DD-832F-AA000400062C
streamUid 3F93EA8B-A947-11DD-848C-AA000400062C

Can anyone tell me how to stop these errors and
what are the next steps i have to do?

Regds,
Acullise

Re: Access Control Violation

Volker Halle — Tue, 11 Nov 2008 07:01:47 GMT

Acculise,

this event is associated with an attempted DECnet file access. Find out, from which node and user the access is happening, check the DECnet proxies for that user on the local node:

$ MC AUTHORIZE SHOW/PROXY remote-node::remote-user

Volker.

Re: Access Control Violation

Accullise — Tue, 11 Nov 2008 07:51:21 GMT

thanks volker...

Actually i have added that user in proxy database today morning...
but still errors are coming...

i have added to proxy by the following commands...

UAF> add/proxy zzzz::yyyy
_local user(s): YYYY

UAF> sh/proxy
_remote user: *

Default proxies are flagged with (D)

LOCAL:.xxxx::yyyy
yyyy

Re: Access Control Violation

Ian Miller. — Tue, 11 Nov 2008 13:29:43 GMT

when that user accesses this system do they specify the local username

node"username"::

As its not a default proxy perhaps they should or you make it a default proxy

Re: Access Control Violation

Hoff — Tue, 11 Nov 2008 14:30:45 GMT

The specified target username (or proxy) doesn't exist, or the target proxy isn't marked /DEFAULT.

Check security auditing for the same time, too.

Flush the caches (if you can't upgrade to Phase IV, then one of the first attempts to fix Phase IV is to flush the Phase V cache), and check that the back-translation values are such that the proxies are triggered. Here, you'd need a proxy or /DEFAULT proxy for the incoming DECnet connection.

As a general recommendation when these sorts of errors show, work through all of the shared files for this cluster (SYLOGICALS.TEMPLATE) and make sure all are configured appropriately on all hosts in the cluster.

AFAIK, this "access control violation" has little or nothing to do with an OpenVMS ACCVIO access violation. Yes; a bad choice of errors. The ACCVIO case is a memory management. This case is usually some sort of proxy or authentication boo-boo.

Re: Access Control Violation

Volker Halle — Tue, 11 Nov 2008 15:45:03 GMT

Acullise,

what Ian was meant to say: you did not specify the /DEFAULT qualifier when adding that proxy, so the remote user must specify the local username, if that proxy is to be used.

If you have an account on that remote system, try a DIR xxxx:: yourself. Have another session opened on node xxx with REPLY/ENABLE. Then watch the messages in real-time and try to understand and fix the problem. Once you've fixed the problem for your account, apply the same fix to the yyyy user account.

Volker.

Re: Access Control Violation

Accullise — Wed, 12 Nov 2008 05:28:22 GMT

Thanks frds,

I have added that in proxy with /default but again same errors are coming. Instrsion also increased.

Intrusion Type Count Expiration Source
--------- ---- ----- ---------- ------
NETWORK INTRUDER 50 12-NOV-2008 10:58:35.44 LOCAL:.sahara::test

please tell me what is the exact cmd and what is the next step?

Re: Access Control Violation

Volker Halle — Wed, 12 Nov 2008 07:09:51 GMT

Acullise,

did you try to delete the intrusion record first ?

$ DELETE/intrusion local:.sahara::test

Volker.

Re: Access Control Violation

Accullise — Wed, 12 Nov 2008 07:56:17 GMT

I HAVE DONE THAT. WHATEVER I HAVE DELETE THE INTRUSIONS, IT IS COMING AGAIN AND AGAIN....

IF I WANT TO ADD THE PROXY IN BOTH NODES?

Re: Access Control Violation

Accullise — Wed, 12 Nov 2008 08:05:31 GMT

That intrusion automatically cleared and it is coming again and again.

can anyone tell me what is the exact cmd to add a proxy?

I have to add in both ends?

I have already added with the following cmd but
errors still coming...

$mc authorize
UAF> add/proxy sahara::test test/default

Re: Access Control Violation

Volker Halle — Wed, 12 Nov 2008 09:23:58 GMT

Aculisse,

in your first entry, you said that this problem is only happening on one of your 4 nodes in the same cluster. Do these system share a common OpenVMS environment, like same system disk or at least all common files set up correctly ? Does the proxy access work to any of the 4 nodes ?

You need to add the proxy only on the destination system. Be aware that the various session control applications can have attributes set to disable outgoing or incoming proxy access. Check with MC NCL SHO SESS CONTROL APP FAL ALL

The correct statement to add your porxy for a DECnet connection would be:

UAF> add/proxy local:.sahara::test test/def

but just using sahara::test might work as well.

Does access work, if you explicitly specify username and password for your test account, i.e.

$ dir node"username password"::

Volker.

Re: Access Control Violation

Accullise — Wed, 12 Nov 2008 09:56:17 GMT

thanks volker...

i have checked with MC NCL, it is in true state
for all.

actually we have four different openvms cluster
but each cluster in different place. In my cluster having 4 alpha nodes. one of my alpha nodes having this problem but SAHARA is the another clusters node.

SAHARA::TEST user only trying to access my node.

Re: Access Control Violation

Volker Halle — Wed, 12 Nov 2008 10:55:50 GMT

Acullise,

discussing and troubleshooting such a problem requires precise configuration information - otherwise it becomes more of a guesswork.

You need to supply information about the source node or cluster from which the access originates and also information about the destination node or cluster. And provide information about what exactly has been changed.

If the access is only happening from one explicit node in the source cluster to one explicit node in the destination cluster, then try from another node or to another node in those clusters. If access is to a DECnet cluster alias, things may just be wrong on node node. First try access by explicitly specifying the correct username and password. Find out whether that works as expected. Then look at NET$SERVER.LOG in the default directory of the destination account and find out the source node information from there. Is it like what you expect ?

Volker.