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

[Paul Moore]

lets get a few basics

a) the gss app runs as some account as far as windows is concerned. 
This has to be an account that exists in AD (since that where all MS
kerberosness flows from)

b) the machine itself has an account in AD
Its called <machinename>$ and is created when the machine joins the
domain

c) Service principal names are associated with AD accounts
you can have several SPNs associated with one account. If you look at
the machine's account you will see
it has several SPNs (host/<machine>, host/<machine>.acme.com, ...)

SO what does this mean

well you could create an account called foo, add an SPN to it called
bar/wizbang, logon as foo and run the server at a command prompt. This
works fine (if you tell the client to target the bar/wizbang spn), but
lacks a little in convenience

{Note - you cannot target an account the does not have an SPN set on it.
Even if the client was to set the target to 'foo' it would fail - AD
wont let you do it}

You really need to run the server as a service. When you run as a
service you have to say what account it runs under. You have 2 choices
1) run as the machine
2) run as somebody else

1 is very convenient because you don't have to create a special account,
nor do you have to enter its password. 
But it is suggested by many that this breaks the least privilege
concept; you are running as Windows version of 'root', this lays you
open to all sorts of potential hacks if your code isnt 100% safe.
Also you dont have to add SPNs to the machine account - its already got
them

2 is safe. Run as account with the bare minimum of rights. But you have
to enter the password in the service UI and either
- stop the password from being forcibly changed (not secure)
- change the password regularly and remember to update the service
settings
And you must add SPNs


-----Original Message-----
From: Matthew M. DeLoera [mailto:mdeloera at exacq.com] 
Sent: Wednesday, June 24, 2009 11:19 AM
To: krbdev at mit.edu
Subject: Re: AcceptSecurityContext (SSPI) fails with SEC_E_LOGON_DENIED
anda GSS-API Linux client

Paul,

(hopefully my last list posting didn't pop up twice....)

Ah, I see. I'll experiment with those notes. They leave me with 2 
offhand questions:

- Are there any conventions surrounding using a host principal versus a 
more custom user principal? Would it be preferable to run as the system 
account so that I can use the host principal, or preferable to create 
some service accounts in order to specify something custom like 
"myservice/<machine name>"? Or is it just whatever I feel like?

- Is the reverse question true? If I want to specify a custom service 
class, must I have a corresponding account? If so, could I just use the 
same class name on each server that run my service?

FYI, I don't intend to run my service on domain controllers. I intend 
for the kdc to be external to all systems running my service.

Regards,
- Matthew


Paul Moore wrote:
> a service has access to the 'keytab' for its own account. SO the
service
> running under kerbsvr account has no access to the 'keytab' that
belongs
> to the system account (the one that belongs to the machine); you were
> trying to authenticate to the system account (host/<machine name>)
>
> Also another thing to remeber is that you need to have the right
'allow
> access from the network ' right set for the on the server machine.
> For regular server and client machines this is OK, but for Domain
> Controllers it is not; DC have this set to a restricted list of
> accounts.
>
>