On 02/20/2014 08:28 PM, Prakash Narayanaswamy wrote: > (2) We're unable to specify a desired name of the form > cifs/instance_n...@fully.qualified.domain.name > <mailto:instance_n...@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_n...@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
