Система Windows 7 не будет общаться с сервером MIT Kerberos

Я установил 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 для аутентификации!

Источник

1 ответ

Решение

Я обнаружил, что если я введу полное имя пользователя 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,

Источник
Другие вопросы по тегам