2012-06-07 9 views
5

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 ...Tworzenie keytabu do użycia z kinit w Windows

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 [email protected] /princ [email protected] /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ć?

+0

DES jest domyślnie wyłączony w Windows 2008 R2 Active Directory i nowszych. To mógł być problem na tym konkretnym froncie, kiedy próbowałeś. –

Odpowiedz

8

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 [email protected] -k 1 -e aes128-cts-hmac-sha1-96 
Password for [email protected]: 
ktutil: l 
slot KVNO Principal 
---- ---- --------------------------------------------------------------------- 
    1 1         [email protected] 
ktutil: wkt /tmp/zz 
$ klist -ek /tmp/zz 
Keytab name: WRFILE:/tmp/zz 
KVNO Principal 
---- -------------------------------------------------------------------------- 
    1 [email protected] (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.

+0

Podczas korzystania z zaufania krzyżowego nakładasz nazwy DNS systemu UNIX i WINDOWS lub czy masz skonfigurowaną subdomenę, aby zamknąć hosty systemu UNIX? –

+1

Nasze nakładają się; to znaczy, nie ma prostej reguły, która mogłaby rozróżnić nazwy hostów w dwóch domenach. Zalecam jednak stosowanie dla każdej z nich nienakładających się domen, jeśli jest to wykonalne, np. * .WIN.FOO.COM i * .UNIX.FOO.COM; nasza mieszana konfiguracja jest wynikiem starszej infrastruktury, której teraz nie możemy zmienić. Konfiguracja mieszana wymaga dużej złożoności w postaci skierowań i/lub statycznej konfiguracji domeny/obszaru po obu stronach, w celu zapewnienia, że ​​wszystkie wnioski o bilet trafiają we właściwe miejsce. Ostatnio użyłem różnych domen w zupełnie nowym wdrożeniu, aby tego uniknąć. –