Conference iosg::all-in-1_v30

    
    Cheryl
    
    "Invalid authentication from the file cabinet server" is usually
    returned when someone tries to perform Management operations without
    the OAFC$SYSMAN identifier being assigned to them.
    
    However, in this case it would appear that a notmal user is receiving
    the errors ?
    
    Check to ensure the remote proxy entry is set with /DEFAULT, and meanwhile
    I'll have a think. 
    
    
    Kevin.
    
    

    
    I don't think it has anything to do with proxies since you say
    everything is on one node. 
    
    Can you turn on the FCS tracing and try it again, this will log what
    is happening with the FCS, run the log through the formatter
    (sys$system:oafc$print_trace_log.exe) and post the results here, 
    please edit the output so that only the session is question is
    in it.
    
    This is the second time I have heard of this happening, haven't
    figured either of them out yet.
    
    
    Things to check:
    
    1) Expired account
    2) expired password
    (they both should get other errors though)
    3) intrusion record
    4) What distribution level are you running at (on both servers)?
    
    --Bob
    

    Here's what I found out from your test, Bob.
    
    SESSION ID:  6516544
    OAFC FUNCTION: OafcOpenCabinetW
    TRACE EVENT: Task Start
    EVENT TIME:  8-DEC-1992 15:33:37.06
    
    SESSION ID:  6516544
    OAFC FUNCTION: OafcOpenCabinetW
    TRACE EVENT: Connection Rcv'd
    EVENT TIME:  8-DEC-1992 15:33:37.21
    FILE CABINET NAME:  MINNIE.FOREHAND
    STRING1 IS:  MINNIE
    STRING2 IS:  FOREHAND
    
    SESSION ID:  6516544
    OAFC FUNCTION: OafcOpenCabinetW
    TRACE EVENT: Connected Rejected
    EVENT TIME: 8-DEC-1992 15:33:37.31
    FILE CABINET NAME:  MINNIE.FOREHAND
    STRING1 IS:  FOREHAND
    
    SESSION ID:  6516544
    OAFC FUNCTION: OafcOpenCabinetW
    TRACE EVENT:  Task Complete
    EVENT TIME: 8-DEC-1992 15:33:37.35
    FILE CABINET NAME:  MINNIE.FOREHAND
    STATUS:  55804130
    
    I looked up the status code and it is the invalid authentication error.
    
    I found out that the file cabinet that the user cannot access are the
    ones that used to be SFCP shared files.
    
    Any other clues?? All help will be appreciated.
    
    Cheryl E.

    
    Cheryl
    
    The only way to get this error is:
    
    1) Incorrect password, but if you are connecting to your own filecab
       on the same node, then we don't check passwords, since VMS already
       did.  When this person gets into ALL-IN-1, did they do anything like
       ALLIN1/USER=xxxxxx?
    
    2) Intrusion record from MINNIE::FOREHAND
    
    The comment about SFCP is curious, the Atlanta CSC has asked us about
    the same problem. I think we are going to need a SFCP expert to help 
    out on this. 
    
    SFCP questions:
    
    1) How does an SFCP drawer become a V3 filecabinet? 
    2) Who owns it?
    3) How is it accessed via V3?
    
    --Bob
    

    Hi Bob,
    
    I will check again on the intursion record. When I dialed in as the
    ALL-IN-1 manager on the customer's system, I did not have enough
    privleges to do a sh intrusion.
    
    These drawers are owned by ALL-IN-1 and to access them they just type in
    the name of the drawer, folder and document. I did not have to supply
    the owner at all.
    
    I'm not sure how they got these drawers into v3.0 but my guess is that
    they used the migration procedure they were given. I will check for
    sure.
    
    Thanks,
    
    Cheryl Estes 

Hi Cheryl,

Are you running ALL-IN-1/English (US)? There is a known I18N problem with the
conversion of SFCP FileCabinets if done in other language flavours than 
English. The result would be that noone but the onwer had access to the new 
Drawer in the end.

Bob,

>    SFCP questions:
    
>    1) How does an SFCP drawer become a V3 filecabinet? 

If the SFCP FileCabinet was called something like:

	Folder: [SFCP]FOLDER
	Title:  First document in SFCP folder FOLDER
	Number: 000001

the conversion would create a MAIN drawer for 'dummy' ALL-IN-1 account 'SFCP' 
with the folder being the folder:

	Drawer: [SFCP]MAIN
	Folder: FOLDER
	Title:  First document in SFCP folder FOLDER
	Number: 000001

Every Shared Cabinet in SFCP did have a 'dummy' ALL-IN-1 account associated 
with it.

