2

I've a question to Samba 4 and Kerberos. I've had a functional SSH with SSO. But now when I've installed Samba 4 it doesn't work and it seems, that nobody has found any solution yet. I just read, that it was really difficult and complicated or On Windows all works fine, but on Linux I've no success yet and so on.

The problem is, that Samba 4 implements Kerberos differently. And it seems to be somehow incompatible with Linux tools like SSH. When I run sshd in debug mode, I see, that it writes:

debug1: Unspecified GSS failure.  Minor code may provide more information
No key table entry found matching host/bolbro.barbucha.local@

But I'm not able to add such principal to Samba principal database. (Although it does not exist, the samba-tool spn add writes, that it is affected by another user.)

My post may sound confusedly, but I've to say, that I don't exactly understand yet, what's the matter and may use in my text some terms wrong. Do you anybody have any expirience with Samba 4 and SSH client working without password? Have you ever succeeded at Samba 4 and SSO on Linux client?

Thanks a lot for any hint or explanation. (I'm using Debian Squeeze, Bolbro is the machine, the Samba 4 and SSHD runs on. The same problem affects the ksu as well.)

Theodor Keinstein
  • 181
  • 1
  • 11

1 Answers1

2

Regrettably haven't found the solution of this problem yet, but something similar works on my computer now. To get NSLCD to work using GSSAPI, I made these commands on the server side:

#create an user with a random password
samba-tool user add --random-password ldap-connect
#the password must not expire
samba-tool user setexpiry --noexpiry ldap-connect
#create a SPN (security principal name)
samba-tool spn add nslcd/bolbro.barbucha.local ldap-connect
#export key table of the user ldap-connect
samba-tool domain exportkeytab krb5.nslcd.keytab --principal=ldap-connect

Each security principal (nslcd) is assigned to a machine (bolbro.barbucha.local) and the service using this SPN is authenticated as an user (ldap-connect). There can be always just one security principal <service>/<machine>. You cannot create nslcd/bolbro.barbucha.local again and assign it to some other user. The security principal host/bolbro.barbucha.local already exists. I thing today, that it may suffice to just export the key table of the user, the critical SPN is assigned to.

We'll see…

Heuréka!

I found the solution today (2014-03-02). Yes, it is really so. I made these steps:

  • joined the client to the domain: net ads join -U administrator, where net is one of Samba utilities
  • uncomented within /etc/ssh/sshd_config on server side and /etc/ssh/ssh_config on client side the line GSSAPIAuthentication no and overwrote no with yes; enabled similarly GSSAPIDelegateCredentials on the client side
  • executed on both sides command net ads keytab create in order to export the needed keys into /etc/krb5.keytab
  • added fully qualified server name into /etc/hosts on the server side

I don't know why, but when I executed sshd on the server side in debug-mode (/usr/sbin/sshd -d), I saw a message, that there is no key table entry found matching host/bolbro@. The expected server name (listed by klist -k /etc/krb5.keytab on the server side) is bolbro.barbucha.local. To append the server's IP-address and fully qualified name bolbro.barbucha.local to /etc/hosts solved the problem.

Community
  • 1
Theodor Keinstein
  • 181
  • 1
  • 11