Я установил MIT Kerberos 1.10 на сервер Debian и, к счастью, мои клиенты Debian аутентифицируются с его помощью. Однако у меня возникли проблемы с тем, чтобы мой компьютер с Windows 7 делал то же самое.
Я использовал ksetup настроить машину следующим образом:
default realm = EXAMPLE.COM (external)
EXAMPLE.COM:
(no kdc entries for this realm)
Realm Flags = 0x5 SendAddress Delegate
Mapping all users (*) to a local account by the same name (*).
Это также изменило имя системы и настройки рабочей группы:
Computer name: lysander
Full computer name: lysander.EXAMPLE.COM
Workgroup EXAMPLE.COM
Согласно документации, если для области нет KDC или паролей, Windows будет использовать DNS, поэтому у меня также настроены следующие записи:
_kerberos._udp.example.com. 300 SRV 10 100 88 kdc.example.com.
_kerberos-adm._tcp.example.com. 300 SRV 10 100 749 kdc.example.com.
kdc имеет запись A, указывающую на IP-адрес сервера.
После настройки системы Windows я перезагрузил ее и попытался войти в систему, отметив, что экран входа в систему предлагал мне войти в систему. EXAMPLE домен. Однако, когда я пытаюсь войти в систему как локальный пользователь sam, который должен быть сопоставлен sam@EXAMPLE.COM, после короткой паузы мне сообщили, что нет доступных серверов входа в систему для обслуживания запроса входа в систему. Я не вижу ничего значимого в журнале событий Windows, и, проверив сетевой трафик между клиентом и сервером, я даже не вижу, что машина Windows пытается связаться с KDC.
Однако это не все плохие новости. Что вселяет в меня надежду, так это то, что я могу использовать runas чтобы получить TGT:
>runas /user:sam@EXAMPLE.COM cmd
Enter the password for sam@EXAMPLE.COM:
Attempting to start cmd as user "sam@EXAMPLE.COM" ...
И в появившемся новом окне:
>klist
Current LogonId is 0:0x14e6649
Cached Tickets: (1)
#0> Client: sam @ EXAMPLE.COM
Server: krbtgt/EXAMPLE.COM @ EXAMPLE.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
Start Time: 2/14/2012 11:54:24 (local)
End Time: 2/14/2012 21:54:24 (local)
Renew Time: 2/21/2012 11:54:24 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Если я затем запустил PuTTY из этой командной строки, я смогу подключиться по ssh к другим серверам, используя SSPI для аутентификации, и все будет в порядке!
Я обнаружил, что если я введу полное имя пользователя sam@EXAMPLE.COM на экране Windows вход в систему работает нормально; sam или EXAMPLE\sam не режьте горчицу. Я не могу найти ничего, подтверждающего, что это ожидаемое поведение, но оно согласуется с внимательным чтением вывода ksetup:
Mapping all users (*) to a local account by the same name (*).
то есть, если вы войдете в систему как sam@EXAMPLE.COM затем локальная учетная запись sam будет авторизован; это не означает, что вы можете войти как sam и система аутентифицирует вас с помощью KDC как sam@EXAMPLE.COM.