J
J
Hello,
I have a server application that I'm installing to IIS 7. The server
application will start a new appDomain to run a plug-in and then use that
plug-in's appdomain for processing plug-in related requests.
When I run this application on Cassini, I don't get any errors.
When I run this application on IIS and I initiate a request by clicking on a
link, the operation completes successfully and I don't get any errors.
BUT, I have a System.Timers.Timer that runs in the background as part of the
same web application and can initiate a request internally without user
interaction. The OnTick handler calls into the plug-in's appdomain just the
same way I would if I were clicking a link in the webapp to prompt the
action. Again, on Cassini, this works fine, but in IIS, I get the following
exception at any AppDomain boundary:
System.ArgumentException: "Invalid token for impersonation - it cannot be
duplicated."
at System.Security.Principal.WindowsIdentity.CreateFromToken(IntPtr
userToken)
at System.Security.Principal.WindowsIdentity..ctor(SerializationInfo
info)
By "any app domain boundary" I mean that it doesn't matter whether I'm
trying to setup the AppDomain in response to the first call to the plug-in
being through OnTick event handler, or whether the OnTick event handler is
calling to the plug-in through an already prepared, previously-used and
running plug-in AppDomain. The stack trace shown is the entire stacktrace
for a call into an already running appdomain that has been successfully been
started as a result of manually clicking a link.
var appDomain = AppDomain.CreateDomain(
PlugInName,
null,
setupInformation); // Always succeeds
appDomain.AssemblyResolve += resolver.Resolve; // Fails on IIS unless the
managed stack originates with a request handler. At this point, though,
WindowsIdentity.GetCurrent() returns the same info in either scenario.
I have configured windows authentication on IIS but NOT impersonation. This
certainly seems to me as though it might have something to do with
impersonation (even though I tell it not to) since it only works
"interactively", but I can't figure out what. If I step through either a
manual call or a Tick event handler, the current windows identity comes up
(correctly) as the IIS AppPool account. I don't see any difference in the
current identities between the two scenarios.
The appdomain account is running as a local admin account for now as I work
through some of these issues. I've created two admin accounts, one I'm
logged in as and browsing the website as (and the website is able to
correctly identify me without impersonating me) and the other admin account
is currently set as the appPool account. But I can switch the appPool
account to be the same admin user and there is no change.
By investigating, using Reflector, System.Security.Principal.WindowsIdentity
and the AppDomain.add_AssemblyResolve(), AppDomain.SetAppDomainPolicy(),
AppDomain.CreateInstanceAndUnwrap(), or any of the other appdomain boundary
calls that will through this exception, I don't see any direct calls to new
WindowsIdentity(). Instead, I believe this is being created as part of the
declarative security attributes that are attached to these AppDomain
methods. I mention that in case it helps.
Any help would be appreciated.
Thanks,
JDK
I have a server application that I'm installing to IIS 7. The server
application will start a new appDomain to run a plug-in and then use that
plug-in's appdomain for processing plug-in related requests.
When I run this application on Cassini, I don't get any errors.
When I run this application on IIS and I initiate a request by clicking on a
link, the operation completes successfully and I don't get any errors.
BUT, I have a System.Timers.Timer that runs in the background as part of the
same web application and can initiate a request internally without user
interaction. The OnTick handler calls into the plug-in's appdomain just the
same way I would if I were clicking a link in the webapp to prompt the
action. Again, on Cassini, this works fine, but in IIS, I get the following
exception at any AppDomain boundary:
System.ArgumentException: "Invalid token for impersonation - it cannot be
duplicated."
at System.Security.Principal.WindowsIdentity.CreateFromToken(IntPtr
userToken)
at System.Security.Principal.WindowsIdentity..ctor(SerializationInfo
info)
By "any app domain boundary" I mean that it doesn't matter whether I'm
trying to setup the AppDomain in response to the first call to the plug-in
being through OnTick event handler, or whether the OnTick event handler is
calling to the plug-in through an already prepared, previously-used and
running plug-in AppDomain. The stack trace shown is the entire stacktrace
for a call into an already running appdomain that has been successfully been
started as a result of manually clicking a link.
var appDomain = AppDomain.CreateDomain(
PlugInName,
null,
setupInformation); // Always succeeds
appDomain.AssemblyResolve += resolver.Resolve; // Fails on IIS unless the
managed stack originates with a request handler. At this point, though,
WindowsIdentity.GetCurrent() returns the same info in either scenario.
I have configured windows authentication on IIS but NOT impersonation. This
certainly seems to me as though it might have something to do with
impersonation (even though I tell it not to) since it only works
"interactively", but I can't figure out what. If I step through either a
manual call or a Tick event handler, the current windows identity comes up
(correctly) as the IIS AppPool account. I don't see any difference in the
current identities between the two scenarios.
The appdomain account is running as a local admin account for now as I work
through some of these issues. I've created two admin accounts, one I'm
logged in as and browsing the website as (and the website is able to
correctly identify me without impersonating me) and the other admin account
is currently set as the appPool account. But I can switch the appPool
account to be the same admin user and there is no change.
By investigating, using Reflector, System.Security.Principal.WindowsIdentity
and the AppDomain.add_AssemblyResolve(), AppDomain.SetAppDomainPolicy(),
AppDomain.CreateInstanceAndUnwrap(), or any of the other appdomain boundary
calls that will through this exception, I don't see any direct calls to new
WindowsIdentity(). Instead, I believe this is being created as part of the
declarative security attributes that are attached to these AppDomain
methods. I mention that in case it helps.
Any help would be appreciated.
Thanks,
JDK