Conference azur::mcc

the PMs are always passing it, the question is actually "what does the
dna4 am require for access control to work?"

I have passed this along to the project lead for decnet modules, he is just
back from vacation so....

    Hi -
     I am one of the access module developers. I would like the address to
    node rtdmsu. I will be trying a few tests on different ultrix notes
    with and without a guest account.
    
    
    
    
    
    
    - darryl

    Darril,
    
    RTDMSU is a node in a hidden area node number 63.12 in Holland
    (Rotterdam).
    
    But as far as I looked in to the problem I'have seen the same problem on
    VMS nodes (hidden area and non hidden area's). I also expirienced this
    problem on a customer side.
    It seems that if NML or the guest account is closed,so you need to
    supply access control info,this access control info is not used
    correctly. Only if you unsecure the node,do a show,then secure the node
    and DO NOT leave DECmcc all works O.K. 
    
    Carlo.

    
    Hi Carlo,
    
    We wanted to bang on your node directly because we haven't had this
    kind of problem at all.  We're trying to figure out what is going on,
    but for us, access control works just fine on VMS and Ultrix systems.
    
    That is, when we don't expect access rights, we don't have 'em.
    When we use explicit information to gain access rights, they work.
    When we have guest privs, they work.  When we need different access
    rights (to SET attributes, for example), we use them explicitly, and
    they work.
    
    I don't have any doubt at all that you're having a problem.  But we've
    got no idea what is happening, or how to reproduce it.
    
    Could you let me know what Operating Systems and versions you've been
    unsuccessful in gaining access to?  Any special setup that you know
    about?  As I remember it, you had to stand on your head and sing three
    verses of some song to get logged into your systems from a remote site;
    you must have a lot of special security associated with your systems.
    
    I know that there are [at least] two ways to encode access information
    in a NICE message.  In ages past, some systems only liked one of them. 
    I haven't seen this in years, and don't expect it is your problem.
    
    We have seen some strange side effects from maximum security on VMS
    systems.  Let's see if I remember it correctly:
    
    	- VMS system with proxy access to a captive, non-privileged
    	  account.
    	- Attempt to login with explicit valid access information to
    	  another account.
    	- You can't gain access to this more privileged account remotely.
    
    I've only seen this on VMS, and still argue about whether this is a
    security feature, or a nightmare.  RTDMSU looks like an Ultrix node.
    
    So, we haven't got a clue.
    
    Any ideas are welcome.
    
    -Jim Carey
    

    More info and this time both the DECmcc node as well as the target
    node are in the same (nonhidden) area 50: (So Jim if you want to test
    it on our systems here let me now,there is in real life a valid nml
    user account on HLRG02 and thus I need to close it for testing...)
    
    The node wich runs DECmcc (HLRG07 node nr:50.830) runs VMS Version V5.4
    The node HLRG02 runs also VAX VMS V5.4.
    The node wich I'm going to use in this example for wich I supply access
    control is  node HLRG02 (50.452)
  I'll be showing DECmcc's behaviour with a valid user and password set up for
  the NML object and without a valid user and password (so I need to supply
  access control info).

I'm running DECmcc version:

MCC> show mcc 0 all cha

MCC 0
AT 24-JUL-1991 13:55:29 Characteristics

Examination of Attributes Shows:
                      Component Version = V1.1.0
               Component Identification = "DECmcc"

Step 1: Node HLRG02 has an object nml with a valid user name and password

 I startup DECmcc on node HLRG07:

$manage/enter
DECmcc (V1.1.0)

MCC> show node4 hlrg02
Using default ALL IDENTIFIERS

Node4 50.452
AT 24-JUL-1991 14:00:05 Identifiers

Examination of Attributes shows:
                                Address = 50.452
                                   Name = HLRG02
MCC>
  Works fine
  I now supply username and password:
MCC>show node4 hlrg02, by user "doolaard" , by password "12345678"
Using default ALL IDENTIFIERS

Node4 50.452
AT 24-JUL-1991 14:02:05 Identifiers

Examination of Attributes shows:
                                Address = 50.452
                                   Name = HLRG02

  Works also fine
  Step 2:
  Now I put on the object nml on node hlrg02 a non existing username:

$mc ncp
NCP>sho obj nml


Object Volatile Summary as of 24-JUL-1990 14:03:16

   Object   Number  File/PID                   User Id          Password

  NML           19  NML.EXE                    NML$SERVER       password

NCP>set obj nml user xxx
NCP>

  On node hlrg07 I still was in DECmcc and when I do :
MCC>show node4 hlrg02
Using default ALL IDENTIFIERS

Node4 50.452
AT 24-JUL-1991 14:08:29 Identifiers
                                   
access control information invalid at Node
MCC>

  Just like I expexted.
  When I now supply access control information:

MCC>show node4 hlrg02, by user "doolaard" , by password "12345678"
Using default ALL IDENTIFIERS

Node4 50.452
AT 24-JUL-1991 14:11:37 Identifiers

Examination of Attributes shows:
                                Address = 50.452
                                Name = HLRG02

MCC>

  Again just as I expexted
  
  Step 3:
  When I now go out of DECmcc on node HLRG07 and back in again (Must go out 
  and back into DECmcc to get the problem).

MCC>exit
$mana/enter
DECmcc (V1.1.0)

MCC>show node4 hlrg02, by user "doolaard" , by password "12345678"
Using default ALL IDENTIFIERS

Node4 hlrg02
AT 24-JUL-1991 14:15:48 Identifiers

access control information invalid at Node
MCC>

  This is NOT what I expected!!!!
  Also the show command without access control fails (expexted) 

  Step 4: 
  When I now put a existing username on the object nml on node HLRG02 it works
  fine again:

NCP>set obj nml user nml$server    (on node hlrg02)

MCC>show node4 hlrg02, by user "doolaard" , by password "12345678" (on HLRG07)
Using default ALL IDENTIFIERS

Node4 50.452
AT 24-JUL-1991 14:19:47 Identifiers

Examination of Attributes shows:
                                Address = 50.452
                                   Name = HLRG02
  OR
MCC>show node4 hlrg02
Using default ALL IDENTIFIERS

Node4 50.452
AT 24-JUL-1991 14:21:28 Identifiers

Examination of Attributes shows:
                                Address = 50.452
                                   Name = HLRG02

  If I now again put a nonexisting username on nml access control keeps working   until I exit DECmcc and go in DECmcc again.

  Hope this will bring some light............

  By the way there are no special security setups for HLRG02 (Although I must
  admit that Jim was right about the things I had to do to log into my home
  account from abroad but thats security.....)

Carlo.