Ricezione della richiesta di accesso utilizzando l'autenticazione Windows integrata

Ho un'applicazione .NET 3.5 in esecuzione su IIS 7 su un server Windows 2003 e non riesco a far funzionare correttamente l'autenticazione integrata di Windows poiché continuo a ricevere la richiesta di accesso. Ho impostato l'autenticazione di Windows su abilitata in IIS con tutti gli altri tipi di sicurezza disabilitati e l'autenticazione / autorizzazione del file web.config dell'applicazione è configurata come:

<system.web>
    <compilation debug="true" strict="false" explicit="true" targetFramework="3.5" />
    <authenticationmode="Windows"/>
    <authorization>
    <deny users = "?" />
    </authorization>
</system.web>

Con questa configurazione, mi aspetto una verifica dietro le quinte dell'utente Windows per consentire l'accesso e negare gli utenti anonimi. Tuttavia, quello che ricevo è un pop-up di accesso a Windows quando provo ad accedere al sito.

Sto risolvendo questo problema da alcuni giorni e non riesco a risolverlo. Sulla base di post con problemi simili, ho confermato che il mio URL non include punti, ho ricontrollato che le mie impostazioni di IE siano impostate su Abilita autenticazione integrata di Windows e ho anche aggiunto il mio URL ai miei siti intranet, ma continuando a ricevere il pop-up.

Per risolverlo ulteriormente, ho abilitato l'autenticazione anonima in IIS e modificato il mio file web.config che mi consente di entrare direttamente e quindi ho aggiunto Response.Write (System.Security.Principal.WindowsIdentifity.getcurrent (). User.name.toString () ) per provare a vedere quale utente viene utilizzato nell'autenticazione. Il risultato che ottengo è IIS APPPOOL \ myapp che è ovviamente il pool di applicazioni IIS per la mia applicazione.

Apprezzo davvero qualsiasi aiuto che chiunque possa fornire in modo che sto ancora utilizzando solo l'autenticazione di Windows ma non ricevo il pop-up e l'autenticazione di Windows viene eseguita contro l'effettivo utente di Windows.

Grazie.

Nota aggiuntiva dopo un'ulteriore risoluzione dei problemi:

Ho appena notato che quando l'accesso non riesce e il prompt di accesso di Windows viene visualizzato di nuovo, viene visualizzato il nome utente che ha tentato di accedere come "SERVERNAME" \ "USERNAME", il che mi ha portato a credere che stesse cercando di convalidare l'utente rispetto al server rispetto al dominio. A conferma di ciò, ho creato un account utente locale direttamente sul server app con lo stesso nome utente e password dell'utente del dominio di rete e ho provato ad accedere di nuovo. Il risultato è stato che ho ricevuto di nuovo la richiesta di accesso, ma quando ho inserito il nome utente e la password questa volta, sono stato in grado di accedere con successo. L'utente di rete e l'app server si trovano sullo stesso dominio, quindi non sono sicuro del motivo per cui l'autenticazione IIS punta agli account del server app locale e non agli account di dominio. Mi rendo conto che questa è una domanda IIS a questo punto, quindi postare su forums.iis.

Ho un server Windows 2008 su cui sto lavorando, quindi la mia risposta non è completamente la stessa di quella che ha l'OP su un server Windows 2003.

Ecco cosa ho fatto (registrandolo qui così posso trovarlo più tardi).

Stavo avendo lo stesso problema:

Nel mio file Web.config , avevo questa sezione:

<system.web>
    <authentication mode="Windows" />
    <authorization>
        <allow users="*" />
        <deny users="?" />
    </authorization>
</system.web>

In IIS, tutto questo sembra essere risolto sotto l' icona di autenticazione .

1. Modifica autorizzazioni: assicurati che il tuo account ASP.NET disponga delle autorizzazioni. Il mio non è stato originariamente aggiunto.

Ora vai nelle funzionalità di autenticazione :

Abilita l' autenticazione anonima con IUSR:

Abilita l' autenticazione di Windows , quindi fai clic con il pulsante destro del mouse per impostare i provider .

NTLM deve essere PRIMO!

Quindi, controlla che in Impostazioni avanzate ... la protezione estesa sia Accetta e Abilita autenticazione in modalità kernel è VERIFICATA:

