AcceptSecurityContext (SSPI) fails with SEC_E_LOGON_DENIED anda GSS-API Linux client
Matthew M. DeLoera
mdeloera at exacq.com
Wed Jun 24 14:19:01 EDT 2009
(hopefully my last list posting didn't pop up twice....)
Ah, I see. I'll experiment with those notes. They leave me with 2
- 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.
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
More information about the krbdev