9

Ho fatto un sito Intranet ASP.NET MVC 3 con l'autenticazione di Windows attivata:ASP.NET MVC 3 sito Intranet su IIS7.5 w autenticazione di Windows dà 401.3 e l'autorizzazione file non riuscita per la richiesta quando si cerca di accedere a

  1. nelle proprietà del file di Visual Studio progetto
  2. nel web.config, vale a dire <authentication mode="Windows"/>
  3. sulle proprietà del sito in IIS 7.5. server

L'accesso anonimo è disabilitato per tutti questi tre sopra, il web.config dice <deny users="?"/>. La rappresentazione è disabilitata in web.config dall'identità <impersonate="false"/> e nelle proprietà del sito nel server IIS 7.5. E infine, il SERVIZIO DI RETE è impostato per eseguire il pool di app e ha anche letto nella cartella del sito (non sono sicuro se è necessario, mi dici, ma di certo non è sufficiente per risolvere il mio problema di seguito).

Ora, quando si accede tramite la finestra di dialogo Autenticazione standard di Windows, agli utenti del dominio viene presentato un errore 401.3 dopo tre tentativi di accesso validi. Questo sembra essere prima ancora di raggiungere il codice del mio sito MVC, cioè sembra completamente collegato a IIS. Il registro eventi dà la seguente tipo di ingresso (è una voce Informazioni, non un errore, e ho offuscato un po 'per proteggere il mio cliente) per tutti gli utenti che ha provato ad accedere:

Event code: 4008 
Event message: File authorization failed for the request. 
Event time: 2012-02-20 18:45:41 
Event time (UTC): 2012-02-20 17:45:41 
Event ID: 6dd3b4bf99784ba1a0fe06694dd89691 
Event sequence: 3 
Event occurrence: 1 
Event detail code: 0 
Application information: 
Application domain: /LM/W3SVC/2/ROOT-1-129742335229554599 
Trust level: Full 
Application Virtual Path:/
Application Path: D:\Public\BlahblahManager\ 
Machine name: HUB01-XYZ123 
Process information: 
Process ID: 2920 
Process name: w3wp.exe 
Account name: NT AUTHORITY\NETWORK SERVICE 
Request information: 
Request URL: http://blahblahmanager.user.ad.blah.com/ 
Request path:/
User host address: 134.XXX.XXX.XXX 
User: USER-AD\teh-user 
Is authenticated: True 
Authentication Type: Negotiate 
Thread account name: NT AUTHORITY\NETWORK SERVICE 
Custom event details: 

È solo quando concedo esplicitamente agli utenti USER-AD\teh-user o USER-AD\Domain l'autorizzazione Read nella cartella principale del sito (D: \ Public \ BlahblahManager) che l'utente può accedere e vedere effettivamente il sito.

Perché è questo? Ci deve essere una sorta di configurazione che mi manca. Non dovrebbe essere sufficiente che il SERVIZIO DI RETE abbia letto nella cartella principale del sito? L'ho cercato su Google per un po 'e l'imitazione è menzionata qui e là, ma la giuria è ancora fuori sembra. Alcuni siti affermano che si dovrebbe andare con la rappresentazione e forniscono esempi su come farlo, ma quando provo gli esempi non funziona ancora. Altri siti dicono che la rappresentazione NON è la strada da percorrere e che è necessario concedere le autorizzazioni della cartella in questi casi. Ma sembra una cosa strana da fare. Gli utenti non hanno attività sul server attuale, dovrebbero funzionare solo attraverso il sito web.

Qualche suggerimento? Qual è in genere la quantità minima di configurazione necessaria per farlo funzionare? Qualche consiglio su come risolvere questo tipo di problema e arrivare alla causa principale?

+0

Hai mai risolto questo problema? – DaveHogan

+0

L'ho risolto con un work-around che non aiuta nel caso generale (molto specifico per il cliente). (Le risposte suggerite finora non sono state d'aiuto purtroppo :( –

+0

Ho lo stesso problema (errori di "Errore file non riuscito per la richiesta" con utente autenticato elencato e Servizio di rete come identità thread, pool di app in esecuzione come NetworkService, IIS 7.5, errore 401 dopo inserire le credenziali) Attualmente il mio unico modo per aggirarlo è garantire a tutti (oa un gruppo specifico di utenti) l'accesso ai file, che sembra una soluzione terribile. Ho installato la stessa app su dozzine di server clienti e non ho avuto bisogno di Forse è qualcosa di peculiare di IIS 7.5, anche se ho già installato lì e non ricordo questo problema – Rory

risposta

1

Controllo doppio L'autenticazione anonima è abilitata su IIS. Also, have a look at this post.

+1

Perché l'anonimato deve essere abilitato? L'OP ha detto esplicitamente che è disabilitato, poiché è richiesta l'autenticazione di Windows. – Rory

2

Mi riferisco per vedere questo post che dichiara tutti i metodi di autenticazione MVC. ma assicurati di aver abilitato l'autenticazione minima richiesta sulla tua applicazione mvc. Si noti che l'autenticazione anonima funziona con le politiche del gruppo. puoi configurarlo seguendo le seguenti: Opzioni Internet -> Scheda Sicurezza -> Intranet locale -> Livello personalizzato, sul tuo browser.

1- Un'altra cosa che può causare il problema è che IIS potrebbe non essere configurato per utenti collegati autorizzati.Alcuni di essi sono:

  • IISService
  • IUSR
  • IIS_IUSRS
  • Network Service

2- verbi anche controllare consentiti in IIS.

3- Sulla cartella radice dell'applicazione Dare accesso in lettura a IIS AppPool \ YourAppPool.

4- Un'altra causa potrebbe essere che le regole di accesso gerarchico nell'applicazione dipendono da quali servizi dell'applicazione si stanno utilizzando, come le regole di accesso al pannello del sito Web.

5- Setting the clientaccesspolicy.xml file.

6- Controllare InitializeService() metodo, si fa a impostare correttamente le regole di accesso entità? Ad esempio:

config.SetEntitySetAccessRule("*", EntitySetRights.All); 

7- Controllare il modulo FileAuthentication a livello di sito Web.

0

Abbiamo anche combattuto con questo problema e abbiamo iniziato a configurare gruppi di sicurezza in modo da poter fornire ai nostri utenti autorizzazioni a livello di file. Quindi, uno dei nostri amministratori di server si è imbattuto in un paio di nuove proprietà che consentono all'app di autenticare il file system in base alle credenziali impostate e ha risolto la necessità per gli utenti di accedere. Ecco cosa è venuto con ...

Ci sono due impostazioni di IIS che controllano questo:

credenziali percorso fisico credenziali percorso fisico di accesso di tipo

Per impostazione predefinita, le credenziali percorso fisico è impostato all'applicazione utente (autenticazione pass-through). Ciò significa che IIS non esegue alcuna rappresentazione durante la gestione delle richieste di autenticazione di Windows. Questo può, tuttavia, essere impostato su un utente specifico (anche se, sfortunatamente, non è l'identità del pool di applicazioni , che sarebbe l'ideale). Percorso fisico Le credenziali Tipo di accesso è impostato per impostazione predefinita su Cancella testo. Per il mio test ho impostato su Interattivo (anche se questo potrebbe non essere il valore corretto). I valori possibili sono Clear-Text, Batch, Interactive e Network.

Per impostare questa funzione ho fatto la seguente:

  1. Creato un account locale (IIS-AccessUser)
  2. Certo IIS-AccessUser leggere ed eseguire l'accesso alla home directory del sito /.
  3. Aggiunto IIS-AccessUser al gruppo IIS_IUSRS (necessario per l'accesso.i file temporanei NET)
  4. Set IIS-AccessUser le credenziali percorso fisico
  5. impostare le credenziali percorso fisico Tipo di accesso a Interactive

fare quanto sopra mi ha permesso di login per l'applicazione direttamente, senza dover consentire agli utenti autenticati o a me di essere un membro di uno dei gruppi nella cartella/home. Rimaneva anche il ruoli di autorizzazione .NET conservati, quindi non riuscivo ancora ad accedere alle parti del sito a cui non ero autorizzato.

0

Ho anche affrontato lo stesso problema su IIS7 con l'autenticazione di Windows, ma con con MVC4. Finalmente trovato questo post. Spero che questo possa aiutare qualcuno in futuro.

0

Non è necessario concedere autorizzazioni di accesso ai file quando si utilizza l'autenticazione di Windows in IIS 7.0 e IIS 7.5.

C'è un modo migliore che siamo stati in grado di scoprire solo perché il nostro amministratore del server ha avvertito i problemi di sicurezza e di gestione derivanti dall'assumere il percorso di concessione dell'accesso a livello di file a utenti e gruppi.

Per chiunque si occupi di questo problema o se si sta configurando un nuovo server IIS7/IIS7.5 e/o si passa da IIS 6, ecco un articolo che fornisce tutte le opzioni di autenticazione di Windows e le configurazioni necessarie per essere modificato per evitare di concedere l'accesso a livello di file a singoli o gruppi.

Leggere i due commenti alla fine del POST per alcune critiche valide dei metodi utilizzati in questo articolo.

http://weblogs.asp.net/owscott/iis-using-windows-authentication-with-minimal-permissions-granted-to-disk

In aggiunta alle informazioni in questo articolo, si prega di essere consapevole del fatto che IIS 7.5 non utilizza i tag di configurazione Web per system.web (almeno non nella mia applicazione MVC 4).

Cerca nei tag system.webserver per la configurazione dell'autorizzazione (dove è necessario elencare il dominio windows \ gruppi a cui un utente deve accedere per accedere all'applicazione).

- DSB