Login Restrictions

[Anthony Tyrell_1]

Hi guys,

I am trying to find a way of restricting users to specfic nodes in our VAX/VMS 5.5 cluster.

There are 2 distinct groups of users who should only be logging in to their own specified node. Is there a way to ensure that if a user from one group tried to log into the incorrect node that they can simply be disconnected? I would imagine some additions to each users login.com may be able to do this but I was hoping for more global solution such as adding a flag to their entry in mc authorize for example. So far my own search has not helped other than finding ways to restrict the times that they are allowed to logon "modify username/[no]access" etc etc

cheers

[Lokesh_2 · Accepted solution]

Hi Anthony,

As you have already mentioned, modifying user login command procedure is one way. But if the user account is not captive or restricted, then he can always user /nocommand qualifier to bypass his login command procedure. Moreover, once logged in he can always telnet or set host to other node. So, I think, you need to modify sylogin.com for this (not user specific login command procedure ).

Another method I can think of (not tested), you can creat nodespecific sysuaf.dat . Simply defind logical SYSUAF to you node specific sysuaf.dat
For example, on node A, you can defind following :

define/system/exec SYSUAF sys$system:sysuaf_nodea.dat

and on node B, you can define,

define/system/exec SYSUAF sys$system:sysuaf_nodeb.dat

Then start adding user accounts to you node specific sysuaf files. Initially you can copy sysuaf.template to start with your node specific sysuaf file. Also, you need to define the above logicals in sylogicals.com too.

HTH,
Thanks & regards,
Lokesh Jain

[Wim Van den Wyngaert]

I wouldn't do it but you can use 2 sysuaf's : 1 for each system. I would prefer the login or (better) sylogin modification.
Also : be carefull with generic batch queues.

May be ACL's are possible too (e.g. only access for sys$node_node1).

[Martin Vorlaender]

Hi,

you can attach arbitrary identifiers to UAF records:

UAF> ADD/IDENTIFIER idname /VALUE=idvalue
UAF> GRANT/IDENTIFIER idname username

Unfortunately, AFAIK, there's no programmatic DCL way you can retrieve that information (short of parsing the output of SHOW PROCESS/ALL), so you'd have to write a small program that calls $FIND_HELD.

Hope it helps,
Martin

[Anthony Tyrell_1]

thanks for your quick reply Lokesh.

It isnt really an option we have to use local sysuaf.dat files. The reason is that the specific users do have logins on the other nodes just that there are a handful of accounts(approx 10 node A, 10 node B) that must ONLY login to these nodes. All other accounts can login across the cluster.

These specific user accounts run an application at logon which fires up a basic GUI environment which would cause problems if launched on wrong node. Therefore only these accounts need to be restricted.

Hope this explains things better.

[Uwe Zessin]

Anthony,

go and code the logic into SYS$MANAGER:SYLOGIN.COM as Lokesh suggested. Dealing with multiple SYSUAFs and a single RIGHTSLIST is a big pain.

[Karl Rohwedder]

F$GETJPI("","PROCESS_RIGHTS") retrieves a comma separated list of identifiers the process holds. But beware, that the list may be quite long and break the symbol length.

[Anton van Ruitenbeek]

Ive had this also with a costumer.
They had multiple SYSUAF, Que-files, RIGHTSLIST. Big pain in the ass.

I changed it to one SYSUAF, RIGHTSLIST etc. and created identifiers ACCESS_. In the SYLOGIN I checked (F$GETJPI("", "RIGHTSLIST") ) for apearance for this identifier. If not, give a beatifull message that the person is connected to the wrong node.
The users who need to logon to both nodes need to have ofcourse both identifiers. Lateron there get more nodes, so more ACCESS_ identifiers. As noticed before, watch out for the size of the identifiers to one person. In I expect in 8.2 (extented DCL) it will be no more the problem. Now we check during the F$GETJPI() for the length, if to long get the next block.
Yes, another costumer of me had the problem of too much identifiers on one process during the upgrade to VMS 7.3-1. System crashes because of a fault in the kernel code of the F$GETJPI.

AvR

[Jan van den Ende]

Anthony,

