unable to grant identifer

[TMcB]

Hi everyone

I have 10 users all sharing the same uic [141,2].
I get an error message when trying to grant them an identifer.
UAF> grant/ident fauser [141,2]
%UAF-E-GRANTUSR, user identifier [141,2] does not exist; FAUSER could not be granted
-SYSTEM-F-NOSUCHID, unknown rights identifier

The identifier is sucessfully used for other accounts which I can see listed using "show/ident fauser/full".

the accounts worked OK yesterday- will it be a case of recovering sysuaf or the rightslist from yesterday

Any ideas??

Thanks

Terry

[Ian Miller.]

what happens when you do this?

UAF> SHOW/BR [141,2]

(Why do you have 10 users with the same UIC? This is not recommended)

[TMcB]

Hi Ian

thanks so much for getting back to me.
I restored the sysuaf and rightslist from yesterday - the accounts worked OK then,
and the users accounts are now OK.

Bye

[Karl Rohwedder]

Perhaps a user was added with /NOADD_IDENT qualifier (or the identifier accidently removed), to readd a user identifier use

UAF> ADD/IDENT/USER=[141,2]

regards kalle

[The Brit]

The problem is that when a user ID is added to the SYSUAF, Authorize will try to add the identifier to the RIGHTSLIST with a value = User_ID UIC.
Unfortunately, the RIGHTSLIST will not allow identifiers with the same value. If you do a

UAF> show /id /value=UIC:[141,2]

you will probably see that only one user ID shows up (this would have been the first account with this uic). The later accounts failed to be added to the rightslist and therefore you cannot grant them additional Identifiers.

The second thing is that you cannot grant an identifier to a UIC, (for the reason described above), it can only be granted to a User ID, and then only if the User ID has a unique UIC.

to remedy the problem:

1. the command above will show you who currently owns the Identifier with the value [141,2].
2. remove the Identifier from the rightslist using "remove /id "
3. modify your 10 users UIC's so that each has a unique UIC, using (modify /UIC=[new UIC]"
4. once they have unique uic's, add them to the rightslist using "add /id /user="
5. You should now be able to grant the "FAUSER" Identifier to the individual users.

Dave.

[Jan van den Ende]

Terry,

I strongly advise you to follow the instructions of Dave "the Brit".

But it is probably not enough...

Now each user has a different UIC value.
_IF_ you still want them to use the same SYS$LOGIN ("home dir"), which _I_ would strongly advice agains, _THEN_ you have to make permissions on that DIR and its contents to all users.
_IF_ (advised) you decide to treat them as separate entities (Why else have you given them individual usernames), _THEN_ give them their own SYS$LOGINs, owned by themselves.

(Hint: if separate usernames are to (be able to) track individual actions, those ARE registered usuually based on UICs, so using 1 UIC deos not distinguish them!)

If you need more guidance, please ask.

Proost.

Have one on me.

jpe

[Jan van den Ende]

Btw, Terry,

from your Forum Profile:


I have assigned points to 212 of 306 responses to my questions.


Maybe you can find some time to do some assigning?

http://forums1.itrc.hp.com/service/forums/helptips.do?#33

Mind, I do NOT say you necessarily need to give lots of points. It is fully up to _YOU_ to decide how many. If you consider an answer is not deserving any points, you can also assign 0 ( = zero ) points, and then that answer will no longer be counted as unassigned.
Consider, that every poster took at least the trouble of posting for you!

To easily find your streams with unassigned points, click your own name somewhere.
This will bring up your profile.
Near the bottom of that page, under the caption "My Question(s)" you will find "questions or topics with unassigned points " Clicking that will give all, and only, your questions that still have unassigned postings.
If you have closed some of those streams, you must "Reopen" them to "Submit points". (After which you can "Close" again)

Do not forget to explicitly activate "Submit points", or your effort gets lost again!!

Thanks on behalf of your Forum colleagues.

PS. - nothing personal in this. I try to post it to everyone with this kind of assignment ratio in this forum. If you have received a posting like this before - please do not take offence - none is intended!

PPS. - Zero points for this.

Proost.

Have one on me.

jpe

[Jon Pinkley]

