On acceptor credentials.
Prakash Narayanaswamy
prakash at nutanix.com
Wed Feb 19 22:19:25 EST 2014
Folks,
While testing the kerberized SMB server, we observed the following: Even if
the *gss_acquire_cred* method is passed *both* the service name and host
name in the form *service at hostname* for the *desired_name* parameter, the
hostname part is ignored during authentication. This observation seems to
violate the following passage on Acceptor names at
http://web.mit.edu/kerberos/krb5-devel/doc/appdev/gssapi.html
If a server wishes to specify a desired_name to
gss_acquire_cred<http://tools.ietf.org/html/rfc2744.html#section-5.2>,
the most common choice is a host-based name. If the host-based
desired_name contains
just a service, then clients will be allowed to authenticate to any
host-based service principal (that is, a principal of the form
service/hostname at REALM) for the named service, regardless of hostname or
realm, as long as it is present in the default keytab. *If the input name
contains both a **service and a hostname, clients will be allowed to
authenticate to any host-based principal for the named service and
hostname, regardless of realm.*
To questions now:
(1) When can the above situation arise?
(2) When we don't enable AES-128/AES-256 encryption in the Windows 2012 AD
for the user account representing our SMB server (with proper SPN set) in
the AD domain, we observe that even the domain name/realm name part is
ignored during authentication. Is this expected?
(3) We don't see any need for the krb5.conf file on the Linux machine that
runs our SMB server. We register the keytab file using
*krb5_gss_register_acceptor_identity
*method*. *Do we really need the krb5.conf file? What do I lose by not
having the krb5.conf in our setup?
Thanks a lot,
Prakash
Prakash N | 408 771 4273
More information about the Kerberos
mailing list