Szenario:
IIS >= 7.5, ASP oder ASP.NET Applikation, Windows Authentication (damit man in der Applikation weiß wer da daher kommt) aber hinten raus soll beim Zugriff auf weitere (Remote-)Resourcen die Identität des Application Pools und nicht der authentifizierte Benutzer verwendet werden.

Hintergrund:
a) Minimalrechte für Application Pool Identity und nicht die Notwendigkeit die authentifizierten Benutzer auf die Files und andere Resourcen die die WebApp braucht zu berechtigen.
b) Application Pool Identity hat Rechte auf Resourcen die die authentifizierten Benutzer nicht haben – die Applikation muss dann natürlich checken ob der aufrufende Benutzer überhaupt das darf was er da gerne hätte.

Problem:
IIS nutzt per Default den authentifizierten Benutzer für die Zugriffe (egal ob lokal oder remote) – was bei Remotezugriffen zum double-hop-Problem führt und damit auf dem direkten Weg in die Kerberos Hölle (oder der aufrufende Benutzer hat überhaupt nicht die notwendigen Rechte auf der Remoteresource, selbst wenn Kerberos Delegation mal ausnahmsweise funktionieren würde).

Lösung:
a) Application Pool Identity setzen.
b) Windows Auth einschalten (alle anderen ab)
c) URL Authorization Regeln für die Benutzer erstellen die dürfen erstellen
OPTIONAL: Über ServerVariables Collection kann mit Item „LOGON_USER“ auf den authentifizierten Benutzer zugegriffen werden (nicht „REMOTE_USER“ – der ist fix mit der AppPool Identity belegt) – und damit können in der Applikation dann Zugriffsentscheidungen getroffen werden. Der ASP.NET Role Provider funktioniert NICHT!
d) Im IIS Manager/Site/Configuration Editor unter system.webServer/serverRuntime den Eintrag authenticatedUserOverride auf "UseWorkerProcessUser" umstellen

Credits: Scott Forsyth’s Blog