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

[Matthew M. DeLoera]

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