Шпаклюйте аутентификацию Kerberos/GSSAPI
Я настроил несколько серверов Linux для аутентификации с Active Directory Kerberos с помощью sssd на RHEL6. Я также включил аутентификацию GSSAPI в надежде на логины без пароля.
Но я, может казаться, не заставляю Шпаклевку (0.63) проходить проверку подлинности без пароля.
GSSAPI работает между системами Linux (openSSH клиент), которые настроены для AD аутентификации, с помощью .ssh/config настроек для включения GSSAPI.
Это также работает от Cygwin (openSSH клиент), с помощью тех же .ssh/config настроек, а также выполняя команду kinit для получения билета.
Также Samba совместно использует во всех системах Linux, включая работу корневых каталогов от Windows Explorer, не требуя пароля (я не уверен, играет ли GSSAPI роль там),
Какие вещи я могу попытаться диагностировать это? Большинство моих пользователей использует Шпаклевку. Кроме того, я не Windows Admin, таким образом, я ничего не могу сделать на контроллерах домена. Моя учетная запись только имеет полномочия добавить серверы к 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 Connection | 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 вместо Mi Crosoft SSPI one,и все должно работать. Если запущен «MIT Kerberos Ticket Manager», он автоматически запросит у вас пароль Kerberos, когда PuTTY потребуется билет, поэтому рекомендуется связать его из папки автозагрузки.
Проблема была в настройке Windows Kerberos. Я думаю, что наша Active Directory настроена напуганно, я не знаю, что я не администратор Windows.
Но я решил проблему, вручную настроив Kerberos с помощью ksetup в Windows 7. CLI.
После перезагрузки на удаленную рабочую станцию я не мог войти в свой компьютер. Это связано с тем, что в исходной конфигурации часть TLD моего домена области всегда отсутствовала (домен \ пользователь), но после того, как я вручную настроил ее, мне пришлось изменить свой домен входа, чтобы отразить полное имя домена области (domain.TLD \ user) и Мне удалось войти в систему на моем ПК с Windows, хотя, похоже, теперь для аутентификации требуется больше времени.
До изменений вывод ksetup показывал только мою область по умолчанию, и это было в нижнем регистре.
Я использовал "nslookup -type = SRV _kerberos._tcp.domain.TLD", чтобы получить все серверы kdc для моей области.
Я не устанавливал никаких флагов.
Я установил сопоставленное имя пользователя "ksetup / mapuser (скрытый) пользователь "
Ресурсы, которые я использовал: 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, как они могут это исправить (это не работает?), Я передам их.
Сначала дважды проверьте, что ваш вывод klist в окне Windows, на котором запущен PuTTY, показывает действительный TGT. Затем в конфигурации сеанса PuTTY убедитесь, что Попытка аутентификации GSSAPI включена в Соединение - SSH - Auth - GSSAPI . Наконец, убедитесь, что он настроен на автоматический вход с вашим именем пользователя в Соединение - Данные . Вы можете либо явно указать имя пользователя, либо выбрать переключатель для Использовать системное имя пользователя .
Исторически это все, что мне нужно было сделать, чтобы беспарольный вход по SSH работал через Kerberos.