System account failure

[Donna Wolf]

I have added a 3rd node to a cluster
sysuaf is shared
System account had been working on this node from decnet/console/batch jobs
system account mysteriously quit working on that node yesterday.
the last thing I did prior to my noticing its demise was configure TCPware not unusual,but I have redid that several times over
and even left tcpware down. rebooted the server etc...
I can log into that node using other accounts (telnet,decnet,console all means).
system account works fine on the other nodes
there is only one login.com in the common shared by this account.
It does not matter if I set host, telnet or use console, batch jobs where user=system it still fails on that node.
the error in accounting is Final status text: %SYSTEM-F-EXITFORCED, forced exit of image or
process by SYS$DELPRC

[Robert Gezelter]

Donna,

There are many possibilities.

One of the first that I would try is perhaps the /NOCOMMAND switch at the username prompt (e.g., Username: system/nocommand). This suppresses the automatic execution of LOGIN file (documented in the HELP text).

You could then do a SET VERIFY and execute LOGIN.COM and see what happens.

There are other possibilities, but the first step is identifying precisely what is failing.

- Bob Gezelter, http://www.rlgsc.com

[Donna Wolf]

Thks, worth a try but same result still will not let me in...

[Robert Gezelter]

Donna,

If /NOCOMMAND does not work. Have you tried putting a SET VERIFY in a node-specific version of SYS$MANAGER:SYLOGIN.COM?

- Bob Gezelter, http://www.rlgsc.com

[Donna Wolf]

yes - but tried again (just in case) - same result

[Robert Gezelter]

Donna,

If I understand this thread correctly, the process is forced exit and you are not even sure that the SYLOGIN.COM is executed?

Can you post the settings for this account?

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

SYSUAF is one of about twenty files that should be shared within a cluster. It's quite common to miss one or two of these files, and various weirdnesses can ensue.

Skim through SYLOGICALS.TEMPLATE and ensure that *all* of the files listed there are shared across all nodes in the cluster.

Remember to try a SHOW INTRUSION, too. It's possible you've received some sort of a sequence of failures and have a DoS on the SYSTEM username, for instance.

In addition to accounting, also review security auditing to see what's written there. Accounting doesn't get all the details.

I'll assume you have tried the SYSTEM login from the OPA0: console on the target box, too.

Check for login limits on SYSTEM, too.

It's also possible for any number of other triggers to arise here, including some local software management application or terminal timeout program that has gone rogue here. Or password management tools, etc.

Or get somebody in to have a look at the box.

[Donna Wolf]

Correct in answer to your question. It is force exit, I am not sure
that login is executed (but all testing and logic makes me 99% sure it is not being executed)
Don't forget it is a cluster with shared and sysuaf and login and system account works on my other 2 nodes
attached system account

[Robert Gezelter]

Donna,

Thank you for the additional material.

I would agree with Hoff, this can be caused by any number of problems (I presume that you have checked the logical names for the RIGHTSLIST and other files to ensure that they point to the correct (same) files on all three nodes.

I do not seen anything that "jumps off the page" with regards to the AUTHORIZE SHOW SYSTEM output.

Since accounting is running, have you determined which image is running when the process is deleted?

This may be one of those that is hard to troubleshoot in the forum. It may be one that needs the actual access to the system [Disclosure: We provide such services, as does Hoff and other regular contributors).

- Bob Gezelter, http://www.rlgsc.com

[Donna Wolf]

thanks-
I checked the logicals for sysuaf only - thanks for reminding me of the others.
but they are common too!

Thank you both --

[Hoff]

Please use the following command sequence to ensure that the SYSUAF file is the same file on all hosts:

SYSMAN> SET ENVIRONMENT/CLUSTER
SYSMAN> DO DIRECTORY /FILE SYSUAF

Ensure the file I/Os all match on all three nodes.

Repeat this for RIGHTSLIST, the NET*PROXY files, and the security files, among other shared files.

Enable security auditing for login, logout, logfail and process services (with the latter particularly for DELPRC calls). See HELP SET AUDIT /ENABLE for details.

Please confirm that ALL of those shared files are in fact shared, and that all logical names are in the proper access mode and logical name table.

Place the line $ EXIT at the top of SYLOGIN.COM and at the top of SYS$MANAGER:LOGIN.COM for the purposes of testing. This really looks like something in the login sequence, based on what I assume is a full login trace that was attached earlier.

Remove the PRCLM setting from SYSTEM. (I'd strongly encourage not making changes to the default SYSTEM username, and I see various changes have been made. SYSTEM is a core HP username, and should see minimal changes from how HP sets it up. Create and use and tailor your own local usernames, as a rule.)

Also confirm the quotas on the originating host are sufficient for the connection, and that the originating and target systems have seen recent AUTOGEN passes with FEEDBACK enabled.

[Jon Pinkley · Accepted solution]

Donna,

"It does not matter if I set host, telnet or use console, batch jobs where user=system it still fails on that node.
the error in accounting is Final status text: %SYSTEM-F-EXITFORCED, forced exit of image or process by SYS$DELPRC"

The first thing I would look at is your system wide login command procedure. The default for this is sys$manager:sylogin.com, but can be overridden with an executive mode logical name that will be visible to a process with UIC [1,4]. Normally the logical name would be in the system logical name table.

sylogin is executed regardless of the presence of /nocommand. That's are very good reason to be especially careful when making changes to it. (and always have a privileged account logged in until you have verified that you can log in from another session, i.e. don't log out, and try to log back in from the same "terminal")

My guess is that there is some checks limit privileged access to "authorized" nodes in the SYLOGIN.COM (and that is only a guess). Perhaps it is checking for specific usernames, perhaps checking for privileges. (if that is indeed what is causing the symptoms). I just checked: $ stop/id=0 will kill the process and leaves the exit status as reported by ACCOUNTING

--------------
Queue entry: Final status code: 00002BD4
Queue name:
Job name:
Final status text: %SYSTEM-F-EXITFORCED, forced exit of image or process by SYS$DELPRC
--------------

so something in sylogin that issues stop/id=0 is a plausible explanation.

I assume the "Unauthorized access ..." message is coming from SYS$WELCOME, so it appears the process is getting logged in.

You could turn on image accounting for a short time, as you will then see what images are being executed, but that doesn't show anything done by DCL commands that are cliroutines instead of images, or anything done with lexical functions. The point being that there are many things that can be done that don't generated image accounting records.

No guarantee that the cause is in sylogin, but that is an easy thing to check and eliminate as a possible cause.

Jon

[Robert Gezelter]

Jon,

Good point!

At several client sites over the years, I have implemented login restrictions based on Identifiers (e.g., LOGIN_).

On such a cluster, adding a new node also requires adding the identifier, and making sure that the flow is correct (e.g., granting the identifier to users, or adding the node name to some list or logical name).

- Bob Gezelter, http://www.rlgsc.com

[Walter Miller_1]

Compare the logicals SYSUAF and SYS$SYLOGIN on the nodes. Is this the node that was recently added to the cluster?

[Donna Wolf]

Thks - Jon had it.
there was a sylogin on the root of the (3rd node a residual of days goneby)
It had a if user=(system) THEN STOP/ID=0
who knows why!!
My bad - I missed that. Thanks