Identity Flow Through Physical Tiers - Protocol Transition
If these articles:
- How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0
- Using Protocol Transition—Tips from the Trenches
are your friends then do not waste your time on this post, please.
The scenario is the same where user sits behind her machine A and access simple ASPX page on box B that access file on share on box C, like this:
What I have so far is:
- Identity Flow Through Physical Tiers - works fine, network resource (the file on network share) accessed by app pool account
- Identity Flow Through Physical Tiers - Impersonation - does not work
- Identity Flow Through Physical Tiers - Delegation- works great and the network resource is accessed by end sure's account
Now I have scenario where employee that tries to access corporate web site she used to use while inside corp walls but this time over Internet.
Another scenario would be where my customers access my web site from Internet and I manage customers identity store using Active Directory (not as just LDAP store rather full blown AD Domain, for LDAP store use ADAM - free download).
I presume in these scenarios the web site would be accessible only over port 443 (default SSL port) - no chance for Windows integrated authentication (which only supported by limited number of browsers... I mean authentication, not SSL).
Here comes in Protocol Transition (PT). Windows 2003 has cool feature - creating windows security context out of thin air - no password and LogonUser WIN API call required....
Keith Brown goes really deep while Exploring S4U Kerberos Extensions in Windows Server 2003
I go for it, here some additions to what was already done in Identity Flow Through Physical Tiers - Delegation:
- Get rid of all or nothing impersonation in web.config:
- Configure both app pool account and the server to support constrained delegation for non-Kerberos authentication using Active Directory users and Computers MMC (CIFS stands for the Common Internet File System, the name of the Microsoft® file server - from Using Protocol Transition—Tips from the Trenches)
- That's scary a bit one - define app pool account to "Act as part of OS" using Local Security Policy MMC on web server (why it is scare and how to handle it - see Using Protocol Transition—Tips from the Trenches)
- Add code that actually utilize Protocol Transition creating WindowsIdentity based on UPN (user principal name) that came in after custom authentication and explicitly impersonate the thread before accessing network resource - our file on share:
string upn = txtCustomUPN.Text;//CAN COME FROM ANY PLACE
//DO INPUT VALIDATION HERE!!!!!
WindowsIdentity wi = new WindowsIdentity(upn);
WindowsPrincipal wp = new WindowsPrincipal(wi);
HttpContext.Current.User = wp;
WindowsImpersonationContext wic = wi.Impersonate();
// ACCESS NETWORK RESOURCE
wic.Undo();
No when I ran my app here is what I get (no impersonation):
Now I simulate passing UPN that came from custom authentication (xacker@demo.lab is valid AD account):
the code above is ran after pressing "Protocol Transition" button
and here is the result of access audit:
Techniques for file access audit are here:
Enjoy