On acceptor credentials.

[Greg Hudson]

On 02/20/2014 08:28 PM, Prakash Narayanaswamy wrote:
> (2) We're unable to specify a desired name of the form
> cifs/instance_name at FULLY.QUALIFIED.DOMAIN.NAME
> <mailto: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@"./

GSS host-based names are of the form "service" or "service at host".  You
cannot specify a realm, and '/' is not a separator.  If you want to
import a Kerberos principal name, use GSS_KRB5_NT_PRINCIPAL_NAME.

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

I believe in this setup, cifs/server_name and cifs/bogus_name will have
the same keys.

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

You're importing cifs/server_name as a host-based name?  I would expect
that to fail with "No key table entry found matching cifs\/server_name/@".

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

If those are the only keys present in the keytab, then there is no way
that any other keys could be used to decrypt the ticket.  So I think
case 2 is succeeding because cifs/bogus_name has the same keys as
cifs/server_name, and cases 3 and 4 are succeeding because the client is
cross-realm authenticating to MY.TEST.DOMAIN.