SharePoint 2013/IIS 7.5 Impersonation/Delegation/Double Hop

Question

Ok, ho impiegato circa 15 ore a provare a risolvere questo problema e sono finalmente stato rassegnato a postare qui per cercare di risolverlo. So che questo post è molto lungo ma ho fatto tutte le normali cose che mi verrà detto di provare, quindi voglio assicurarmi che sia chiaro, quindi non perdiamo tempo a riguardo.

Ho una macchina virtuale Win Server 2008 R2 ospitata su un server ESXi 5.0. Su questo server ho installato l'anteprima di SharePoint Foundation 2013 e tutti i pre-requisiti, ecc. Sto eseguendo tutto da questo server (MSSQL, IIS 7.5, servizi di SharePoint) poiché avremo un utilizzo molto limitato e avremo solo circa 30 utenti. Una cosa che ho disperatamente bisogno di aggiungere a SharePoint è la possibilità per gli utenti di modificare le loro informazioni in Active Directory (Server 2003) poiché il nostro annuncio è poco popolato ed è obsoleto. Ho trovato una WebPart perfetta e funziona meravigliosamente per la modifica degli utenti.

Il problema si presenta quando voglio configurare la WebPart per consentire all'utente di modificare solo se stessi. La WebPart (correttamente) utilizza questa riga di codice in C# .NET :. per ottenere l'identità attualmente connessa che è stata autenticata con l'autenticazione di Windows in IIS. Invece, ciò restituisce l'utente locale NT AUTHORITY/IUSR. (So ​​che questa non è una novità per nessuno).

System.Security.Principal.WindowsIdentity.GetCurrent().Name;

Così ho iniziato la mia ricerca e ha fatto in modo delle seguenti cose.

Nel mio web.config per SharePoint, ho il seguente:

<authentication mode="Windows" /> <identity impersonate="true" />

In IIS, ho le seguenti impostazioni di autenticazione per il sito IIS che ospita l'installazione di SharePoint:

Anonymous Authentication Disabled 
ASP.NET Impersonation  Enabled 
Basic Authentication  Disabled HTTP 401 Challenge 
Digest Authentication  Disabled HTTP 401 Challenge 
Forms Authentication  Disabled HTTP 302 Login/Redirect 
Windows Authentication  Enabled  HTTP 401 Challenge 

Quindi so che il sito sta ancora effettuando l'accesso con l'utente anonimo anche se l'autenticazione anonima è disabilitata. Mi sono imbattuto in informazioni sul problema del doppio salto che corrisponde ai miei problemi e ho trovato questo link e ho seguito tutte le indicazioni in questo post: http://blogs.technet.com/b/taraj/archive/2009/01/29/checklist-for-double-hop-issues-iis-and-sql-server.aspx. Dopo ogni passaggio, ho verificato eventuali cambiamenti nel comportamento dell'applicazione, ma non ne ho mai trovato nessuno.

In sintesi ho fatto la seguente:

1. ho creato un account utente di dominio per eseguire il pool di applicazioni. Per il test, ho fatto di questo utente un membro del gruppo Domain Admins.
2. Ho modificato una riga in web.config su <add key="aspnet:AllowAnonymousImpersonation" value="false" /> (era vero). Ciò impediva all'utente NT AUTHORITY \ IUSR di eseguire l'applicazione e invece veniva eseguito con l'account di dominio creato per eseguire il pool di app. Ora potevo accedere a SharePoint e accedere alla mia WebPart, tuttavia, come previsto, mi ha presentato le informazioni di AD per l'utente del dominio che eseguiva il pool di app, piuttosto che l'utente del dominio che si era autenticato. Quindi so che WebPart funziona e ha le autorizzazioni necessarie ecc. Ma System.Security.Principal.WindowsIdentity.GetCurrent().Name; sta ancora restituendo l'utente che sta eseguendo il pool di app, ad es.la rappresentazione non funziona ancora
3. In Utenti e computer AD, ho concesso Trust this computer for delegation to any service per il server virtuale su cui viene eseguito tutto questo.
4. Poiché non disponevo della scheda "Delega" per l'account utente del dominio che eseguiva il pool di app, ho dovuto registrare un SPN per l'utente. Dopo aver registrato tutti gli SPN copiati dall'elenco di SPN del server e anche un paio di SPN http che ho trovato online, e anche l'impostazione di Trust this user for delegation to any service sull'utente, non si sono verificati cambiamenti nel comportamento dell'applicazione.
5. Mi sono assicurato che l'utente del dominio con cui stavo effettuando l'accesso non fosse protetto dalla delega
6. Sono entrato nell'editor dei criteri locali sul server SharePoint e mi sono assicurato che l'utente del dominio che eseguiva il pool di app fosse autorizzato a "Agisci come parte del sistema operativo "e" Impersonare un client dopo l'autenticazione ".
7. Altre cose che ho provato
   • Aggiungi Negotiate:Kerberos come un provider di autenticazione per Windows Auth sul sito web IIS
   • Confermata la presenza di queste due linee in SharePoint web.config:
     

Di seguito sono i miei record SPN sul DC:

setspn -l SPserver 
Registered ServicePrincipalNames for CN=SPserver,CN=Computers,DC=DOMAIN,DC=local: 
    MSSQLSvc/SPserver.DOMAIN.local:appPoolUser 
    WSMAN/SPserver 
    WSMAN/SPserver.DOMAIN.local 
    TERMSRV/SPserver 
    TERMSRV/SPserver.DOMAIN.local 
    RestrictedKrbHost/SPserver 
    HOST/SPserver 
    RestrictedKrbHost/SPserver.DOMAIN.local 
    HOST/SPserver.DOMAIN.local 



setspn -l appPoolUser 
Registered ServicePrincipalNames for CN=appPoolUser,OU=Utility,OU=Users,OU=Company Name,DC=DOMAIN,DC=local: 
    http/subdomain.domain.com 
    http/SPserver.DOMAIN.local 
    RestrictedKrbHost/appPoolUser.DOMAIN.local 
    RestrictedKrbHost/appPoolUser 
    MSSQLSvc/appPoolUser.DOMAIN.local:appPoolUser 
    HOST/appPoolUser 
    HOST/appPoolUser.DOMAIN.local 

Ho riavviato il server e IIS diverse volte durante questo processo. Ancora quando accedo, la mia web part mi identifica come utente che esegue il pool di applicazioni. So che ci sono dei problemi come usare un pool di app in modalità Classic ma che è deprecato. Ci sono altri modi per ottenere il nome corretto in .NET, ma non voglio dover cambiare la web part e, cosa più importante, questo è il modo corretto per farlo e dovrei riuscire a farlo funzionare. Non voglio dover continuamente aggirarlo.

Se qualcuno ha altre idee su cosa potrebbe causare il problema, mi piacerebbe ascoltarle.

Answer 1

Non sicuro se il problema persiste, il seguente post potrebbe essere di aiuto. Double Hop Impersonation, Protocol Transitioning and Constrained Delegation in ASP.NET 4