Autenticazione Putty Kerberos / GSSAPI

Ho configurato alcuni server Linux per l'autenticazione con Active Directory Kerberos usando sssd su RHEL6. Ho anche abilitato l'autenticazione GSSAPI nella speranza di accessi senza password.

Ma non riesco a convincere Putty (0.63) ad autenticarsi senza una password.

GSSAPI funziona tra sistemi Linux (client openSSH) configurati per l'autenticazione AD, utilizzando le impostazioni .ssh / config per abilitare GSSAPI.

Funziona anche da Cygwin (client openSSH), usando le stesse impostazioni .ssh / config ed eseguendo il comando kinit per ottenere un ticket.

Anche le condivisioni Samba su tutti i sistemi Linux, comprese le home directory, funzionano da Windows Explorer senza richiedere una password (non sono sicuro che GSSAPI entri in gioco lì)

Che tipo di cose posso provare a risolvere questo problema? La maggior parte dei miei utenti usa Putty. Inoltre, non sono un amministratore di Windows, quindi non posso fare nulla sui controller di dominio. Il mio account ha solo i privilegi per aggiungere server al dominio AD.

Ho attivato la registrazione dei pacchetti SSH putty. Ho trovato questo tipo di interessante, non sono ancora sicuro di cosa fare con queste informazioni:

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.

Su macchine Windows che fanno parte di un dominio Active Directory, gli utenti ricevono il loro ticket di concessione ticket Kerberos quando accedono a Windows e PuTTY è in grado di utilizzarlo per l'autenticazione se l'autenticazione GSSAPI è abilitata in Connessione configurazione PuTTY | SSH | Auth | GSSAPI (e altri metodi di autenticazione che tenta prima di GSSAPI, come chiave pubblica tramite Pageant, non sono impostati o disabilitati in Connection | SSH | Auth).

[Se è necessaria anche la delega dei ticket (ad es. Per montare i file system kerberized sul server dopo l'accesso), assicurarsi che anche la delega GSSAPI sia abilitata in PuTTY e che i server a cui si accede siano contrassegnati in Active Directory nella scheda Delega come " Affida questo computer per la delega a qualsiasi servizio (solo Kerberos) ", che non sono predefiniti. Quest'ultima impostazione di trust in AD è stranamente necessaria solo perché la delega funzioni da client Windows come PuTTY; non è necessario per i client Linux "ssh -K".]

Su macchine Windows autogestite (personali) che non fanno parte di un dominio di Active Directory, è comunque possibile utilizzare l'autenticazione Kerberos / GSSAPI (e la delega dei ticket) tramite PuTTY, ma è necessario ottenere il biglietto da soli. Sfortunatamente, Windows 7 non viene installato con alcun equivalente del programma kinit (per richiedere manualmente un ticket) e PuTTY non richiede nemmeno la password Kerberos se non si dispone di un ticket. Pertanto, è necessario installare MIT Kerberos per Windowspacchetto, che include sia i soliti strumenti da riga di comando kinit / klist / kdestroy, sia uno strumento GUI "MIT Kerberos Ticket Manager". Usa quelli per ottenere il tuo biglietto, quindi PuTTY utilizzerà automaticamente la libreria MIT GSSAPI invece di quella di Microsoft SSPI, e dovrebbe funzionare tutto. Se "MIT Kerberos Ticket Manager" è in esecuzione, ti chiederà automaticamente la password Kerberos quando PuTTY ha bisogno di un ticket, quindi è una buona idea collegarlo dalla cartella Startup.

Per prima cosa controlla che l'output della tua lista sulla casella di Windows che esegue PuTTY mostri un TGT valido. Quindi, nella configurazione per la sessione PuTTY, assicurarsi che il tentativo di autenticazione GSSAPI sia abilitato Connection - SSH - Auth - GSSAPI. Infine, assicurati che sia configurato per accedere automaticamente con il tuo nome utente Connection - Data. È possibile specificare esplicitamente il nome utente o selezionare il pulsante di opzione per Usa nome utente di sistema .

Storicamente, questo è tutto ciò che ho dovuto fare per far funzionare l'accesso SSH senza password tramite Kerberos.

Il problema era nell'installazione di Windows Kerberos. Penso che il nostro Active Directory sia configurato in modo strano, non so davvero di non essere un amministratore di Windows.

Ma ho risolto il problema configurando manualmente Kerberos usando ksetup nella CLI di Windows 7.

Dopo un riavvio sulla mia workstation remota non sono riuscito ad accedere al mio PC. Questo perché nella configurazione originale la porzione TLD del mio dominio realm era sempre assente (dominio \ utente) ma dopo averlo configurato manualmente dovevo cambiare il mio dominio di accesso per riflettere il nome completo del dominio realm (domain.TLD \ user) e Sono stato in grado di accedere al mio PC Windows, anche se sembra richiedere più tempo per l'autenticazione ora.

Prima delle modifiche l'output di ksetup mostrava solo il mio regno predefinito, ed era in minuscolo.

Ho usato "nslookup -type = SRV _kerberos._tcp.domain.TLD" per ottenere tutti i server kdc per il mio regno.

Non ho impostato alcuna bandiera.

Ho impostato il mio nome utente "ksetup / mapuser user@domain.TLD mappato"

Risorse che ho usato: https://wiki.ncsa.illinois.edu/display/ITS/Windows+7+Kerberos+Login+using+External+Kerberos+KDC

https://www.cgl.ucsf.edu/Security/CGLAUTH/CGLAUTH.html

Se qualcuno ha qualche suggerimento che posso dare agli amministratori di Windows su come possono risolvere questo problema (è rotto?), Lo passerò.