Folks, 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. This observation seems to violate the following passage on Acceptor names at http://web.mit.edu/kerberos/krb5-devel/doc/appdev/gssapi.html
If a server wishes to specify a desired_name to gss_acquire_cred<http://tools.ietf.org/html/rfc2744.html#section-5.2>, the most common choice is a host-based name. If the host-based desired_name contains just a service, then clients will be allowed to authenticate to any host-based service principal (that is, a principal of the form service/hostname@REALM) for the named service, regardless of hostname or realm, as long as it is present in the default keytab. *If the input name contains both a **service and a hostname, clients will be allowed to authenticate to any host-based principal for the named service and hostname, regardless of realm.* To questions now: (1) When can the above situation arise? (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? (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? Thanks a lot, Prakash Prakash N | 408 771 4273 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
