Conference iosg::all-in-1

        Will not allow to act as a system manager or admin. What does
        this really mean?
        
        Is it like not being able to login into VMS account? 
        
        Maybe $SHOW INTRUSION and the $DELETE/INTRUSION *
        
        _veli
        

    Veli -1 asked exactly the right question. What do you mean by:
    "...will not allow them to act as a system manager or an
    administrator."?
    
    I understand it to mean that they cannot enter the MGT or ADM subsystems
    from within ALL-IN-1. 
    
    This could be lots of things, but it is strange that it is appearing on
    one node in the cluster only. One thing you could do quite easily, is
    go into ALL-IN-1 on the rogue system, in the rogue account, and turn 
    >DEBUG_ON. Then enter the option 'SM' and watch what happens as you go
    through the script SM_INIT_MGT. This does all the rights checking and
    you may see, by examining the symbols, where it is failing.
    
    On the other hand, you may mean that these users cannot run
    housekeeping jobs etc. which is a different set of problems.
    
    Also, please remember that standard ALL-IN-1 was designed with the
    intention of having only one 'real' manager, and many 'administrators'.
    It is not wholly correct to make many people managers, though we run
    several systems like that here. What I do to make other users managers
    is grant them oa$manager identifier, Nominate them as administrators
    from MUA, and give them quite extensive VMS privs (;-). Also, you will
    have to consider which of them you want to receive housekeeping reports
    as set by fields in the system policies. 
    
    regards,
    davet 

    Good Morning,
    
    I'm sorry for the confusion. What I mean is they cannot access the SM
    and ADM menus. ALL-IN-1 tells them they are not allowed to act as a
    manager or something like that.
    
    I turned on trace and it revealed that for some  reason,
    sm_init_mgt.scp cannot find the identifiers on the users sysuaf record.
    When it does the RIGHTS FIND_ID OA$MANAGER, OA$ADMIN, it does not find
    anything and therefore the symbol is set to spaces. It fails at this
    point. I had an account where this did work and turned trace on and
    watched what happened with that account. It was able to find the rights
    id just fine. 
    
    Looking the account, these users have alot going on on this system.
    Their sysuaf records have 23 identifiers on them. I am not sure if on
    this node they are not stepping on their own toes. I noticed in the
    sylogin.com file they had some node specific information but nothing
    that would cause this to happen.
    
    At this point I am grasping at straws and searching for any
    suggestions.
    
     anything, please let me
    know.
    
    Cheryl Estes  

    Hi,
    
    For some reason the bottom part of my message was cut off. I was
    saying if you can think of anything, please let me know.
    
    Cheryl 

    Could you try the RIGHTS FIND_ID OA$MANAGER interactively on the 'bad' 
    node for these accounts?
    <rights find_id "oa$manager"\get oa$status
    If status is not 1, check in authorize that the identifier has been
    granted to the correct OpenVMS account. If it has, then the RIGHTS code
    may be being fooled by some strange definition of rightslist.dat on
    that node?
    (I'm off to a meeting now, but will look at OARIGHTS code again later)
    cheers,
    DaveT 

    Hi Dave,
    
    The <rights find_id "oa$manager"\get oa$status command returns a value
    of 0. Looked at the profile record and it is pointing to the correct
    OpenVMS account and that account does have the proper identifier.
    
    Customer does not have any logicals pointing to the rightslist.dat
    files. 
    
    Hope this helps,
    
    Cheryl 

    I have 22 identifiers, and it works for me.
    
    You could try using the DCL lexical as another check:
    
    	Rights_held = f$getjpi( "","PROCESS_RIGHTS" )

    Hello,
    
    I tried this and it gives all the information regrading her account
    including the rights identifiers that ALL-IN-1 cannot find. We saw
    oa$manager and oa$admin.
    
    Cheryl 

    ok - next try!
    
    Has oa$manager by any chance been granted with an unusual attribute?
    (e.g. DYNAMIC). 
    
    From authorize:
    UAF> LIST/RIGHTS {VMSusername}
    ...then look at the RIGHTSLIST.LIS produced.
    
    Failing this, what sort of machine is this one, compared to the others
    in the cluster. Anything strange in its startup compared to the others?
    
    sorry not to be much help.
    DaveT

    Hi Dave,
    
    We tried the UAF> LIST/RIGHTS ELIINV and did not find anything unusual.
    It only gave the name of the identifier and the number. Nothing else.
    
    All the systems in this cluster are 6610's. They startup applications
    based on node names. On the node in particular, they are running an
    application called SASS????
    
    I had her to create another generic account without all the other
    software they run and without all the identifiers on it. We granted
    this user the privileges to act as managers and nominated this account
    as an administrator.
    
    We logged into the account. SM and ADM options worked just fine.
    Customer also had CM on her form library field so we decided to
    nominate this account with CM privileges. We tried to account again and
    it still worked.
    
    I suggested that she look through her startup procedures for node
    NEPTUN and see if they are doing something strange. Also suggested she
    remove the sysuaf record for one of the users and add it back to see if
    that clears this up. I know I'm grasping again. 
    
    Thanks for your time. I will call her again on Monday.
    
    Cheryl Estes 
    

    Wasn't there a restriction in ALL-IN-1 on the number of identifiers a
    user could have?  I don't remember what it applied to.
    
    Ben

    Good Morning,
    
    The number of identifiers are not the problem. I added all the
    identifiers she had to my test account and it worked just fine.
    
    Customer worked for awhile with the bootup team from Digital and they
    could not find anything wrong. They did find another rightslist.dat
    file in another directory and renamed it. They rebooted the system
    twice and her account still does not work. She removed her account from
    sysuaf and readded it but it still does not work. She created another
    test account and gave it management privs and it worked fine. The
    problem seems to only exist on existing accounts. I will have her to
    add an account that is an exact duplicate of her account and see if
    that account will work. They are running alot of other applications.
    
    Customer wants us to continue to work on this. She wants me to elevate
    this call to engineering because I am out of ideas. Before I do this,
    does anyone have anymore ideas??
    
    Thanks,
    
    Cheryl Estes                             

    Hello,
    
    The customer called and said that the problem was fixed. There was an
    issue with the bootup process.
    
    Thanks for all your help.
    
    Cheryl