GSS API and impersonate client in the server
mattias.karlsson at sungard.com
Mon Nov 1 10:15:14 EST 2004
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
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
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
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/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
More information about the Kerberos