[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

3675.0. "ANOTHER DSO problem" by UTRTSC::SMEETS (Look at the ALL-IN-1 side of life) Fri Dec 17 1993 14:51

Hello

Another D(istributed) S(haring) O(ption) problem from the same customer as in
topic 3638.

ALIAS problem.

System X 		System Y
ALIAS Z			No alias
user A			user B (MAIN)

User A on system X requests IAD on system Y, user B

Situations
==========

1. Proxy on system Y
   *::A			X::A			Drawer Main of User B 
   B 		or 	B		--->	reading drawer information isn't
   default		default			a problem.

2. Proxy on system Y
   Z::A
   B		--> Drawer Main of user B, reading drawer information results in
   default	    error message "Insufficient privileges"

3. Proxy on system Y
   Z::A
   B	 and alias out enabled on obj_73 on node X
   Default

   Result: Drawer Main of user B, reading drawer information results in error
           message "Invalid authentication error". This operation takes also a
	   resonable amount of time. A trace (Gold %) shows that all ACCESS.DAT
           files are visited.

4. Same situation as in 2. only user B has granted reading access to main drawer
   for OAFC$DEFAULT account. Result: No problems when reading.

Help will be again appreciated !

Martin_who_doesn't_like_DSO_problems_at_all.
T.RTitleUserPersonal
Name		DateLines
3675.1Not quite sure what to sayCHRLIE::HUSTONFri Dec 17 1993 18:5312
    
    1,2,4 are all 100% correct, assuming that in 1,2 oafc$default does
    not have access to any drawers.
    
    Can't explain 3. I would think it would give the same error as 2, or
    give you the information. The entire mess aroudn alias enabled etc
    is slightly grey with respect to the DSO (unless it has been changed
    recently). Turn on FCS tracing and see if that gives any more
    inforamation.
    
    --Bob
3675.2FCS traceUTRTSC::SMEETSLook at the ALL-IN-1 side of lifeMon Dec 20 1993 09:2513
Hello Bob,

>    1,2,4 are all 100% correct, assuming that in 1,2 oafc$default does
>    not have access to any drawers.
    
Why would situation 2 be 100% correct ? I would expect the same result as in 
situation 1. !

Customer turned on FCS tracing regarding situation 2. result AccessCheckFail on
OA$DATA_SHARE:PARTITION.DAT. The problem seems to be that in situation 2 
OAFC$DEFAULT is trying to read the drawer information. 

Martin
3675.3cluster alias include '::'?CHRLIE::HUSTONMon Dec 20 1993 14:537
    It seems that for some reason, your system is not respecting proxies
    into the cluster alias, can you do a $sho log sys$cluster_node and
    see what it says? By chance, does it not include the '::' on the 
    end of the node name?
    
    --Bob
3675.4InconsistencyUTRTSC::SMEETSLook at the ALL-IN-1 side of lifeWed Dec 22 1993 16:3367
Hi Bob,

SYS$CLUSTER_NODE = X::

It's kind of strange ... I can reproduce the problem now !!!

We've a cluster (alias UTRTSC) which consists of two nodes UTRACK and UTRYIT, 
and we've a standalone system called SSOIOS. at both systems I have an account
SMEETS

Here's my scenario.

A1. On node SSOIOS I define proxy UTRACK::SMEETS SMEETS (default). 
A2. MC NCP SET KNOWN PROXIES ALL
A3. On node UTRACK I do IAD of system=SSOIOS, user=SMEETS
    Result I see two drawers, which is OK
    On node SSOIOS I see the following clients connected.
   (Selections: 0   )         (Server: SSOIOS::"73=" )        (New messages: 0  )

    No.   Client                   Mgt Loc Rem Tra Originating client

  > 1     SMEETS                    Y   N   N   N  UTRACK::SMEETS


                            Index of Server Clients
   (Selections: 0   )         (Server: SSOIOS::"73=" )        (New messages: 0  )
 
    No.   Client                   Mgt Loc Rem Tra Originating client

    > 1     SMEETS                    N   Y   N   N  UTRACK::SMEETS
      2     SMEETS                    Y   N   N   N  UTRACK::SMEETS

B1. On node SSOIOS I define proxy UTRTSC::SMEETS SMEETS (default). 
B2. MC NCP SET KNOWN PROXIES ALL
B3. On node UTRACK I do IAD of system=SSOIOS, user=SMEETS
    Result I see two drawers, which is OK
    On node SSOIOS I see the following clients connected.

    (Selections: 0   )         (Server: SSOIOS::"73=" )        (New messages: 0  )

    No.   Client                   Mgt Loc Rem Tra Originating client

  > 1     SMEETS                    Y   N   N   N  UTRACK::SMEETS

B4. Now I read the drawer information and get "insufficient privileges".
    On node SSOIOS I see the following clients connect.

                            Index of Server Clients
   (Selections: 0   )         (Server: SSOIOS::"73=" )        (New messages: 0  )

     No.   Client                   Mgt Loc Rem Tra Originating client

   > 1     OAFC$DEFAULT              N   Y   N   N  UTRACK::SMEETS
     2     SMEETS                    Y   N   N   N  UTRACK::SMEETS


If I grant OAFC$DEFAULT read access to my drawers than the problem is gone.

So, it looks like there is somekind of inconsistency. I've would expect with
proxy UTRTSC::SMEETS no drawers at all to be seen.

I understand when proxy check fails, OAFC$DEFAULT will try its luck. 
UTRACK::SMEETS not equals UTRTSC::SMEETS so OAFC$DEFAULT will check for access.

I seem to miss a point./...

Martin
3675.5Seems to be a proxy recognition problemCHRLIE::HUSTONWed Dec 22 1993 18:2799
    
    re .4

>SYS$CLUSTER_NODE = X::

    That is what it should be (assuming X is the node name)


>A1. On node SSOIOS I define proxy UTRACK::SMEETS SMEETS (default). 
>A2. MC NCP SET KNOWN PROXIES ALL
Note that this is meaningless to the server (step A2). The server caches
    security information. (more later)
                        
>A3. On node UTRACK I do IAD of system=SSOIOS, user=SMEETS
>    Result I see two drawers, which is OK
>    On node SSOIOS I see the following clients connected.
>   (Selections: 0   )         (Server: SSOIOS::"73=" )        (New messages: 0  )
>
>    No.   Client                   Mgt Loc Rem Tra Originating client
>
>  > 1     SMEETS                    Y   N   N   N  UTRACK::SMEETS
>
>
>                            Index of Server Clients
>   (Selections: 0   )         (Server: SSOIOS::"73=" )        (New messages: 0  )
> 
>    No.   Client                   Mgt Loc Rem Tra Originating client
>
>    > 1     SMEETS                    N   Y   N   N  UTRACK::SMEETS
>      2     SMEETS                    Y   N   N   N  UTRACK::SMEETS

    Why the two outputs? I assume it is a before/after scenario? If so it
    makes perfect sense. The IAD establishes a system managmenet connection
    which is #2 above.
    
>B1. On node SSOIOS I define proxy UTRTSC::SMEETS SMEETS (default). 
>B2. MC NCP SET KNOWN PROXIES ALL
>B3. On node UTRACK I do IAD of system=SSOIOS, user=SMEETS
>    Result I see two drawers, which is OK
>    On node SSOIOS I see the following clients connected.
>
>    (Selections: 0   )         (Server: SSOIOS::"73=" )        (New messages: 0  )
>
>    No.   Client                   Mgt Loc Rem Tra Originating client
>
>  > 1     SMEETS                    Y   N   N   N  UTRACK::SMEETS
>
>B4. Now I read the drawer information and get "insufficient privileges".
>    On node SSOIOS I see the following clients connect.
>
>                            Index of Server Clients
>   (Selections: 0   )         (Server: SSOIOS::"73=" )        (New messages: 0  )
>
>     No.   Client                   Mgt Loc Rem Tra Originating client
>
>   > 1     OAFC$DEFAULT              N   Y   N   N  UTRACK::SMEETS
>     2     SMEETS                    Y   N   N   N  UTRACK::SMEETS
>
    
    To me, this looks like a READ of the drawer information does not
    do system management call, it brokered from UTRACK to SSOIOS, and
    it could not find a proxy, so used OAFC$DEFAULT. Why it couldn't find
    a proxy, I haven't a clue?
    
>If I grant OAFC$DEFAULT read access to my drawers than the problem is gone.

    This reinforces the lack of proxy idea.
    
>So, it looks like there is somekind of inconsistency. I've would expect with
>proxy UTRTSC::SMEETS no drawers at all to be seen.
>
    
    The FCS will have cached the first system management session that went
    to SSOIOS, when you made the second IAD request, the fcs on teh cluster
    would scan its list of established system management connects, it would
    have found one to SSOIOS and used it, hence no authentication would 
    have been done. The system management connections time out eventually, 
    until that point, once established, they never do connect security
    again.
    
    The only scary part in all this is the use of OAFC$DEFAULT. You would
    have to turn FCS trace on again and show me what FCS calls are being 
    made, it looks like the R on the drawer is making a call to a
    non-system managment routine to the local FCS, then brokering to the
    standalone system, the result of the broker connect security is that
    there is no proxy (I believe you said there would be one from teh 
    ALIAS), so it uses OAFC$DEFAULT.
    
    Can you get the FCS trace log of this?
    
    --Bob
I understand when proxy check fails, OAFC$DEFAULT will try its luck. 
UTRACK::SMEETS not equals UTRTSC::SMEETS so OAFC$DEFAULT will check for access.

I seem to miss a point./...

Martin
3675.6commentsUTRTSC::SMEETSLook at the ALL-IN-1 side of lifeThu Dec 23 1993 09:4260
Hello Bob,

>A3. On node UTRACK I do IAD of system=SSOIOS, user=SMEETS
>    Result I see two drawers, which is OK
>    On node SSOIOS I see the following clients connected.
>   (Selections: 0   )         (Server: SSOIOS::"73=" )        (New messages: 0  )
>
>    No.   Client                   Mgt Loc Rem Tra Originating client
>
>  > 1     SMEETS                    Y   N   N   N  UTRACK::SMEETS
>
>
>                            Index of Server Clients
>   (Selections: 0   )         (Server: SSOIOS::"73=" )        (New messages: 0  )
> 
>    No.   Client                   Mgt Loc Rem Tra Originating client
>
>    > 1     SMEETS                    N   Y   N   N  UTRACK::SMEETS
>      2     SMEETS                    Y   N   N   N  UTRACK::SMEETS
>
>    Why the two outputs? I assume it is a before/after scenario? If so it
>    makes perfect sense. The IAD establishes a system managmenet connection
>    which is #2 above.
 
The second is after I did read the drawer information.
   
>     No.   Client                   Mgt Loc Rem Tra Originating client
>
>   > 1     OAFC$DEFAULT              N   Y   N   N  UTRACK::SMEETS
>     2     SMEETS                    Y   N   N   N  UTRACK::SMEETS
>
>    
>    To me, this looks like a READ of the drawer information does not
>    do system management call, it brokered from UTRACK to SSOIOS, and
>    it could not find a proxy, so used OAFC$DEFAULT. Why it couldn't find
>    a proxy, I haven't a clue?

Why doesn't FCS use the already established management link. It's a bit 
confusing for the end-user. If one requests an index of all drawers which are
available to him/her, I would expect that he/she also could read the drawer 
information.

>    The FCS will have cached the first system management session that went
>    to SSOIOS, when you made the second IAD request, the fcs on teh cluster
>    would scan its list of established system management connects, it would
>    have found one to SSOIOS and used it, hence no authentication would 
>    have been done. The system management connections time out eventually, 
>    until that point, once established, they never do connect security
>    again.

That's not correct. After the first IAD & R I disconnected both clients, 
changed the proxy and finally did the second test.
    
>    Can you get the FCS trace log of this?
    
Ok, hold on, have to create them first.

Regards and Merry Xmas,

Martin
3675.7If they need FC attrs, can't use SM rtnsCHRLIE::HUSTONThu Dec 23 1993 14:0432
    
    re .6
    
>Why doesn't FCS use the already established management link. It's a bit 
>confusing for the end-user. If one requests an index of all drawers which are
>available to him/her, I would expect that he/she also could read the drawer 
>information.
    
    Beats me, I didn't write the IOS level, just the FCS level. It uses a
    new link because they are not using a FCS system management call, if
    they did (routines are OafcShowFileCabinet and OafcShowPartition to get
    drawer info), then it would use the same link.  THey used an "normal"
    API call, hence it goes through authentication/authorization again and
    creates another link. My GUESS is that during the first call to get
    the IAD info (from OafcShowPartition), they got the UID of the drawer
    then called OafcListW to get the rest. Now that I think about it, there
    is a major stumbling block to keep them from using OafcShowFileCabinet.
    If they need info that is not available from OafcShowPartiton, then 
    they could not use ShowFileCabinet. All FCS routiens are available
    to ONLY system managers, ie those who hold the OAFC$SYSMAN rights ID, 
    the exception is OafcShowPartition, this had special hooks put in for
    doing an IAD.
    
>That's not correct. After the first IAD & R I disconnected both clients, 
>changed the proxy and finally did the second test.
    
    Ok, I didn't realized you disconnected. THe disconnect will kill all 
    system management sessions that you had setup.  So on the second
    try you will indeed get new connections.
    
    --Bob
3675.8server traceUTRTSC::SMEETSLook at the ALL-IN-1 side of lifeThu Dec 30 1993 13:0413
Hi Bob,

As requested I've enabled server tracing.

The text trace files can be found in UTRTSC::USER3:[SMEETS.PUBLIC]

UTRACK_PROXY.DAT, proxy enabled for UTRACK::SMEETS

UTRTSC_PROXY.DAT, proxy enabled for UTRTSC::SMEETS

Have fun and happy new year,

Martin