Dopo aver eseguito questa operazione, sono tornato alla mia applicazione Web, ho fatto clic sul collegamento Sfoglia e ho effettuato l'accesso senza dover fornire nuovamente le mie credenziali.

Spero che questo si riveli vantaggioso per molti di voi, e spero che sia utile anche per me in seguito.

Solo a beneficio degli altri. Se l'errore è un 401.1 Unauthorizede il codice di errore corrisponde0xc000006d , stai effettivamente riscontrando una "funzionalità" di sicurezza che blocca le richieste a FQDN o intestazioni host personalizzate che non corrispondono al nome del tuo computer locale:

Segui questo articolo di supporto per risolvere il problema:

https://webconnection.west-wind.com/docs/_4gi0ql5jb.htm (originale, ora defunto: http://support.microsoft.com/kb/896861 )

Dall'articolo di supporto, per assicurarti che non si perda:

La soluzione è un hack del registro che disabilita esplicitamente questa politica.

Per eseguire questa configurazione manualmente, trova questa chiave nel registro sul server:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa

e modifica o aggiungi una nuova chiave:

DisableLoopbackCheck (DWORD)

quindi ha inviato il valore a 1 per disabilitare il controllo di loopback (l'autenticazione locale funziona) o a 0 (l'autenticazione locale non è consentita).

O più facilmente puoi usare Powershell:

New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name "DisableLoopbackCheck" -Value "1" -PropertyType dword

Sembra che anche le build recenti di Windows 10 (1803 e successive?) Richiedano questa impostazione di configurazione per l'autenticazione locale.

Questo mi ci è voluto un po 'perché i commenti di tutti gli altri qui non mi sono stati d'aiuto. Ho trovato questo articolo e l'ho risolto!

Ho avuto un problema simile per cui volevo proteggere solo una certa parte del mio sito web. Tutto ha funzionato bene tranne che in IE. Ho abilitato sia l'autenticazione anonima che quella di Windows. Per Anonimo, l'identità è impostata sull'identità del pool di applicazioni. Il problema era con l'autenticazione di Windows. Dopo un po 'di ricerche ho acceso Fiddler e ho scoperto che utilizzava Kerberos come provider (in realtà è impostato su Negozia per impostazione predefinita). L'ho passato a NTLM e questo l'ha risolto. HTH

Daudi

Aggiungi l'autorizzazione [Domain Users] alla tua sicurezza web.

• Fai clic con il pulsante destro del mouse sul tuo sito in IIS nella cartella Siti
• Fare clic su Modifica autorizzazioni ...
• Seleziona la scheda Protezione
• Nella sezione Gruppo o nomi utente fare clic sul pulsante Modifica ...
• Nella finestra a comparsa Autorizzazioni, sotto Gruppo o nomi utente fare clic su Aggiungi ...
• Immettere [Domain Users] nei nomi degli oggetti per selezionare l'area di testo e fare clic su OK per applicare la modifica
• Fare clic su OK per chiudere il popup Autorizzazioni
• Fare clic su OK per chiudere il popup Proprietà e applicare le nuove impostazioni

Non creare errori sul tuo server cambiando tutto. Se si dispone di Windows che richiede di accedere quando si utilizza l'autenticazione di Windows su 2008 R2, è sufficiente andare su Providerse spostarsi su NTLMper ciascuna applicazione. Quando Negotiateè il primo nell'elenco, l'autenticazione di Windows può smettere di funzionare proprietà per un'applicazione specifica su 2008 R2 e ti può essere richiesto di inserire nome utente e password che non funzioneranno mai. A volte succede quando hai effettuato un aggiornamento della tua applicazione. Assicurati solo di essere il NTLMprimo della lista e non vedrai mai più questo problema.

Se il tuo URL ha dei punti nel nome di dominio, IE lo tratterà come se fosse un indirizzo Internet e non locale. Hai almeno due opzioni:

1. Ottieni un alias da utilizzare nell'URL per sostituire server.domain. Ad esempio, myapp.
2. Segui i passaggi seguenti sul tuo computer.

Vai al sito e cancella la finestra di dialogo di accesso. Lascia che questo accada:

Nelle impostazioni di IE:

WindowsIdentity.GetCurrentè corretto: dovresti ottenere l'utente APPPOOL. Questo perché il processo ASP.NET, che sta eseguendo il codice, è l'identità corrente. Se vuoi che restituisca all'utente l'identità del sito, dovrai aggiungere la seguente riga nel tuo web.config:

