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/ [email protected]. 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/[email protected] 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 <[email protected]> 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@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. > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
