AcceptSecurityContext (SSPI) fails with SEC_E_LOGON_DENIED and a GSS-API Linux client
Matthew M. DeLoera
mdeloera at exacq.com
Wed Jun 24 13:52:31 EDT 2009
Actually, my Windows service is running under the kerbsvr user account,
not the system account.....
Per your suggestion, I created a "kerbsvr/deloera.exacqlinux.org"
principal in my kdc, then imported "kerbsvr at deloera.exacqlinux.org" into
my gss_init_sec_context call. The server process was still running as
the kerbsvr user account. It worked.
I *really* appreciate your tip!
Can you or someone tell me what this means, then? FYI, my test service
can build and run in Windows (with SSPI) as well as Linux (via GSSAPI)
and is intended to be compatible with both AD and Linux KDCs. The Linux
version was extremely simple to get working, and it's super easy to
manage my keytab.
My understanding of Windows service security is much sketchier,
unfortunately. Since there's no keytab, my understanding is totally
empirical right now, and it's not easy to find good references on
"Kerberized Windows service". When working with AD, it works if I create
the SPN via ktpass, map it to the account as which the service will run,
then request that SPN in my client. So that leaves me with questions
about setspn vs. ktpass, host/deloera.exacqlinux.org vs.
myservice/deloera.exacqlinux.org, and as what account should a Windows
service run in which circumstances.
As for working with krb5-kdc, why did it work with the user principal
under which the service was running, instead of the generic host
principal? Is the host principal really an SPN, or something slightly
different, and am I misunderstanding things? As which Windows account
should I run my service?
Also, are there any good examples or guides that I should check out?
I've gotten this far by synthesizing a lot of different bits and pieces
here and there, but I'm still looking for good references to further
clarify all of this.
Thanks for the assistance!
Sam Hartman wrote:
> Is your server actually running as the system account?
> If so, then no idea.
> If not, then for the server name in gss_init_sec_context, please try
> importing the name of the account it is running as.
More information about the krbdev