Risoluzione dei problemi di autenticazione di Windows (nessuna sfida) in IIS 7.5?

So che ci sono migliaia di segnalazioni di persone che hanno problemi a far funzionare l'autenticazione integrata di Windows con IIS, ma sembrano tutti portare a pagine Web che non si applicano o soluzioni che ho già provato. Ho già implementato dozzine di siti come questo prima, quindi o c'è qualcosa di bizzarro nel server / nella configurazione, oppure sto guardando da troppo tempo e non vedo l'ovvio.

In poche parole, tutto funziona perfettamente sulla mia macchina locale, ma cade a pezzi sul server di produzione, che per quanto posso dire ha la stessa identica configurazione .

Sulla macchina locale:

La macchina esegue Windows 7 Ultimate, Service Pack 1, IIS 7.5.
Il sito è stato testato con successo, utilizzando sia IIS che VS Web Development Server.
La configurazione del sito IIS ha tutti i metodi di autenticazione disabilitati tranne l' autenticazione di Windows.
Il computer locale non si trova su alcun dominio.
I provider impostati sono Negoziazione e NTLM (non Negozia: Kerberos).
La protezione estesa è disattivata.
Tutti i browser testati (IE, Firefox, Chrome) mostrano il prompt di richiesta e mi consentono di accedere al dominio localhost con il mio account di Windows (locale).
Tutti i browser testati funzionano anche utilizzando un indirizzo IP locale opaco - quindi ai browser stessi non sembra importare se il sito appare "locale" o "remoto".
Ho aggiunto una riga di visualizzazione alla pagina Web che mostra l'utente attualmente connesso e mostra esattamente cosa mi aspetterei (qualunque utente locale con cui ho effettuato l'accesso).

Sulla macchina remota:

Il server esegue Windows Server 2008 R2, IIS 7.5.
Il caricamento della pagina Web genera un errore 401.2 immediato : non sei autorizzato a visualizzare questa pagina a causa di intestazioni di autenticazione non valide. Non viene mai visualizzata alcuna richiesta di sfida.
La configurazione del sito IIS ha tutti i metodi di autenticazione disabilitati tranne l' autenticazione di Windows.
Il computer remoto non si trova su alcun dominio.
I provider impostati sono Negoziazione e NTLM (non Negozia: Kerberos).
La protezione estesa è disattivata.
Sul computer remoto (sessione desktop remoto), lo stesso errore viene visualizzato in Internet Explorer indipendentemente dal fatto che il dominio sia localhost o l'indirizzo IP esterno.
Se provo a visualizzare il sito Web remoto dal mio computer locale , l'errore è ancora 401, ma un 401 leggermente diverso. Nessun sottocodice, con il testo: accesso negato a causa di credenziali non valide.
La funzione ruolo IIS di autenticazione di Windows è installata.
Il WindowsAuthentication modulo viene aggiunto (a livello server).
Lo stesso errore si verifica se disattivo l'autenticazione di Windows e abilito l'autenticazione di base.
Il sito si carica se disattivo l'autenticazione di Windows e abilito Anonimo (ovviamente).
Ho già seguito tutti i passaggi per la risoluzione dei problemi sul supporto Microsoft: Risoluzione dei problemi relativi agli errori HTTP 401 in IIS
Ho già provato la soluzione alternativa mostrata su un'altra pagina di supporto Microsoft (presumibilmente per forzare NTLM come unico metodo).

Ultimo ma non meno importante, ho provato ad attivare FREB per errori 401.2 e i risultati non sembrano dirmi nulla di utile, tutto ciò che vedo è il seguente avviso:

MODULE_SET_RESPONSE_ERROR_STATUS

ModuleName IIS Web Core
Notification 2
HttpStatus 401
HttpReason
HttpSubStatus 2 non autorizzato
ErrorCode 2147942405
ConfigExceptionInfo
Notifica AUTHENTICATE_REQUEST
ErrorCode L'accesso è negato. (0x80070005)

... questo sembra semplicemente dirmi quello che già so (che sta semplicemente rifiutando la richiesta invece di negoziare le credenziali).

La traccia indica che il modulo WindowsAuthentication è caricato correttamente perché esiste una NOTIFY_MODULE_STARTriga con ModuleName= WindowsAuthentication(e vari altri eventi di follow-up ASP.NET - [un] fortunatamente, qui non ci sono errori o avvisi interessanti).

Qualcuno può dirmi cosa potrei perdere qui?

Aggiornamento rapido:

Sto un po 'a disagio a inviare un intero dump di Wireshark in quanto rivelerebbe IP, URL e altre cose, ma ho fatto un confronto fianco a fianco delle risposte HTTP da localhost e dal server remoto in Fiddler, e sembra abbastanza auto -evidente qual è il problema:

localhost:

HTTP / 1.1 401 Non autorizzato
Controllo cache: privato
Tipo di contenuto: text / html; charset = utf-8
Server: Microsoft-IIS / 7.5
Autenticazione WWW: negoziazione
Autenticazione WWW: NTLM
X-Powered-By: ASP.NET
Data: sab, 17 dic 2011 23:42:34 GMT
Lunghezza contenuto: 6399
Supporto proxy: autenticazione basata sulla sessione

A distanza:

HTTP / 1.1 401 Non autorizzato
Tipo di contenuto: testo / html
Server: Microsoft-IIS / 7.5
X-Powered-By: ASP.NET
Data: sab, 17 dic 2011 23:43:13 GMT
Lunghezza contenuto: 1293

