Создание keytab для использования с kinit в Windows

Question

Я пишу плагин pGina, чтобы получить токены AFS и Kerberos TGT из нашего KDC при входе в систему, при этом я заметил, что функция «kinit» заключается в том, что она не позволит вам предоставлять какие-либо вход, если он не был с клавиатуры, мне показалось, что я просто перенаправляю стандартный ввод ...

Кто-то предложил использовать файл keytab для принципала, который казался очень простым, пока я не понял, что использовал только kutil on linux и у меня возникают трудности с версией Windows, которая является ktpass.exe. Я неоднократно пытался с большим количеством комбинаций аргументов для создания Keytab, но не было абсолютно никакого успеха до сих пор, текущая команда Я выдачи является:

ktpass /out key.tab /mapuser user$@MERP.EDU /princ user.merp.edu@MERP.EDU /crypto RC4-HMAC-NT /ptype KRB5_NT_PRINCIPAL /pass mahpasswordlol /target MERP.EDU

К сожалению, все это выводит это

Using legacy password setting method

FAIL: ldap_bind_s failed: 0x31

Который согласно моим исследованиям является проблема аутентификации/шифрования, я пытался сделать это с другой D ES, но это тоже не работает ... у кого-нибудь есть опыт/идеи о том, как это может работать?

Answer 1

ktpass.exe действительно ужасно; Я не использую его. Вместо этого, просто использовать ktutil на Unix, чтобы создать соответствующий Keytab самостоятельно, используя пароль, например .:

$ ktutil 
ktutil: addent -password -p foo@BAR -k 1 -e aes128-cts-hmac-sha1-96 
Password for foo@BAR: 
ktutil: l 
slot KVNO Principal 
---- ---- --------------------------------------------------------------------- 
    1 1         foo@BAR 
ktutil: wkt /tmp/zz 
$ klist -ek /tmp/zz 
Keytab name: WRFILE:/tmp/zz 
KVNO Principal 
---- -------------------------------------------------------------------------- 
    1 foo@BAR (aes128-cts-hmac-sha1-96) 

Ошибка LDAP привязки указывает, что Ktpass не может аутентификации в контроллере домена; вы вошли в учетную запись домена, когда это произойдет? Это должна быть учетная запись домена, а не локальная (и она должна быть уполномочена внести необходимые изменения в AD, хотя не хватает именно этого, чтобы дать ошибку разрешения, а не связывать).

FWIW, мы придерживаемся другого подхода к этому: мы используем доверие между сферами между нашими областями Unix и AD. AD TGT, который пользователь получает при входе в систему, достаточен для получения учетных данных для служб в области Unix; например, я могу использовать PuTTY для SSH в хосте Unix, Firefox/Chrome/IE для аутентификации в веб-службах Unix (Apache/mod_auth_kerb) и т. д.