GSS API and impersonate client in the server

[Mattias Karlsson]

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")?

Thanks
Mattias

deengert at anl.gov ("Douglas E. Engert") wrote in message news:<417014E6.5010308 at anl.gov>...
> 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:
> > Hi
> > 
> > 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?
> > 
> > Thanks
> > Mattias
> > ________________________________________________
> > Kerberos mailing list           Kerberos at mit.edu
> > https://mailman-mit-edu.ezproxyberklee.flo.org/mailman/listinfo/kerberos
> > 
> > 
> > 
>  
> -- 
> 
>   Douglas E. Engert  <DEEngert at anl.gov>
>   Argonne National Laboratory
>   9700 South Cass Avenue
>   Argonne, Illinois  60439
>   (630) 252-5444
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman-mit-edu.ezproxyberklee.flo.org/mailman/listinfo/kerberos