Multiple Realms e Multiple TGTs in MIT Kerberos per Windows

Il mio computer locale utilizza Windows 7 Pro e appartiene al regno LR, gestito da server AD. Accedo al mio computer mentre sono collegato alla rete di quel regno. Posso visualizzare il TGT con MIT Kerberos per Windows ver. 4.0.1.

Voglio accedere alle risorse su un regno straniero, FR. Non esiste alcun trust Kerberos tra LR e FR, ma consentono il traffico TCP tra loro. Richiedo un TGT per FR con il suo KDC (Red Hat IdM / FreeIPA) e inserisco correttamente la mia password quando contestato. Ancora una volta, posso visualizzare il TGT con MIT Kerberos per Windows ver. 4.0.1. Ora posso accedere alle risorse in FR su SSH senza che mi venga richiesta una password, nonostante provenga da LR.

Il problema è quando ottengo il TGT per FR, il TGT per il mio preside LR scompare. Solo il FR TGT è visibile nel Kerberos del MIT. Se blocco il mio computer e quindi lo sblocco con la mia password, ora FR TGT è sparito, sostituito da un nuovo LR TGT.

Sembra che MIT Kerberos per Windows possa memorizzare solo un TGT alla volta. Ogni TGT funziona completamente per il suo regno a tutti gli effetti. Come posso configurare MIT Kerberos per farmi avere due TGT contemporaneamente, uno per ogni reame? È possibile "compartimentare" con più istanze client, ognuna delle quali punta a un diverso KRB5_CONFIG e keytab locale? Se non ci riesco, esiste un'implementazione alternativa di Windows sul lato client Kerberos 5, anche quando non ci sono trust inter-realm?

PS - Non voglio una fiducia. Non riesco a fidarmi.

AGGIORNAMENTO: Ho lasciato fuori alcuni di questi dettagli in precedenza perché pensavo che potesse confondere il problema. Ma in base alla risposta di Brad, potrebbe essere giustificato. Mi aspetto che la maggior parte dei software locali utilizzi l'implementazione Windows integrata di Kerberos e utilizzi sempre il keytab LR.

Tuttavia, gli utenti esperti come me usano Heimdal sotto Cygwin per SSH in FR. Mi aspetto che qualsiasi cosa passi attraverso le DLL di Cygwin usi heimdal e non veda mai il LR TGT (cosa che non succede, almeno non di default). Parlo esplicitamente e vado avanti.

La parte difficile arriva per gli utenti non esperti che devo supportare e che non usano Cygwin ma usano PuTTY. PuTTY ti consente di specificare sia il percorso della libreria che la DLL per cui utilizzare l'implementazione GSSAPI. Ad esempio, sto configurando sessioni SSH per utilizzare le DLL Kerberos MIT anziché le DLL di Windows integrate. Speravo che ci fosse una DLL là fuori che o non ha mai provato a trovare il LR TGT (come heimdal) o ha permesso più TGT da più regni. Non deve avere una finestra della GUI come MIT Kerberos, ma aiuta.

Bene, non dirò che NON può essere fatto con Windows, ma dirò che la limitazione è basata sulla sessione. Il problema quindi è che per ogni sessione Windows memorizza nella cache un ticket. Quando si blocca il computer quindi lo si sblocca, viene avviata un'altra sessione e viene richiesta una nuova chiave dal KDC. La stessa cosa accade quando ci si disconnette e si accede nuovamente al computer. Questo metodo è in realtà il modo in cui le autorizzazioni utente sono determinate anche per le sessioni del server, il che significa che la chiave / ticket può essere memorizzata nella cache in modo che ogni risorsa o sessione del server avviata non debba chiederti la password, ma non ho mai sentito / letto / ricercato per essere in grado di memorizzare nella cache più di uno.

Ora, probabilmente lo saprai già, data la tua conoscenza che hai visualizzato nella tua domanda, quindi dirò che in base al fatto che Windows memorizza la chiave che ricevi quando viene emesso un TGT ed è basato sulla sessione, non lo so pensa che sia possibile con JUST Windows. Il Kerberos MIT per Windows potrebbe avere un modo per avviare due sessioni sotto un utente, ma anche in questo caso, non sono sicuro di come le risorse a cui accedete saprebbero quale coppia di ticket / chiave utilizzare. Ha senso?

Si prega di vedere questo per una descrizione di come Windows memorizza TGT / coppie di chiavi.

Ottima domanda a proposito.

OK, ho trovato una soluzione funzionante che ha bisogno di un po 'più di lucido, quindi potrebbe non funzionare in tutti gli ambienti.

Funziona con:

1. MIT Kerberos per Windows 4.0.1 con strumenti di supporto di Windows (KSETUP.EXE, KTPASS.EXE)
2. GUSTO 0.63
3. Windows 7 SP1

