Classic asp “An error occurred when verifying security for the message.” iis7 transport level security

Question

On II7 we host a WCF/asp.net based API. In order to allow users of a classic asp application to connect to the API we had to publish a version we refer to as "transport". This Transport version is written in asp.net too, it points to the same assembly , its just the security layer is different to allow classic asp to authenticate. Transport level security is used as opposed to message based security.

When using a browser to load the service reference i can loading the svcutil.exe ... WDSL page.

When using my test asp page to call a web method from this reference i get the following returned:

Finished calling Web Service. Status = Internal Server Error ResponseText = a:InvalidSecurityAn error occurred when verifying security for the message.

This suggests that the authentication is failing. When testing using asp.net or the application WCF storm to contact the normal API everything works well.

The API was recently migrated , it would appear something has not been setup correctly but i am at a loss to explain what.

I can browse to the svcutil.exe ... WDSL service reference, when selecting it via the browser i get the expect XML response.

The USER NAME and password utilised work when using the non-classic asp publicaiton of the API using the message based secuirty.

Would it be possible to post some troubleshooting tip that may help diagnoise the issue please specifically regarding transport level security fault finding and setup ?

Thank you Scott

EDITED TO ADD THE FOLLOWING UPDATE:

Attempted to use the Default App Pool and a new App Pool but same problem persists.

My test page error: ResponseText = a:InvalidSecurityAn error occurred when verifying security for the message.

IIS LOG shows: v3/transport/testclassicasptransportwcfservice.asp ( 200 0 0 ) (i.e iis 200) /V3/Transport/DeviceService.svc/DeviceService (500 0 0) (i.e iis error 500)

note: virtual dir defined on TRANSPORT and V3. V3 works ok using .net as opposed to classic asp to authenticate.

EVENT LOG: The Template Persistent Cache initialization failed for Application Pool 'transport' because of the following error: Could not create a Disk Cache Sub-directory for the Application Pool. The data may have additional error codes.

This reference appears to suggest a fix but many of the DIR paths and references in "appcmd" dont exist.

_http://theether.net/kb/100127

Answer 1

REF http://theether.net/kb/100127

1. load cmd prompt
2. CD to C:\Windows\System32\inetsrv
3. enter: appcmd list config -section:system.webServer/asp
4. the following path is displayed: c:\inetpub\conf\temp\ASP compiled templates
5. check path exists (it does)

6. Check if the NETWORK SERVICE has permissions to access "ASP compiled templates" If not from appcmd execute;

   icacls "c:\inetpub\conf\temp\ASP Compiled Templates" /grant "NETWORK SERVICE:(OI)(CI)(M)"
   

   should read "sucessfully processed 1 files"

   restarted app pool.

THE "InvalidSecurityAn error occurred when verifying security for the message" problem still persists but the "COULD NOT CREATE A DISK CACHE SUB-DIRECORY .... " error from the eventlog is no longer occurring.

Sorry another update. The network service permission change DID NOT resolve the issue , changeing to the DEFAULT APP POOL solved the problem.

Got a lead at last. Examined:

1. ServiceSecurityAudit set in service behaviour. Ref http://intrepiddeveloper.wordpress.com/2008/08/07/security-event-logging-auditing/#
2. IIS logs (simply shows the non-specific error 500.)
3. Fault tracing enabled( also shows error 500).
4. Custom errors were off
5. Friendly IE messages were off
6. Asp client side and server side debugging on
7. ProcessMon running , no errors.
8. Web.config httpErrors errorMode="Detailed" /> +

ServiceSecurityAudit found me an "Object reference not set to an instance of an object" so sounds like our app has a bug.

---

Follow up (17/08/11):

Service Security Audit documented here:

http://intrepiddeveloper.wordpress.com/2008/08/07/security-event-logging-auditing/

Was the key for us to resolve this issue. Uncovered the Object Reference Error which indicated out Business Objects and Data Access dlls were out of alignment. Using CLASSIC ASP to contact the WCF.NET API using TRANSPORT AUTHENTICATION there was abolutely no indication of this error until Service Security Audit was enavled on the behaviour.config file in the WCF deployment.