Domanda

Ho appena creato un sito Web ASP MVC di base per la distribuzione sulla nostra intranet. Si aspetta che gli utenti si trovino nello stesso dominio della casella IIS e se non sei un utente Windows autenticato, non dovresti ottenere l'accesso.

L'ho appena distribuito su IIS6 in esecuzione su Server 2003 R2 SP2. L'app Web è configurata con il proprio pool con il proprio account utente del pool. Le opzioni di sicurezza della directory IIS per l'app Web sono impostate su "Sicurezza integrata di Windows" solo e il file web.config ha:

<authentication mode="Windows" />

Da una sessione di Desktop remoto sul server IIS6 stesso, una finestra del browser IE7 può autenticare e navigare con successo l'app Web se vi si accede tramite http :. // localhost / myapp

Tuttavia, anche dal server, se vi si accede tramite il nome del server (es. http: // myserver / myapp ) quindi IE7 presenta una finestra di dialogo delle credenziali che dopo tre tentativi di immissione delle credenziali corrette alla fine restituisce "Errore HTTP 401.1 - Non autorizzato: accesso negato a causa di credenziali non valide".

Lo stesso problema si verifica quando una workstation passa all'URL dell'app Web (utilizzando naturalmente il nome del server e non " localhost ").

Il server IIS6 è un membro dell'unico dominio che abbiamo e non ha un firewall abilitato.

C'è qualcosa che non sono riuscito a configurare correttamente perché funzioni?

Grazie,


Ho provato i suggerimenti di Matt Ryan, Graphain e Mike Dimmick fino ad oggi senza successo. Ho appena creato un laboratorio di test di macchine virtuali con un Server 2003 DC e un server IIS6 server 2003 separato e sono in grado di replicare il problema.

Vedo una voce nel registro eventi di sistema del server IIS6 la prima volta che provo ad accedere al sito tramite l'URL non localhost (ovvero http: // IIS / myapp ). Anche gli URL FQDN falliscono.

  

Fonte: Kerberos, ID evento: 4
  Il client Kerberos ha ricevuto un errore KRB_AP_ERR_MODIFIED dall'host server / iis.test.local. Il nome di destinazione utilizzato era HTTP / iis.test.local. Ciò indica che la password utilizzata per crittografare il ticket di servizio Kerberos è diversa da quella sul server di destinazione. Comunemente, ciò è dovuto agli account macchina identici nel regno di destinazione (TEST.LOCAL) e al regno del cliente.

È stato utile?

Soluzione

Dopo un'approfondita ricerca su Google sono riuscito a trovare una soluzione sul seguente articolo MSDN:
Come: creare un account di servizio per un'applicazione ASP.NET 2.0

In particolare la sezione Considerazioni aggiuntive che descrive " Creazione di nomi principali di servizio (SPN) per account di dominio " usando lo strumento setspn dagli Strumenti di supporto di Windows:

  

setspn -A HTTP / myserver MYDOMAIN \ MyPoolUser
  setspn -A HTTP / myserver.fqdn.com MYDOMAIN \ MyPoolUser

Ciò ha risolto il mio problema sia sul mio laboratorio di test virtuale sia sul mio server dei problemi originale.

C'è anche una nota importante nell'articolo che l'uso dell'autenticazione di Windows con utenti di pool personalizzati limita il nome DNS associato ad essere utilizzato solo da quel pool. Cioè, un altro pool con un'altra identità dovrebbe essere associato a un nome DNS diverso.

Altri suggerimenti

Sembra la nuova funzionalità di sicurezza del controllo di loopback di Windows Server 2003 SP1. A quanto ho capito, è progettato per prevenire un particolare tipo di attacco di intercettazione.

Da http://support.microsoft.com/kb/896861

Sintomi

Quando si utilizza il nome di dominio completo (FQDN) o un'intestazione host personalizzata per esplorare un sito Web locale ospitato su un computer che esegue Microsoft Internet Information Services (IIS) 5.1 o IIS 6, è possibile che venga visualizzato un messaggio di errore simile al seguente: HTTP 401.1 - Non autorizzato: accesso non riuscito Questo problema si verifica quando il sito Web utilizza l'autenticazione integrata e ha un nome mappato all'indirizzo di loopback locale.

Nota Questo messaggio di errore viene visualizzato solo se si tenta di esplorare il sito Web direttamente sul server. Se si esplora il sito Web da un computer client, il sito Web funziona come previsto.

CAUSA

Questo problema si verifica se si installa Microsoft Windows XP Service Pack 2 (SP2) o Microsoft Windows Server 2003 Service Pack 1 (SP1). Windows XP SP2 e Windows Server 2003 SP1 includono una funzionalità di sicurezza del controllo di loopback progettata per aiutare a prevenire attacchi di riflessione sul computer. Pertanto, l'autenticazione ha esito negativo se il nome FQDN o l'intestazione host personalizzata utilizzata non corrisponde al nome del computer locale.

Soluzione

  • Metodo 1: disabilita il controllo di loopback
  • Metodo 2: specificare i nomi host

Vedi http://support.microsoft.com/kb/896861 per i dettagli.


Modifica - ho appena notato che hai detto che lo stavi vedendo anche dai PC client ... è più insolito. Ma cercherei comunque di provare una di queste soluzioni alternative, per vedere se il problema è stato corretto (e in tal caso, potrebbe indicare un problema con la tua configurazione DNS).

Mi sembra che tu abbia fatto tutto bene.

Sono sicuro che lo sei, ma ti sei assicurato di utilizzare "DOMINIO \ utente" come account utente e non solo "utente"?

IE7 invia le credenziali di Windows (NTLM, Kerberos) solo se identifica il server come su Intranet. IE7 ha anche aggiunto una funzione di blocco della zona Intranet: se non si è su un dominio, per impostazione predefinita i server no si trovano nella zona Intranet. Ciò è stato fatto per prevenire attacchi di migrazione di zona.

Per modificarlo, vai su Strumenti / Opzioni Internet, scheda Sicurezza, quindi fai clic su Intranet locale. Puoi quindi aggiungere manualmente i server che dovrebbero essere trattati come Intranet, facendo clic sul pulsante Siti, quindi su Avanzate o dicendo a IE di non rilevare automaticamente la tua Intranet e selezionando le altre caselle di controllo appropriate.

Ho appena riscontrato il problema opposto: il mio sito si autentica esternamente ma non localmente.

L'ho confrontato con i siti in cui lavoriamo e la differenza era che il sito che non è riuscito ad autenticarsi utilizzava l'autenticazione di Windows.

Tuttavia, altri siti con cui lavoro (questo è un server di sviluppo) tendono ad avere l'autenticazione di base.

Non so perché esattamente ma questo l'ha risolto.

Tuttavia, allo stesso tempo ho notato " Dominio predefinito " e "Regno" " impostazioni.

So che è molto improbabile, ma potrebbero forse aiutare a tutti?

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top