[35788] in Kerberos
Re: On acceptor credentials.
daemon@ATHENA.MIT.EDU (Greg Hudson)
Thu Feb 20 21:56:10 2014
Message-ID: <5306C03A.1010008@mit.edu>
Date: Thu, 20 Feb 2014 21:55:54 -0500
From: Greg Hudson <ghudson@mit.edu>
MIME-Version: 1.0
To: Prakash Narayanaswamy <prakash@nutanix.com>
In-Reply-To: <CANeUsQ8swVDM0ODrLcAFjwTSB-TiO3eHh=wmQ0T2Zsmr+Puojw@mail.gmail.com>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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@FULLY.QUALIFIED.DOMAIN.NAME
> <mailto:instance_name@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@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@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.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
