Memorizzazione dell'autenticazione Kerberos per la rappresentazione successiva

Question

È possibile memorizzare un ticket Kerberos per utilizzarlo successivamente per impersonare l'utente?

Ho lo scenario in cui un utente invoca direttamente un sistema esterno per elaborare alcuni dati. Il sistema esterno si basa sull'utente che viene rappresentato/autenticato correttamente nell'AD.

Ora il sistema chiamante deve cambiare in modo che una coda si trovi tra l'utente e il sistema esterno e il lavoro dalla coda venga trasferito al sistema esterno da quella coda da un servizio Windows. Questo servizio deve impersonare l'utente affinché il sistema esterno gestisca correttamente i diritti dell'utente.

Dato che non riesco a cambiare il sistema esterno e non posso memorizzare il nome utente e la password in coda, posso salvare un ticket Kerberos quando l'utente aggiunge nuovi elementi di lavoro alla coda e successivamente impersona l'utente tramite il servizio quando consegna i dati al sistema esterno. Come lo farei in C#?

Answer 1

Potrebbe essere possibile salvarlo, ma penso che il biglietto sarà di breve durata. Sfortunatamente, eseguirai sicuramente lo Kerberos double-hop issue in cui l'autenticazione fallisce dal servizio al servizio, a meno che tu non abbia configurato correttamente la delega sulla tua rete. Ciò richiederà la configurazione di alcuni SPN (nomi principali del servizio) nella directory attiva per indicare ai server di fidarsi l'uno dell'altro.

Non ho mai provato a salvare i ticket Kerberos per un certo periodo di tempo, quindi anche dopo aver combattuto con la delega e SPN potrebbe non funzionare.

Ecco un post rapido su come configurare IIS7 to handle double hop Kerberos tickets e un altro articolo su handling it from the networks point of view.

Vorrei poter essere di maggiore aiuto e postare codice e non articoli, ma mentre indaghi vedrai che questa è la rovina dell'autenticazione Kerberos. In bocca al lupo!

Answer 2

• Edit: Questo è il più vicino che posso ottenere alla tua domanda reale: si può iniziare un thread separato sotto la rappresentazione, fare la richiesta da lì, tutto il tempo che ci vuole? Sotto le coperte questo farà ciò che è necessario (a meno che il processo di servizio non sia terminato, naturalmente).

Come un microsoft ci ha detto una volta "la sicurezza è la cosa che interrompe il funzionamento dell'applicazione quando la si distribuisce". (Il suo punto era di testare con una configurazione di sicurezza realistica).

Il ticket può avere una durata di 10 ore, ma è il momento da quando è stato emesso. Potrebbe avere solo una frazione di quello che rimane dal momento in cui l'utente effettua la richiesta.

Suggerisco di risolvere semplicemente il problema sottostante in un modo diverso.

Qual è il motivo per cui ora è necessario fare la coda? Semplicemente perché il servizio esterno è strozzato nelle ore di punta?

• Riesci a rinforzare o scalare l'hardware? Di solito il modo più economico.
• Avete effettivamente autorizzazioni completamente separate o gli utenti inseriscono un numero finito di ruoli? Se i ruoli potessero registrare il ruolo in cui si trovava l'utente e utilizzare nomi utente appositamente creati per accedere al servizio esterno, uno per ciascun ruolo.
• Il servizio esterno è tuo?Puoi aggiungere un'opzione "fingere di essere Bob" che non si basa su Windows Impersonation?
• È possibile avviare un thread separato sotto la rappresentazione, effettuare la richiesta da lì, per quanto tempo impiega? Quindi rispediscilo all'utente? (Sì, questo avverrà sotto le copertine, facendo quello che chiedi)
• Infine, potresti mettere l'utente in una "coda di razionamento" del browser. Cioè emettili con un numero, poi fai in modo che il browser si aggiorni ogni 10 secondi (o usi Ajax) per dire loro quante persone ci sono davanti in coda. Quando è il loro turno, effettua la richiesta effettiva sotto falsa identità. (Ciò impone loro di mantenere aperta la finestra del browser durante l'attesa in coda e richiede inoltre di tenere traccia delle richieste in sospeso e dei browser attivi rispetto ai browser obsoleti). Cattivo, ma funzionerà.

Senza conoscere il problema reale, è difficile consigliarlo, oltre a dire non farlo in questo modo: troppi trucchi.

Answer 3

Questa soluzione è dotato di un enorme avvertimento, ma invece di memorizzare gettoni/biglietti, è possibile utilizzare la funzione LsaLogonUser e delega vincolata ad ottenere un token per la rappresentazione senza credenziali che forniscono, in questo momento il lavoro è pronto per essere rimosse dalla coda.

In questo modo viene implementata la transizione del protocollo, in cui le credenziali non Windows (ad esempio su un sito Web pubblico) possono essere mappate a un utente di dominio che viene rappresentato per l'accesso alle risorse interne.

L'avvertenza è, questo è ovviamente un enorme buco di sicurezza potenziale, e l'account che esegue il processo che chiama LsaLogonUser deve essere concesso SeTcbPrivilege ("Agisci come parte del sistema operativo").

Se c'è un modo di conservare un biglietto, sarebbe ovviamente molto meglio, ma la prima cosa che ho pensato quando ho visto la domanda era il problema del tempo di scadenza che @Ben ha menzionato.

Modifica: A couple di excellent articles sulla transizione del protocollo e sulla delega vincolata, con ampia copertura dei rischi coinvolti.