Re: Kerberos protocol transition is not working over DCOM

From: Petteri Stenius (jeps_at_discussions.microsoft.com)
Date: 03/21/05 

Date: Mon, 21 Mar 2005 12:31:04 -0800

Hi,

Yes, CoCreateInstanceEx succeeds but the QueryInterface after that fails. I
can see the COM+ component's constructor being called on the server side.

I thought I had the principal names and delegation issues sorted out because
if I setup cloaking, call ImpersonateLoggedOnUser and try to call the COM+
component from within the same process then everything is ok.

1) The COM+ component is running as Network Service. No difference if it was
running as SYSTEM. I haven't yet tried with a normal account. Maybe I'll try
that next.

2) This domain account (TEST15$ in my case) is assigned with
servicePrincipalName values of:
HOST/TEST15
HOST/TEST15.test.local
rpcss/TEST15
rpcss/TEST15.test.local
cifs/TEST15
cifs/TEST15.test.local

The HOST and rpcss princpals are the only ones I have seen being requested
for during the COM+ calls in my Network Monitor traces.

3) The account calling LsaLogonUser is service1 and it has the above six
values assigned to msDS-allowedToDelegateTo. No other values from TEST15. The
servicePrincipalName of service1 is "ws/service1" (something I've made up to
enable the Delegation tab in user management). The service1 account is member
of the "Domain Users" and "Windows Authorization Access Group" groups in the
domain, and member of the Administrators group on the local host (and has TCB
privilege enabled).

I'm running with KerbDebugLevel set to ffffffff. Some messages that could be
of interest are appearing in the debug log:

524.620> Kerb-Warn: KerbGetTgtForService getting new TGT for account
524.620> Kerb-Warn: KerbGetTgtForService falied to refresh TGT 0xc0000001
for user1@test.local
...
524.620> Kerb-Error: KerbGetS4UServiceTicket cannot get S4U Tgt - c0000001
524.620> Kerb-Error: KerbGetS4UProxyEvidence failed to get S4U ticket -
c0000001
524.620> Kerb-Error: Failed to get S4UProxy Evidence ticket c0000001

user1 is the account I'm trying to impersonate.

Thanks,
Petteri

"Keith Brown <Pluralsight>" wrote:

> >>Primary tokens need to have the user's credentials as I understand it.<<
>
> Joe,
>
> What you're thinking of is the *impersonation level* of the token. You are
> correct that by default, an S4U logon returns a token with an impersonation
> level of IDENTIFY.
>
> But this is orthogonal to whether the token is designed for processes
> (primary token) or threads (impersonation token). This latter distinction is
> totally historical - you can always convert between the two types of tokens
> using DuplicateTokenEx, as Petteri is doing successfully.
>
> Back to the *impersonation level* now. Whoever calls LsaLogonUser must have
> SeTcbPrivilege in order to get an impersonation level of IMPERSONATE, and
> Petteri says he's in the TCB, and based on the fact that he can indeed get
> tickets for CIFS using an S4U token, I'm guessing he's doing everything right
> WRT calling LLU/CPAU.
>
> So Petteri, is the CoCreateInstanceEx call failing?
> If the server object is being created, it sounds as though you have
> successfully authenticated with the SCM on the COM+ server box, but when
> CoCreateInstancEx tries to unmarshal the interface pointer(s) it was given by
> the SCM, it fails to authenticate with the server *process*, which is running
> under a different identity than the SCM.
>
> My first guess is that you've got a problem with service principal names,
> which is why you're seeing the negotiation with the server process (via a
> dynamic port, not port 135) drop down to NTLM.
>
> Let's see...
>
> 1) I assume you've configured your COM+ server app to run under a domain
> account, and that you're not running as SYSTEM*. Am I correct?
>
> 2) What (if any) service principal names (SPN) have you configured for this
> domain account?
>
> 3) What SPNs have you listed in the allowed-to-delegate-to box in Active
> Directory for the account that you're using to call LsaLogonUser?
>
> Keith
>
> * It would very likely work smoothly if you were running it as SYSTEM, but
> don't succumb to the temptation ;-)
>

Relevant Pages

  • Re: Sql Reporting Serviced - > ASP.NET ACCESS DENIED!
    ... The account you are logging in to when on the server doesn't have the ... do you have <Impersonate> set to True? ... > Exception Details: System.UnauthorizedAccessException: Access to the path ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: security on the web.config file
    ... the reason I use the impersonate is the web site will allow ... different network shares on multiple servers so the impersonated account has ... the .config file can only we accessed from the server ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Global.asax not allowing identity impersonation?
    ... When you set Identity Impersonate=true, ... request processing. ... Not allowed to use the ASPNET machine account in SQL Server (very ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Win2000 Impersonation weirdness? (or is it a conundrum?)
    ... Is the server joined to a domain? ... priveleges to impersonate in a domain. ... The privilege need not be ... > default as an unprivileged account ...
    (microsoft.public.win2000.security)
  • Re: Win2000 Impersonation weirdness? (or is it a conundrum?)
    ... Is the server joined to a domain? ... priveleges to impersonate in a domain. ... The privilege need not be ... > default as an unprivileged account ...
    (microsoft.public.security)