>    2) Who owns it?

The 'dummy' ALL-IN-1 account. Well, dummy isn't really the right word as the
account needed to be used for reading mail, do maintainance, etc.

>    3) How is it accessed via V3?

After the conversion just like any other Drawer. The conversion routine would 
create the necessary datafiles, grant the necessary ACEs etc. 

HTH,

	Simon    

    Hello,
    
    This system is English (US). They used the conversion procedure
    provided with the 3.0 upgrade. 
    
    This user does not have an intrustion record.
    
    If you look at the drawer through drawer management it looks like this:
    
    Drawer: [BPWP]MAIN - the owner is ALLIN1.
    
    But to access it, you just type in BPWP.
    
    Hope this helps.
    
    Cheryl E.

    Re .6 (Bob)
    
    >  The comment about SFCP is curious, the Atlanta CSC has asked us
    >  about the same problem. I think we are going to need a SFCP expert to
    >  help out on this.
    
    It might be the same call - Cheryl is the Atlanta CSC she just for some
    strange reason uses an old v2.4 node to do her noting from!
    
    Cheryl,
    
    What does the SFCP migration log show for these drawers there may be
    some clues there.
    
    regards,
    
    Andrew.D.Wicks (not an SFCP expert but I did see it fail in Denver a lot)
       

>    1) How does an SFCP drawer become a V3 filecabinet? 
There is no difference between an SFCP cabinet and a normal user 
before the upgrade to Diamond. The partition seeding program should 
see dan SFCP cabinet and convert the structure of the cabinet to a 
drawer. The migration tool primarially converts the ACLs. 

>    2) Who owns it?
The owner was set when the drawer was created. 

>    3) How is it accessed via V3?
Like a normal drawer. 

1. Here are some things to try. Login to the account that is the 
   drawer owner.

2. See if the drawer is shared and with who and with what rights. 

	NOTE: If you can't access the drawer as the owner it could 
	      be that it didn't seed correctly. 

	      If the ACL isn't right it could be that the Migration 
	      tool failed. (this is extremely unlikely). 

3. Actually check that there is an ACCESS.DAT in the default directory. 

4. Make sure the system thinks it is really a drawer. 

This might give us some clues as to where the thing went wrong. 

Cheers, 
jal

Just to reduce the confusion a little.

Cheryl is the CSC specialist working this problem with the customer, she 
asked me if I had any ideas and after checking everything I could think of
I sent mail to Bob Huston and suggested that she put this note here.

As far as I know this problem is unique to this customer.

The drawer in question is a pre-V3.0 SFCP drawer owned by the ALL-IN-1 manager
that was converted during the installation of V3.0.

We checked the ACLs on all the drawer and document files and they were fine,
ACCESS.DAT was present and correct, ALL-IN-1 was happy with the drawer when
examined from the Manage Drawer menus and the ALL-IN-1 Manager (the drawer
owner) can edit the documents in the drawer without any problem. The user can
access the drawer provided they do not do anything that involved the FCS (e.g.
they can refile a document to another folder in the same drawer, but not to
a folder in another drawer.

This may be a problem with the user rather than the drawer.

We are going to check the following with the customer ...

- Can the other users who have access to this drawer (but do not own it) perform
  operations that involve the FCS?

- Can this user access any other drawers that used to SFCP drawers and perform
  operations that involve the FCS.

Hopefully this will isolate the problem to either the drawer or the user, in the
mean time any other ideas would be welcome.

Terry

    Hello,
    
    We've been able to rule out SFCP. We had the customer to create a new
    drawer and grant access to this user. She could not edit a document in
    this drawer either. 
    
    He created a new user, gave them access to both drawers and the new
    user received the same error.
    
    Other users, who had access before the update to 3.0 can still access
    the drawer. Looked at the server to see who had access connections already
    made. Found 4 connections. Gave one of them access to the drawer and
    had them to try to edit a document. This operation was successfull for
    this user.
    
    We looked at the SYSUAf record and it looked good. Looked also at the
    profile entries.
    
    Clues???
    
    Cheryl Estes
             

    And some more...
    
    Per Terry's suggestion we had the user try to RSV (reserve) a document
    in his own file cabinet.  Then he was able to edit documents in the
    shared drawers.
    
    So, it appears that once the connection has been established to the
    FCS, it works after that.  Certain operations do not seem to be able to
    make the connection.
    
    Any ideas out there?
    
    Bina Cline
    Atlanta CSC

    
    Ok, since what you are saying makes not sense whatsoever :-), its time
    to take some wild guesses.
    
    It sounds as if the direct access of the SFCP drawer is using a
    different code path to connect to the FCS than when you do a 
    reserve, which also will make a FCS connect.
    
    Can anyone from ios land check the following in the code that requests
    the connect to the FCS:
    
    - In both situations, where does the password come from?
    - In both situations, where does the FCname and VMS username come from?
    - Do either think there is a secondary password?
    - Does IOS support secondary passwords when connecting to the FCS?
    
    And one for the support folks:
    
    - Does the account in question have a secondary password?
    - Has it ever had one?
    
    --Bob
    

