Conference iosg::all-in-1_v30

    It is currently unclear when remote drawer access will be made
    available, so I will just discuss the problems with local access.
    
    To avoid problems with changing UICs I would recommend using Group
    Services. When you share a drawer with a group, members of the group
    will retain access even if their UIC number changes. 
    
    The extra overhead would then be that if a user changes jobs, the user
    may need to be added to new groups and removed from old ones.
    
    Cheers
    
    Stuart

    
    How do I go about granting access to a drawer to a user on a remote 
    node ?  If I go to the Drawer Management menu and try to edit the 
    drawer access, it won't allow me to enter anything other than the 
    local users.  I couldn't find anything in the documentation on how
    to do this.  For example, suppose I want to grant Read access to 
    my drawer MAIN to user XYZZY::JOHN_DOE.
    
     I have all of the necessary licenses installed to implement 
    distributed sharing.  Forgive me if I missed something in the 
    documentation somewhere, but I've tried all kinds of different ways
    to enter the username, and none of them work,  I either get a bogus
    rights id error, or invalid VMS username error.  It looks like it 
    wants to see a VMS account on the local system only.
    
    Thanks, Larry

    
    re .2
    
    You need to know which LOCAL user the remote person proxies into
    when they do a remote connection, use this username in the
    form for sharing the drawer.
    
    --Bob
    

    
    
    Hi Larry,
    
    Remote shared filing functionality is an additional package to
    ALL-IN-1, known as the Distributed Sharing Option (DSO). 
    
    There is no additional code necessary, but you will need the correct
    license which is now called A1-DIST-SHR.
    
    The DSO license is shipped with a small piece of documentation which
    addresses how to establish a DSO environment, along with setting user
    expectations and highlighting known problems and limitations.
    
    I'll send this to you.
    
    Hope it helps, and please contact me if you have any problems,
    
    Kevin.
    
    
    
                             

    
    Okay, suppose I want XYZZY::JOHN_DOE to have access to my drawer 
    MAIN, however I only want to grant him READ access.
    
    I give him proxy access to my account.  He now has _full_ access 
    to my drawer.  How do I set it up so that he only has READ access ?
    
    Thanks again, Larry

    re: .4
    
     Notes collision .. yes, please send it to me when you get the 
    opportunity, I'd appreciate it.  I do have the DSO license installed,
    however I never received the documentation you mentioned.
    
    Thanks, Larry

    
    I've read the documentation, and it's basically the way I have the 
    system set up.
    
    Default proxy setup for:
    
    Remote_user:         Local_user:
    HIDEOA::BOGGS        VIGNEAULT
    
    Now I'm supposed to grant access to the remote user by specifying the
    local username (?).  So using Drawer Management (DRM) I try to do an
    edit Drawer access, and use my local username of VIGNEAULT.  This isn't
    a valid entry because I own the drawer.   Even if it were, suppose I 
    wanted to share my drawer with a few different people and give them 
    all specific access levels, simply using my username is not enough to
    accomplish this.  How do I grant specific Read access to HIDEOA::BOGGS
    to my drawer [VIGNEAULT]RUTABAGA and READ/WRITE access to XYZZY::JOHN_DOE 
    for drawer [VIGNEAULT]REPORTS for example.  I must be missing something 
    here.
    
    Thanks, Larry

    Surely you need to create a local SYSUAF entry LOCAL_BLOGGS, give him a
    proxy form the remote account REMOTE::BLOGGS, and then do the
    appropriate sharing access to LOCAL_BLOGGS.
    
    Or don't I understand this stuff at all?
    
    Graham

    
    Pardon my expression, but !!!Yuck!!!
    
     INSPECT will surely complain about this scenario since the proxy
    accounts will never actually show interactive logins.  This also 
    means that the system manager must create uaf accounts for every 
    user that wants to share drawers remotely.  
    
    Just to ensure that I totally understand the process -
    
    - I create a local uaf record for LOCAL_BLOGGS
    
    - I setup a proxy for REMOTE::BLOGGS   LOCAL_BLOGGS
    
    - I then grant access to my drawer to user LOCAL_BLOGGS specifying
      whatever access level I want.
    
    This also means that Joe_average user cannot remotely share a drawer
    unless they get the system or ALL-IN-1 manager to configure it for 
    them.
    
    Larry

    
    Larry,
    
    Strange, we have a lot of Proxy accounts, but the only time Inspect
    complained about them was when these had privs. Since we removed the
    privs, no complaints. Anyway, probably not the place for this.
    
    You don't need to create a proxy for all users. Think of something
    like:
    
    - Create local uaf for 'Read' to drawers:       LOCAL_READ
    - Create local uaf for 'Read/Write' to drawers: LOCAL_RW 
    - Setup proxy for REMOTE::BLOGGS        LOCAL_READ
    - Setup proxy for REMOTE::AVERAGE_JOEs  LOCAL_READ
    - Setup proxy for REMOTE::MORE_THAN_AVERAGE_JOEs LOCAL_RW
    
    or something similar. 
    
    Just an idea.
    
    	Simon

    
    Larry,
    
    THere are a couple of things that you are missing to get the full
    understanding of this:
    
    1) When the FCS proxies someone into a local account they set the
       last NON-interactive login time so inspect does not flag it.
    
    2) Proxying someone into your account is a bad thing to do, when you
       do this, they basically become you with all your privs when they
       connect.
    
    3) If you don't want to set up all the proxies, there is a default
       account set up when the FCS is installed. It is called OAFC$DEFAULT.
       Its purpose is to proxy people into when they have no "real" 
       proxy. The reasonsing for this was to allow world read type of 
       access to drawers/documents. You could simply not give the guy a 
       proxy, or proxy him into OAFC$DEFAULT, then use OAFC$DEFAULT as 
       the basis for the drawer sharing.
    
    4) As for giving access to different drawers, you have to set each
       drawes access individually.
    
    --Bob
    

    
    Hi Simon,
    
     Your scheme would work, however correct me if I'm wrong.  Let's 
    assume that I have a generic sysuaf record called LOCAL_RWC.
    
    I have two local users, LOCAL_A, LOCAL_B, and two remote users
    REMOTE_A, REMOTE_B.
    
    User LOCAL_A grants RWC access to his drawer for REMOTE_A by 
    allowing RWC access for user LOCAL_RWC, and a proxy entry is
    setup for REMOTE::REMOTE_A LOCAL_RWC
    
    User LOCAL_B grants RWC access to his drawer for REMOTE_B by 
    allowing RWC access for user LOCAL_RWC, and a proxy entry is 
    setup for REMOTE::REMOTE_B LOCAL_RWC
    
    The end result is that users REMOTE_A or REMOTE_B actually have 
    access to _either_ LOCAL_A or LOCAL_B if they know which drawers
    to use.  Sounds like a big security issue.  
    
    Larry
    

    
    Larry,
    
    > The end result is that users REMOTE_A or REMOTE_B actually have
    > access to _either_ LOCAL_A or LOCAL_B if they know which drawers
    > to use.
    
    Correct. Another indication that you have to very carefull setting up
    proxies. But these are all examples of how it could be done.
    
    > Sounds like a big security issue.
    
    Depends how it's implemented.
    
    Ciao,
    
    	Simon

    
    Well, at least I now understand the methodology behind it. I think
    the documentation I've seen is a bit vague relative to the need of a
    SYSUAF account being required. It would sound like the most secure 
    way to do it would be to have an individual SYSUAF entry for each
    user who wants to allow their drawer to be shared, for instance
    BLOGGS and BLOGGS_DRW, DOE and DOE_DRW etc..
    
    Has anyone else implemented any other schemes around this issue ?
    I'd be interested in hearing other ways that folks have done this.
    
    	Thanks for all your help - Larry

    Hi,
    
    can you give me a pointer from where I can copy this DSO-Document,
    please ?
    
    Many thanks in advance and
    
    Best regards
    
    Charly_from_CSC Vienna