>>>>The Brit wrote at Aug 7, 2007 16:30:34 GMT:
"The later accounts failed to be added to the rightslist and therefore you cannot grant them additional Identifiers.

The second thing is that you cannot grant an identifier to a UIC, (for the reason described above), it can only be granted to a User ID, and then only if the User ID has a unique UIC."<<<<<
--------------------------------------------------------------------------

Neither of those statements is accurate. But then neither is UAF> help grant/identifier

While it is true that you cannot grant an identifier to a UIC, the only thing you can grant an identifier to is a UIC valued identifier. You do not grant an identifier to a USERNAME, although a UIC valued identifier can have the same name as a USERNAME, and this is in fact the most common case.

Identifiers are defined by the RIGHTSLIST file. When you create an identifier, you add a record to the RIGHTSLIST file that associates a unique name to a unique value. In other words, there is a one-to-one correspondence between identifier names, and identifier values. Some identifier values correspond to UIC values, some to non-UIC values. You can only grant non-UIC valued identifiers, and you can only grant to UIC valued identifiers. When you grant an identifier, you create a record in the RIGHTSLIST file, which has the primary key set to the non-UIC value of the identifier being granted, and the holder value set to the UIC valued identifier that the identifier is being granted to.

For you to be able to grant an identifier to a UIC, there must be a UIC valued identifier representing the UIC. If this UIC valued identifier is deleted, all records in the RIGHTSLIST file associated with that UIC are removed. This is the most likely event that caused TMcB's problem. If you have security auditing enabled for AUTHORIZATION, you should be able to determine the process that did the deed.

There is no change to the SYSUAF due to additions or deletions of identifiers. The SYSUAF file has no place to store them. However, a USERNAME in the SYSUAF file is related to identifiers based on the UIC associated with the USERNAME. This is the reason why it is recommended that a single USERNAME be assigned a specific UIC value. The UIC is the basis of protection.

NOTE WELL: If you have multiple USERNAMEs with the same UIC, for example, [123,1], you cannot grant an identifier to one of those usernames without the identifier being granted to all other USERNAMES with that UIC value. Also, you can grant an identifier to a UIC valued identifier that no USERNAME is associated with.

As always, if you think I am incorrect, please say so, but provide evidence.

Extraordinary claims require extraordinary evidence, so I have attached a log file demonstrating my claims.

Jon

[Karl Rohwedder]

To add to Jon:

You cannot have identifiers with numeric names.
E.g. we have an application that uses numeric usernames. To add the correspondig UIC-valued identifiers, another name must be selected and the correspondence of username/identifier is broken.

regards kalle

[The Brit]

Sorry for being unclear, I meant to say that you cannot grant an identifier to a UIC if it is a duplicate, i.e. if multiple user names have the same UIC value.

Dave

[Jon Pinkley]

>>>>I meant to say that you cannot grant an identifier to a UIC if it is a duplicate, i.e. if multiple user names have the same UIC value.

Dave<<<<

So you are claiming that if the following is
done:

$ uaf:==$authorize
$ uaf add user1/uic=[123,456]
$ uaf add user2/uic=[123,456]
$ uaf add /id itrcdemo

Then the following will not work?

$ uaf grant/id itrcdemo [123,456]

Jon

[Ian Miller.]

What matters is does the identifier exist whose value is the UIC.

See attached

[Jan van den Ende]

Take the previous example by Ian, and, before the UAF> REM/ID default,
try to GRANT TESTID to TEST1 or TEST2.
It will be instructive.

Bottom line: Maintain a one-to-one relation of usernames & UIC-identifiers, or be prepared to deal with counter-intuitive "features"!

Proost.

Have one on me.

[The Brit · Accepted solution]

I guess Jon didn't actually try this! So here goes.


$ mc authorize
UAF> add user1/uic=[123,456]
%UAF-I-ADDMSG, user record successfully added
%UAF-I-RDBADDMSGU, identifier USER1 value [000123,000456] added to rights database
<<<< OK So far!

UAF> add user2/uic=[123,456]
%UAF-I-ADDMSG, user record successfully added
%UAF-E-RDBADDERRU, unable to add USER2 value [000123,000456] to rights database
-SYSTEM-F-DUPIDENT, duplicate identifier
<<<< User account added OK, but Identifier not added to rightslist, duplicate!!