this looks like a minor subset of some functionality we have.
Many apps on 4-node cluster. Most apps are clusterwide, but various apps are for some reason bound to a single node; and sometimes we want to reserve a node for maintenance work, and restrict clusterwide apps to the 3 other nodes.
Some LAT connections, mostly telnet.
We have implemented this by having the users NEVER connect to a node or to the cluster, but instead having DNS have the names of ALL applics, with (round-robin) CNAME(s) to the node(s) that currently offer the service. Same, but even easier principle for LAT services.
On the nodes we define systemwide logicals of name NODE_, and any user trying to activate an applic NOT available on the current node gets blasted.

This not only gives you what you are asking, with any desired granularity, but also allows you to SHUFFLE your apps if desired for any reason (eg, maintenance, or new hardware).


Jan

[Antoniov.]

Hi Anthony,
I haven't a cluster avaiable so I can't verify; my question is:
If they are logged as remote, I guess you can limit in SYSUAF the remote interactive access otherwise yuo can only update SYLOGIN.COM

Antonio Vigliotti

[Willem Grooters]

I may be wrong, but AKAIK logging on onto the CLUSTER means your process can reside on an arbitrary clusternode - it can not be determined what will be your host for that session.
That means that if you want to restrict users to a specific machine, don't let them logon to the cluster but to a specific node.
(AKA Unix-cluster login)

But as suggested already:

If you want to restrict ANY access to the other node, put an ACL to any file that disallows users that do not hold that identifier. if possible, group the files onto seperate directories (or even disks)

To whic group a user belogs can be stored (the standard way) in SYSUAF.

an example:

Cluster consiste of NodeA and NodeB.
Some users are restricted to NodeA, some to NodeB, and a third group needs acces to both.
The first group has ACL for NodeA only.
The second group has ACL for NodeB only.
The third group has both.

The location for NodeA specific files allow acess for NodeA-Id holders only, nodeB specific files fro NodeB only, and shared files carry both. When access is blocked from the highest point (disk, or directory), you have the least trouble:

(ID=NodeA, access=Read+write+execute+delete)
(ID=*, access=none)

will allow NodeA holders to access the files below this root, but NodeB holders cannot access it.

(If you are running 7.3-2, you could even think of writing your own SYSUAF/LDAP extension)

Willem

[Dale A. Marcy]

How do the users run the application? If it is by a symbol, what we have done is re-define the symbol on nodes that cannot run the application to type a message to user instructing them which nodes they can run the application on.

[Martin P.J. Zinser]

Hi,

depending on your setup. If the users neatly separate along UIC groups or can be organized that way a simple test in sylogin using f$getjpi("","grp") would be
sufficient to grant or deny access.

Greetings, Martin

[Terry Yeomans]

Sorry to simplify things a bit but why don't you just DISUSER the accounts on the nodes required ? You can then look at the INTRUSIONS on each node to see who is doing what.
Terry.

[Jan van den Ende]

Terry,

Since the flags are SYSUAF attibutes, that would imply multiple SYSUAF's, which was already rejected as a highly unwanted solution.

Jan

[John Gillings]

Anthony,

Use identifiers. Here's a simple mechanism. Suppose you have 2 nodes, A and B. Any process logged into node A will have a rights identifier SYS$NODE_A, those on B will have SYS$NODE_B. You can create an identifiers DISALLOW_A and DISALLOW_B and GRANT it to any users you want to deny access to a specific node. Now create a command procedure containing a LOGOUT command:

CHECK_NODE_ACCESS.COM
$ LOGOUT

Put an ACL on it:
(IDENTIFIER=SYS$NODE_A+DISALLOW_A,ACCESS=EXECUTE)
(IDENTIFIER=SYS$NODE_B+DISALLOW_B,ACCESS=EXECUTE)
(IDENTIFIER=*,ACCESS=NONE)

From SYLOGIN.COM simply add

$ @CHECK_NODE_ACCESS

Those users with the identifier pairs will be able to execute the procedure, anyone else will be denied access and therefore won't get logged out. You may want to place the lines:

$ DEFINE/USER SYS$OUTPUT NL:
$ DEFINE/USER SYS$ERROR NL:

immediately before the check to avoid error messages. One potential problem is anyone with BYPASS privilege will also get logged out (but then no one should have BYPASS by default!).

An alternative is to reverse the sense of the access and use the procedure to define a global symbol or logical name, then test its existence and logout anyone who doesn't have it.