Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / ASP.NET / Web Services / January 2007

Tip: Looking for answers? Try searching our database.

Cannot use usernameForCertificateSecurity with IIS application pool custom account

Thread view: 
Enable EMail Alerts  Start New Thread
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. ---&gt; 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 Magazines

Get 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 ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.