Re: Copying users over the nodes

You can copy the files. This sometimes causes issues with accounts created by products. e.g DECnet account passwords have to match the passwords in the DECnet object database.You can add the identifier for a users UIC value with ADD/ID/USER=usernamein authorize.

Other identifiers - I find it easier to add and grant them. The identifier values can be different on different nodes. The file structure of RIGHTLIST.DAT is more complicated than SYSUAF so I don't know if doing a similar trick in DCL will work.

Re: Copying users over the nodes

Hi,

in older times, not knowing much about record management, I've created some procedures to read output file from $ MCR AUTHORIZE SHOW USER * /FULL and convert it to Authorize commands to create new accounts. Advantage of it is, that you have also Ident. information in this output. Just proxy is missing. You can do it separately.But you have to have the same UIC for a user and identifiers on all nodes. It's a good practice indeed. Otherwise, SYSUAF.DAT gets a bit messy. I assume, the same can be done by reading directly from SYSUAF.DAT, NET$PROXY.DAT and RIGHTSLIST.DAT , but didn't do it yet.

This gives two big advantages:-- A file copy by BACKUP/OWN=ORIG maintains file ownership and access BY NUMERIC VALUE, and so, ONLY if the numeric values are identical, the ownerships and accessibilities are kept consistent-- If ever in the future those systems are to be integrated, ownerships are protections are already synchronous.And if you EVER have to merge some systems, you will know what a PITA it can be if they are not!

Re: Copying users over the nodes

The format of the SYSUAF.DAT, RIGHTSLIST, and associated files are upward-compatible.

The same basic steps necessary for moving RIGHTSLIST and SYSUAF files to another node are rather similar to the steps involved in merging these files in an OpenVMS Cluster.

Regarding the new NET$PROXY.DAT file, I hope we have to use syss$system: convert_proxy.exe to convert netproxy.dat to net$proxy.dat

The big task here is that as RIGHTSLIST identifier values and UIC values that end up scattered around the target system must be rationalized to node where you copy.

The lattermost case is resolving the identifier values is the often most difficult part. If you find that an identifier value (or identifier name) from the source RIGHTSLIST collides with that of an identifier existing on the target system, you must first determine if the two identifiers perform the same function. In most cases, they will not. If you encounter a collision, changing both of the identifier binary values (or names)involved in the collision to new and unique values can prevent security problems.

In the same way the problem exist with UIC values, as these too tend to be scattered all over the system environment. Like thebinary identifier values, you will find UIC values associated with disks, ACLs, queues, and various other structures.

Re: Copying users over the nodes

Be careful! There is a lot of scope here for errors and confusion. For example, usernames with duplicate UICs, invalid device, directory & file specifications.

As you've found, playing with UAFs from DCL can exceed DCL token limits. As Jan has pointed out WRITE/SYMBOL should get beyond most of those errors, but not necessarily all (V8.2 extended DCL should help even more).

>We have long ago learned to add>identifiers NOT by just >UAF>ADD/ID , but to >explicitly give them their value as well.

Note that Ian said:

UAF> ADD/IDENT/NAME=name

This will find the UAF record "name", take the UIC value and create the correct identifier. Since it also accepts wild cards, this is a neat way to reconstruct a broken RIGHTSLIST, at least the username identifiers:

UAF> ADD/IDENT/NAME=*

HOWEVER, if the user has been granted any identifiers, ADD/IDENT won't reconstruct the user's rightslist.

> Wouldn't it be nice if we had an>application (from HP or the user>community) that could assist with >merging SYSUAF, RIGHTSLIST, proxies, etc.?

CONVERT and/or MERGE already do a fairly good job of this, except they don't allow adding the new records to an open output file.

On the other hand, the most obvious place to put this capability (especially inter node copies) is in the OpenVMS Management Station.

Re: Copying users over the nodes

has its good points I suppose but I'm not convinced that managing a VMS system or systems from a windows PC is a good idea. Now if something similar was added to the VMS Cockpit Manager http://www.emulatorsinternational.com/en/cockpit.htmthat would be differnt :-)