Re: Kerberos protocol transition is not working over DCOM
From: Joe Kaplan \(MVP - ADSI\) (joseph.e.kaplan_at_removethis.accenture.com)
Date: Tue, 22 Mar 2005 00:14:11 -0600
Thanks for the clarification, Keith. I had gotten the impression that it
was not possible to create a primary token if you didn't have the user's
plain text credentials, which you wouldn't with with an S4U token. I'm not
sure where I got that. Given that DuplicateTokenEx was working, this makes
"Keith Brown <Pluralsight>" <email@example.com> wrote in message
>>>Primary tokens need to have the user's credentials as I understand it.<<
> 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
> level of IDENTIFY.
> But this is orthogonal to whether the token is designed for processes
> (primary token) or threads (impersonation token). This latter distinction
> totally historical - you can always convert between the two types of
> using DuplicateTokenEx, as Petteri is doing successfully.
> Back to the *impersonation level* now. Whoever calls LsaLogonUser must
> 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
> 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
> the SCM, it fails to authenticate with the server *process*, which is
> 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
> 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?
> * It would very likely work smoothly if you were running it as SYSTEM, but
> don't succumb to the temptation ;-)