secondary group for the user

[Amit Phadnis]

Hi,

Is there any secondary group funda in the Open VMS? If there how to create the secondary group for the user?

Actually I want to make create a .com file, which after executing will allow only limited and particular defined users only to login.

Rest all other users will not able to login.

Also if any user is already logged in, afer running this file,his session should get killed if his username or UID is not mentioned in the group which is allowed.

have U any plans or script for this?

Amit.

[Ian Miller.]

The command procedure could define a logical name. In SYLOGIN you could check for this login and only allow the required users to login. The command procedure could also scan for users currently logged in and log them out (see F$CONTEXT, F$PID, F$GETJPI)

[Robert Gezelter]

Amit,

If I understand the posting correctly, there are really two questions:

1) can I limit logins to a particular group?
2) can I log off users who do not belong to this group?

The answer to both questions is yes, although the techniques are different.

Microsoft's Windows family of systems (Windows NT, 2000, XP, 2003, VISTA) use a concept of accounts belonging to multiple groups as part of their security model. For example, an account may be a member of the Admistrator, Site Administrator, and Remote Users groups). OpenVMS uses a slightly different model.

In OpenVMS, users have a single group assignment. This is used for as part of the privilege and basic file management scheme. Users (and their processes) and also may hold a collection of Identifiers. The meaning of "Holding an Identifier" is most commonly access rights to a set of files and resources, which is part of the overall protection environment.

Identifier possession can also be checked from DCL (using the lexical function F$GETJPI) and the underlying system serice or run time library call from within programs. How to do this is covered briefly in my DECUS presentation "DCL Lexicals: OpenVMS Juhitsu" from the 1995 Fall US DECUS Symposium, available through http://www.rlgsc.com/decus/usf95/index.html

A modification to SYS$MANAGER:SYLOGIN.COM to check for a particular Identifier under certain circumstances is not difficult. Please remember to omit the consequences if the user is a member of one of the system management groups (or holds the SYSPRV) privilege.

Logging people off who are already on is more complex, but can be done.

I hope that I have been of assistance. If I have been unclear, please let me know.

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

[Hein van den Heuvel]

There are scripts floating around to prohibit multiple logins

The best method on VMS for this is to simply $OPEN/ERROR=in_use a specific file exclusively. If that works, the process is the first and only. If it fails, well it is in use and the scipt jumps to label 'in_use' where you issue an expkanation, log the event and exit.

There is no multy group concept, but something close and better on VMS: RIGHTS.
You PROTECT specific OBJECTS (like files) and then allow holders os specific RIGHT to access them A user can have many or no rights.

Please check the manuals (and help) for a while before asking details.
Hints:
$HELP SHOW PROC/RIGHT
$MCR AUTHORIZE HELP GRANT
$MCR AUTHORIZE HELP ADD
$HELP SET SECU
:

hth,
Hein van den Heuvel

[Amit Phadnis]

Heuvel,

As you have mentioned, we can use RIGHT concept to protecting the users from login. But in that case, that will be all time protection.

my requirement is such that, suppose we are having server maintainance and we want no users should login except system administrators. In such case these prevetion of login to others users is for particular short time. After which they again should able to login.

Will this thing can achieved by logic you are suggesting?

Amit.

[Martin Hughes]

The method suggested by Ian is the neatest way to lock out general users. Setting this up requires some DCL skills and familiarity with lexicals.

Another method is to set interactive logins to zero, thereby stopping any users without OPER privelege logging in. This method assumes that your general user base does not have OPER privelege.

[Hein van den Heuvel]

>> As you have mentioned, we can use RIGHT concept to protecting the users from login. But in that case, that will be all time protection.

Well, you could dynamically chance security settings, but that does not feel right.

Admittedly I read your question differently from what you intended and now clarified.

Teh file mechanism was in fact a cheap / simple wrapper aroudn the OpenVMS Lock Manager.

LOCKS, not logical names, are the very best way to control this, but require real programming, not scripting. You can require a concurrent-read lock for 'normal users'. In special times, request a 'protected write' lock. This can trigger a blocking AST in for the normal users allowing for very gracefull end (message to screen). If the user do not go, then GETLKI can be used to find out who is blocking. Cluster wide. Sweet stuff!

Files can be used to approach this:
$OPEN/READ/SHARE=READ/ERROR=closed_for_business for normal use.
$OPEN/READ/ERROR=kill_users for super use.

$SHOW DEV/FILE would give a quick list of PIDs to STOP if neede.


>> my requirement is such that, suppose we are having server maintainance and we want no users should login except system administrators.

Would that be for 1 system, or the cluster?

