[comp.os.vms] Proxy access

vtcf@NCSC.ARPA (Williams) (11/03/87)

I have a problem with a hopefully easy solution.  Here's the scenario:
Joe has accounts on VAXA and VAXB. Each account has proxy logins enabled.
If Joe is logged on to VAXA, he can copy files to VAXB, or copy files from
VAXB to VAXA, without having to specifiy username, password, disk, and
directory.  However, if he's logged in to VAXB, he must specify his username
and password.  Otherwise, the file goes to the default DECNET account, or,
if he specifies disk and directory, he gets an "insufficienr privilege or
file protection violation."  Both accounts have proxy access, and the FAL
object in the NCP has proxy access both incoming and outgoing.  I don't know
that much about networking, so I must be missing something.  Any ideas?

Thanks in advance,

Tom Williams
vtcf@ncsc.arpa

dugal@uriecl.UUCP (11/09/87)

	In article <8711022234.AA10014@ncsc.ARPA>, Tom Williams writes:
 
>I have a problem with a hopefully easy solution.  Here's the scenario:
>Joe has accounts on VAXA and VAXB. Each account has proxy logins enabled.
>If Joe is logged on to VAXA, he can copy files to VAXB, or copy files from
>VAXB to VAXA, without having to specifiy username, password, disk, and
>directory.  However, if he's logged in to VAXB, he must specify his username
>and password.  Otherwise, the file goes to the default DECNET account, or,
>if he specifies disk and directory, he gets an "insufficienr privilege or
>file protection violation."  Both accounts have proxy access, and the FAL
>object in the NCP has proxy access both incoming and outgoing.  I don't know
>that much about networking, so I must be missing something.  Any ideas?
 
Try checking your EXECUTOR's set-up to be sure that you have DEFAULT PROXY
set to BOTH.  In other words:
 
	NCP> DEFINE EXEC DEFAULT PROXY BOTH
	NCP> SET EXEC DEFAULT PROXY BOTH
 
This may not be it, but it'd sure stop you from proxying.
 
+---------------------------------------------------------------------------+
| David G. Dugal        University of R.I., Engineering Computer Laboratory |
| System Manager        306 Bliss Hall, Kingston, RI 02881  (401) 792-2488  |
|                                                                           |
|       Internet:       dugal%ecl1.SPAN@star.stanford.edu                   |
|       SPAN/HEPnet:    ECL1::DUGAL  -or-  6334::DUGAL                      |
|       UUCP:           allegra!rayssd!uriecl!dugal                         |
|       PSI:            PSI%31103210735::ECL1::DUGAL                        |
|       MCI Mail: 299-5584  Easylink: 62926791  TWX: 650-299-5584           |
|                                                                           |
|       "Logic is a small bird chirping in a meadow.                        |
|        Logic is a wreath of flowers ... that smell BAD."                  |
+---------------------------------------------------------------------------+

sandrock@uxc.cso.uiuc.edu (11/12/87)

> /* ---------- "Proxy access" ---------- */
> I have a problem with a hopefully easy solution.  Here's the scenario:
> Joe has accounts on VAXA and VAXB. Each account has proxy logins enabled.
> If Joe is logged on to VAXA, he can copy files to VAXB, or copy files from
> VAXB to VAXA, without having to specifiy username, password, disk, and
> directory.  However, if he's logged in to VAXB, he must specify his username
> and password.  Otherwise, the file goes to the default DECNET account, or,
> if he specifies disk and directory, he gets an "insufficienr privilege or
> file protection violation."  Both accounts have proxy access, and the FAL
> object in the NCP has proxy access both incoming and outgoing.  I don't know
> that much about networking, so I must be missing something.  Any ideas?
>
> Thanks in advance,
>
> Tom Williams
> vtcf@ncsc.arpa

     I had a similar problem, which may or may not apply in your case:
   if VAXB belongs to a VAXcluster called, say CLUS, you must not only
   specify VAXB::USERNAME, but also CLUS::USERNAME. In fact I found I
   had to specify proxies for all the nodes in the cluster, as well as
   for the cluster alias.
     It wouldn't surprise me if there was a better way to do this, but
   this was what worked for me.

     Regards,

        Mark Sandrock, (sandrock@uxc.cso.uiuc.edu)