A parte alcune differenze apparentemente insignificanti come il controllo della cache, la differenza principale è che il server remoto non sta inviando le intestazioni WWW-Authenticate al client.

Quindi, suppongo che restringa la domanda a: Perché IIS non sta inviando le intestazioni WWW-Authenticate quando l'autenticazione di Windows sembra essere installata, caricata ed abilitata esclusivamente?

— Aaronaught
fonte

Ti dispiace catturare un wirehark in chiaro del tentativo di autenticazione (cambia prima la tua password in qualcosa da buttare via - non vogliamo che i tuoi veri hash di password in rete)? Circa 18 mesi fa una patch di Windows ha apportato alcune modifiche alla negoziazione HTTP NTLM (a proposito, i sistemi sono stati completamente aggiornati?) Che ha fatto saltare in aria l'app di un fornitore e mi ha dato molta più esperienza di quella che mi piacerebbe ammettere con l'analisi conversazioni di negoziazione.

— Shane Madden

@ShaneMadden: in un certo senso mi dispiace per tutte le varie informazioni che vorrei esporre, ma posso fare una sessione di Fiddler che dovrebbe essere quasi la stessa, e quindi posso almeno anonimizzare gli IP e così via - e in effetti l'ho già fatto, i risultati dovrebbero essere abbastanza autoesplicativi (il client non sta mostrando il prompt delle credenziali perché il server non ne richiede nessuno).

— Aaronaught il

Oh, interessante, qualcuno sembra aver segnalato questo problema anche su Stack Overflow - nessuna risposta lì, purtroppo.

— Aaronaught il

@Aaronaught Come hai ottenuto un nome utente diverso qui rispetto a Cooking? Quando ho visto questa domanda per la prima volta, ho pensato che fosse qualcuno che ti stava falsificando.

— Ward - Ripristina Monica

@Ward: chiunque può modificare il proprio nome utente, fa parte del profilo. Questo era il mio originale, ne uso solo altri sui siti non tecnologici.

— Aaronaught il

Problema risolto. Alla fine ho deciso di confrontare il elenco dei moduli fianco a fianco e in realtà ne mancava uno. Si scopre che ci sono due moduli di autenticazione di Windows:

Elenco dei moduli

Sul server, il WindowsAuthenticationmodulo gestito era lì, ma non il nativo WindowsAuthenticationModuleevidenziato sopra. Perché è stato configurato in questo modo è un'ipotesi di chiunque, ma apparentemente se il modulo nativo non è caricato, il modulo gestito si caricherà allegramente e fallirà silenziosamente.

Quindi, per tutti i futuri lettori che riscontrano questo problema, assicurati di avere entrambi i moduli caricati , perché IIS non ti avviserà se manca uno di essi.

— Aaronaught
fonte

Il modulo di autenticazione di Windows gestito non è quello che sembra. È il supporto per le identità di Windows in ASP.Net ed è sempre installato (quando è installato ASP.Net). Ma il modulo nativo di autenticazione di Windows è ciò che viene installato quando si spunta il componente Windows Auth in Server Manager, ed è quello che è necessario affinché tale opzione di autenticazione diventi visibile nella GUI di autenticazione.

— TristanK,

@TristanK: in questo caso, quel componente era spuntato, ma il modulo non era installato. (L'opzione era, tuttavia, visibile nella GUI di autenticazione - quindi sono abbastanza sicuro che la schermata dipenda dal modulo gestito, non da quello nativo.)

— Aaronaught il

Sto pensando che potrebbe essere ottenuto in questo modo a causa di manomissioni dei file di configurazione (probabilmente ApplicationHost.config). Ma suppongo che non abbia importanza come sia uscito tutto da quel colpo; lo ha fatto.

— Aaronaught il

Bene, chiaramente. Windows Auth non funziona a meno che non succeda qualcosa; in questo caso, mentre la domanda afferma che la configurazione è identica, ciò risulta essere falso; quindi non ha funzionato allo stesso modo. QED.

— TristanK,

Questo problema del modulo mancante mi ha appena morso in Windows Server 2012 R2. È incredibile che non ci siano indicazioni quando si verifica questa condizione. Comunque, grazie mille per questa risposta; Mi stavo letteralmente strappando i capelli!

— Rob Davis,

Abbiamo scoperto che questo non risolve necessariamente il problema per gli sviluppatori che lavorano localmente su siti ASP.NET in esecuzione con autenticazione di Windows. Abbiamo trovato un hack del registro che disabilita il controllo di loopback; questo risolto: -

chiave di registro - HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ Lsa

Crea un DWORD con valore 1 chiamato "DisableLoopbackCheck"

Dovrai riavviare la macchina per rendere effettive le impostazioni

— sh1rts
fonte

Ho scoperto che potevo passare da DisableLoopbackCheck a 1 e 0 e la modifica avrebbe avuto effetto immediato. Inoltre, è possibile visualizzare l'ID evento 4625 nel registro eventi Registro sicurezza con il messaggio "Impossibile accedere all'account".

— alastairtree,

Grazie! 2 giorni di scappatoia con l'autenticazione IIS e le versioni .Net solo per scoprire che stavo usando il mio file hosts per creare una voce DNS fittizia durante il test di una migrazione del sito.

— JohnLBevan,