What does exactly mean "granting access to a drawer to the proxi account"?

I work on node AAA and I want to grant access to my drawer to user MARIO working
on node BBB:

-	I created a proxi VMS account on node AAA named BBB_MARIO

-	I used MRU option to associate remote user BBB::MARIO to local
	(VMS) user BBB_MARIO

How can I grant access to my drawer to local (VMS) user BBB_MARIO?

I edit my drawer and attempt to add user BBB_MARIO, MARIO or BBB::MARIO
to the list of authorized users, but I get a message that sounds like
"Unknown ALL-IN-1 user". Is it correct? Is it a bug?

Does it mean I have to setup an ALL-IN-1 account for remote users?

Is there a particular syntax I have to use?

						Mario

Note: Remote access on my nodes works, because if I add *GLOBAL to the list of
authorized users of my drawer user MARIO does access my drawer from node BBB!

    You have to go into AUTHORIZE and create a VMS account on the system
    where the drawer is. Then give the remote user a proxy to that account.
    Finally give the account you have just created access to the drawer.
    
    There is a system management option (MGT MFC MRU) to manage the proxies.
    
    Graham

>    You have to go into AUTHORIZE and create a VMS account on the system
>    where the drawer is. Then give the remote user a proxy to that account.
>    Finally give the account you have just created access to the drawer.

I apologize: my question was exactly: how can I give the account I have just 
created access to the drawer?

>    There is a system management option (MGT MFC MRU) to manage the proxies.
    
It is correct! But how can I introduce the name of the proxi I just created?
I tryied many different syntaxes, but the only valid names look to be the local
ALL-IN-1 users!

I looked at the named data of form FC$SIMPLE$ACCESS and to scripts 
FC_ID_VALID.SCP, but I was unable to find the answer...

Have I to specify any particular identifier while creating the proxi account?

Regards
						Mario