On acceptor credentials.

[Prakash Narayanaswamy]

Greg,

We relooked at our test setup and the 2 cases that you had cited in your
previous response for why the hostname is ignored does not apply to us --
We neither specify ignore_acceptor_hostname anywhere (we don't have
krb5.conf in the first place) nor do we have multiple principals in the
keytab with the same key.

(1) The hostname is, however, ignored.  I'll explain my setup below.
(2) We're unable to specify a desired name of the form cifs/
instance_name at FULLY.QUALIFIED.DOMAIN.NAME. The gss_acquire_cred fails with
the message *"No key table entry found matching
cifs/instance_name\@FULLY.QUALIFIED.DOMAIN.NAME@".*

While importing the name we use GSS_C_NT_HOSTBASED_SERVICE oid.

Our test setup:

(1) A user representing our SMB server is created in AD in the domain
MY.TEST.DOMAIN. It has 2 service principal names assigned, viz.,
cifs/server_name and cifs/bogus_name.
(2) Both the server_name and bogus_name resolve to the IP of our SMB server.
(3) The client is a Windows machine. We always do "klist purge" before
every experiment to clear the cached tickets.
 (4) On the SMB server side, on start up, we register the keytab, import
the name "cifs/server_name", acquire the creds and later use the creds in
the gss_accept_security_context calls.
(5) Doing a klist on the keytab at the server side shows the following and
only the following for the principal name:
cifs/server_name at MY.TEST.DOMAIN.There are of course multiple entries
for the 5 common encryption methods.

With this setup here is what I observe. Assume that the SMB share with the
name "my_share" exists.

*Case 1:*
Windows client domain: MY.TEST.DOMAIN
 > dir \\server_name\my_share
Works as expected.

*Case 2:*
Windows client domain: MY.TEST.DOMAIN
> dir \\bogus_name\my_share
Works. Not expected. Seems that the hostname part is ignored.

*Case 3:*
Windows client domain: MY_SECOND.TEST.DOMAIN
> dir \\server_name\my_share
Works. May be expected because I could not succeed specifying the realm
name while specifying the desired_name to gss_acquire_cred method.

*Case 4:*
Windows client domain: MY_SECOND.TEST.DOMAIN
> dir \\bogus_name\my_share
Works. But not expected for the same reason as Case 2.

We are using KRB 5 Release 1.12.1 with the patch that you gave us for the
bug at *http://krbdev.mit.edu/rt/Ticket/Display.html?id=7858
<http://krbdev.mit.edu/rt/Ticket/Display.html?id=7858>*

Can you please clarify?

Thanks a lot

Prakash N | 408 771 4273



On Wed, Feb 19, 2014 at 9:17 PM, Greg Hudson <ghudson at mit.edu> wrote:

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