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

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

5140.0. "Questions on multiple users and access" by ADO75A::BOUCHER () Thu Jun 03 1993 00:18

Greetings,

    DECmcc-BMS V1.3.0
    MIR as namespace
    V5.5-2 VMS
I have some questions regarding multiple users of DECmcc and how to limit  the
amount of things that they can do in a Director.
    
    I have a customewr who has overall control over a comms network which
    services a number of client departments. Some of the equipment is
    shared, and as such access to other portions of the network that do not
    belong to a client department should not be visible to non interested
    parties, ie hackers, browsers, the idle curious, the nosey, etc. 
    
    One option is to delete the menu options that may cause problems from
    the IMPM so that they do not have the access to them.
    
    Q1:	Is it possible to remove certain destructive menu options so that
    they are not presented to a "client user" ?  eg Open Domain,
    deregister, etc ?
    
    Q2:  Is it possible to allow a client to have access to the IMPM and
    not the FCLPM ?
    
    Quick sketch on reasoning:
    
    			CUSTOMER_DOMAIN
    				|
     		_________________________________
    		|				|
    	      CLIENT_X			     CLIENT_Y
    		|				|
    	________________		_________________
    	|		|		|		|
    SITE_1	     SITE_2	      SITE_1	      SITE_2
    
    Client X is to be a client user of the customer, and as such will have
    CLIENT_X as the default domain, so that his structure will enable him
    to see all sub domains, but not any other domains.  The same will apply
    for Client Y.  I need a way to restrict them from seeing into the
    others domains and from doing anything destructive on the network
    (predominately cisco SNMP entities), eg deregister, disable interfaces,
    etc.
    
    Any suggestions would be appreciated.
    
    Reece Boucher
    Adelaide, Australia
T.RTitleUserPersonal
Name
DateLines
5140.1some answersSTKHLM::BERGGRENNils Berggren EIS/Project dpmt, Sweden DTN 876-8287Thu Jun 03 1993 03:1949
Reece,

We've done some of what you're asking for at the swedish PTT.

>>> Q1:s it possible to remove certain destructive menu options so that
>>> they are not presented to a "client user" ?  eg Open Domain,
>>> deregister, etc ?

Yes, It  is  simple  to  remove  destructive  DIRECTIVES, such as SET,
DISABLE, ...

1.  Copy the   dictionary,  MCC_SYSTEM:MCC_FDICTIONARY.DAT  to  a  working
directory.

2.  Redefine  the  MCC_SYSTEM  logical  to point to a search-list with
your  working  directory  as  the  first directory in the list and the
normal MCC-directories after.

3.  Use  DAP  '$MANAGE/TOOLKIT/DICTIONARY' , and delete the destructive
directives.  'DAP> DELETE CLASS NODE4 DIRECTIVE SET '  (I am not 100% 
sure if the syntax is correct...)

4.  Exit DAP and have it rebuild the parse-table.

5.  Divide the different user-categories into different UIC-groups and
create  group-logical  names  for  MCC_SYSTEM  to  point  to different
search-lists,  where  the  first  directory  in the lists contains the
modified parse-tables.


I don't  know  how  to  remove other operations other than DIRECTIVES,
e.g.  'Open Domain'.

It's always  possible to set protection on the map-files for different
domains, but I don't know how secure that would be.

I guess  that  using  DNS  would  make  it  easier to protect access to
domains, but you're using the local MIR as namespace, so...

    
>>> Q2:  Is it possible to allow a client to have access to the IMPM and
>>> not the FCLPM ?

I guess  setting protection on the file SYS$SHARE:MCC_FCL_PM.EXE would
do it.



         /Nils
5140.2Thanks for the responseADO75A::BOUCHERThu Jun 03 1993 19:315
    Nils,
    
    	Thanks for the quick reply.  I'll give it a go.
    
    	/Reece...