I'll start out by saying - I hate the approach we are using. ;)
We setup IIS behind an F5, using a shared domain account to run the AppPool - so there is a single account passing the user credentials to the web. Because, Kerberos.
With all the hosts configured with non-kernel mode auth, https bindings set, and the required SPN's for flavor. Our users login with PIV to their PC, launch the browser (ie) with elevated creds - using runas from the command line or right-click/runas a different user from the shortcut icon.
the web interface accepts the pass through credentials of the connected user.
The site is available to their non-priv account, without providing any privileges other than read. When their browser connects in elevated priv mode, then their delegated rights are served up all steamy with a side of rice.
One missing-link in the ARS world, is a proper challenge from the ARS web site to ask for PIV/PIN and username hint. Give me that, and I'll be happy - too.
I'll start out by saying - I hate the approach we are using. ;)
We setup IIS behind an F5, using a shared domain account to run the AppPool - so there is a single account passing the user credentials to the web. Because, Kerberos.
With all the hosts configured with non-kernel mode auth, https bindings set, and the required SPN's for flavor. Our users login with PIV to their PC, launch the browser (ie) with elevated creds - using runas from the command line or right-click/runas a different user from the shortcut icon.
the web interface accepts the pass through credentials of the connected user.
The site is available to their non-priv account, without providing any privileges other than read. When their browser connects in elevated priv mode, then their delegated rights are served up all steamy with a side of rice.
One missing-link in the ARS world, is a proper challenge from the ARS web site to ask for PIV/PIN and username hint. Give me that, and I'll be happy - too.
