Conference decwet::nt-developers

3245.0. "Access denied/named pipes/RPC" by PTHRED::SHARRIS () Fri May 30 1997 15:06

    I'm looking for more ideas about what could be causing an "Access
    denied" message that we get when we try to use RPC with named pipes
    to a particular machine.  This same call works ok on other machines
    running the same version of NT, so I'm looking for something that must
    need tweaking on the problem machine.
    
    Here's the scenario:
    
      Machine "x" tries to access Machine "y" with an RPC call using    
      a named pipe.  Both machines are running NT V4.0, Service Pack 2,
      both are Intel machines.
    
      The logged-on user on Machine "x" does NOT have a local account
      on machine "y" - but does have a domain account.  (If we put a local
      account on machine "y" or if the user from "x" logs into the
      domain account, everything is just fine.  But, since this same
      scenario works to machine "z", where there is not a local 
      account either, and it DOES use the domain account, it doesn't make 
      sense!) 
    
      All machines have Guest accounts and have "Everyone, Guests,
      Administrators" set in the User Rights for "Access to this computer 
      from network". (I was trying everything!) Guest belongs to the Guests 
      group, as well.
    
      All machines are in the same domain.
    
      Access using TCP doesn't have this kind of problem...only named
      pipes.
    
    I tried auditing logon failures and object access on machine "y",
    but it doesn't seem to tell me much.  When it fails, it says that  it
    was a logon failure from "domain x, username", and it was KsecDD giving
    the failure on a network login of type 3 (network login).  Note that it
    does not reference the REAL domain name, it references it as domain
    "x",  since the user is logged in locally on machine "x".
    
    When it works, we don't even see a network login being audited!  (And
    I have both success/failure being audited.)
    We only see the subsequent 'impersonation' login that our server code does
    to login (so the audit entry shows a login type of 2 from advapi). 
    This is from our "logon_as_user" call in the server.
    
    We also tried some things programmatically, but they didn't seem to
    help: using the example from the MSDN of Server.c for named pipes,
    we tried setting a security descriptor that allows "everyone"
    access to the named pipe. (SECURITY_WORLD_RID gets SPECIFIC_RIGHTS_ALL
    and STANDARD_RIGHTS_ALL.)  Then we send this security descriptor in as
    the last parameter to rpc_server_use_all_protseqs, when registering
    the server on Machine "y".  But this didn't seem to make any difference
    at all.  Nor could I detect anything happening in the audit file when
    I tried this, altho the debugger indicated success status on all
    calls...We couldn't find much documentation on this parameter to 
    rpc_server_use_all_protseqs, however.  Maybe this kind of SD should
    be applied in some other fashion?
    
    On the other hand, access to node "z" works just fine without any
    programming changes.  
    
    Shouldn't the access right to "access this computer from the network"
    be all that is needed?  Any ideas on anything else to look at
    here?!?!?!?    

    
    i am not sure i follow : don't you say that if either x or z logs into 
    the domain then they can access y ? i did not understand where z does 
    something x can't.
    

    re: .1   There are several cases.  It's true that if node x is logged
    into the domain account, everything works, to both machines y and z.
    
    But if node x is logged into the local account, and there is no local
    account for that user on y OR z, but there are domain accounts for that
    user on y and z, then rpc access works to node z, but doesn't work to
    node y, for some reason...