Conference iosg::all-in-1_v30

    Sunil,
    This shouldn't really be happening. Could I ask you to get the
    following information from the customer:
    1) the exact error message(s) returned
    2) the highest member number in the UIC group s/he is using
    3) are there any 'old' or customized mua_create.com's in the site 
       areas of oa$lib: ?
    
    	Thanks,
    	DaveT

    Hi Dave,
    
    Okay I have the answer to your questions.
    
    >1) the exact error message(s) returned
    
    In the create user logfile the customer get's the following error
    message "UIC Group is full".  No other message is displayed, like the
    %what-?-ever types that we love dearly :-).
    
    >2) the highest member number in the UIC group s/he is using
    
    [2033,177776]  
    
    >3) are there any 'old' or customized mua_create.com's in the site
        areas of oa$lib: ?
    
    None.
    
    Rather than including a whole list of the users in this note and their
    uic's, I have a log file on RIPPER::USER$TSC:[SETHI]Q30854.LOG. It's
    interesting to see how the user part of the uic jumps from 7 to 3750.
    
    Thanks for your help,
    
    Sunil

Hi Sunil,

Well it looks like information 2) holds the answer. The message they are 
seeing is coming from the Make_UIC function. It has as its upper limit on
UIC member numbers, 177776. This being the case, it cannot add another member 
to this group, and effectively, says 'this group is full'. This is the 
intended way of working. For security reasons, which I'm sure you know, 
previous member numbers cannot be re-used, so the sysuaf entry and the VMS 
account are not created.

All I can suggest that your customer might consider doing is to work around
the problem, e.g.:
	. start using another UIC group
	. change the UIC of this account that is so high, and is effectively
	  'filling' the group; set the member number lower, so that Make_UIC
          can pick up the next unallocated number in the group
	. create new accounts in this group with Authorize, and then use
          ALL-IN-1 Create User to layer an account on an existing VMS a/c.

Others might be able to think of other creative work-arounds.

    
Now (takes deep breathe!) - own personal opinion coming up -...
I think it's pretty silly of your customer to create an account with the 
highest possible member number in a group, if s/he knew that they wanted to
use the intervening (unused) numbers at a later date. ;-)
Apologies - had to get that off my chest!
Cheers
DaveT

    Hi Dave,
    
    >I think it's pretty silly of your customer to create an account with
    >the highest possible member number in a group
    
    True, the customer has now given me the whole picture.  What happened
    was that they had to move users from one group to another and there
    were hundreds of them.  The customer had some software that generated
    uic numbers (member part) randomly and this caused the problem.  
    
    The way the problem was reported was that ALL-IN-1 was the cause of the
    their ill's, having got your words of wisdom I felt confident to question 
    the customer further.  I just don't understand some customers they seem to
    hide these little facts that are so important, makes me a little mad.
    
    The customer wants to submit an SPR to enable free uic's to used. The
    argument goes if an account is deleted any access to the shared drawers
    must be removed also, this will overcome the security problems.
    
    Regards,
    
    Sunil

    There's lots of discussions in here about reusing UICs, which is
    strongly discouraged. If your customer thinks that by deleting the
    account all other ACLs specifying that account go away, he doesn't
    quite understand things!
    
    Suppose I have a drawer to which I grant a user access. What happens is
    that an ACL is added to the drawer's ACCESS.DAT specifying that user.
    If the user is subsequently deleted, no change is made to the
    ACCESS.DAT file, since there are no backwards pointers from a user to
    all the drawers that he has access to�. So later on, another user is
    created with the same UIC, and he gets access to my drawer!
    
    Graham
    
    �In fact there is no way that you know that you have been granted
    access to a drawer unless you are manually informed.

    Hi Graham,
    
    What the customer is trying to say is that there should be pointers to
    the shared drawers.  When an account is deleted the ACL's should be
    deleted.  Now I am not going to argue with the customer because as we
    know the customer is always right !!!
    
    Regards,
    
    Sunil

    Sunil,
    
    	It might be feasible for ALL-IN-1 to go through the drawers on the
    system to check if any ACLs exist for the account to be deleted.  What
    is less feasible, but just as necessary to ensure security, would be to
    check *every* file on *every* disk for ACLs.  Otherwise if the UIC is
    reused the new user would be able to access the files available to the
    previous user.
    
    	To avoid having to do this, security conscious sites do not reuse
    UICs.  ALL-IN-1 meets their needs by ensuring UICs generated by create
    user are not reused.  To implement this, it assumes UICs will be
    allocated within groups sequentially, so only stores the highest member
    number for each group. If member numbers are not allocated
    sequentially, then the gaps are not usable by ALL-IN-1 create User.
    
       	If your customer wants to work-around this he could always
    customize out this check.
    
    Martin.