<identity impersonate="true" />

Ciò fa sì che il processo assuma l'identità dell'utente che richiede la pagina. Tutte le azioni verranno eseguite per loro conto, quindi qualsiasi tentativo di leggere le cartelle sulla rete o di accedere alle risorse del database e simili significherà che l'utente corrente avrà bisogno delle autorizzazioni per queste cose. Puoi leggere ulteriori informazioni sul furto d'identità qui . Tieni presente che, a seconda di come è impostata la topologia del tuo server web / database, potresti incorrere in problemi di delega con la rappresentazione attivata.

Ma il tuo problema originale è che sembra che l'identità non possa essere determinata e stai ricevendo un popup di accesso. Noterò che non è necessario il <deny>blocco se è stata disabilitata l'autenticazione anonima in IIS. Non lo includiamo mai (tranne in <location>blocchi speciali e simili), quindi direi che potresti provare a rimuoverlo e riprovare. Tutto il resto suona bene, però.

Non hai specificato quale utente sta eseguendo il pool di applicazioni in IIS. È un account personalizzato o è quello predefinito? Se è personalizzato, è un account di dominio o un account locale sul server web? Gli account personalizzati a volte possono richiedere alcuni passaggi in più, come la registrazione di un SPN. Inoltre, potrebbe essere un problema con l'account personalizzato che non dispone dell'autorizzazione in AD per risolvere l'account dell'utente in arrivo.

Potresti anche controllare i log di IIS per vedere quale risposta viene restituita. Molto probabilmente sarà un 401, ma dovrebbe avere un numero secondario dopo di esso come 401.2 o qualcosa del genere. Quel sotto-numero a volte può aiutare a determinare il problema alla radice. Questo articolo della Knowledge Base ne elenca cinque.

Questo ha risolto il problema per me.

Il mio server e il PC client sono Windows 7 e sono nello stesso dominio

1. in iis7.5-abilita l'autenticazione di Windows per la tua Intranet (disabilita tutte le altre autenticazioni .. inoltre Non c'è bisogno di menzionare l'autenticazione di Windows nel file web.config