UAF> add /id itrcdemo
%UAF-I-RDBADDMSG, identifier ITRCDEMO value %X80010034 added to rights database
<<<< Identifier added OK

Now try

UAF> grant/id itrcdemo [123,456]
%UAF-I-GRANTMSG, identifier ITRCDEMO granted to USER1
<<<< Identifier only granted to USER1

Now try
UAF> show /brief user2
Owner Username UIC Account Privs Pri Directory

USER2 [123,456] Normal 4 Disuser
UAF> grant /id itrcdemo user2
%UAF-E-GRANTUSR, user identifier USER2 does not exist; ITRCDEMO could not be granted
-SYSTEM-F-NOSUCHID, unknown rights identifier

Checking the original post, this was the error that the Q was about. and the answer is still that you need to have unique UIC's to get all of the user_ID's into the Rightslist. You cannot grant additional identifiers to a user unless their user id is in the rightslist.

The "grant" command appears to work, since it gives no errors, however it only grants the ID to the single user who is in the rights list with the value [123,456]. The remaining users with that UIC cannot receive the Identifier.

Dave

[Jan van den Ende]

Dave,

a NEARLY perfect example sequence.

>>>
UAF> show /brief user2
<<<

had you refrained from specifying /brief, you would have seen another counter-intuitive phenomenon.

Because user2 _DOES_ have the uic [123,456], the account of user2 HAS identifier itrcdemo, and therefor user2's account shows the right itrcdemo.
Only the granting mechanism seems not to be able to make the connection which AUTHORIZE SHOW obviously can.

Proost.

Have one on me.

jpe

[Jon Pinkley]

Dave,

Please look at the annotated logfile I attached to my note dated Aug 8, 2007 09:26:49 GMT.

Jon

[The Brit]

Hi Jon,
Follow all you said, however there is one command you didn't include, (neither did I)

again,

$ mc authorize
UAF> add user1 /uic=[123,456]
%UAF-I-ADDMSG, user record successfully added
%UAF-I-RDBADDMSGU, identifier USER1 value [000123,000456] added to rights databa
se

UAF> add user2/uic=[123,456]
%UAF-I-ADDMSG, user record successfully added
%UAF-E-RDBADDERRU, unable to add USER2 value [000123,000456] to rights database
-SYSTEM-F-DUPIDENT, duplicate identifier

UAF> add /id itrcdemo
%UAF-I-RDBADDMSG, identifier ITRCDEMO value %X8001002D added to rights database

UAF> grant /id itrcdemo [123,456]
%UAF-I-GRANTMSG, identifier ITRCDEMO granted to USER1

UAF> show/id/full itrcdemo
Name Value Attributes
ITRCDEMO %X8001002D
Holder Attributes
USER1

Even though the UAF record indicates that USER2 has the Identifier, the RightsList insists that it has only been granted to USER1.

While most of the discussion so far has been very informative, and I thank you for that, the real question is whether USER2 is able to access protected objects using the ITRCDEMO identifier.
According to his UAF record, he should be able to. Or whether the final arbiter is the Rightslist, who seems to disagree.

Dave.

[Jon Pinkley]

Now do this:

$ mc authorize
UAF> rename/id user1 itrcuser
UAF> SHOW USER/FUL USER1 ! the uic will display [123,456] ([ITRCUSER])
UAF> SHOW USER/FUL USER2 ! the uic will display [123,456] ([ITRCUSER])
UAF> SHOW itrcuser ! should display %UAF-W-BADSPC, no user matches specification
UAF> SHOW /ID/FUL ITRCDEMO !(this should display) ITRCUSER as the holder.

ITRCUSER is not a username, it is an identifier name for a UIC. And it is the entity that other non-uic based identifiers are granted to.

During LOGINOUT UAF is read, the UIC is determined, Using the UIC the RIGHTSLIST is consulted to find the identifiers (also referred to as RIGHTS) held by the UIC. These rights are added to the process's RIGHTSLIST (as is seen in "process rights" in the output of show process/rights. This is an in memory copy, and if revoke the rights via UAF, it will not remove rights form the process, they stay until the process is logged out, or the rights are disabled (set rights/disable)

Jon