Putty Kerberos / GSSAPI аутентификация

Я настроил несколько серверов Linux для аутентификации в Active Directory Kerberos, используя sssd на RHEL6. Я также включил аутентификацию GSSAPI в надежде на вход без пароля.

Но я не могу заставить Putty (0.63) аутентифицироваться без пароля.

GSSAPI работает между системами Linux (клиент openSSH), которые настроены для аутентификации AD, используя параметры .ssh / config для включения GSSAPI.

Он также работает из Cygwin (клиент openSSH), используя те же настройки .ssh / config и команду kinit для получения заявки.

Также Samba использует все системы Linux, в том числе домашние каталоги, работающие из Windows Explorer, без пароля (я не уверен, что GSSAPI вступит в игру)

Какие вещи я могу попытаться устранить это? Большинство моих пользователей используют Putty. Кроме того, я не администратор Windows, поэтому я ничего не могу сделать на контроллерах домена. Моя учетная запись имеет только права на добавление серверов в домен AD.

Я включил ведение журнала пакетов SSH замазки. Я нашел это интересным, но я не уверен, что делать с этой информацией:

Event Log: Server version: SSH-2.0-OpenSSH_5.3
Event Log: Using SSH protocol version 2
Event Log: We claim version: SSH-2.0-PuTTY_Release_0.63
Outgoing packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
Incoming packet #0x0, type 20 / 0x14 (SSH2_MSG_KEXINIT)
Event Log: Doing Diffie-Hellman group exchange
Outgoing packet #0x1, type 30 / 0x1e (SSH2_MSG_KEX_DH_GEX_REQUEST)
Incoming packet #0x1, type 31 / 0x1f (SSH2_MSG_KEX_DH_GEX_GROUP)
Event Log: Doing Diffie-Hellman key exchange with hash SHA-256
Outgoing packet #0x2, type 32 / 0x20 (SSH2_MSG_KEX_DH_GEX_INIT)
Incoming packet #0x2, type 33 / 0x21 (SSH2_MSG_KEX_DH_GEX_REPLY)
Outgoing packet #0x3, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR client->server encryption
Event Log: Initialised HMAC-SHA1 client->server MAC algorithm
Outgoing raw data at 2014-11-25 00:21:08
Incoming packet #0x3, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Initialised AES-256 SDCTR server->client encryption
Event Log: Initialised HMAC-SHA1 server->client MAC algorithm
Outgoing packet #0x4, type 5 / 0x05 (SSH2_MSG_SERVICE_REQUEST)
Incoming packet #0x6, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
...%gssapi-keyex
,gssapi-with-mic
,password.
Event Log: Using SSPI from SECUR32.DLL
Event Log: Attempting GSSAPI authentication
Outgoing packet #0x6, type 50 / 0x32 (SSH2_MSG_USERAUTH_REQUEST)
Incoming packet #0x7, type 60 / 0x3c (SSH2_MSG_USERAUTH_GSSAPI_RESPONSE)
Event Log: GSSAPI authentication initialised
Outgoing packet #0x7, type 61 / 0x3d (SSH2_MSG_USERAUTH_GSSAPI_TOKEN)
Incoming packet #0x8, type 61 / 0x3d (SSH2_MSG_USERAUTH_GSSAPI_TOKEN)
Event Log: GSSAPI authentication initialised
Event Log: GSSAPI authentication loop finished OK
Outgoing packet #0x8, type 66 / 0x42 (SSH2_MSG_USERAUTH_GSSAPI_MIC)
Incoming packet #0x9, type 51 / 0x33 (SSH2_MSG_USERAUTH_FAILURE)
...%gssapi-keyex
,gssapi-with-mic
,password.

На компьютерах с Windows, которые являются частью домена Active Directory, пользователи получают свой билет на выдачу билетов Kerberos при входе в Windows, и PuTTY может использовать его для аутентификации, если аутентификация GSSAPI включена в соединении конфигурации PuTTY | SSH | Auth | GSSAPI (и другие методы аутентификации, которые он использует перед GSSAPI, такие как открытый ключ через Pageant, не устанавливаются и не отключаются в Connection | SSH | Auth).

