Conference pamsrc::objectbroker_development

2452.0. "OBB_INV_SECAUTHNFAIL (e), DCE specific: Failed to authenticate requester" by XSTACY::GORMAN (Unfathomable, is the course of action.) Fri Mar 14 1997 09:05

Hi; 
I have a client on Digital UNIX OBB V2.7-11
And server on OpenVMS OBB V2.7-11

The server has - (nodename is hps126)

>  Attributes:   AuthrWOAuthn is ENABLED  (I've tried this with DISABLED as well)
>                Active transports are TCPIP, DECnet
>                OrbV12 style Agent


> Configuration  "DECnet and TCP/IP Configuration"  (Current)
> -------------------------------------------------------
>  Authentication
>    AuthrWOAuthn: Enabled
>    Package:      Trusted
>     Description: Trusted authentication package
>  Network
>    Package:      TCP
>     Description: TCP/IP transport package
>    Package:      DECnet
>     Description: DECnet transport package
>  Logging Level                  All
>  Keep database files            0
>  Object Hash Table Size         0


The security model on the Implementations on the server are OPEN

The client has - (nodename is osf600)

>  Attributes:   AuthrWOAuthn is DISABLED
>                Active transports are TCPIP
>                OrbV12 style Agent

> Configuration  "TCP/IP-Only Configuration"  (Current) 
> -------------------------------------------------------
>  Authentication
>    AuthrWOAuthn: Disabled
>    Package:      Trusted
>     Description: Trusted authentication package
>  Network
>    Package:      TCP
>     Description: TCP/IP transport package
>  Logging Level                  Process
>  Keep database files            0
>  Object Hash Table Size         0




When the Client is run it reports an error 

>Going to fetch Product Information
>System Exception Reported
>CORBA_INTERNAL
>OBB_INV_SECAUTHNFAIL (e), DCE specific: Failed to authenticate requester
>-OBB_COM_CMPNOTCONF (e), Component `$ComponentName$' not configured.
>-OBB_COM_CMPNOTCONF (e), Component `DECnet' not configured.
>-OBB_INV_UNKNODE (e), Unknown node `hps126' specified.

We dont have DCE installed on the client system; and we cant figure out
from the logfiles why authentication should be failing and why its reporting
a DCE error. Help! Thanks

Anthony





OBB_TRACE_FLAGS=QFIPRT

OBB C++ Library Compile Date/Time: Feb  5 1997 11:43:12
OBB C++ Compile Command: cxx
OBB C++ Compile Flags: -c -std1 -trapuv -g -DPROD -Dexterndata    -D_BSD -Dalpha
 -Dosf -Dunix -Dsys5      -I/usr/lib/ObjectBroker/cxxbld -I/usr/lib/ObjectBroker
/cxxsrc/

**** Skip Method Selection, OpInfo Created by STUB


**** Implementation Selection


**** Callout to method map resolve rtn.

*** Load Network implementation TCP
        FamilyName<5> <TCPIP>
ImagePath<26> </usr/shlib/libobbtrntcp.so>
        LibraryName: /usr/shlib/libobbtrntcp.so

**** Server Instance Selection

 Selection policy defaulting to advertisements, local_node, default_nodes.

 Context scope default to USER.

 Get Server Selection Node List:

 Possible server selection nodes: <2>
   000. OBB_LOCAL                        = osf600.ilo.dec.com
   001. OBB_DEFAULT_NODES                = hps126.mro.dec.com

 Looking for running server:

 Looking for servers on node osf600.ilo.dec.com.

*** Load Agent implementation OrbV12
        FamilyName<3> <OBB>
ImagePath<25> </usr/shlib/libobbagncl.so>
        LibraryName: /usr/shlib/libobbagncl.so
Obtaining Security Key for Client ID 7b6c5b928a83.02.10.b7.a0.4c.00.00.00
 Impl ID 65e448ecbd2c.0c.7e.0b.00.00.00.00.00

List of server supported sec. types isn't known yet. Trying client sec types in
turn

 Number of client supported security types: 1
Trying each of the sectypes from above list


*** Load Authentication implementation Trusted
        FamilyName<3> <TRS>
ImagePath<26> </usr/shlib/libobbsectrs.so>
        LibraryName: /usr/shlib/libobbsectrs.so
Trying to get security key using Trusted package

Successfully obtained key/established context using security package Trusted

Signing messsage from Client ID 7b6c5b928a83.02.10.b7.a0.4c.00.00.00
 to Impl ID 65e448ecbd2c.0c.7e.0b.00.00.00.00.00
 Using Trusted Security package to sign message.

 Status of signing message: OBB_SUCCESS (s), Successful completion.
*** Request Sent: Synchronous Invoke.
*** Method: 65e448f20f7c.0c.7e.0b.00.00.00.00.00.
***    MethodServerClass: 65e448ecbd2c.0c.7e.0b.00.00.00.00.00
***    Marshalled Buffer: 572
***    Allocated Buffer : 1926
***    Transport Status: OBB_SUCCESS (s), Successful completion.
 Trying to verify message from client UUID 7b6c5b928a83.02.10.b7.a0.4c.00.00.00

 Using Trusted security package to verify signed message

 Stauts of verifying signed message: OBB_SUCCESS (s), Successful completion.
***    Operation Status: OBB_INV_METHODFAIL (e), Method execution failed.

 Looking for servers on node hps126.mro.dec.com.
Obtaining Security Key for Client ID 7b6c5b928a83.02.10.b7.a0.4c.00.00.00
 Impl ID 65e448ecbd2c.0c.7e.0b.00.00.00.00.00

List of server supported sec. types isn't known yet. Trying client sec types in
turn

 Number of client supported security types: 1
Trying each of the sectypes from above list

Trying to get security key using Trusted package

Successfully obtained key/established context using security package Trusted

Signing messsage from Client ID 7b6c5b928a83.02.10.b7.a0.4c.00.00.00
 to Impl ID 65e448ecbd2c.0c.7e.0b.00.00.00.00.00
 Using Trusted Security package to sign message.

 Status of signing message: OBB_SUCCESS (s), Successful completion.
*** Request Sent: Synchronous Invoke.
*** Method: 65e448f20f7c.0c.7e.0b.00.00.00.00.00.
***    MethodServerClass: 65e448ecbd2c.0c.7e.0b.00.00.00.00.00
***    Marshalled Buffer: 572
***    Allocated Buffer : 1926
***    Transport Status: OBB_SUCCESS (s), Successful completion.
 Trying to verify message from client UUID 7b6c5b928a83.02.10.b7.a0.4c.00.00.00

 Using Trusted security package to verify signed message

 Stauts of verifying signed message: OBB_SUCCESS (s), Successful completion.
***    Operation Status: OBB_SUCCESS (s), Successful completion.

fixed it; the server side has a UCX tcp/ip address entry which mapped the
hostname.x.y.z to a hostname and that hostname was pased back to the client
(must be as part of the authentication process) and the client then
tried to use the hostname name to look up the bind server for an address
but of course the bind server knew nothing of the hostname; it would
only know about it if it was hostname.x.y.z
so the solution was to update th UCX address entry in UCX on the server side.
The DCE part of the error message seems to be a bit misleading