Perché usare Kerberos invece di NTLM in IIS?

Questo è qualcosa a cui non sono mai stato in grado di rispondere come piace a me: qual è il vero vantaggio dell'utilizzo dell'autenticazione Kerberos in IIS anziché in NTLM?

Ho visto molte persone davvero lottare per installarlo (me compreso) e non sono stato in grado di trovare una buona ragione per usarlo. Ci devono essere alcuni vantaggi piuttosto significativi, altrimenti non varrebbe la pena crearlo, giusto?

Solo dal punto di vista di Windows:

NTLM

• funziona con entrambi esterni (non di dominio) e interne clienti
• funziona con account di dominio e account utente locali nella casella IIS
  • utilizzando gli account di dominio, solo il server richiede la connettività diretta a un controller di dominio (DC)
  • utilizzando gli account locali, non è necessaria la connettività ovunque :)
  • non è necessario accedere come utente in questione per utilizzare una credenziale
  • A parte : non è che raro che una corrente continua a essere sopraffatto da un server occupato NTLM (IIS, Exchange, TMG / ISA, ecc) con il volume di richieste NTLM (per mitigare: MaxConcurrentAPI, AuthPersistSingleRequest(false) ., Più veloce DC) ( Self bonus referenziale .)
• richiede la connettività client solo al server IIS (sulla porta del sito, nient'altro. Cioè, tutto accade su HTTP (o HTTPS).)
• può attraversare tutta la procura supporto HTTP keep-alive s
  • potresti essere in grado di utilizzare TLS / SSL per aggirare gli altri
• richiede più round trip per l'autenticazione, con piccoli pacchetti
  • (il modello di registro è 401.2, 401.1, 200 con nome utente)
• non può essere utilizzato in scenari in cui è richiesta l'autenticazione a doppio hop
  • cioè le credenziali dell'utente devono essere inoltrate a un servizio su un altro computer
• supporta client meno recenti (<Win2000)
• È suscettibile alle discrepanze del livello di autenticazione LM (non corrispondente lmcompatibilitylevel)
• viene utilizzato come fallback dal pacchetto di negoziazione in caso di errore Curb.
  • ( non "se l'accesso viene negato con Curb", Curb deve interrompere l'utilizzo di NTLM, in genere sembra che non si ottenga un ticket. Se il client riceve un ticket e non è perfetto, ciò non causa un fallback.)

Kerberos

• funziona solo con client attualmente aggiunti al dominio
  • richiede la connettività client a un controller di dominio Active Directory (tcp / udp 88) E al server (i ticket vengono recuperati dal client dal controller di dominio tramite la porta Curb e quindi forniti al server tramite HTTP)

• potrebbe essere in grado di attraversare un proxy, ma vedi il punto DC sopra: devi comunque essere sulla stessa rete di un DC attivo, così come il server .

  • quindi in teoria se hai un dominio in cui i client connessi a Internet hanno chattato direttamente con un controller di dominio connesso a Internet, è fattibile. Ma non farlo se non lo sapevi già.
  • Negli scenari proxy inverso (ISA / TMG), il server di transizione protocollo deve trovarsi su quella rete, cioè non sul client ... ma il client non è realmente quello che esegue il bit Kerberos (necessariamente - pensa Forms auth to Curb transizione).

• ticket è di lunga durata (10 ore ), il che significa meno comunicazioni DC durante la durata del ticket - e per sottolineare: questo potrebbe salvare da migliaia a milioni di richieste per client per tutta quella durata - ( AuthPersistNonNTLMè ancora una cosa; la convalida PAC Kerberos era una cosa)

• richiede un solo round-trip per l'autenticazione, ma la dimensione del payload di autenticazione è relativamente grande (comunemente 6-16K) ( 401 , {(codificato) token size} 200 )
• può essere utilizzato con la delega (sempre vincolata ) per abilitare l'autenticazione di Windows dell'utente che si connette al servizio successivo
  • ad esempio, per consentire UserAl'accesso a IIS e utilizzare lo stesso account utente quando IIS accede a SQL Server, si tratta di "delega dell'autenticazione".
  • ( Vincolato in questo contesto significa "ma non altro", ad esempio Exchange o un'altra casella SQL)
• è attualmente il pacchetto di sicurezza principale per l'autenticazione di negoziazione
  • ciò significa che i membri del dominio Windows lo preferiscono quando possono ottenerlo
• richiede la registrazione di SPN , il che può essere complicato. Regole che aiutano .
• richiede l'uso di un nome come destinazione, non di un indirizzo IP
• motivi per cui Curb potrebbe non funzionare:
  • utilizzando un indirizzo IP anziché un nome
  • nessun SPN registrato
  • SPN duplicati registrati
  • SPN registrato con account errato ( KRB_ERR_AP_MODIFIED)
  • nessuna connettività DNS / DC client
  • impostazione proxy client / Zona Intranet locale non utilizzata per il sito di destinazione

Mentre ci siamo:

Di base

• può multi-hop. Tuttavia, esponendo il nome utente e la password direttamente all'app Web di destinazione
  • che può quindi fare tutto ciò che vuole con loro. Qualunque cosa .
  • "Oh, un amministratore di dominio ha appena usato la mia app? E ho appena letto la loro e-mail? Quindi ho reimpostato la password? Awww. Peccato "
• necessita di sicurezza a livello di trasporto (ad esempio TLS / SSL) per qualsiasi forma di sicurezza.
  • e quindi, vedi il numero precedente
• funziona con qualsiasi browser
  • (ma vedi il primo numero )
• richiede un solo round-trip per l'autenticazione ( 401 , 200 )
• può essere utilizzato in scenari multi-hop perché Windows può eseguire un accesso interattivo con credenziali di base
  • Potrebbe essere necessario LogonTypeconfigurarlo per eseguire ciò (si pensi che il valore predefinito sia cambiato in testo in chiaro tra il 2000 e il 2003, ma potrebbe non ricordare)
  • ma di nuovo , vedi il primo numero .
  • Hai l'impressione che il primo numero sia davvero, davvero importante? È.

Per riassumere:

Il cordolo può essere complicato da configurare, ma ci sono un sacco di guide (la mia ) là fuori che cercano di semplificare il processo e gli strumenti sono notevolmente migliorati dal 2003 al 2008 ( SetSPNpossono cercare duplicati, che è il problema di rottura più comune ; usaSETSPN -S ogni volta che vedi una guida per usare -A, e la vita sarà più felice).

La delega vincolata vale il costo di ammissione.

• Kerberos ha la reputazione di essere un meccanismo di autenticazione più veloce e sicuro di NTLM.
• Storicamente è stato anche più facile connettersi tramite server proxy rispetto a NTLM, a causa della natura basata sulla connessione di NTLM.
• Detto questo, come noterai, Kerberos è più difficile da avviare e richiede una connessione all'AD non sempre pratica.

Un altro approccio sarebbe quello di impostare l'autenticazione negotiatee utilizzare entrambi anziché uno anziché l'altro.

Da Microsoft Application Verifier , che rileva errori comuni degli sviluppatori. Uno di quegli errori è l'uso di NTLM :

NTLM è un protocollo di autenticazione obsoleto con difetti che potenzialmente compromettono la sicurezza delle applicazioni e del sistema operativo. Il difetto più importante è la mancanza di autenticazione del server, che potrebbe consentire a un utente malintenzionato di indurre gli utenti a collegarsi a un server contraffatto. Come corollario dell'autenticazione del server mancante, le applicazioni che utilizzano NTLM possono anche essere vulnerabili a un tipo di attacco noto come attacco di "riflessione". Quest'ultimo consente a un utente malintenzionato di dirottare la conversazione di autenticazione di un utente con un server legittimo e di utilizzarlo per autenticare l'attaccante sul computer dell'utente. Le vulnerabilità e le modalità di sfruttamento di NTLM sono l'obiettivo di aumentare l'attività di ricerca nella comunità della sicurezza.

Sebbene Kerberos sia disponibile da molti anni, molte applicazioni sono ancora scritte per usare solo NTLM. Ciò riduce inutilmente la sicurezza delle applicazioni. Kerberos non può tuttavia sostituire NTLM in tutti gli scenari, principalmente quelli in cui un client deve autenticarsi su sistemi che non fanno parte di un dominio (una rete domestica forse è la più comune di queste). Il pacchetto di sicurezza Negozia consente un compromesso retrocompatibile che utilizza Kerberos ogni volta che è possibile e ritorna a NTLM solo quando non vi è altra opzione. Il passaggio al codice per utilizzare Negotiate anziché NTLM aumenterà in modo significativo la sicurezza per i nostri clienti introducendo al contempo poche o nessuna compatibilità con le applicazioni. Negoziare da solo non è un proiettile d'argento - ci sono casi in cui un attaccante può forzare il downgrade a NTLM ma questi sono significativamente più difficili da sfruttare. Tuttavia, un miglioramento immediato è che le applicazioni scritte per utilizzare correttamente Negozia sono automaticamente immuni agli attacchi di riflessione NTLM.

A titolo di ultimo avvertimento contro l'uso di NTLM: nelle future versioni di Windows sarà possibile disabilitare l'uso di NTLM sul sistema operativo. Se le applicazioni hanno una forte dipendenza da NTLM, non riusciranno semplicemente ad autenticarsi quando NTLM è disabilitato.

Dovresti aggiungere un punto molto importante:

Kerberos è un protocollo standard e aperto in Unix da oltre 20 anni, mentre NTLM è una soluzione puramente proprietaria di Microsoft e nota solo a Microsoft.

Kerberos è necessario se è necessario impersonare l'utente per accedere a risorse che non si trovano sul server iis.