Autorizzazioni IIS AppPoolIdentity e file system per l'accesso in scrittura

Ecco un problema con IIS 7.5 e ASP.NET con cui ho cercato e non ho trovato nulla. Qualsiasi aiuto sarebbe molto apprezzato.

La mia domanda è: utilizzando ASP.NET in IIS 7.5, in che modo IIS e / o il sistema operativo consentono all'applicazione Web di scrivere in una cartella come C:\dumpquando si esegue in piena fiducia? Come mai non devo aggiungere esplicitamente l'accesso in scrittura per l'utente del pool di applicazioni (in questo caso ApplicationPoolIdentity)?

Questo lo so:

• In IIS 7.5, l'identità predefinita per un pool di applicazioni è ApplicationPoolIdentity.
• ApplicationPoolIdentity rappresenta un account utente di Windows chiamato "IIS APPPOOL \ AppPoolName", che viene creato quando viene creato il pool di applicazioni, dove AppPoolName è il nome del pool di applicazioni.
• L'utente "IIS APPPOOL \ AppPoolName" è un membro predefinito del IIS_IUSRSgruppo.
• Se si esegue in Full Trust, l'applicazione web può scrivere a molte aree del file system (escluse le cartelle come C:\Users, C:\Windows, ecc). Ad esempio, l'applicazione avrà accesso per scrivere in alcune cartelle, ad esempio C:\dump.
• Per impostazione predefinita, al IIS_IUSRSgruppo non viene concesso l'accesso in lettura o scrittura C:\dump(almeno non l'accesso visibile attraverso la scheda "Sicurezza" in Esplora risorse).
• Se neghi l'accesso in scrittura IIS_IUSRS, otterrai SecurityException quando provi a scrivere nella cartella (come previsto).

Quindi, tenendo conto di tutto ciò, come viene concesso l'accesso in scrittura all'utente "IIS APPPOOL \ AppPoolName"? Il processo w3wp.exe viene eseguito come questo utente, quindi cosa consente a questo utente di scrivere in una cartella a cui non sembra avere accesso esplicito?

Si noti che capisco che probabilmente è stato fatto per comodità, dal momento che sarebbe un problema concedere a un utente l'accesso a tutte le cartelle in cui è necessario scrivere se si esegue in Full Trust. Se si desidera limitare questo accesso, è sempre possibile eseguire l'applicazione in Trust medio. Sono interessato a scoprire come il sistema operativo e / o IIS consentono l'esecuzione di queste scritture, anche se sembra che non sia concesso alcun accesso esplicito al file system.

Il ApplicationPoolIdentityviene assegnato l'appartenenza del Usersgruppo così come il IIS_IUSRSgruppo. A prima vista questo può sembrare un po 'preoccupante, tuttavia il Usersgruppo ha diritti NTFS piuttosto limitati.

Ad esempio, se provi a creare una cartella nella C:\Windowscartella, scoprirai che non puoi. Deve ApplicationPoolIdentitycomunque essere in grado di leggere i file dalle cartelle di sistema di Windows (altrimenti come altrimenti il ​​processo di lavoro sarebbe in grado di caricare dinamicamente le DLL essenziali).

Per quanto riguarda le tue osservazioni su come poter scrivere nella tua c:\dumpcartella. Se dai un'occhiata alle autorizzazioni nelle Impostazioni di sicurezza avanzate, vedrai quanto segue:

Vedi quel permesso speciale ereditato da c:\:

Questo è il motivo per cui il tuo sito ApplicationPoolIdentitypuò leggere e scrivere in quella cartella. Tale diritto viene ereditato c:\dall'unità.

In un ambiente condiviso in cui è possibile avere diverse centinaia di siti, ognuno con il proprio pool di applicazioni e identità del pool di applicazioni, è necessario archiviare le cartelle del sito in una cartella o volume in cui è stato Usersrimosso il gruppo e le autorizzazioni impostate in modo tale che solo gli amministratori e il L'account SYSTEM ha accesso (con ereditarietà).

Assegnereste quindi individualmente le autorizzazioni necessarie che ciascuna IIS AppPool\[name]richiede sulla propria cartella principale del sito.

È inoltre necessario assicurarsi che tutte le cartelle create in cui vengono archiviati file o dati potenzialmente riservati siano Usersrimosse dal gruppo. È inoltre necessario assicurarsi che le applicazioni installate non memorizzino i dati sensibili nelle loro c:\program files\[app name]cartelle e che invece utilizzino le cartelle del profilo utente.

