Re: Kerberos protocol transition is not working over DCOM

From: Joe Kaplan \(MVP - ADSI\) (joseph.e.kaplan_at_removethis.accenture.com)
Date: 03/22/05


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
sense.

Thanks!

Joe K.

"Keith Brown <Pluralsight>" <keith_brown@newsgroups.nospam> wrote in message
news:9D796826-BD42-4106-B840-DA41E379D178@microsoft.com...
>>>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 ;-)
>