AcceptSecurityContext (SSPI) fails with SEC_E_LOGON_DENIED and a GSS-API Linux client

[Matthew M. DeLoera]

Sam,

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!

Regards,
- Matthew


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