For Kerberos authentication with ssh (openssh 1:5.1p1-5) it seems to be necessary to add a servicePrincipalName host/fqdn@REALM to Samba4 (alph14), i.e. a lowercase variation of the existing HOST@fqdn@REALM to /etc/krb5.keytab. Following the thread "question about service principals (samba4)" on samba-technical, the /etc/krb5.keytab was copied from secrets.keytab.
The following shell code adds the SPN, maybe it would be good to add the lowercase version already during Samba4 provision.
ldbmodify -H /var/lib/samba/private/secrets.ldb \
-b "flatname=$windows_domain,cn=Primary Domains" <<%EOF
dn: flatname=$windows_domain,cn=Primary Domains
Created attachment 6217 [details]
Patch proposal for the secretsdb_self_join function in the provision module
Adding ldap/fqdn as well makes it possible to use 'ldapsearch -Y GSSAPI' with an openldap server (on a non-standard port on the same host).
(In reply to comment #2)
> Created an attachment (id=6217) [details]
> Patch proposal for the secretsdb_self_join function in the provision module
Well, but this is not AD compliant. AD only knows about an upcased "HOST". Probably we could workaround somehow to lowercase "HOST" on (our) the server side.
(In reply to comment #2)
> Adding ldap/fqdn as well makes it possible to use 'ldapsearch -Y GSSAPI' with
> an openldap server (on a non-standard port on the same host).
Under normal conditions you should already have the 'ldap/<FQDN>' service principal name present. It's added by the "samba_spnupdate" script, which is started by the "samba" executable. This has been implemented like this in order to have always the same SPNs regardless of a provision or domain join (which in fact are very different procedures).
The list of added SPNs to the DC can be customised, please look for the file "spn_update_list" under "source4/setup" in the source tree or "private" in the binary distribution.
I saw that list and see that by default it adds e.g.
to the machine account. But this entry (and the uppercase HOST/fqdn) was not sufficient to make the ldapsearch -Y GSSAPI (or ssh) work. In the test it only worked after adding this SPN to secrets.keytab by extending the secrets.ldb entry. What is the recommended way to configure this?
I hope that our kerberos expert (abartlet) comments.
Yes, we should have a clearly documented way to have Samba manage names in the system keytab.
You are correct that editing secrets.ldb is the right way to have Samba generate the required entries. There is also the krb5Keytab option that allows Samba to manage any filesystem path, not just the secrets.keytab.
You are also correct that it's not a matter of the AD rules, but what names other applications expect to read, and that's why this functionality was added in the first place, we just need to make it clear to administrators how to use it.
Andrew, should we leave that open?
Transforming this into a "Feature request".
I don't think it's a too good ideas to make secrets.ldb generate all the keytab entries we will ever need.
A way better solution would be to work on the ktpass.sh, I have patches here http://git.samba.org/?p=mat/samba.git;a=shortlog;h=refs/heads/pybindings for manipulating keytabs in python. I think it would be a better idea for provision to generate keytab like krb5.keytab with entries like host/dcname and such.
Just my point of view of course ...