On acceptor credentials.

[Greg Hudson]

On 02/19/2014 10:19 PM, Prakash Narayanaswamy wrote:
> 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.

I cannot reproduce this behavior; in my tests, if a hostname is
specified in the desired_name field, it properly restricts which keytab
principals can be used.  Can you give more detail on what you are observing?

> (1) When can the above situation arise?

As far as I know, only if:

* You specify ignore_acceptor_hostname in krb5.conf, or

* You have entries for multiple principals in the keytab which share the
same key.  Because of service aliases, we generally ignore the principal
the initiator states that it is trying to authenticate to, and instead
just check whether we can decrypt the ticket with any key in the keytab
which matches the specified acceptor name.  See:
http://k5wiki.kerberos.org/wiki/Projects/Aliases

> (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?

Since a host-based GSSAPI name does not specify a Kerberos realm, it
does not restrict the realm of keytab entries which can be used to
decrypt the ticket.

> (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?

I don't believe you need a krb5.conf file for a GSS server application.