Creazione di un keytab da utilizzare con kinit in Windows

Question

Sto scrivendo un plugin pGina per ottenere token AFS e un Kerberos TGT dal nostro KDC al momento dell'accesso, mentre scrivendo ho notato una 'caratteristica' di kinit che non consente di fornire alcun ingresso a meno che la sua dalla tastiera, c'è andato la mia idea di appena reindirizzare l'input standard ...

qualcuno ha suggerito di utilizzare un file keytab per il principale, che sembrava super facile, fino a quando mi sono reso conto che avevo usato solo Kutil su linux e sto avendo difficoltà con la versione di Windows di ciò che è ktpass.exe. Ho provato più volte con un gran numero di combinazioni di argomenti per creare un keytab, ma ho avuto assolutamente nessun successo finora, il comando corrente che sto emittente è quello:

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

Purtroppo tutto questo uscite è

Using legacy password setting method

FAIL: ldap_bind_s failed: 0x31

che secondo la mia ricerca è un problema di autenticazione/crittografia, ho provato con l'altra D Le impostazioni ES, ma anche questo non sembra funzionare ... qualcuno ha qualche esperienza/idee su come questo potrebbe funzionare?

Answer 1

ktpass.exe è davvero terribile; Io non lo uso Invece, basta usare ktutil su Unix per creare un abbinamento keytab in modo indipendente utilizzando la password, ad es .:

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

L'errore binding LDAP indica che Ktpass non è possibile autenticare al controller di dominio; sei loggato in un account di dominio quando questo accade? Deve essere un account di dominio, piuttosto che locale (e deve essere autorizzato ad apportare le modifiche necessarie ad AD, sebbene manchino solo a ciò darebbe un errore di autorizzazione piuttosto che un vincolo).

FWIW, adottiamo un approccio diverso: utilizziamo il trust cross-realm tra i nostri domini Unix e AD. Il TGT AD che l'utente ottiene al momento del login è quindi sufficiente per acquisire credenziali anche per i servizi nel regno Unix; Ad esempio, posso usare PuTTY in SSH in un host Unix, Firefox/Chrome/IE per autenticare i servizi Web Unix (Apache/mod_auth_kerb), ecc.