[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:	OLD ALL-IN-1 (tm) Support Conference
Notice:	Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:	IOSG::PYE

Created:	Thu Jan 30 1992
Last Modified:	Tue Jan 23 1996
Last Successful Update:	Fri Jun 06 1997
Number of topics:	4343
Total number of notes:	18308

3667.0. "DSO and Remote sharing and Proxys" by LARVAE::JORDAN (Chris Jordan, TSE - Technology Services, End-User Computing) Wed Dec 15 1993 16:18

The problem:
------------
The System Managers need to get involved to set up proxy 
accounts when a user wants to allow access to his drawer to a 
remote user....

    
A solution:
-----------
When a user wants to specify a remote user on the drawer sharing 
(or Group Services) area, a customisation means that the NETPROXY 
file is checked to see if it exists. If it doesn't, then a file is 
created that shows the user and the node. 
A batch job is running every half hour, which reads these files, 
checks and adds a new user.....

Any Problems envisaged??


Another Solution:
-----------------
The NETPROXY.DAT file on each node is updated with every user on 
all other nodes... This will be about 20,000 entries per node.

Any Problems envisaged??

To do this, it is expected that when a new user is created, their
details (VMS Username, Node, ALL-IN-1 name) are copied into one 
central file in the network, and once a week each node will check 
there NETPROXY.DAT file against this central file, and 
delete/remove or add details as necessary.

Any Problems envisaged??

Thanks for your help....
    
    By the way: The customer need is for any one of 20,000 ALL-IN-1 users
    on 125 different nodes around the Wide-Area Network to be able to be
    given access (by the owner of the drawer) to any drawer in that users
    File Cabinet... and to do this with as little work for the System
    Managers, and as little problems for the users, as possible....
    
    Help and advice is appreciated.

T.R Title User Personal
Name Date Lines

3667.1 Lots of problems, need DECdas on VMS CHRLIE::HUSTON Wed Dec 15 1993 16:34 63

T.R	Title	User	Personal Name	Date	Lines
3667.1	Lots of problems, need DECdas on VMS	CHRLIE::HUSTON		`Wed Dec 15 1993 16:34`	63
	Where to start? >When a user wants to specify a remote user on the drawer sharing >(or Group Services) area, a customisation means that the NETPROXY >file is checked to see if it exists. If it doesn't, then a file is >created that shows the user and the node. >A batch job is running every half hour, which reads these files, >checks and adds a new user..... > >Any Problems envisaged?? All kinds of problems, first off, it takes a priv'd user to create a proxy entry, secondly opening this up to the average user creates a massive security hole around who has remote access, into which accounts etc. Thirdly, creating the proxy file on the fly will not work, the DSO depends on the FCS, when the FCS starts up, it opens the proxy file, if it does not exist, then it basically shuts down remote access. If you create the proxy file while the FCS is running, it will have no effect, you will have to re-start the FCS. >Another Solution: >----------------- >The NETPROXY.DAT file on each node is updated with every user on >all other nodes... This will be about 20,000 entries per node. > >Any Problems envisaged?? This is a bit of overkill in the proxy file, how do you decide who to proxy people into? Also may grant remote access (via DECnet) to people who don't need it or you don't want to have it. >To do this, it is expected that when a new user is created, their >details (VMS Username, Node, ALL-IN-1 name) are copied into one >central file in the network, and once a week each node will check >there NETPROXY.DAT file against this central file, and >delete/remove or add details as necessary. > >Any Problems envisaged?? Again, you need two usernames for the proxy, the remote node::user and the local username to see who to proxy the guy into, you still don't seem to have a way to determine this. The solution that you need, is a true distributed security model in which there is a single "network" login. Unfortunately, this is not available on VMS yet, Digital is making DECdas available on Ultrix, you need it on VMS to accomplish this. When we (the FCS team) designed the proxy method, it was a given that it would be a system management nightmare, there simply was not alternative. I suggest you simply tell them that they need to do it by hand. I suggest NOT doing blind proxy from everywhere to everywhere. Not sure if you understand or not, but there is already a "global" proxy in the FCS. If no proxy is found, the user is authenticated into the OAFC$DEFAULT account, this is used for world access (at least by design), what you could do (though from a security point, not suggested), is to simply give OAFC$DEFAULT some privs, or access to everything, if you do this, everyone has access to everything, and you have no need to use proxies all over the place. --Bob

    
    Where to start?
    
>When a user wants to specify a remote user on the drawer sharing 
>(or Group Services) area, a customisation means that the NETPROXY 
>file is checked to see if it exists. If it doesn't, then a file is 
>created that shows the user and the node. 
>A batch job is running every half hour, which reads these files, 
>checks and adds a new user.....
>
>Any Problems envisaged??
    
    All kinds of problems, first off, it takes a priv'd user to create a
    proxy entry, secondly opening this up to the average user creates  a
    massive security hole around who has remote access, into which accounts
    etc.  Thirdly, creating the proxy file on the fly will not work, the
    DSO depends on the FCS, when the FCS starts up, it opens the proxy
    file, if it does not exist, then it basically shuts down remote access.
    If you create the proxy file while the FCS is running, it will have
    no effect, you will have to re-start the FCS.
    
>Another Solution:
>-----------------
>The NETPROXY.DAT file on each node is updated with every user on 
>all other nodes... This will be about 20,000 entries per node.
>
>Any Problems envisaged??

    This is a bit of overkill in the proxy file, how do you decide who
    to proxy people into? Also may grant remote access (via DECnet) to 
    people who don't need it or you don't want to have it.
    
>To do this, it is expected that when a new user is created, their
>details (VMS Username, Node, ALL-IN-1 name) are copied into one 
>central file in the network, and once a week each node will check 
>there NETPROXY.DAT file against this central file, and 
>delete/remove or add details as necessary.
>
>Any Problems envisaged??
    
    Again, you need two usernames for the proxy, the remote node::user and
    the local username to see who to proxy the guy into, you still don't
    seem to have a way to determine this.
    
    The solution that you need, is a true distributed security model in
    which there is a single "network" login. Unfortunately, this is not
    available on VMS yet, Digital is making DECdas available on Ultrix, you
    need it on VMS to accomplish this. When we (the FCS team) designed the 
    proxy method, it was a given that it would be a system management 
    nightmare, there simply was not alternative.  I suggest you simply tell
    them that they need to do it by hand. I suggest NOT doing blind proxy
    from everywhere to everywhere.
    
    Not sure if you understand or not, but there is already a "global" 
    proxy in the FCS. If no proxy is found, the user is authenticated into
    the OAFC$DEFAULT account, this is used for world access (at least by
    design), what you could do (though from a security point, not
    suggested), is to simply give OAFC$DEFAULT some privs, or access to 
    everything, if you do this, everyone has access to everything, and you
    have no need to use proxies all over the place.
    
    --Bob