GSS API and impersonate client in the server

Douglas E. Engert deengert at
Tue Nov 2 11:50:19 EST 2004

Mattias Karlsson wrote:
> Hi and thanks for your answer.
> I now have a GSS sample client that can authenticate to a SSPI sample
> server. The sample server can then impersonate the client via the SSPI
> call ImpersonteSecurityContext.
> However, this does not work if the SSPI sample server runs on a Win
> 2k3 SE machine. It works if the server runs on a XP (SP 1 or SP 2) or
> a Win2K machine. This really puzzles me!
> The error I get is a "Miscellaneous failure" with "Unknown error code"
> in the GSS sample client when feeding the gss_init_sec_context
> function the token received from the server (gss_accept_sec_context
> call).
> Is it possible that some default configuration etc on Win 2K3 SE
> triggers this? How is Win 2k3 SE different from XP/Win 2K (in a
> "Kerberos view")?

It could be that W2k3 is using some new features that are not
supported in your Kerberos, and it can't handle the returned message.

Could it also be you have to recompile the server for w2k3?

What version of Kerberos client are you using?

Do you have any trace like Ethereal?

The question is what was returned, an error, or some vaild message
that the client could not handle.

> Thanks
> Mattias
> deengert at ("Douglas E. Engert") wrote in message news:<417014E6.5010308 at>...
>>If I am understand you reasoning you don't want to use
>>SSPI because you have some unix servers and clients.
>>But the SSPI and Kerberos GSSAPI use the same wire protocol,
>>so you could be using InitializeSecurityContext on WIndows and
>>gss_accept_sec_context on UNIXservers.
>>We do this all the time with a SecureCRT client on Windows using
>>either Kerberos for Windows gssapi or MS SSPI Kerberos to OpenSSH
>>sshd server with MIT Kerberos gssapi.
>>Going the other way with Unix client using gss_init_sec_context and
>>a windows server using AcceptSecurityContext should also work and
>>delegation should work. I have not tried this. There may be issues when
>>you try and use the delegated credential to impersonate the user as
>>it will need a PAC. Kerberos is strictly authentication. AD add to
>>the Kerberos ticket authorization information. So it may mean you need to
>>use AD for the KDC.
>>Mattias Karlsson wrote:
>>>I'm about to kerberize our product and will use the gss api. When
>>>analyzing the different components in our system I found that I need
>>>to be able to impersonate the client in the server using the client
>>>credentials. The reason for doing this is that the server needs to be
>>>able to access Windows resources (registry) with client permissions.
>>>How it works in the unkerberized client/server is that the client
>>>sends it's Windows user and password to the server in the beginning of
>>>the session. The server does a (WIN API) LogonUser and a
>>>ImpersonateLoggedOnUser and can then act as the client in that thread.
>>>I don't want to send user/password over the network but need to be
>>>able to impersonate the client!
>>>The Windows SSPI API provides functions like
>>>InitializeSecurityContext, AcceptSecurityContext and
>>>ImpersonateSecurityContext but I don't want to use SSPI since I got
>>>some UNIX servers and clients as well. Is it possible to use the
>>>delegated_cred_handle or context_handle I get from the gss api call
>>>gss_accept_sec_context and use it (maybe cast it) in the
>>>ImpersonateSecurityContext function? Or is there some other way to do
>>>this? I assume I need to specify the GSS_C_DELEG_FLAG in the clients
>>>gss_init_sec_context call, is there anything else that must be done?
>>>Kerberos mailing list           Kerberos at
>>  Douglas E. Engert  <DEEngert at>
>>  Argonne National Laboratory
>>  9700 South Cass Avenue
>>  Argonne, Illinois  60439
>>  (630) 252-5444
>>Kerberos mailing list           Kerberos at
> ________________________________________________
> Kerberos mailing list           Kerberos at


  Douglas E. Engert  <DEEngert at>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

More information about the Kerberos mailing list