I'm typically a java developer but was asked to "tweak" a small ASP app my organization has. It basically accepts user input into a form and then emails the data. In my sendmail.asp file I set a session attribute (Session("emailText") = message) and then redirect to page printResults.asp.
That page is basically an HTML page with a single line of VBScript code at line 21: <%Response.Write(Session.Contents("emailText")) %> .
This all works on my local IIS server but when I deployed it to the host server to test & demo it I got this error:
Microsoft VBScript runtime
error '800a01a8'
Object required: ''
/sub3/printResults.asp, line 21
Since I am new to ASP I have no clue why this would work locally but not on the host server. Any ideas or suggestions would be most helpful.
Is it possible that Session State has been disabled either in IIS or elsewhere in code?
When you redirect to printResults.asp are you staying in the same domain and sub-domain (session state will not be maintained between domain/sub-domains) and not switching between HTTP/HTTPS (sessions may have been set to HTTP only)?
Related
There are lots of questions that ask about the 80072ee2 "The operation timed out" error in msxml3.dll, but most are resolved by moving the requested URL to a different application pool. But, we already do this and are still getting this error on a semi-regular basis.
We're running a Windows 2008 server and IIS7.5 - the website is Classic ASP and the code is:
set xmlhttp = CreateObject("MSXML2.ServerXMLHTTP")
xmlhttp.open "GET", "http://www.mysite.co.uk/_search/search.php", false
xmlhttp.send ""
strResponseText = xmlhttp.responseText
set xmlhttp = nothing
The folder '_search' is a virtual folder and is set to use a separate application pool from the main site. It is a busy-ish site, and we don't get a timeout every-time it's called... but once you get one, there are often a number of them in succession. We know this is happening because we're logging the 500 errors on the site.
Does anyone have any ideas (please don't suggest re-writing the Classic ASP or PHP - it's not possible at the moment)?
Thanks
Your code looks absolutely fine. Two things you can try though.
First try
Server.CreateObject("MSXML2.ServerXMLHTTP.6.0")
This may not make any difference, but you're msxml6.dll - which is present on IIS7 - rather than the older msxml3.dll
Second, if you have Remote desktop access, see what happens when you try to access http://www.mysite.co.uk/_search/search.php from the server's own copy of IE. I've encountered situations where you can't see a site the server hosts itself through the external URL and you have to use localhost or 127.0.0.1
I solved it by creating a new site with the same physical path domain name etc but different port number (like 81)
xmlhttp.open "GET", "http://www.mysite.co.uk:81/_search/search.php", false
asp.net app (c#) worked fine in debug mode; published, getting 401.1 error (unauthorized).
When I put in the url, a dialog asks for username & password. Put it in 3x, error.
It's an internal app, using Windows authentication only.
IIS 7.5, using ApplicationPoolIdentity.
SQLServer Database
Specific Error Message from 401.1 page:
Module WindowsAuthenticationModule
Notification AuthenticateRequest
Handler ExtensionlessUrlHandler-Integrated-4.0
Error Code 0x8009030e
Requested URL http://smalltools.dbsvc.com:80/ Ap
Physical Path C:\inetpub\SmallTools
Logon Method Not yet determined
Logon User Not yet determined
The app has a users table to determine the "role" of that user. I put a method in the master page that queries the table based on authenticated user, and returns the role. This, in turns, determines which buttons are visible on the navigation bar.
Looked in the security log, and found the following 3 entries:
2012-07-20 14:55:11 10.0.1.38 GET / - 80 - 10.0.13.106 Mozilla/5.0+(Windows+NT+6.1;+rv:14.0)+Gecko/20100101+Firefox/14.0.1 401 2 5 15
2012-07-20 14:55:20 10.0.1.38 GET / - 80 DE\cin.bro 10.0.13.106 Mozilla/5.0+(Windows+NT+6.1;+rv:14.0)+Gecko/20100101+Firefox/14.0.1 500 0 0 125
2012-07-20 14:55:20 10.0.1.38 GET /favicon.ico - 80 DE\cin.bro 10.0.13.106 Mozilla/5.0+(Windows+NT+6.1;+rv:14.0)+Gecko/20100101+Firefox/14.0.1 404 0 2 0
Any idea what might be causing the inability to log in? Any clues what I can fix to make it work? I've researched all day and haven't found what might be the problem.
Any information is gratefully received.
Thanks
Cindy
I've successfully solved the issue; I had to allow impersonation, and make an adjustment to the AD group.
The article in the following link helped a great deal:
http://msdn.microsoft.com/en-us/library/bsz5788z.aspx
If this is an external site, then Windows authentication isn't really the way to go. But you can still do it, here's some links I found that should help.
Q&A about similar issue
Microsoft guide on how to implement
Typically Windows Authentication is used with internal systems because the users are logged on directly to the system and all their credentials are right there. However for external apps this isn't always the case, since your home Windows account and work windows account aren't the same, in addition you may not even be using windows from the external location.
Another gotcha I came across is the local loopback address security check when you setup a DEV instance and modify hosts file to use Fully Qualified Domain Name (FQDN) or simply when you browse IIS site with custom headers and the name does not match the server hostname. While this is necessary for production servers it is a problem when setting up Developer environments.
"This issue occurs when the Web site uses Integrated Authentication and has a name that is mapped to the local loopback address"
There are two main methods to resolve the issue:
Specify host names (Preferred method if NTLM authentication is desired) by creating/updating the Multi-String value:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Disable the loopback check (less-recommended method - do not use on production servers) by setting the following registry DWORD value to 1
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\DisableLoopbackCheck
Please refer to this HTTP 401.1 - Unauthorized: Logon Failed - Microsoft Support article for detailed overview and registry settings.
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
REF http://theether.net/kb/100127
load cmd prompt
CD to C:\Windows\System32\inetsrv
enter: appcmd list config -section:system.webServer/asp
the following path is displayed: c:\inetpub\conf\temp\ASP compiled templates
check path exists (it does)
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:
ServiceSecurityAudit set in service behaviour. Ref http://intrepiddeveloper.wordpress.com/2008/08/07/security-event-logging-auditing/#
IIS logs (simply shows the non-specific error 500.)
Fault tracing enabled( also shows error 500).
Custom errors were off
Friendly IE messages were off
Asp client side and server side debugging on
ProcessMon running , no errors.
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.
I have a Windows 2003 server running IIS 6 and have some scripts that do automated setup and creation of websites. They are not working on a new server I cam commissioning (they already work happily on 3 other W2K3 servers). The problem appear to boil down to WMI security on the IIS provider. The ASP code below represents the problem (although it is not the original code that causes the problem - this is a simplified demonstration of the problem).
Set wmiProvider = GetObject("winmgmts:\\.\root\MicrosoftIISv2")
If wmiProvider is Nothing Then
Response.Write "Failed to get WMI provider MicrosoftIISv2<br>"
End If
Response.Write "Querying for IISWebService...<br>"
Set colItems = wmiProvider.ExecQuery("Select * From IISWebServer",,0)
Response.Write "Error: " & Hex(Err.Number) & " (" & Err.Description & ")<br>"
If I run this in my browser, I get an access denied error reported after the ExecQuery call. I have set WMI access for the IUSR_ user from the Root branch all the way down. In fact, I can query for IP address information using the CIMV2 provider quite happily. If I put the IUSR user in the machine admins group it all works, but I don't really want to do that.
This must be a DCOM/WMI security problem, but I can't work out what else there is. Can anyone shed any light?
After reading G. Stoynev's comment asking if any events were logged in the Windows Logs, I checked the event logs on the server to which I'm attempting to access IIS remotely via WMI, and lo and behold I found an event with the following text:
Access to the root\WebAdministration namespace was denied because the namespace is marked with RequiresEncryption but the script or application attempted to connect to this namespace with an authentication level below Pkt_Privacy. Change the authentication level to Pkt_Privacy and run the script or application again.
See the code in this answer to the related SO question c# - "Access is denied" Exception with WMI.
Here's some example C# code that I added that seemed to resolve this issue for me:
ConnectionOptions options = new ConnectionOptions();
options.Authentication = AuthenticationLevel.PacketPrivacy;
ManagementScope managementScope = new ManagementScope(#"\\remote-server\root\WebAdministration", options);
// ...
If this is something that you intend to run as a tool for yourself or your admin (as opposed to the unwashed anonymous masses), here is a way I have used in the past (YMMV):
Set up a new directory in your website (e.g. /SiteCreate) and place your WMI scripts there
Configure a Windows user that has appropriate rights (probably admin in this case but you should use whatever is pertinent to your app)
Turn off the anonymous access to the directory you created in step 1 and then set the security to allow access only to the user you created in step 2 (turn on the authentication for that directory)
Now, when you navigate to that directory in your browser, you should get a login prompt. When you enter the username/password you created in step 2 your script will have the appropriate rights to perform your WMI requests.
Not a DCOM issue, more so a WMI security and encryption issue. Try changing the GetObject moniker to include impersonation and pktPrivacy, eg:
Set wmiProvider = GetObject("winmgmts:{impersonationLevel=impersonate;authenticationLevel=pktPrivacy}!\root\MicrosoftIISv2")
Refer to the follow MS article for more info:
http://msdn.microsoft.com/en-us/library/aa393618(v=vs.85).aspx
I need to generate a CTL for use with IIS7.
I generated a CTL file using MakeCTL (on Win2k3 SDK) and put only my own RootCA certificate in the CTL.
However, when I then use adsutil.vbs to set my website to use this CTL, I get:
ErrNumber: -2147023584 (0x80070520)
Error Trying To SET the Property: SslCtlIdentifier
I'm using adsutil.vbs like this:
cscript adsutil.vbs set w3svc/2/SslCtlIdentifier
where is the friendly name of the CTL
The problem is, I am not able to set a friendly name. At the end of the wizard it says "Friendly Name: ".
In IIS6 I can create a CTL with a friendly name (showing in Certificates MMC) but if I export it from there, when I import it, it no longer has a friendly name.
Can anyone show me how to do it please?
This should work on IIS 7.0 but probably not on IIS 7.5.
Let us know if this page is helpful please - http://www.rethinker.net/Blog/Post/14/How-to-Create-and-Use-a-CTL-for-IIS-7-0
I'm experiencing exactly the same problem and am having the same trouble finding an answer.
There appears to be no documented way to create a friendly name for Certificate Trust Lists using MakeCTL. And the only documented way to add a CTL to IIS7 uses the adsutil script Neil references above, yet it requires a friendly name. I assume we could dig into a programatic way to do this but I'm not looking to get that deep.
The core of this problem is that IIS7 seems to have lost favor for CTL's, else it would have some UI support for them. Are people using some alternative to CTL's in combination with Client Side Certificates?
I find it odd this isn't a bigger problem for IIS7.
Update:
I finally came back to this and have figured out the Friendly Name issue. To get a friendly name assigned you must store the CTL in the Certificate Store rather than to a file (I had always used the file approach previously). So, using MakeCTL in the wizard mode (no arguments) and choosing to 'Certificate Store' on the 'Certificate Trust List Storage' page results in a new page that let's you specify a Friendly Name.
So I now have a CTL in the 'Intermediate Certification Authorities' certificate store of LocalMachine. Now I am trying to use 'netsh http add sslcert' to assign the CTL to my site.
Before I could use this command I had to remove the existing SSL cert that was assigned to my site for server authentication. Then in my netsh command I specify the thumbprint of that very same SSL cert I removed, plus a made up appid, plus 'sslctlidentifier=MyCTL sslctlstorename=CA'. The resulting command is:
netsh http add sslcert ipport=10.10.10.10:443 certhash=adfdffa988bb50736b8e58a54c1eac26ed005050 appid={ffc3e181-e14b-4a21-b022-59fc669b09ff} sslctlidentifier=MyCTL sslctlstorename=CA
(the IP addr is munged), but I am getting this error:
SSL Certificate add failed, Error: 1312 A specified logon session does not exist. It may already have been terminated.
I am sure the error is related to the CTL options because if I remove them it works (though no CTL is assigned of course).
Can anyone help me take this last step and make this work?
UPDATE 01-07-2010: I never resolved this with IIS 7.0 and have since migrated our app to IIS 7.5 and am giving this another try. I installed IIS6 Compatibility on my test server and tried the steps documented here using adsutil.vbs. I immediately ran into this same error that Niel did above:
ErrNumber: -2147023584 Error trying to SET the Property: SslCtlIdentifier
when running this command:
adsutil.vbs set w3svc/1/SslCtlIdentifier MyFriendlyName
I then went on to try the next adsutil.vbs command documented and it failed with the same error.
I have verified that the CTL I created has a Friendly Name of MyFriendlyName and that it exists in the 'Intermediate Certification Authorities\Certificate Trust List' store of LocalComputer.
So once again I am at a dead standstill. I don't know what else to try. Has anyone ever gotten CTL's to work with IIS7 or 7.5? Ever? Am I beating a DEAD horse. Google turns up nothing but my own posts and other similar stories.
Update 6/08/10 - I can now confirm that KB981506 resolves this issue. There is a patch associated with this KB that must be applied to Server 2008 R2 machines to enable this functionality. Once that is installed all works flawlessly for me.
The question is about IIS7, but for anyone looking for this information - from IIS8 you no longer need to use CTLs, but rather use "Client Authentication Issuers" in the certificate store.
This is documented in more detail: http://technet.microsoft.com/en-us/library/hh831771.aspx