DefaultAppPool viene eseguito con privilegi speciali elevati su IIS?

Question

Sto eseguendo un pezzo di codice all'interno di una pagina Web che interroga il metabase di IIS utilizzando ADSI. Il codice è semplice come questo:

 DirectoryEntry iisNode = 
     new DirectoryEntry("/LM/W3SVC/1/ROOT/MyAspWebsite-1-128886021498831845"); 
     foreach (DirectoryEntry de in iisNode.Parent.Children) 
     { 
      System.Console.WriteLine(de.Name); 
     } 

Questo funziona bene quando faccio funzionare la pagina/sito sotto la DefaultAppPool su IIS7/W2K8. Tuttavia quando creo la mia propria piscina app e lascio le proprietà lo stesso come il pool di app di default, questo codice non riesce con il seguente errore:

Caught: System.Runtime.InteropServices.COMException 
Failed to parse virtual directory: 
     /LM/W3SVC/1/ROOT/MyAspWebsite-1-128889542757187500 
System.Runtime.InteropServices.COMException (0x80070005): Access is denied. 

Quali privilegi speciale fa il DefaultAppPool ha? Non vedo alcun documento. Ho bisogno che funzioni nei pool di app non predefiniti, ma senza dando all'intero processo di lavoro privilegi elevati. Ho anche provato a utilizzare i parametri username e password del costruttore DirectoryEntry, utilizzando l'Admin sul computer su cui IIS7 è in esecuzione, ma che non ha modificato nulla. Noterò anche che questo funziona fine su IIS6 e W2K3.

Qualsiasi aiuto è apprezzato.

Answer 1

Potrebbe non rendersene conto, ma l'identità effettiva che esegue il codice potrebbe non essere uguale a quella elencata per w3wp.exe in Process Explorer. È necessario impostare un punto di interruzione o eseguire WindowsIdentity.GetCurrent().Name vicino alla riga di codice incriminata (DirectoryEntry.Parent.Children) che genera la violazione di COMException/"Accesso negato".

Ad esempio, per me, il processo del mio pool di app, w3wp.exe, era in esecuzione come NETWORK SERVICE nella finestra del Task Manager, come descritto sopra. Tuttavia, quando ho controllato l'effettiva identità di runtime, si è scoperto che era il nuovo utente integrato di IIS7 IUSR, che era diverso dal valore che avrei ottenuto in IIS6, che era NETWORK SERVICE.

using System.Security.Principal; 

Console.WriteLine(
    WindowsIdentity.GetCurrent().Name); // IUSR on IIS7, NETWORKSERVICE on IIS6 
foreach (var de in DirectoryEntry("/LM/W3SVC/1/ROOT/MySite".Parent.Children)) 
{ 
    System.Console.WriteLine(de.Name); 
} 

Sembra che in IIS6, SERVIZIO DI RETE aveva il permesso di esplorare la IIS Metabase attraverso la Directory Service Active Interface (ADSI) con la classe DirectoryEntry. La nuova identità IUSR in IIS7, tuttavia, non lo è. Al fine di eseguire il codice di cui sopra, si dovrà direttamente impersonate an account con esistente ADSI privilegi di lettura, ad esempio:

using (new MyImpersonationWrapper("admin","pass")) 
{ 
    foreach (var de in DirectoryEntry("/LM/W3SVC/1/ROOT/MySite".Parent.Children)) 
    { 
     System.Console.WriteLine(de.Name); 
    } 
} 

Implementare il proprio involucro rappresentazione e protezione di un account locale corretto è un esercizio Lascio a tu, come il tuo (sicurezza) esigenze possono variare.

In alternativa, è possibile cercare le informazioni desiderate utilizzando WMI provider for IIS7 come suggested on this MSDN blog post.

Answer 2

Vorrei controllare il percorso in cui si sta accedendo alla voce della directory. È possibile che tu possa avere un servizio in conflitto. Controlla il tuo visualizzatore di eventi.

Questo collegamento va a qualcuno che ha avuto un problema simile e ha scoperto che because Skype was running on port 80 it was causing a conflict with the path.

Ma la vera risposta alla tua domanda è "No, non c'è niente di speciale per il pool di app di default".

Answer 3

Vorrei verificare che l'utente NetWorkServices abbia accesso alle directory fisiche a cui sta tentando di accedere. Appare dall'errore che stai accedendo a siti diversi sotto quello che funziona e uno che non lo fa, è corretto?

Come affermato da parte dell'utente precedente non v'è niente di speciale l'AppPool predefinito e uno si crea (a meno che non si modificano le impostazioni del costume AppPool. IIS non utilizzare i permessi di qualsiasi utente è configurato per eseguire l'AppPool sotto.

Answer 4

è un po 'difficile da dire dalla tua descrizione esattamente quello che potrebbe essere in corso ma da quello che ho capito di avere una configurazione come questa:

DefaultWebSite 
    | 
    +-- VirtualDirectory 
     | 
     +-- ShowIISMetaData.aspx 

credo che il problema è che la pagina che si suppone mostra che MetaData di IIS sta tentando di guardare ai figli del suo genitore (in altre parole i suoi fratelli).

foreach (DirectoryEntry de in iisNode.Parent.Children) 

questo funziona solo se il pool di applicazioni per il sito Web predefinito e la directory virtuale sono gli stessi piscina fisico.

Answer 5

In questo numero mancano alcune informazioni. Entrambi gli account sono in esecuzione con lo stesso account utente, quindi il comportamento dovrebbe essere lo stesso. Ti suggerisco di provare a eseguire il codice con un'installazione vaniglia di IIS, il problema si verifica ancora?

Come altri hanno fatto riferimento, se i conti sono uguali, è perché è stata apportata qualche modifica alla metabase.

Answer 6

Le credenziali associate al pool di applicazioni saranno quelle utilizzate durante il tentativo di interrogare AD.Quindi, se entrambi i pool di app sono in esecuzione con le stesse credenziali, questo non è un problema.

Sono disponibili impostazioni di autenticazione diverse nei siti di test? Se, ad esempio, hai integrato selezionato su uno e non su un altro ... questo potrebbe spiegare il comportamento che stai riscontrando.