Better way to modify user's UIC group...

[Bob Talbot]

Hi Folks,

I am trying to right up some procedures for our operators dealing with maintaining the user population on our VMS systems. Adding users is no problem. But, when we receive a request to move a user from one department to another - i.e. moving them to a different UIC group/account, finding the next available UIC, revoking rights identifiers, granting rights identifiers, setting the default directory and files to the new UIC group (and corresponding ACCOUNT), etc., etc,. etc. IT really requires a VMS system Manager who knows his/her way around authorize. Unfortunately, our operators are not as savey. I searched to see if there was a DCL routine out there (ala adduser.com) but have come up empty.

Any suggestions to streamline this procedure so our operators do not have to do a lot of research/UAF commands when moving a user from one department to another?

Thanks.

Bob

[Robert Gezelter]

Bob,

Personally, if I were doing this, I would write a command procedure that did all of the work. It would take several hours, but it would transform this from a system manager chore to an administrative task.

At first impression, you could look up the proposed new UIC using either the RIGHTSLIST (probably easiest using the lexical functions) or by other methods. Then it is necessary to modify all of the references to the old UIC to the new UIC. Depending on your user community, this can be a challenge.

For normal user accounts, things are not too complex. The challenge is for users who are more sophisticated, or shall I say those who make more extensive use of the system's protection capabilities. The side effects can be interesting. Consider, for example, that the group logical name table will also change, and this may affect parts of the user's login script adversely.

All in all, it can be done, but care is needed.

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

[Hoff]

Lock down intra-group and world access based on UIC, and use identifiers and potentially resource identifiers to control membership to the particular organization(s).

Yes, intra-group access and similar protection settings are discretionary, though you can certainly run simple tools that reset the various object protections.

Assign and leave the users in the same UIC, and tweak membership by granting or revoking identifiers as needed.

Stephen Hoffman
HoffmanLabs LLC

[John Gillings]

Bob,

If this type of thing happens regularly, I'd recommend changing the way you allocate UICs. Stop using GROUP to indicate departments. Allocate a permanent UIC to a person when their account is first created, then use rights identifiers to determine (logical) group membership. Remember that UICs having group and member numbers is a throwback to the VMS V3 security model, which is itself derived from even older 16 bit operating systems. Don't be limited by the archaic model, just because it's there. The V4+ model is far more flexible.

As well as greatly simplifying the process of moving users from department to department (just revoke the old department and grant the new one), you have the flexibility of allowing one user to straddle departments. This might help in transition, or for mangers who need visibility into two or more domains.

From where you are at the moment, this might be a reasonably large task, but once it's done, things should be much simpler into the future.

(on the subject of UICs & implied reuse, I always recommend UAF> REMOVE/NOREMOVE when deleting a user. Keep the rights identifier for the UIC to block reuse).

[Aaron Lewis_1]

Bob, what I've done on a couple of my systems with the same issue, is to create a 'dummy' account that is 'expired & disusered' for each department. Then when somebody moves, or is added the opearator just needs to copy the dummy to the new username, and remove the expired & disuser flags.

[Dean McGorrill]

theres a lot to moving users around. when I
was at didital we had what seemed to be a large move a month. we even gave each system blocks of numbers for identifiers. a users files could move that way w/o identifier value collision to another system. we pulled all-in-one data, even
new mail count from vmsmail_profile.data.
eventually we got good enough to move people w/o any complaints (about us) I will see if I can find some of those tools in
my archives.

Dean

[Jan van den Ende]

Bob,

we have a similar need.

And at 20 - 50 mutations daily (and incidental peak numbers of > 1000 have occured several times) it is clear that this should not be done by hand.

Firstly, we DECLARED that the info in the personnel system is considered to be correct. Anything needs changing/correcting? Have that entered in the personnel system be the PO department.
Each day a batch of all changed records is presented to VMS (and Unix, and Windows).
Each entry in that system is identified by a unique number, and we decided to use (the octal value of) that numeber as the member UIC.
And each department has its own ACCOUNT name, and e numeber which is the identifier name of the GROUP UIC.
Various applications also use fields from the personnel record as user attributes.

Users from some departments automatically get application identifiers, or are revoked upon leaving a department.

All the rest is "just" a (big) DCL procedure that takes care of all UAF mutations, login device / owner switching, moving of files, and required mutations in the various databases.

"A change requires thinking about it. A repeat change requires optimizing. A regular changed requires to be automated".

Proost.

Have one on me.

jpe