2. quindi vai al PC client .. IE8 o 9- Strumenti-Opzioni Internet-Sicurezza-Intranet locale-Siti-avanzati-Aggiungi il tuo sito (togli il contrassegno "richiedi server verfi ... "..non serve

3. IE8 o 9- Strumenti-Opzioni Internet-Sicurezza-Intranet locale-Livello personalizzato-utenteautenticazione-accesso-selezione accesso automatico con nome utente e password correnti

4. salva queste impostazioni .. hai finito .. Non più la richiesta di nome utente e password.

5. Assicurati, poiché il tuo PC client fa parte del dominio, devi avere un GPO per queste impostazioni, .. altrimenti questa impostazione verrà ripristinata quando l'utente accederà a Windows la prossima volta

Può essere correlato al browser. Se stai usando IE, puoi andare su Impostazioni avanzate e selezionare la casella di controllo "Abilita autenticazione integrata di Windows".

Nel mio caso le impostazioni di autorizzazione non sono state configurate correttamente.

Dovevo

1. aprire le regole di autorizzazione .NET in Gestione IIS

   

2. e rimuovere la regola di negazione

   

Nella nostra Intranet il problema è stato risolto dal lato client modificando le impostazioni di sicurezza come mostrato qui. Entrambe le caselle di controllo a destra hanno funzionato per noi.

Ho appena risolto un problema simile con un'applicazione ASP.Net.

Sintomi: potrei accedere alla mia app utilizzando un utente locale, ma non un utente di dominio, anche se la macchina è stata correttamente unita al dominio (come dici nella nota aggiuntiva). Nel visualizzatore eventi di sicurezza, si è verificato un evento con ID = 4625 "Domain sid inconsistent".

Soluzione: ho trovato la soluzione qui . Il problema era che le mie macchine di prova dove venivano clonate macchine virtuali (Windows Server 2008 R2; un controller di dominio e un server web). Entrambi avevano lo stesso SID della macchina, che apparentemente causava problemi. Ecco cosa ho fatto:

1. Rimuovi il server web dal dominio.
2. Esegui c: \ Windows \ System32 \ Sysprep \ Sysprep.exe nella VM.
3. Riavvia la VM.
4. Unisci il server web al dominio.

Perdi alcune impostazioni nel processo (preferenze utente, IP statico, ricrea il certificato auto-firmato), ma ora che le ho ricreate, tutto funziona correttamente.

Ho anche avuto lo stesso problema. Ho provato la maggior parte delle cose trovate su questo e altri forum.

Alla fine ha avuto successo dopo aver fatto un piccolo RnD.

Sono entrato in Impostazioni IIS e poi nelle opzioni di autorizzazione del mio sito Web ho aggiunto il mio gruppo utenti di dominio organizzazioni.

Ora poiché a tutti gli utenti del mio dominio è stato concesso l'accesso a quel sito Web, non ho riscontrato questo problema.

Spero che questo ti aiuti

Hai provato ad accedere con il prefisso del tuo dominio, ad esempio DOMINIO \ Nome utente? IIS 6 utilizza per impostazione predefinita il computer host come dominio predefinito, quindi specificare il dominio all'accesso potrebbe risolvere il problema.

Ho provato i trucchi di configurazione IIS di cui sopra e l'hack del registro di loopback e ho rivisto e ricreato le autorizzazioni del pool di app e una dozzina di altre cose e ancora non sono riuscito a sbarazzarmi del ciclo di autenticazione in esecuzione sulla mia workstation di sviluppo con IIS Express o IIS 7.5, da una sessione di navigazione locale o remota. Ho ricevuto quattro risposte di stato 401.2 e una pagina vuota. Lo stesso identico sito distribuito sul mio server di staging IIS 8.5 funziona perfettamente.

Alla fine ho notato che il markup nel corpo della risposta che è stato reso vuoto dal browser conteneva la pagina predefinita per un accesso riuscito. Ho determinato che la gestione degli errori personalizzata per ASP.NET e HTTP per l'errore 401 stava impedendo / interferendo con l'autenticazione di Windows sulla mia workstation ma non il server di staging. Ho trascorso diverse ore a giocherellare con questo, ma non appena ho rimosso la gestione personalizzata solo per l'errore 401, la workstation è tornata alla normalità. Presento questo come un altro modo per colpire il tuo stesso piede.

L'autenticazione di Windows in IIS7.0 o IIS7.5 non funziona con kerberos (provider = Negotiate) quando l'identità del pool di applicazioni è ApplicationPoolIdentity One deve utilizzare il servizio di rete o un altro account integrato. Un'altra possibilità è usare NTLM per far funzionare Windows Authenticatio (in Autenticazione Windows, Provider, mettere NTLM in primo piano o rimuovere negoziazione)

chris van de vijver

Ho avuto lo stesso problema perché l'utente (identità) che ho utilizzato nel pool di applicazioni non era al di sotto del gruppo IIS_IUSRS. Aggiunto l'utente al gruppo e tutto funziona

Nel mio caso la soluzione era (oltre alle regolazioni suggerite sopra) riavviare il computer di sviluppo locale / IIS (server di hosting) dei miei / utenti. Il mio utente è stato appena aggiunto al gruppo di sicurezza AD appena creato e il criterio non si applicava all'account utente AD fino a quando non ho disconnesso / riavviato il mio computer.

Spero che questo possa aiutare qualcuno.

Ho riscontrato lo stesso problema di richiesta di credenziali, ho fatto una ricerca rapida e nulla su Internet lo avrebbe risolto. Ci è voluto del tempo per trovare il problema, uno sciocco.

In IIS -> Impostazioni avanzate -> Credenziale percorso fisico (è vuoto)

Non appena ho aggiunto un ID macchina (dominio / utente) che ha accesso alla VM / al server, la richiesta della password si interrompe.

Spero che questo ti aiuti

Stavo riscontrando questo problema su .net core 2 e dopo aver esaminato la maggior parte dei suggerimenti da qui sembra che ci siamo persi un'impostazione su web.config

<aspNetCore processPath="dotnet" arguments=".\app.dll" forwardWindowsAuthToken="false" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" />

L'impostazione corretta era forwardWindowsAuthToken = "true" che sembra ovvio ora ma quando ci sono così tante situazioni per lo stesso problema è più difficile da individuare

Modifica: ho anche trovato utile il seguente articolo di Msdn che descrive la risoluzione del problema.

Ho riscontrato lo stesso problema ed è stato risolto modificando l'identità del pool di applicazioni del pool di applicazioni in cui è in esecuzione l'applicazione Web in NetworkService