[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

1800.0. "Authenticated in mail directory errors" by KERNEL::OTHENJ () Wed Nov 18 1992 10:33

Hello,

	Can someone help me with my understanding of ALL-IN-1 and /proxy in 
the DDS database? 

	In v2.4, DDS was integrated with ALL-IN-1 following the normal 
procedure. This created accounts such as the one below;

        Organization name               : Customer Support
        Given name                      : Julie
        Surname                         : Othen
        Name                            : Julie Othen
        Location                        : CSC
        Free-format postal address      : Digital Equipment Co.
        Free-format postal address      : Customer Support Centre
        Free-format postal address      : Jays close
        Free-format postal address      : Viables Ind. Est.
        Free-format postal address      : England
        Reverse lookup                  : OTHEN@A1@WAYOUT
        Master copy owning node         : WAYOUT
        MHS/VMS address number          : 1
                MHS/VMS address part    : WAYOUT
                MHS mailbox             : A1
                MHS User identifier     : OTHEN
        Access Time                     :  4-JUN-1992 22:02:11.91
        Update Time                     : 16-NOV-1992 11:37:30.76
        DDSID                           : 21280A800095B9DAE36F0280A8A50000
                                                                            
	This worked correctly before an upgrade to v3.0 of ALL-IN-1. Since 
the upgrade, I have found that the only way to stop the error

"You could not be authenticated in the mail directory"

is to add /proxy on the ALL-IN-1 account. This adds the line 

        Proxy user agent                : OA$WAYOUT$ALLIN1       

onto the subscriber entry. The error then goes away.

	My understanding was this; I thought the proxy user agent was only 
required on the manager's account, and any dds subscribers that had been 
moved from other systems - so I do not see why /proxy is needed on the 
local node where the subscriber entry was created.

	Has there been any change in the code for ALL-IN-1 v3.0, as I 
noticed that if you create an account, it does create it with a /proxy on 
the dds subscriber?

	The customer has found the same problem as us on upgrading, while 
still using MR v3.1, so it does not look specific to 3.2 of MR.

	Does the subscriber DDSID entry have any link to the UA DDSID, as I 
was wondering if the UA was blown away and had to be recreated, if this 
would cause the problem.

	Any help much appreciated,

		Julie

	
    
T.RTitleUserPersonal
Name
DateLines
1800.1UmAIMTEC::WICKS_ALiverpool 4 Norwich 1Wed Nov 18 1992 17:2119
    Julie,
    
    This couldn't possibly have worked in v2.4 or v2.3 since the PROXY
    field has always been a required field on all SUBSCRIBER objects
    (not just the MANAGER) and is accessed by MAIL INIT as part of the
    authentication process.
    
    You didn't blow away your USERAGENT entry by any chance thus
    "orphaning" all the SUBSCRIBER objects?
    
    There is no link between a SUBSCRIBER ddsid and a USERAGENT ddsid
    
    If Suzanne didn't throw away her course notes from the Valbonne
    seminar in 1989 there was an excellent description of all this given
    by the developer (:==:).
    
    Regards,
    
    Andrew.D.Wicks
1800.2more questionsKERNEL::OTHENJThu Nov 19 1992 12:3830
    Hi,
    
    	Thanks for the reply, but could someone explain /proxy details in a
    bit more depth.
    
    	On ALL-IN-1 v2.4, all our entries in mbman do not have /proxy
    identifiers on them, but as normal with life at the CSC, DDS was not
    currently configured. After resetting it up (recreating the entry in
    UAPASSWRD and running useragent_post), all users received 
    
    You could not be authenticated in the mail directory,
    
    which could only be resolved by adding a /proxy to their entries. If
    the useragent was blown away at some time, would this remove the /proxy
    from the accounts, as I am sure we have not all manually gone into
    mbman and removed /proxy from their subscriber entries??
    
    	My other point of confusion is with subscriber_add.scp. If I 
    
    <get #dds_account = "OTHEN"
    <do subscriber_add
    
    it will create an entry in MBMAN with a /proxy on it, but I cannot see
    where this is done from the script. The subscriber DSAB field name for
    /proxy is PROXY, but this field is not mentioned in the write add
    subscriber. Where does it add the field??
    
    			Thanks,
    
    				Julie 
1800.3BLISS is ignorance!AIMTEC::WICKS_ALiverpool 4 Norwich 1Thu Nov 19 1992 18:0727
    Julie,
    
    I don't know about someone but will I do?
    
    %TITLE 'OADDS - ALL-IN-1 / DDS Integration DSAB action routines'
    ....
    
    ! AUTHOR: Andrew.D.Wicks
    !         Vidyut Desai
    ...
                   
    (:==:) (:==:)
    
    PROXY is one of the protected fields in the DSAB hence why it doesn't
    appear in any of the excellent SUBSCRIBER_ scripts. The addition of
    it when a SUBSCRIBER is added is done down at BLISS level in a routine
    called OA$dds_object_action - line 1850 to be exact.
    
    Deleting a USERAGENT object does have the side-effect of removing the
    PROXY (which after all is just the DDSid of the UA) from all the
    SUBSCRIBER objects thus "orphaning" them.
    
    I have a 7 page reply on this if you want!
    
    Regards,
    
    Andrew.D.Wicks