[Если вам также необходимо делегирование билетов (например, для монтирования керберизованных файловых систем на сервере после входа в систему), убедитесь, что делегирование GSSAPI также включено в PuTTY, а серверы, на которые вы входите, помечены в Active Directory на вкладке Делегирование как « Доверяйте этот компьютер для делегирования какой-либо службе (только Kerberos) », которой они не являются по умолчанию. Эта последняя настройка доверия в AD, как ни странно, необходима только для делегирования для работы с клиентами Windows, такими как PuTTY; он не нужен для клиентов Linux "ssh -K".]

На самоуправляемых (личных) компьютерах Windows, которые не являются частью домена Active Directory, вы все равно можете использовать аутентификацию Kerberos / GSSAPI (и делегирование билетов) через PuTTY, но вы должны получить билет самостоятельно. К сожалению, Windows 7 не поставляется с каким-либо эквивалентом программы kinit (чтобы вы вручную запрашивали билет), и PuTTY также не запрашивает ваш пароль Kerberos, если у вас нет билета. Таким образом, вы должны установить MIT Kerberos для Windowsпакет, который включает в себя как обычные инструменты командной строки kinit / klist / kdestroy, так и аккуратный инструмент с графическим интерфейсом «MIT Kerberos Ticket Manager». Используйте их, чтобы получить билет, и тогда PuTTY автоматически использует библиотеку MIT GSSAPI вместо библиотеки Microsoft SSPI, и все должно работать. Если запущен «MIT Kerberos Ticket Manager», он автоматически запросит у вас пароль Kerberos, когда PuTTY понадобится билет, поэтому рекомендуется связать его из папки «Автозагрузка».

Сначала дважды проверьте, что ваш вывод klist в окне Windows, на котором запущен PuTTY, показывает допустимый TGT. Затем в конфигурации для вашего сеанса PuTTY убедитесь, что включена попытка аутентификации GSSAPIConnection - SSH - Auth - GSSAPI . Наконец, убедитесь, что он настроен на автоматический вход в систему с вашим именем пользователя Connection - Data. Вы можете явно указать имя пользователя или выбрать переключатель Использовать системное имя пользователя .

Исторически это все, что мне нужно было сделать, чтобы беспарольный вход в SSH работал через Kerberos.

Проблема была в настройке Windows Kerberos. Я думаю, что наш Active Directory настроен в стиле фанк, я действительно не знаю, что я не администратор Windows.

Но я исправил проблему, настроив Kerberos вручную с помощью ksetup в CLI Windows 7.

После перезагрузки на удаленную рабочую станцию ​​я не смог войти на свой ПК. Это связано с тем, что в исходной конфигурации часть TLD моего домена realm всегда отсутствовала (домен \ пользователь), но после того, как я настроил ее вручную, мне пришлось изменить свой домен для входа в систему, чтобы он отражал полное имя домена области (domain.TLD \ user) и Я смог войти в систему на моем ПК с Windows, хотя теперь для аутентификации требуется больше времени.

До изменений вывод ksetup показывал только мою область по умолчанию, и это было в нижнем регистре.

Я использовал "nslookup -type = SRV _kerberos._tcp.domain.TLD", чтобы получить все серверы KDC для моей области.

Я не установил никаких флагов.

Я установил на карту свое имя пользователя "ksetup / mapuser user@domain.TLD user"

Ресурсы, которые я использовал: https://wiki.ncsa.illinois.edu/display/ITS/Windows+7+Kerberos+Login+using+External+Kerberos+KDC

https://www.cgl.ucsf.edu/Security/CGLAUTH/CGLAUTH.html

Если у кого-то есть какие-либо предложения, которые я могу дать администраторам Windows, как они могут это исправить (это сломано?), Я передам это.