Many thanks to all who have considered and helped with this issue. As near as we can tell it is sort of user corruption. We are not sure if it was on the domain or cached on the web server. After a couple days of troubleshooting, we decided to make a copy of the domain service account that we are using to run the App Pool. Switched the App Pool to run as the new account and it worked. Did not change a single setting on the new user, just copied the existing user. Still does not explain why the local admin account would not work. Grrrrr!
Jarod, just to clarify the cosign log was populated, but no errors. ----- Original Message ---- From: Jarod Malestein <[email protected]> To: Mike Gallo <[email protected]> Cc: [email protected] Sent: Wed, October 7, 2009 3:34:30 PM Subject: Re: [Cosign-discuss] Strange Permission Issue Hello, Mike, I'm sorry you are having trouble with the IIS cosign filter. My comments are further down: On Oct 7, 2009, at 1:38 PM, Mike Gallo wrote: > Hello, > > I am hoping someone has already encountered and solved this issue. > > We have Cosign 3 running on Win 2003. > Cosign runs fine on a test site that is a simple static HTML page. The App > Pool is running as Network Service. > > We are trying to get Cosign to protect a .Net Web Application that connects > to a SQL Server database on another server. On our current production > version of this site, without Cosign, the App Pool runs as a domain service > account that is a user on the Web server and the DB server. > > So, on our dev box we turn on Cosign for this site: > > If we set the App Pool to run as the domain service account, just like our > production set up. Then browse to the site we get a msg from Firefox, "The > connection to the server was reset while the page was loading." No Cosign > login page. > > So we take a step back and take the application out of the scenario and run > against the simple HTML test page: > > If we set the App Pool to run as the domain service account, Cosign login > page does not come up. We get the same error, "The connection to the server > was reset while the page was loading." So it does not appear to be an issue > with the Application. > > If we set the App Pool to run as the built in local admin account then browse > to the site we get what appears to be an IIS message "Service Unavailable" > (I triple checked the password.) > > If we set the App Pool to run as the Network Service account the Cosign login > page comes right up and allows login. But of course the Network Service > account cannot connect to the database so the application does not run. > > If we set the App Pool to run as my Domain Admin User ID everything works > just fine. Cosign login page comes up, then redirects to the application. > > We tried making the domain service account a local admin on both machines. > No luck, Cosign still will not come up. > > We tried making the domain service account a domain admin. No luck, Cosign > still will not come up. > > I tried explicitly adding the domain service account to IIS_WPG and full > control on the Cosign directory. No luck. > > As far as logs: > The Cosign log is spotless. No issues. Spotless as in empty? That's not good. At the lesat, it should have something in there stating what version of cosign started up. > On the failed attempts IIS is throwing: 8007006d and 0x80. When googled both > these errors will eventually point you to David Wang's blog where he tells > you, that you need to troubleshoot you application, not IIS. > Are there any cosign-related messages in the event viewer? Details on what to do about them are here: http://webapps.itcs.umich.edu/cosign/index.php/Troubleshooting#IISCosign_filter > There seems to be some network resource that Cosign needs that the Network > Service account has access to but a Local Admin does not??? > Stranger things have happened. It sounds like you found the correct permissions combination -- the one where you were redirected to the login page, try that one again -- but were foiled on the return from the login server. The cosign filter does not actually try to make any network connections until after a user has logged in. Be sure there is not a firewall preventing outgoing connections on port 6663. (There are other possibilities such as bad or expired certs, but we'll start with the easiest possibilities.) If none of these help you along, you can always dig deeper: http://webapps.itcs.umich.edu/cosign/index.php/Troubleshooting#Digging_Deeper Jarod ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Cosign-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cosign-discuss
