I have a problem with a service-oriented application that is using
impersonation.

MachineA (Web Server) - Hosts webservices
MachineB (App Server) - Talks to multiple types of resources (SQL,
WMI, HTTP).

MachineA remotes to MachineB (remoting is hosted via IIS).

MachineA and MachineB have IIS using Anonymous w/ a service account
(MyUser1). The web.config for both MachineA and MachineB are using
<identity impersonate="true" />.

The ASPNet account uses default settings (MACHINE / AUTOGENERATE).

When I call a web service on MachineA communication with MachineB
occurs correctly. When MachineB calls a remote resource (say WMI on
MachineC), the call occurs correctly and I get a valid response. On
first glance everything looks wonderful.

After a short number of requests, the ASPNet account on MachineC will
become locked out. When I look at the security audit logs on
MachineC, I see the logon from the expected identity (MyUser1), BUT I
also see a failed logon attempt from MachineB/ASPNet.

It looks like for some reason, MachineB is still flowing it's own
ASPNet process identity (in addition to the impersonated user) and is
unable to authenticate (MachineB/ASPNet will not have the same
password as MachineC/ASPNet).

Why would this happen? MachineB communicates with MachineC using a
variety of different mechanisms (SQL via ADO.Net, WMI, and HTTP).
When making the SQL or WMI calls I see this behavior, with the HTTP I
don't.

Any ideas? It seems like I'm missing something really simple here.

- Ben