Tworzenie keytabu do użycia z kinit w Windows

Question

Piszę wtyczkę pGina, aby uzyskać tagi AFS i TGT Kerberos z naszego KDC przy logowaniu, podczas gdy pisząc zauważyłem "cechę" kinit, że nie pozwoli ci to dostarczyć wejście, chyba że jest to z klawiatury, wpadł mi pomysł na przekierowanie standardowego wejścia ...

Ktoś zasugerował użycie pliku keytab dla zleceniodawcy, co wydawało się bardzo łatwe, dopóki nie zdałem sobie sprawy, że użyłem tylko Kutila na Linuksie i mam trudności z wersją Windows tego, co jest ktpass.exe. I wielokrotnie próbował z dużej liczby kombinacji argumentów stworzyć keytab ale mieli absolutnie żadnego sukcesu dotąd obecny komenda ja wydawanie jest:

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

Niestety to wszystko wyprowadza jest

Using legacy password setting method

FAIL: ldap_bind_s failed: 0x31

który według moich badań jest problem uwierzytelniania/krypto, próbowałem go z innymi D Ustawienia ES, ale to też nie działa ... Czy ktoś ma jakieś doświadczenie/pomysły na to, jak to może działać?

Answer 1

ktpass.exe jest rzeczywiście okropny; Nie używam tego. Zamiast tego, po prostu użyć ktutil na Unix stworzyć pasujący keytab niezależnie przy użyciu hasła, np .:

$ 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) 

Błąd wiążą LDAP wskazuje, że ktpass nie może uwierzytelnić do kontrolera domeny; jesteś zalogowany na konto domeny, gdy tak się dzieje? Musi to być konto domenowe, a nie lokalne (i musi być autoryzowane do dokonywania koniecznych zmian w AD, chociaż brakowało tylko tego, który dawałby błąd pozwolenia zamiast wiązania).

FWIW, podchodzimy do tego w inny sposób: wykorzystujemy zaufanie między dziedzinami między domenami Unix i AD. AD TGT, do którego użytkownik się loguje, jest wystarczający do uzyskania referencji dla usług w dziedzinie Unix; np. mogę użyć PuTTY do SSH do hosta Unix, Firefox/Chrome/IE do uwierzytelniania w usługach internetowych Unix (Apache/mod_auth_kerb), itp.