.NET Forum / ASP.NET / Web Services / January 2007
Cannot use usernameForCertificateSecurity with IIS application pool custom account
|
|
Thread rating:  |
Martin Pes - 30 Nov 2006 09:11 GMT Hi,
I am using web service secured by the WSE 3.0 usernameForCertificateSecurity policy. The service is running on Windows 2003, IIS 6.0. Everything works fine if the IIS application pool uses default NETWORK_SERVICE identity. If I change the identity to the custom account I am getting the following error in server WSE 3.0 output trace:
<?xml version="1.0" encoding="utf-8"?>
<log>
<outputMessage utc="30/11/2006 08:43:18" messageId="urn:uuid:993091ef-b795-4fc2-8707-03076e9107c4">
<processingStep description="Unprocessed message">
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>Server was unable to process request. ---> The system cannot find the file specified.
</faultstring>
<detail />
</soap:Fault>
</soap:Body>
</soap:Envelope>
</processingStep>
<processingStep description="Entering SOAP filter Microsoft.Web.Services3.Design.UsernameForCertificateAssertion+ServiceOutputFilter" />
<processingStep description="Exception thrown: Cannot secure outgoing message from the service. The security context token cannot be retrieved from the session state."> at Microsoft.Web.Services3.Security.SecureConversationServiceSendSecurityFilter.SecureSecurityConversationMessage(SoapEnvelope envelope, Security security, MessageProtectionRequirements response)
at Microsoft.Web.Services3.Security.SecureConversationServiceSendSecurityFilter.SecureMessage(SoapEnvelope envelope, Security security)
at Microsoft.Web.Services3.Security.SendSecurityFilter.ProcessMessage(SoapEnvelope envelope)
at Microsoft.Web.Services3.Pipeline.ProcessOutputMessage(SoapEnvelope envelope)</processingStep>
</outputMessage>
</log>
Some extra information: * If I change the usernameForCertificateSecurity policy to usernameOverTransportSecurity it works. That suggests that the error has something to do with the certificate. * I have set access to the certifacate private key for the custom service account (if I do not do that the error looks different anyway) * The IIS application pool custom service account identity was created using the instruction in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/PAG HT000009.asp * It does not matter if the service account is local or domain. I am getting the same error. * The exact policy specification is bellow:
<policy name="OperatorClientPolicy"> <usernameForCertificateSecurity establishSecurityContext="true" renewExpiredSecurityContext="true" requireSignatureConfirmation="false" messageProtectionOrder="SignBeforeEncryptAndEncryptSignature" requireDerivedKeys="true" ttlInSeconds="300">
<serviceToken>
<x509 storeLocation="LocalMachine" storeName="My" findValue="CN=EMSAppSever, CN=PES.CNCZ.CZ, CN=PES, O=CN Resources International (CZ) a.s., C=Czech Republic" findType="FindBySubjectDistinguishedName" />
</serviceToken>
<protection>
<request signatureOptions="IncludeAddressing, IncludeTimestamp, IncludeSoapBody" encryptBody="true" />
<response signatureOptions="IncludeAddressing, IncludeTimestamp, IncludeSoapBody" encryptBody="true" />
<fault signatureOptions="IncludeAddressing, IncludeTimestamp, IncludeSoapBody" encryptBody="false" />
</protection>
</usernameForCertificateSecurity>
<requireActionHeader />
</policy>
Any help would be greatly appreciated.
Regards,
Martin
Pablo Cibraro [MVP] - 30 Nov 2006 15:06 GMT Hi Martin,
It seems to be a bug or problem in one of the CryptoAPI functions. (.NET uses that functions to manage the X509 Certificates). If you look for that problem in google, you will find many entries with similar descriptions.
In IIS 5.0/6.0 to process the PFX file I use the CryptoAPI function PFXImportCertStore, but RevertToSelf must be called prior to calling PFXImportCertStore, and the virtual directory's Application Protection option must be set to Low. Otherwise I receive the error "The system cannot find the file specified".
However, I am not sure if this problem also applies for WSE.
Regards, Pablo Cibraro.
> Hi, > [quoted text clipped - 115 lines] > > Martin Martin Pes - 01 Dec 2006 07:58 GMT Hi Pablo,
Thanks a lot for hints. Unfortunately if it is a case of CryptoAPI bug I cannot use your workaround - I do not call these functions, I believe WSE 3.0 does it. I also run IIS in 6.0 mode (using application pool) so I cannot set the Application Protection to 'Low' (which I believe it is only possible in IIS 5.0 isolation mode).
It still bugs me that the default NETWORK_SERVICE account runs fine and other account does not.
Martin
> Hi Martin, > [quoted text clipped - 133 lines] >> >> Martin Martin Pes - 18 Dec 2006 17:46 GMT I have finally sorted out this.
The trick is when you create a new windows account for the new IIS application pool you have to log in into this account interactively first (e.g. using Remote Desktop).
My theory is (and I was inspired by another slightly unrelated posting) that WSE uses user scope data area (some directory in C:\Documents and Settings\<user>\....). I guess if you create a new windows login this user scope data area is not created until you actually login into this account in a normal user interactive session. And if the area does not exists the WSE fails with error "The system cannot find the file specified."
I don't know if this theory is right but it works.
> Hi, > [quoted text clipped - 115 lines] > > Martin Martin Pes - 19 Dec 2006 12:11 GMT My theory about user scope data was wrong and I still cannot use the usernameForCertificate with IIS application pool custom account. Well, at least in normal circumstances.
My client can connect successfully to server only if there is an interactive session under the custom account running.
On one machine I log remotely into server using remote desktop and custom account credentials. On second machine I can start application client and connect to application server successfully as long as the interactive session is running or my application pool working process is still running. If the application working process shuts down because of inactivity and there is no interactive session the client cannot log in again.
Very weird.
I am wondering if anyone ever used the smart client connecting to the application server using usernameForCertificate WSE configuration and IIS working under a different account than built-in NETWORK_SERVICE. Seems to me a like very standard scenario...
Steven Cheng[MSFT] - 21 Dec 2006 08:26 GMT Hi Martin,
Just want to know whether you've turned on integreted windows authentication on your webservice server machine and does your webservice client also need to provide windows credential when calling the webservice? Based on my research, there are some issue (have similar symptom with you) which is caused by kerberos authentication fails when server service is using a custom account. So you've already use "anomymous access" for your webservcie virtual dir in IIS, that should not be the problem.
Also, if you're using ASP.NET 2.0, you can use the "aspnet_regiis -ga" command to grant the sufficient permission to a custom account that will be used to run ASP.NET application
http://msdn2.microsoft.com/en-us/library/k6h9cz8h(vs.71).aspx
If you have any other finding, please also feel free to post here.
Sincerely,
Steven Cheng
Microsoft MSDN Online Support Lead
==================================================
Get notification to my posts through email? Please refer to http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues where an initial response from the community or a Microsoft Support Engineer within 1 business day is acceptable. Please note that each follow up response may take approximately 2 business days as the support professional working with you may need further investigation to reach the most efficient resolution. The offering is not appropriate for situations that require urgent, real-time or phone-based interactions or complex project analysis and dump analysis issues. Issues of this nature are best handled working with a dedicated Microsoft Support Engineer by contacting Microsoft Customer Support Services (CSS) at http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Martin Pes - 28 Dec 2006 07:47 GMT Hi Steven,
Thanks for response. Regarding your questions:
My client needs to provide windows credentials to call the web service. Because the client is supposed to connect over internet I cannot use windows authentication. So IIS has windows authentication off and anymous access on. As I have already stated, if I use only usernameOverTransport it works fine. But when I switch to usernameForCertificate it fails - so this suggests that the problem has to do something with the certificate.
I have set access to the certificate private key for the custom service account and also I have used "aspnet_regiis -ga".
As I said in previous post it works fine if there is an active remote desktop session logged into the same account in the time of using the web service.
I am getting quite desperate as the code should go to production soon and I still did not sort it out.
Martin
> Hi Martin, > [quoted text clipped - 44 lines] > This posting is provided "AS IS" with no warranties, and confers no > rights. Steven Cheng[MSFT] - 03 Jan 2007 02:24 GMT Hello Martin,
Thanks for your reply.
So you've totally turned off windows authentication, this seems a bit hard to troubleshoot, I'll help you perform some further research and discuss with some other WS engineers to see whether there is any existing issue reference. I'll update you as soon as I get any new finding. BTW, due to the nature of this issue, it may require complex troubleshooting such as production debugging, if you do feel this an urgent issue, I suggest you directly contact CSS for further assistance on this:
http://msdn.microsoft.com/subscriptions/support/default.aspx
Sincerely,
Steven Cheng
Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.
Steven Cheng[MSFT] - 05 Jan 2007 09:19 GMT Hello Martin,
I've discussed this with some other engineers and we've got some further progress. Your observations are correct. From the stack below, it seems like you are using SecureCoversation. By default, WSE 3.0 will do stateful SecureCoversations, and this requires the use of DPAPI? in order to encrypt the state of the conversation. This state is passed with each message with the SecurityContextToken so that the server doesn? have to maintain any state.
When your App Pool is running under a Network Service account, encrypting using the DPAPI? will work, because it has a logon session. DPAPI? require this logon session to exist in order to work the way WSE is using it.
One option is for you to do what you state below and have that interactive logon session when you change the AppPool? identity. Another approach is to turn off stateful SecureCoversation, which will in turn not use DPAPI? at all. Keep in mind that this requires the server side to keep track of the session state, so in the event of an AppPool recycle, this state is lost.
If you really need stateful secure conversations, and just cannot do with interactive logon sessions, then there is a third approach of having that state be encrypted with the public key of an X509 cert. Typically, for secure conversations the STS (SecurityTokenService) issuing the SecurityContextToken (SCT) and the target service with which the client uses this SCT to talk to are one and the same, hence this is not an issue. It is only an issue if the STS and the Target Service aren? the same, in which case the public key will have to be the one that the target service can understand and decrypt.
Please let me know if you have any further questions.
Sincerely,
Steven Cheng
Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|