DCOM hell with SP2, Only way out seems to be system wide anonymous login

From: George Mills (mswlogo_at_hotmail.com)
Date: 10/30/04

  • Next message: TC10284: "Win XP SP2 Your Computer May not Be Protected Ballon Redisplays"
    Date: Fri, 29 Oct 2004 23:50:32 -0400
    
    

    I have a DCOM application that needs to run between all combinations of
    XP-SP1, XP-SP2, and Win2k

    All was fine until XP-SP2.

    We can get everything working if we add Remote Acess to Anonymous Login DCOM
    Limits.

    The Client is a Win32 desktop app. The server is an ATL COM Service.

    I keep getting E_ACCESSDENIED on the CoCreateInstanceEX() on Client (when
    Anonymous Login is disabled)

    The ATL COM service also calls back on a Client Sink interface.

    Everything is started manually on both Client and Server.

    I want to enable the simplest (most portable) authetication.

    Most customers run using an NT Domain. Some do not, And some cross domains.

    Previously to XP-SP2 we used CoInitializeSecurity to shutdown all
    authetication.
    We are not worried about security risks through our applications.

    But I don't want to open up the the new Computer wide ACL to Anonymous Login
    to allow just our application to run.

    I believe I am coming across the wire as anonymous and tried the suggestion
    posted below to use NTLM authebtication.

    But it still fails.

    Note the service is running under the default "System" account.

    What am I missing?

    ======================= OLD POST by someone else ===================

    Hi...

    To make the client-server communication to be non
    anonymous, refer to the help on ::CoInitializeSecurity
    function, it describes it pretty good.

    Remember that ::CoInitializeSecurity must be called on
    both the client and server.
    It's some time since I tested it, since I decided to go
    for the anonymous logon, but after searching some code I
    think these examples will work for you.
    --- Server Side ---
    SOLE_AUTHENTICATION_SERVICE* pacAuth = new
    SOLE_AUTHENTICATION_SERVICE;

    pacAuth->dwAuthnSvc = RPC_C_AUTHN_WINNT;
    pacAuth->dwAuthzSvc = RPC_C_AUTHZ_NAME;
    pacAuth->pPrincipalName = NULL;
    pacAuth->hr = S_OK;

    ::CoInitializeSecurity
    (NULL,1,pacAuth,NULL,RPC_C_AUTHN_LEVEL_CONNECT,RPC_C_IMP_L
    EVEL_IMPERSONATE,NULL,EOAC_NONE,NULL);

    --- Client Side ---
    ::CoInitializeSecurity(NULL, -1, NULL, NULL,
    RPC_C_AUTHN_LEVEL_NONE, RPC_C_IMP_LEVEL_IDENTIFY, NULL,
    EOAC_NONE, NULL);

    aiAuthInfo.dwAuthnSvc = RPC_C_AUTHN_WINNT;
    aiAuthInfo.dwAuthzSvc = RPC_C_AUTHZ_NAME;
    aiAuthInfo.dwAuthnLevel = RPC_C_AUTHN_LEVEL_CONNECT;
    aiAuthInfo.pwszServerPrincName = NULL;
    aiAuthInfo.dwImpersonationLevel =
    RPC_C_IMP_LEVEL_IMPERSONATE;
    aiAuthInfo.pAuthIdentityData = NULL;
    aiAuthInfo.dwCapabilities = 0;

    siServerInfo.dwReserved1 = 0;
    siServerInfo.pwszName = A2W("<Your servername>");
    siServerInfo.pAuthInfo = &aiAuthInfo;
    siServerInfo.dwReserved2 = 0;

    mrmq[0].pIID = &<Your interface ID>;
    mrmq[0].pItf = NULL;
    mrmq[0].hr = 0;

    ::CoCreateInstanceEx(<Your classid>, NULL,
    CLSCTX_LOCAL_SERVER | CLSCTX_REMOTE_SERVER,
    &siServerInfo, 1, mrmq);

    Regarding Workgroup security... To be able to run with
    authenticated users the logins must (as you indicates) be
    the same username and password on both the server and
    client.

    --Rune G

    >-----Original Message-----
    >Hi all,
    >
    >Let me say at first that SP2 is a lot of work for me so
    far... Our
    >application worked for NT4 and up and since SP2, there
    is a lot the be
    >configured to make it work. I have found the info to
    configure XP SP2 for
    >anonymous client-server authentication and it's working.
    >
    >Now I need to find a way not to use anonymous-logon to
    make dcom work. Most
    >of my clients are not on a domain, not even on a same
    workgroup. Is there a
    >way to make dcom use connect or something else, without
    opening everything
    >for anonymous.
    >
    >I tried different approach, but the server alway see the
    client coming with
    > NT AUTHORITY\ANONYMOUS LOGON SID ...
    >
    >Even if I set my client side for "connect".
    >
    >>From what I understand.
    >1. On the client side, Dcom obtains a user name
    >2. The server authenticate the user
    >3. Is the user in the list
    >4. Fail or accept
    >
    >So if I have on client-server(not a domain) the same
    user/pass pair, it
    >should work?
    >
    >I probably don't understand this correctly, since I
    cannot make it work
    >outside anonymous.
    >
    >Any help - pointers would be appreciated.
    >
    >Regards
    >
    >
    >.
    >


  • Next message: TC10284: "Win XP SP2 Your Computer May not Be Protected Ballon Redisplays"

    Relevant Pages

    • DCOM authetication hell with SP2
      ... We can get everything working if we add Remote Acess to Anonymous Login DCOM ... The Client is a Win32 desktop app. ... Everything is started manually on both Client and Server. ... >Now I need to find a way not to use anonymous-logon to ...
      (microsoft.public.win32.programmer.ole)
    • Re: Remote DCOM on WinCE 6.0
      ... as in the client case. ... allowing the selected user name to start the server or, at least, access the ... You have to make sure that your code to actually create the remote ... Once you have all of that, run your DCOM client application in the ...
      (microsoft.public.windowsce.embedded)
    • Re: DCOM security in Windows Server 2003 SP1
      ... it's unfortunate that they chose a different name for it in the server edition if it's indeed the same thing. ... DCOM by one account or set COAUTHINFO in COSERVERINFO in CoCreateInstanceEx) with special activation privilege, for example, a domain account in the newly created build-in group "Distributed DCOM user", and switch back to the identity that runs the client program after the activation? ... like to grand remote activation permission to "Everyone" in the computerwide restrictions or DCOM limits whatever it is called, just because our client program fails. ...
      (microsoft.public.win32.programmer.ole)
    • Re: Remote DCOM on WinCE 6.0
      ... Now we're focussing on loading the server ... as in the client case. ... applet's Network ID tab to be a user name and password that the remote ... Once you have all of that, run your DCOM client application in the ...
      (microsoft.public.windowsce.embedded)
    • Re: Remote DCOM on WinCE 6.0
      ... In fact, the WinCE device will run the server, not the client. ... You have to make sure that your code to actually create the remote object ... Once you have all of that, run your DCOM client application in the debugger ...
      (microsoft.public.windowsce.embedded)