Quindi sì, a prima vista sembra che ApplicationPoolIdentityabbia più diritti di quanto dovrebbe, ma in realtà non ha più diritti di quanto imponga l'appartenenza al gruppo.

Un ApplicationPoolIdentityappartenenza al gruppo 's può essere esaminato utilizzando le Sysinternals Process Explorer strumento . Trova il processo di lavoro in esecuzione con l'identità del pool di applicazioni che ti interessa (dovrai aggiungere la User Namecolonna all'elenco di colonne per visualizzare:

Ad esempio, ho un pool qui denominato 900300che ha un'identità del pool di applicazioni di IIS APPPOOL\900300. Facendo clic destro sulle proprietà per il processo e selezionando la scheda Sicurezza vediamo:

Come possiamo vedere IIS APPPOOL\900300è un membro del Usersgruppo.

1. Fare clic con il tasto destro sulla cartella.

2. Fai clic su Proprietà

3. Fai clic sulla scheda Sicurezza. Vedrai qualcosa del genere:

4. Fai clic sul pulsante "Modifica ..." nella schermata sopra. Vedrai qualcosa del genere:

5. Fai clic sul pulsante "Aggiungi ..." nella schermata sopra. Vedrai qualcosa del genere:

6. Fai clic sul pulsante "Posizioni ..." nella schermata sopra. Vedrai qualcosa del genere. Ora, vai all'inizio della struttura ad albero e seleziona il nome del tuo computer, quindi fai clic su OK.

7. Ora digita "iis apppool \ your_apppool_name" e fai clic sul pulsante "Controlla nomi". Se l'apppool esiste, vedrai il nome del tuo apppool nella casella di testo con sottolineato. Fai clic sul pulsante OK.

8. Seleziona / deseleziona qualsiasi accesso sia necessario concedere all'account

9. Fai clic sul pulsante Applica e poi su OK.

Ogni pool di applicazioni in IIs crea la propria cartella utente protetta con l'autorizzazione FULL di lettura / scrittura per impostazione predefinita in c: \ users. Aprire la cartella Utenti e vedere quali cartelle del pool di applicazioni sono presenti, fare clic con il pulsante destro del mouse e controllare i loro diritti per l'account virtuale del pool di applicazioni assegnato. Dovresti vedere l'account del tuo pool di applicazioni già aggiunto con accesso in lettura / scrittura assegnato alla sua radice e alle sue sottocartelle.

Quindi quel tipo di accesso all'archiviazione dei file viene eseguito automaticamente e dovresti essere in grado di scrivere quello che ti piace nelle cartelle degli account utente dei pool di app senza modificare nulla. Ecco perché sono stati creati account utente virtuali per ciascun pool di applicazioni.

Ho provato questo per risolvere i problemi di accesso a un sito Web IIS, che si manifestava come qualcosa di simile nei registri eventi → Windows → Applicazione:

Nome registro: applicazione
Fonte: ASP.NET 4.0.30319.0
Data: 1/5/2012 16:12:33
ID evento: 1314
Categoria di attività: Evento Web
Livello: informazioni
Parole chiave: classico
Utente: N / A
Computer: SALTIIS01

Descrizione:
Codice evento: 4008 
Messaggio di evento: autorizzazione file non riuscita per la richiesta. 
Ora dell'evento: 05/01/2012 16:12:33 
Ora dell'evento (UTC): 06/01/2012 00:12:33 
ID evento: 349fcb2ec3c24b16a862f6eb9b23dd6c 
Sequenza eventi: 7 
Evento: 3 
Codice dettaglio evento: 0 

Informazioni sull'applicazione: 
    Dominio applicazione: / LM / W3SVC / 2 / ROOT / Applicazione / SNCDW-19-129702818025409890 
    Livello di fiducia: completo 
    Percorso virtuale dell'applicazione: / Applicazione / SNCDW 
    Percorso applicazione: D: \ Sites \ WCF \ Application \ SNCDW \ 
    Nome macchina: SALTIIS01 

Informazioni sul processo: 
    ID processo: 1896 
    Nome del processo: w3wp.exe 
    Nome account: iisservice 

Richiesta di informazioni: 
    URL richiesta: http: //webservicestest/Application/SNCDW/PC.svc 
    Percorso richiesta: /Application/SNCDW/PC.svc 
    Indirizzo host utente: 10.60.16.79 
    Utente: js3228 
    È autenticato: vero 
    Tipo di autenticazione: negoziazione 
    Nome account discussione: iisservice 

Alla fine ho dovuto dare al Everyonegruppo di Windows l' accesso in lettura a quella cartella per farlo funzionare correttamente.