К сожалению, пока не нашел решения этой проблемы, но что-то подобное работает на моем компьютере сейчас. Чтобы заставить NSLCD работать с использованием GSSAPI, я выполнил эти команды на стороне сервера:

#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

Каждый участник безопасности ( nslcd ) назначен машине ( bolbro.barbucha. local ), а служба, использующая это SPN, аутентифицируется как пользователь ( ldap-connect ). Всегда может быть только один участник безопасности <служба> / <машина> . Вы не можете снова создать nslcd / bolbro.barbucha.local и назначить его другому пользователю. Участник безопасности host / bolbro.barbucha.local уже существует. Сегодня я думаю, что может быть достаточно просто экспортировать ключевую таблицу пользователя, которому назначен критический SPN.

Посмотрим…

Heuréka!

Я нашел решение сегодня (2014-03 -02). Да, это действительно так. Я сделал следующие шаги:

• присоединил клиента к домену: net ads join -U administrator , где net - одна из утилит Samba
• , не входящих в состав / etc / ssh / sshd_config на стороне сервера и / etc / ssh / ssh_config на стороне клиента строка GSSAPIAАутентификация нет и вместо нет используется да ; включен аналогично GSSAPIDelegateCredentials на стороне клиента
• выполняется с обеих сторон команда net ads keytab create для экспорта необходимых ключей в /etc/krb5.keytab
• ] добавил полное имя сервера в / etc / hosts на стороне сервера

Я не знаю почему, но когда я выполнил sshd на стороне сервера в режиме отладки ( / usr / sbin / sshd -d ), я увидел сообщение, что не найдено записи в таблице ключей, соответствующей хосту /bolbro @ . Ожидаемое имя сервера (указанное в klist -k /etc/krb5.keytab на стороне сервера) - bolbro.barbucha.local . Добавление IP-адреса и полного имени сервера bolbro.barbucha.local в / etc / hosts решило проблему.