Hi Bob,
I hope you except an answer to your questions from non-IOS land 8^)

There is only a single code path for the FCS connect.

The parameters for the OafcOpenCabinet call are taken from 
values which are set during ALL-IN-1 initialization and which should
*never change during the lifetime of the ALL-IN-1 session*.
These values are
		NODE		taken from system logical SYS$NODE
		VMSUSER		taken from a GETJPI call
		USERNAME	either same as VMSUSER or what was
				specified with /USER
    
The OafcOpenCabinet is then called with

		Cabinet			NODE.USERNAME
		User_ID.vms_account	VMSUSER
		User_ID.vms_password	VMSUSER
		User_ID.vms_password2	0
    
SO, I don't understand at all what's happening to the user.

Cheers,
	helmut
    

    
    re .16
    
    Guten Tag heir Graef, vie gates?
    
>I hope you except an answer to your questions from non-IOS land 8^)

    You're close enough to IOS land :-), after all you wrote it.
    
>The parameters for the OafcOpenCabinet call are taken from 
>values which are set during ALL-IN-1 initialization and which should
>*never change during the lifetime of the ALL-IN-1 session*.
>These values are
>		NODE		taken from system logical SYS$NODE
>		VMSUSER		taken from a GETJPI call
>		USERNAME	either same as VMSUSER or what was
>				specified with /USER
>    
About what I figured.
    
>The OafcOpenCabinet is then called with
>
>		Cabinet			NODE.USERNAME
>		User_ID.vms_account	VMSUSER
>		User_ID.vms_password	VMSUSER
>		User_ID.vms_password2	0
>    
>SO, I don't understand at all what's happening to the user.

    I see two potential problems with this, one is of course, if the 
    VMSUSER has a secondary password, the FCS will reject the connect.
    
    The second, and I'll leave it up to you if this really is a problem, 
    is that if USERNAME does not equal VMSUSER, then what will happen is 
    that you will be allowed to connect to the filecabinet, and will be
    accessing the drawers/folder/... of node.username, but you will be
    authenticated as VMSUSER, hence you will only be given access to 
    the documents and other FC objects that VMSUSER has access to.
    
    A little example:
    
    User1 enters ALL-IN-1 by doing $ ALLIN1/USER=USER2, now all will go
    great when they connect since the authentication username (user1)
    matches the transport username (again user1). You will now be in 
    user2's FC. The problem is that you are not really user2 to teh FCS, 
    you may be to IOS, but to the FCS you are USER1. So when you attempt 
    to read/edit/... any document, the access checks will be based on
    the username user1, not user2 as I think it is expected.
    
    This was done to keep people from having access to any FC on the
    same node.
    
    Also note, this "cross authentication" is not the problem of .0, 
    they are not making it this far, they can't get past the original
    authentication for some reason. But they can if they do a reserve first
    which really confuses me.
    
    --Bob
    
    

    
    Answers to the questions posed in the last few notes:
    
    - ALL-IN-1 username and VMS username are the same for this user
    - This user does not have a secondary VMS password or an ALL-IN-1
      password and has never had either one
    
    So what now?  I would appreciate suggestions on how to troubleshoot
    this further,
    
    Bina Cline
    Atlanta CSC

    RE :.17
    
    Well, Bob - I reckon that that's exactly what should happen (your
    description of authentication when USER1 does ALLIN1/USER=USER2). The
    user should be authenticated as his "real" self, not as USER2.
    
    Dave.

    
    bina,
    
    The part that has me really confused is the part about being able to
    connect when doing a reserve first. They should be using the same
    code path as Helmut said, therefore, they should be no different.
    I am at a loss as to what to tell you.
    
    One thing I would try, if possible, have the customer connect via 
    TeamLinks, this will also pass in the password and run the
    authentication code in the FCS.
    
    --Bob

    
    Just an update, after having both FCS team members and CSC dial into
    the customer to try and debug this with a debuggable FCS, the problem
    has "magically been fixed". We did nothing, it just went away on its
    own.
    
    Oh well, must be the wonderfull self-correcting code in the FCS :-)
    
    --Bob