Anyway, the OPER priv, as replied just now, already implements the prevention of login in. It does not kill. A quick DCL loop with F$GETJPI and checking for processes holding OPER priv should be easy enough to construct.
Be sure to use 'STOP/EXIT' instead of, or before 'STOP/ID' to give processes a chance to clean up. (flush RMS buffers). On older VMS versions you may need a little program (as provided below) to achieve that.

Hein.

#include stdio
main(int argc, char *argv[])
{
int pid, sys$forcex();
if (argc < 2) return 16;
sscanf (argv[1], "%x", &pid);
return sys$forcex(&pid,0,0);
}


>> In such case these prevetion of login to others users is for particular short time. After which they again should able to login.

I might still prefer, and try to get, to blcok specific activities, not the login.
Surely there is no harm just having them logged in. They should just not be able to do certain things which is different all together. Blocking login is too big a hammer for a subtle person like myself :-).

Compare with cellphones in the airplane/theater/meetings. Do you want to prevent the audience from walking in with a phone (at performance times) or do you just want them not to use it during special times?

>> Will this thing can achieved by logic you are suggesting?

Ys, As per shared file explanation.

Regards,
Hein

[Robert Gezelter]

Amit,

Preventing users from logging on during maintenance is straightforward using identifiers.

The (most flexible) way it is done is to define a logical name in the system, group, or other persistent logical name table that specifies what identifiers are PROHIBITED from logging onto the system at this time. Then then embed the appropriate check in the SYS$MANAGER:SYLOGIN.COM file (I have also accomplished similar things using group login files and concealed logical names, as was described in my OpenVMS Technical Journal, article (see http://www.rlgsc.com/publications/vmstechjournal/inheritance.html ).

In this way, "maintenance" can be defined in a far less privileged way, since the Group Logical Name tables are controlled by a different privilege. The same thing can be done with separate logical name tables to control different applications.

The key to this is the list of identifiers held by each user, and locating user default directories on a rooted directory tree pointed to by a concealed logical name (as described in the article).

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

[Jan van den Ende]

Amit,

you specified
>>>
my requirement is such that, suppose we are having server maintainance and we want no users should login except system administrators
<<<

VMS (or OpenVMS, which really are the same) has, from the earliest I can remember, always had a dedicated mechanism for that:
$ SET LOGINS/INTERACTIVE=0

Then only users that have DEFAULT PRIV = OPER (typically system managers & operators, or what you call Administrators) in their authorisation are allowed to log in.

If service is to resume, then simply
$ SET LOGIN/INTER=

hope this helps

Proost.

Have one on me.

jpe

[Jon Pinkley · Accepted solution]

The use of a logical name containing the list of "exceptions" and a check in SYS$SYLOGIN has been proposed, and that will work. I will make an alternative proposal.

The use of identifiers (RIGHTS) can be used here. Specifically, the combination of process and system rights.

First create an identifier that you will grant to users that you want to allow to log onto the system when the others are disallowed. For this example, I will use DB_ACC. This same identifier can be used to grant access to files, or even charge disk quota against if it has the resource attribute.

Now grant this identifier to all the users that you want to be able to log in at all times.

Now the non-obvious part. VMS allows you to grant an identifier to the current node (system). These rights show up in the System rights: list at the bottom of the output from

$ show process/rights

On most systems, the only identifier that will show up here is the node specific identifier, SYS$NODE_nodename. For example, if your nodename is AMIT, you will see SYS$NODE_AMIT.

Let's assume that you normally allow all users to login, but prohibit logins when some special system maintenance is in process.

In your SYS$COMMON:[SYSMGR]SYSTARTUP_VMS.COM issue the command:

$ set rights/enable/system DB_ACC

Once that is active, all processes on that node will "hold" the DB_ACC identifier; i.e. it will show up in the list returned by f$getjpi("","RIGHTSLIST")

After it has been added to the systems rightslist, put a check in your SYS$SYLOGIN to check whether this identifier is in the list of rights.

For example

$ myrights_c = "," + f$getjpi("","RIGHTSLIST") + ","
$ if f$locate(",DB_ACC,",myrights_c) .lt. f$length(myrights_c)
$ then
$ ! allow login
$ else
$ ! disallow login
$ endif

Your command file to disable logins would then have the command:

$ set rights/disable/system DB_ACC

and to re-enable:

$ set rights/enable/system DB_ACC

Note that all UICs that have been explicitly granted the identifier will have DB_ACC in their process rightslist, and therefore taking it out of the system rightslist will not affect them.

You also want to kill all the currently logged in processes that do not hold the DB_ACC identifier, so you will need to have the command procedure scan through all the processes as suggested by Ian Miller, but check if DB_ACC is in their process list, and kill them if it is not. This is similar to the case with logical names.

The advantage of using a logical name with a list of "excluded" users would be that it is much easier to change "on the fly". If you have a cluster, you can even put the logical name in a clusterwide logical name table. If you have a cluster, and you don't need to control access to files based on whether the identifier is held, then this is a lot simpler than using system rights, which must be enabled on each system in the cluster.

The advantage of identifiers is that they can be used to protect access to various objects, like files and queues.

We use the identifier method, and sysman to enable/disable the system rights clusterwide.

[Jan van den Ende]

Amit,

I would tend to elect Jon Pinkley's method over my own!!

And so mostly, because _HIS_ method also works for NON_interactive accesses..

I worked it over twice, and found it so good, that I intend to implement it on OUR site (of course, after trying it on our sandbox)

I was not aware of
$ set rights/enable/system
so, give Jon full points, and any you did not intend upon may be considered given by me.

Proost.

Have one on me.

jpe

[Robert Gezelter]

Jon,

Enabling and disabling is an interesting solution.

I admit that I prefer using the logical name approach for two reasons:

- it can be controlled it on a cluster-wide basis if desired; and
- it can be controlled on a group-by-group basis (on some systems, I actually have implemented it to leave users on, just remove certain menu items during application maintenance)

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

[Hein van den Heuvel]

Yeah, but you can not see who looked at a logical name. You'll still need a mechanism (rights? privs?) to find out who to kill or suspend.

A shared file is trival and gives a simple method to see who is blocking

A lock gives that also, and can trigger action in consumers, but requires coding.

[Robert Gezelter]

Hein,

Actually, the way I do it it is straightforward. First, I use the logical name to only contain a list of disabled (or enabled) user groups/applications.

Then, if you want to track who attempted to login (and you want the audit events), simply create a file that is checked (if you disable logins for that group, simply protect the file and you will get an alarm).

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

[Jan van den Ende]

Bob,

yes, that is about the thing we use, but with finer granularity:
Each application requires an identifier to activate, and we rename the identifier if we want to block that applic.
The numeric value stays, and the user still holds it, but the Alphabetic check fails, disallowing activation (a lot better/faster/easier than re-granting ~3 - 4 K of users!)
The nodes that the app is allowed to run on is controlled by its DNS name pointing to the allowed nodes, and we catch any tricksters by system-wide LNMs to block access for those that somehow DO try to start the an app at a (temporarily?) forbidden node. Just fantastic for applic rolling upgrades!

But still I LOVE the simplicity of system identifiers, and that mechanism escaped me until now.

fwiw

Proost.

Have one on me.

jpe

[Jon Pinkley]

Jan van den Ende wrote:
>>I would tend to elect Jon Pinkley's method over my own!!

>>And so mostly, because _HIS_ method also works for NON_interactive accesses..

>>I worked it over twice, and found it so good, that I intend to implement it on OUR site (of course, after trying it on our sandbox)

Jan, thanks for the kind words, but I am not sure how system identifiers alone solve the problem of non interactive access any better than the logical name approach, or even the set login/inter=0 approach. We can put ACL's on queues, but that will just cause a submit to fail, and that may or may not be what you want to happen. For interactive users, it is probably ok, but do you want a batch job to fail when it tries to resubmit itself?

In the simple case where all users that you want to allow in have OPER as a default privilege, then a stop/queue/next on user accessible queues, and set login/inter=0 + waiting for any running batch jobs to complete
is certainly a lot simpler than using system rights or logical names. For Amit's case that may be sufficient. That's what we used to do, but we now have the requirement to allow different "groups" of users in at different times, and the use of identifiers is the method I used.

Be aware that if you are using the identifier for access checks in an ACL, having the identifier "pulled out from under" the process can cause failures. The effect is immediate and seen by all processes on the system, just like a system logical name. If the identifier is being used for file access checks in an ACL, and the identifier is removed, the next open will fail. Files that are already open are not affected. This can cause problems if you are not aware of what is happening. e.g. a batch process that is partially complete could fail at the next file open.

We have batch queues for each set of users, and the batch queues are stopped before we do our maintenance. If you allow an entry to start, and it exits due to not holding the identifier, the entry is lost. So you need to either stop the queues, or use queue characteristics to prevent jobs from starting.

[Jon Pinkley]

Jan van den Ende wrote:
"Each application requires an identifier to activate, and we rename the identifier if we want to block that applic.
The numeric value stays, and the user still holds it, but the Alphabetic check fails, disallowing activation (a lot better/faster/easier than re-granting ~3 - 4 K of users!)
The nodes that the app is allowed to run on is controlled by its DNS name pointing to the allowed nodes, and we catch any tricksters by system-wide LNMs to block access for those that somehow DO try to start the an app at a (temporarily?) forbidden node. Just fantastic for applic rolling upgrades!"

That's clever. And it avoids the problem of an application failing due to an identifier being removed out from under it, since the ACLs are looking only at the binary values.

Do you have this identifier check in the application (or a sharable image they link agaist)? Do you use the identifier in any ACLs?

Jon

[Amit Phadnis]

Hi Jon,

thanks for your wonderful solution and logic.
But I am facing problem when granting the identifier to the user. I am getting following error,

UAF> grant/identifier LOGIN [600,5]
%UAF-W-NOTIDFMT, ID name parameter does not translate to ID format

How to ge out of this error.

Amit.

[Martin Vorlaender]

Amit,

$ HELP/MESSAGE NOTIDFMT

The identifier name that you specified does not translate to a corresponding value in general identifier format. Identifier name values translate to either general identifier format or UIC format. General identifier names may be 1 through 31 alphanumeric characters and are stored with an integer value in the range of 32,768 to 268,435,455. General identifiers are created by the AUTHORIZE command ADD/IDENTIFIER.

When the AUTHORIZE command GRANT/IDENTIFIER is used, the first identifier specified must be in general identifier format. In other words, a UIC-format identifier cannot be granted to another UIC-format identifier.

Determine why the identifier name is not a general ID. An identifier name and its corresponding value can be displayed with the AUTHORIZE command SHOW/IDENTIFIER. To change the value of an identifier name, use the AUTHORIZE command MODIFY/IDENTIFIER.

cu,
Martin

[Amit Phadnis]

Martin,

I have used the username instead of UIC, but getting same error message.

UAF> grant/identifier LOGIN aphadnis
%UAF-W-NOTIDFMT, ID name parameter does not translate to ID format
UAF>

Now how to translate to ID Format. 'aphadnis' is the id-name.

Amit.

[Ian Miller.]

the problem is with the identifier
LOGIN

What is the result of
UAF> SHOW/ID/FULL LOGIN

[Jon Pinkley]

Amit,

As Martin and Ian have hinted, the most likely problem is that LOGIN is an identifier associated with a UIC, and not a general identifier.

In the following, COOKER is a UIC identifer, which normally coorespond to a USERNAME. The value shows up as [grp,mem]. UIC identifiers can't be granted. DEVELOPER is a general identifier, and it can be granted to a UIC. They will have a Value displayed in Hex starting with %

$ uaf s /id cookev
Name Value Attributes
COOKER [000043,100443]
$ uaf s /id developer
Name Value Attributes
DEVELOPER %X800100AC RESOURCE
$

>>>UAF> grant/identifier LOGIN aphadnis
>>>%UAF-W-NOTIDFMT, ID name parameter does not translate to ID format
>>>UAF>
>>>
>>>Now how to translate to ID Format. 'aphadnis' is the id-name.

Is LOGIN the identifier you are going to enable when logins are allowed? If so, it must be a general identifier.

Do you know how the LOGIN identifier was created? If it was created when a user LOGIN was added, then you will need to choose a different ID name.

To create a new general identifier, use a command like command

$ mcr authorize add/id LOGINOK

Authorize will choose the "next" available number and associate it with the identifier name specified (LOGINOK).

Then you would grant LOGINOK to a UIC using either form, i.e. either

UAF> grant/identifier LOGINOK [600,5]

or

UAF> grant/identifier LOGINOK aphadnis

I just looked at the help in Authorize for add/identifier, and there isn't an example showing the simple case.

My guess is that you followed the example given for INVENTORY, which was a UIC. If that is the case, and there is nothing using that identifier, you can delete the identifier and the add it. If you did not create the LOGIN identifier using a command like UAF> add /id LOGIN /value=[2,4], then do not delete it! I am not giving the commands that are used to delete it, because I want you to be sure that is what you want to do before you do it.

Good luck,

Jon

[Jon Pinkley]

Amit,

My last paragraph had the incorrect syntax for adding a uic valued identifier.

The correct syntax would have /value=uic:[2,4]

My point is, always check the help/documentation before blindly following any advice you get here, because we're humans too.

Cheers,

Jon

[Jan van den Ende]

@Jon

a few answers back you asked

>>>
Do you have this identifier check in the application (or a sharable image they link agaist)? Do you use the identifier in any ACLs?
<<<

We do this alphanumeric check first thing in the (attempted) application startup.
And yes, ALL files belonging to an applic are so protected.
It is even taken one step further: all these _ACCESS identifiers are created with /ATTRIB=DYNAMIC.
In SYS$SYLOGIN any xxx_ACCESS idents are DISABLED (ttat is why DYNAMIC) upon NETWORK login to prevent access to them without the application logic.
(Of course, specific files that should be NETWORK accessible are NOT subject to such refusal).

hth

Proost.

Have one on me.

jpe