Stavo cercando nella fonte del Kerberos del MIT e mi sono imbattuto nel README per Windows . Di particolare interesse sono stati i diversi valori per la cache delle credenziali . Si sposa con un valore predefinito di API :, ma ho sorprendentemente trovato il mio registro usando MSLSA: invece.

Ho giocato con diversi valori di ccname sotto HKEY_CURRENT_USER\Software\MIT\Kerberos5. Ho provato MEMORY: all'inizio, che ha portato ad alcuni comportamenti interessanti. All'apertura di una sessione PuTTY, la finestra del Ticket Manager del MIT Kerberos si ripristinava e tornava in primo piano, chiedendomi di inserire le credenziali. Wow! Non è mai successo prima, ma purtroppo PuTTY lo respingerebbe. Il valore che ha fatto il trucco per me è stato FILE:C:\Some\Full\File\Path. Non sono esattamente sicuro di come proteggere l'accesso al file specificato, quindi lo lascerò come esercizio per il lettore. Ho avuto lo stesso comportamento da finestra a primo piano, questa volta è piaciuto solo a PuTTY. Anche la finestra Gestione ticket mostrava entrambi i biglietti LR e FR. I biglietti hanno dimostrato di essere inoltrabili e sopravvivrebbero a più blocchi / sblocchi di Windows. NOTA:assicurati di uscire completamente e riavviare Ticket Manager tra le modifiche al registro. Non ho ancora provato un ccname di API: ancora.

Non so se questo fa la differenza o no, ma ho anche giocato con KSETUP prima che iniziasse a funzionare. All'inizio, un KSETUP senza parametri mi mostrerebbe solo informazioni sull'LR. Ho aggiunto alcune informazioni sul FR sulla mia workstation locale.

ksetup /AddKdc FOREIGN.REALM KDC.FOREIGN.REALM
ksetup /AddRealmFlags FOREIGN.REALM TcpSupported Delegate NcSupported

Per me, sembra che ci sia un bug in Kerberos per Windows.

Ho trovato il seguente:

Se utilizzo l'opzione "get ticket" nella finestra di KfW 4.0.1, funziona (TM); Posso premere il pulsante "Ottieni biglietto" e acquisire altri biglietti per i biglietti originali che ho ricevuto quando eseguo l'accesso.

Se premo l'opzione "make default" nella finestra KfW, da quel momento in poi ogni volta che premo "get ticket", il nuovo ticket sostituirà qualunque ticket sia quello predefinito, anziché aggiungere un'altra voce all'elenco dei ticket noti . Controllare il registro a quel punto mostrerà che ccnameè stata aggiunta una voce (come nella risposta di Toddius). La rimozione di tale voce, sorprendentemente, ripristinerà il comportamento precedente di consentire più ticket.

In seguito alla risposta di Toddius, ho un collega in una situazione simile (Windows 7 Enterprise a 64 bit, unito a un dominio AD, che esegue anche MIT Kerberos per Windows 4.0.1): la sua copia del Kerberos Ticket Manager sarebbe consentirgli solo di avere un principale / un TGT. Ogni volta che utilizzava il pulsante "Ottieni biglietto" per ottenere un TGT per un principale diverso, il principale precedente scompariva.

Ho esaminato il file README e la maggior parte delle chiavi del Registro di sistema sono state impostate come previsto, ad eccezione della chiave ccname nel percorso HKEY_CURRENT_USER\Software\MIT\Kerberos5. Quella chiave è stata impostata sul valore MSLSA:. La nostra soluzione era di cambiarlo in API:. Più specificamente, i passaggi sono stati:

1. Esci da Kerberos Ticket Manager, insieme a tutte le altre applicazioni (poiché riavvierai).
2. Nel percorso del Registro di sistema HKEY_CURRENT_USER\Software\MIT\Kerberos5, modificare la chiave ccname in API:(API, quindi due punti).
3. Esci da regedit e riavvia.
4. Dopo aver effettuato nuovamente l'accesso, esegui Kerberos Ticket Manager e utilizza il pulsante Ottieni biglietto per ottenere il TGT del tuo principale non AD.

Con i passaggi precedenti, tutto ha funzionato e ora il mio collega è in grado di vedere più entità / TGT contemporaneamente.

A proposito, MIT Kerberos per Windows introduce il proprio set di programmi da riga di comando (come klist) e tali programmi supportano più cache di credenziali. Sul mio sistema a 64 bit, quando corro "C:\Program Files\MIT\Kerberos\bin\klist.exe" -A"dopo aver ricevuto più TGT, vedo il mio principal Active Directory nella cache MSLSA e quindi ho una cache API per ogni principale aggiuntivo.

PS Questa è la mia prima voce su questo sito, quindi non sono stato in grado di aggiungerlo come commento alla risposta di Toddius. Scuse!