Problem with SYSUAF

[Karen Lee_3]

I was having a problem with adding an ID to a user record - it kept saying the id was there but when i did a UAF>show username the id wasn't visible. so i decided to 'remove username' and start all over again.

now it keeps saying the user record already exists. I've tried to look it up by uic... not there, i show the username ...not there.

on the usersname home directory it still shows it owned by the user - what's up with that.

i went through the entire system disk to make sure there wasn't another copy of the sysuaf.dat - i did find one so i renamed it. my sysuaf logical points to sys$sydevice:[vms$common.sysexe]sysuaf.dat and the file is there.

what's up with this???

[Ian Miller.]

could there be an identifier with the same value as the UIC of the user that you are trying to add.

What is the exact error message?

[Heinz W Genhart]

Hi Karen

there is a logical name sysuaf. The best is you define this name in syslogicals.com.

def/sys/exec sysuaf sys$common:[sysexe]sysuaf.dat

If not allready so, copy then the sysuaf.dat to sys$common:[sysexe] (there where it belongs to)

You can then use MC authorize to add, modify , remove ..... user accounts.

Without this logical name you have to do a set default to sys$common:[sysexe] prior to using authorize.
Also without the logical and your default set to your home directory, authorize will find out, that there is not yet (maybe) a sysuaf.dat and authorize will ask you to create one. If you did this once before, you have perhaps a sysuaf.dat in your home director or within that directory where was your default when using authorize

Hope that helps

best regards

Heinz

[Karen Lee_3]

Ian, it will let me re-add the username 'salesar', but says it's a duplicate. then if i try and grant/id it says it's a duplicate

it's behaving like there is a shadow sysuaf.dat file somewhere that it's reading but i'm not able to actually see or write to.

[Uwe Zessin]

Karen,
can you copy the exact command and error message?

To me, it sounds like you have a duplicate identifier. It is possible to mess with the SYSUAF/RIGHTSLIST.

Let's assume we have a username UWE with UIC [77,1]. It is possible that there is an identifier KAREN with UIC [77,1]. In that case you can get an error message when you try to create a username KAREN with UIC [77,2], for example.

[Heinz W Genhart]

Hi Karen

can you write your doings into a logfile.
Importand would be a mc authorize show 'username' and a mc authorize sho /ident *

Regards

Heinz

[Jan van den Ende]

Karen,

with the info given so far, I an tempted to do 2 things:

MC authorise show

that record has a UIC value,, and now

MC AUTHORIZE show /id /valu=uic=[the_found_valie>]

I more or less expect this to reveal smothing odd.

Proost.

Have one on me.

jpe

[Karen Lee_3]

found the problem. it seems that when i removed the original username it left the rights identifier for that account - no idea why. so when i 'readded' it with a new uic it kept saying it already existed.

I re-added the account with the same old uic number and it looks fine now. sorry guys, but thanks for all your help.

[John Gillings]

Karen,

>it seems that when i removed the original
>username it left the rights identifier for
>that account - no idea why. so when
>i 'readded' it with a new uic it kept
>saying it already existed.

This is a GOOD policy. When removing a username use UAF> REMOVE/NOREMOVE to leave the rights identifier in place.

Why? Because it helps you identify which UICs have been used in the past. A good site security policy will forbid the reuse of a UIC for a different person. This will prevent files and access rights belonging to the original owner of the UIC being accessible to the new owner.

USERNAMEs vs IDENTIFIERs

Your confusion is "normal" and somewhat of a right of passage for an OpenVMS system manager. The rights identifier mechanism was added in V4, and not implemented in the UAF file. Identifiers are stored in an independent file (RIGHTSLIST), so the system manager must understand they sometimes need to be managed separately.

In the UAF, the USERNAME is the primary NODUP key, and there may be multiple UAF records with different USERNAMEs, but sharing the same UIC. In RIGHTSLIST, both the UIC and the IDENTIFIER must be unique. So, if you have multiple usernames sharing a UIC, there will only be ONE identifier. When you add a new username with an existing UIC, AUTHORIZE will attempt to create a rights identifier. Since the UIC is already in use, the attempt fails with a DUP error.

You need to learn that the USERNAME is a UAF entity. It has a corresponding UIC which may be shared by other usernames. The RIGHTS IDENTIFIER is an independent RIGHTSLIST entity. It also has a corresponding UIC, which is unique.

Also note that despite the HELP text, both parameters to UAF> GRANT/IDENTIFIER are IDENTIFIERS.

By convention the rights identifier corresponding to a particular UIC is *usually* set to the same string value as the username with the same UIC. However, this need not be the case! (breaking this convention can be a threat to your sanity!)

If you see any kind of DUP message, you need to check all these:

UAF> SHOW username
UAF> SHOW/BRIEF [uic]
UAF> SHOW/IDENT username
UAF> SHOW/IDENT/VALUE=UIC:[uic]

If you follow the policy of never reusing a UIC, if you see an identifier already defined with a different name you need to choose a different UIC.

Another clue to a UIC/username clash is in the output of

UAF> SHOW username

Look at the way the UIC is displayed. It will look something like this:

UIC: [100,5] ([username])
or
UIC: [100,5] ([group,username])

If the username shown in the brackets is different, that indicates the UIC identifier is different from the username.

(hoping that all makes some sense!)

[Robert Gezelter]

Karen,

Yes, that would do it.

As John explained, while there is a convention that rights identifiers have the same name as the username, this is far from a requirement (for various reaons).

The problem you encountered is not uncommon. Most of the time that I have found it, it was caused by a migration of a user from one UIC group to another.

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