I’ve looked everywhere and have not found a good source for this information, so I figured I would write about it here in a quick note.

My problem, I have a new server, I created several virtual servers, and I grouped the virtual servers together with their own AD. I then setup IIS on one of those servers, I created a standard website and I went to the “Home Directory” tab and selected the “A share located on another computer” option. Entered in the network directory (\\server\share) and clicked the “Connect As…” button.  I then enter in the login and password of an account on the host machine to access the network share.

Now everything is going along pretty well, but here’s a little more info. The host machine is in a workgroup, it’s my home machine and I want to have several sets of virtual server domains.  I can run quite a few of them with dual (physical) quad core 2ghz AMD 64bit processors and 32gigs of ram plus 2tbs of space. Though I left the host in a workgroup to keep it neutral (I thought).

So how does one pass though the security that was entered in the above tab? I kept getting server 500 errors and couldn’t figure out why. I had the account setup on the host; everything was setup fine on the virtual box. Hmmm then I read this little note:

“Pass-Through Authentication in a Workgroup Environment

 

In a workgroup environment, all user accounts are local. Pass-through authentication using Basic authentication can still function, as long as both the IIS and file servers have user accounts with identical user names and passwords. This configuration quickly becomes an administrative burden and consequently is not widely implemented. For these circumstances, designating a single user account designed specifically for use with the UNC connection is likely the best choice.“

This was found via this link: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/webapp/iis/remstorg.mspx#EVC

So, a nice simple issue, but I’m running a domain and a workgroup and talking between the two. No matter it seems that they are treated the same. Hence I created an account on the local virtual web server that is named exactly the same as the one on the host (same password). Boom another error. I had to give write access to the “c:\windows\.........\Temporary ASP.NET Files” folder for the local account on the virtual web server. Then all was well with the world. I’m up and running.

Now since this is just for my experimenting and home stuff, I wouldn’t advise anyone to do this for a production environment.

I also want to take this time to talk about another tool.

I created a base image and then used differencing disks for all my virtual servers. Well this made them all have the same SID when I went to add them all to a domain. I had to use this tool found here:

http://technet.microsoft.com/en-us/sysinternals/bb897418.aspx

Called NewSID.exe, I ran it on each of the virtual servers and boom all was well. So if anyone has this problem when setting up their test environments, I hope this is of some use.

Hi Everyone,

Well this is just my announcement to the world.

I’m now working for Microsoft as a consultant in the field.

I started Oct. 15^th 2007 and man my head is still whirling. There is so much to learn and so many resources. It’s simply amazing the resources Microsoft places in the hands of its employee’s. It just shows how valuable their employees are to Microsoft.

In my previous experience, I might have had a single video and maybe an employee handbook; with Microsoft it’s more like 4 weeks’ worth of online training, plus 3 weeks at MSU (Microsoft University).

While other company’s give you a laptop, a cube and walk away, not Microsoft. Granted I did have to install all the tools I believed I needed, I was told where everything was and given a roadmap.

Granted I’ve only been here for a couple weeks, I’m just so excited; I’ve never felt as valued for what I bring to a company before. Within 1 week I was already working on my first project, which I’m leading and could be a pretty major project.

If you ever thought about working for Microsoft, I encourage you to give it a go. If you thought MS is some bloated company that can’t move fast, you would be so surprised. The amount of resources that Microsoft employs to better service its customers and research and development is just unbelievable.

Also as a previous Microsoft MVP I have always been a big supporter of Microsoft and it’s products. While I’m now at Microsoft I plan to continue my activities in the .NET community here in the South East. I will be at the SQL Saturday in Orlando coming up this November 10^th (http://www.sqlsaturday.com/). I encourage all to attend. While I’m no longer an MVP, I look forward to a very active FY08 in the community.

I’m hoping to use some of my new found resources to help the community in ways I couldn’t before. I’ve been thinking of some interesting topics for FY08; please provide your vote on any of them.

·         LinkQ, how does it affect DAL/BL development and how can you employ it to the max!

·         LOB (Line of Business) WPF, bringing 3.5 together

·         JavaScript to the Max in VS.NET 2008, also Do’s and Don’ts

·         InfoPath, SharePoint Workflow and Moss, bringing you solutions faster

These might not all be ready by the start of FY08, I have three weeks of solitude in Redmond coming up and I plan on using every bit of it (after classes and other) to get a good start on these subjects.

Please post a message of support for any of these subjects, or if you think I’m wasting my time on any of these subjects or have a subject you been dying to get covered, then let me know.

Till I see you all again, have a great one. I will of course keep you all up to date in my journey in Microsoft.

Now there are plenty of posts out there that deal with WSE, though we are going to concentrate solely on Mutual Authentication.

Mutual authentication requires certificates to be in both locations, now it is possible for use of a single certificate. The problem is once the single certificate is compromised then the whole system is compromised, we will go deeper into this soon.

Let’s look at a simple setup:

Now we want to make it so that all communications between this client and server are secure and only this client can talk to this service.

In order to achieve this, we must create 2 certificates that both contain a public/private keys as well as Digital Signature,  Key Encipherment Data and Encipherment. We will go though how to create this type of certificate later.

Hence here is how we have to break down the certificates.

Now in order for Mutual Authentication to work, the Service (server side) needs each client you plan to allow to connect (Authorization, Authorized Clients). The client only requires its own certificate and the public key certificate of the server.

Now first we need to have .NET 2.0 and WSE 3.0 installed as well as VS.NET 2005.

Let’s take a look at what the client’s web.config looks like (and what it must contain), when you run though the WSE 3.0 wizard in VS.NET you will get several things added to your configuration file. One of those items worth mentioning is:

<microsoft.web.services3>

    <policy fileName="wse3policyCache.config" />

    <security>

      <x509 allowTestRoot="false" verifyTrust="true" />

    </security>

</microsoft.web.services3>

This tells WSE3 what policy file to use; it also lets it know if we are doing this in test and if we should verify the trust of the certificate.

If Trust is set to true then the issuer of the certificate has to be a trusted source (as well as the issuer of the Server certificate). If you run into trust issues on the client of the server certificate, you can always add the certificate to the trusted people store of your certificate stores. One way to have an un-trusted certificate is if you use your own CA to issue certificates and the foreign computer that it is imported into is not in your domain. Since it’s not in your domain, it can’t walk the certificate ladder to verify if it trusts the issuer of the certificate.

There are times when you will need to debug what’s going on in your web service. You would simply add this line and place it as follows:

  <microsoft.web.services3>

    <diagnostics>

      <trace enabled="false" input="InputTrace.webinfo" output="OutputTrace.webinfo" />

    </diagnostics>

    <policy fileName="wse3policyCache.config" />

    <security>

      <x509 allowTestRoot="false" />

    </security>

  </microsoft.web.services3>

Setting the “Trace Enabled” to true will now save all information that either hits or is sent to the service. Hence if you turn this on the web service side, then input = data coming in from client and output = data going to client. If you turn this on the client side then input = data coming in from service and output = is data going out to service. Most problems will generate a WSE910 error, hence without this trace information you will go insane trying to find out what the problem is.

Now let’s look at the policy file, it is also possible to have more then one policy, for instance you have a client application that calls several web services. Note if all those web services are on different computers and you are using mutual authentication then your client will need the public key certificate for each service.

<policies xmlns="http://schemas.microsoft.com/wse/2005/06/policy">

  <extensions>

    <extension name="usernameForCertificateSecurity" type="Microsoft.Web.Services3.Design.UsernameForCertificateAssertion, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

    <extension name="x509" type="Microsoft.Web.Services3.Design.X509TokenProvider, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

    <extension name="requireActionHeader" type="Microsoft.Web.Services3.Design.RequireActionHeaderAssertion, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

  </extensions>

  <policy name="ClientPolicy">

    <mutualCertificate11Security establishSecurityContext="true" renewExpiredSecurityContext="true" requireSignatureConfirmation="true" messageProtectionOrder="SignBeforeEncrypt" requireDerivedKeys="true" ttlInSeconds="300">

      <clientToken>

        <x509 storeLocation="LocalMachine" storeName="My" findValue="CN=Clntcert" findType="FindBySubjectDistinguishedName" />

      </clientToken>

      <serviceToken>

        <x509 storeLocation="LocalMachine" storeName="My" findValue="CN=Srvcert" 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>

    </mutualCertificate11Security>

    <requireActionHeader />

  </policy>

</policies>

Ok, as you can see here we have a “ClientPolicy” setup here, now we are not going to go though everything, but what I wanted to point out that causes the most trouble is that everything here (including the “extensions” at the top) needs to be the same as the servers policy file. Hence if you do something as simple as setting the “establishSecurityContext=”false”” and the server has it set to “true” then boom your connection between the client and server will fail. Now the differences are what certificates to use. Here you see the client’s certificate is “CINTCERT” and is what is used for the client token, then for the service token we got “SRVCERT” which is the public key certificate on the client of the server.

As you can see, it’s very important that settings match up, any one setting will cause a 910 error that means NOTHING AT ALL, and it’s so general that there are hundreds of things that could cause the error, including the two machines being out of time sync.

Another common error is that it can’t read the private key because of access security issues. Hence if you run trace it might tell you that “Object contains only the public half of a key pair. A private key must also be provided” now this could be a messed up certificate, or it could be that it can’t read the certificate. Hence the only way to fix this (after you verified that the client certificate has a public/private combo) is to give “Everyone” full rights to the “C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto” folder. Yes I know this isn’t nice, but I have personally tried giving proper accounts (Network Services and such) the rights needed and there is something, somewhere that keeps things from not working. Setting “Everyone” to full control fixes the problems. Now you must also hit the “Advanced” button and replicate the permissions to ever sub folder and item as well. This is also what was found via several searches on Google, many other people had to resort to the same extremes to get things working.

Now if I sound like I just know how to make it work a not how it works, you are right. Many long days on the phone with MS and many long hours finding solutions to issues have taught me one thing. Change 1 value and nothing works, it’s that simple. Just 1 value change and you get a very vague error and spend hours to track it down. To the point that you just concentrate on making sure things are the same all the way across the boards.

Let’s take a look at a service’s Policy file.

<policies xmlns="http://schemas.microsoft.com/wse/2005/06/policy">

  <extensions>

    <extension name="usernameForCertificateSecurity" type="Microsoft.Web.Services3.Design.UsernameForCertificateAssertion, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

    <extension name="x509" type="Microsoft.Web.Services3.Design.X509TokenProvider, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

    <extension name="requireActionHeader" type="Microsoft.Web.Services3.Design.RequireActionHeaderAssertion, Microsoft.Web.Services3, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />

  </extensions>

  <policy name="IEPUserGroupList">

    <authorization>

      <allow user="CN=IEPWSE" />

      <deny user="*" />

    </authorization>

    <mutualCertificate11Security establishSecurityContext="true" renewExpiredSecurityContext="true" requireSignatureConfirmation="true" messageProtectionOrder="SignBeforeEncrypt" requireDerivedKeys="true" ttlInSeconds="300">

      <serviceToken>

        <x509 storeLocation="LocalMachine" storeName="My" findValue="CN=Srvcert" 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>

    </mutualCertificate11Security>

    <requireActionHeader />

  </policy>

</policies>

As you can see here, much of it looks the same (such as the Service Token). The big difference you will see is the “Authorization” section. Here we can set who’s allowed to use this web service.

The “<allow user="CN=IEPWSE" />” section sets the allowed certificates, to allow more, just keep adding more of these sections. Now the “<deny user="*" />” section pretty much says don’t allow anyone, of course unless they been allowed already in the allow section.

Lets talk a bit about creating Test Certificates. We can easily create test certificates via the certificate creation tool “Makecert.exe” (ref: http://msdn2.microsoft.com/en-us/library/bfsktky3(VS.80).aspx).

We simply create a couple test certificates:

makecert.exe -sr LocalMachine -ss MY -a sha1 -n CN=DevServer -sky exchange -pe DevServer.cer

makecert.exe -sr LocalMachine -ss My -a sha1 -n CN=DevClient -sky exchange –pe DevClient.cer

One thing you want to be sure about is you set this option in the web/app.config:

<x509 allowTestRoot="false" verifyTrust="true" />

To:

<x509 allowTestRoot="true" verifyTrust="false" />

On both sides (web service and client side), this way these certificates created above will work. Note this is strictly only for testing.

You still need to make sure your service or application's security account has sufficient to access the certificate's private key. The “WinHttpCertCfg.exe" (ref: http://support.microsoft.com/kb/901183) tool can help grant access permission for certificates; you can find it in the WSE 3.0 SDK's installation folder.

Now lets talk about creating real certificates, the following outlines how to create certificates from a certificate authority.

Problem

You are using WSE 3.0. Everything was working fine during development on another client machine

However, that dev setup is not valid on the network. So, you are setting up new certificates on both sides.

You are using WSE for authentication

When setting up the WSE configuration, you get this error on the client when selecting a certificate:

"Selected Certificate does not support data encryption"

Environment

WSE 3.0

Windows 2003

Troubleshooting /Resolution 

1. From http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wse3.0/html/97451b4c-d25b-480d-b304-3bde7834eaf5.asp

Error message - Security token does not support Data Encryption.

Cause - The Key Usage property of the certificate does not include Data Encipherment.

Remedy - Use a certificate with a Key Usage property that includes Data Encipherment.

2. We reviewed the certificate and the key usage settings are  - Digital Signature and Key Encipherment.

The certificate also needs to include a key usage of Data Encipherment per the MSDN documention on WSE 3.0

You were not certain how to get such a certificate, but had access to the CA Server.

3. We discussed the following article but it did not quite help.

273856  Third-party certification authority support for encrypting file system

http://support.microsoft.com/default.aspx?scid=kb;EN-US;273856

4. We discussed how we can request a new certificate from the browser by going to http://CAName/certsrv

We can select "Other" for "Type of Certificate needed" and then put in this identifier for OID "1.3.6.1.4.1.311.10.3.4" and get a certificate that has Data Encipherment as a Key Usage

However, your web interface for requesting a certificate looks very different.

You do not have the same options when requesting certificate from browser.

You have an option to "Select Template", options in the drop-down menu include "Basic EFS", "EFS Recovery Agent", "User", etc.

We tried each of these options, however none of them issue a certificate with Key Usage of "Data Encipherment"

5. So, it looks like the CA setting of the templates would need to be modified.

You have full access to the CA server.

6. We looked into possible ways of modifying the templates. We discussed that none of the built-in certificate templates issue a certificate with "Data Encipherment" as a Key Usage and that is precisely what WSE needs.

Here are the steps we took to create a new template with a Key Usage of “Data Encipherment”.
1. Open the certificate template on the CA Server machine - certtmpl.msc

2. Find a template that is close to the type of template we want to create, right click on it, and select "Duplicate Template". In our case, we selected the "Web Server" certificate to duplicate.

3. Give a new name to this new template and make the modifications necessary:

a. On the General tab, Select "Publish certificate in Active Directory"

b. On the request handling tab, from the "Purpose" drop down list, select "Signing and encryption"

c. On the Extensions tab, select "Key Usage" and hit Edit. Under Encryption, the second radio button should be selected "Allow key exchange only with key encryption". Under this select the checkbox for "Allow encryption for user data" (this is what gives the "Data Encipherment" key usage). "Digital Signature" should already be selected; if not, select it.

d. On the Extensions tab, select "Application Policies" and hit Edit. Then add "Client Authentication",  if it is not already in the list of "Application Policies"

4. Open Active Directory Sites and Services. Go to view and select "Show Services node" if Services node is not visible.

a. Expand Services, Public Key Services, Certificate Templates and select the new template

b. Go to the properties of the new template and go to the Security tab. Select ENROLL for the appropriate user(s).

5. Go into Certification Authority MMC and Right Click on "Certificate Templates" and select New->Certificate Template to Issue. Select the new template

6. Now, you should be able to browse to the certificate server's web interface (http://localhost/certsrv) and request the new certificate type.

We walked through the steps above and this seemed to work!, Now, you were able to get a new certificate with correct key usage.

So, we got a certificate with following properties:
Key Usage  - Data Encipherment, Key Encipherment, Digital Signing

Purpose – Client Authentication, Server Authentication.

Root Cause

The certificate being used did not have a Key Usage of “Data Encipherment”

From http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wse3.0/html/97451b4c-d25b-480d-b304-3bde7834eaf5.asp

Error message - Security token does not support Data Encryption.

Cause - The Key Usage property of the certificate does not include Data Encipherment.

Remedy - Use a certificate with a Key Usage property that includes Data Encipherment.

Related Knowledge Base Articles

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wse3.0/html/97451b4c-d25b-480d-b304-3bde7834eaf5.asp

Tips & Tricks

Here we are just going to list out the things that cause most of the problems after you get things setup.

• MAKE SURE YOUR URLS ARE CORRECT (to the service you are calling)!
• Make sure client has Public half of Server Certificate and server has public half of Client Certificate.
• Make sure your policy files are configured (as far as options) exactly the same on both the client and server.
• Be sure to either give full control to the crypto directory “C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto” to Everyone or use the “WinHttpCertCfg.exe" utility.
• WSE910 can be anything, turn on tracing on both the client and server
• Make sure the client and server clocks are in sync, they can not be out of sync since soap messages are time sensitive (expire times).
• Be sure that the certificates you create support “Data Encipherment, Key Encipherment, Digital Signing”.
• If you are using certificates that cross domains and have your web/app.config option “VerifiyTrust” set to true, you must have all the client certificates in the “TrustedPeople” store. If you don’t then they won’t be trusted and you will get a WSE910 failure.
• Unit test your web service before enabling certificates, if it fails for non-WSE reasons, it will cause a WSE910 error.

An important thing to keep in mind at all times is that this is a message level defense, hence people can still hit the service as well as see it’s methods, they just can’t execute any methods.

What can I say, I’m sure many of you have put this to use, though here I want to publicly complain about a couple issues.

For one it would have been nice if there was some event that got clicked when one clicked a link. That could have been handled much like how my solution would show.

The other thing is support for a simple target, yep; you can put in a link but not say a target. Now how annoying is that? I don’t think the guys that developed this control even had framesets on their mind at all.

Well to my solution.

It’s rather simple when you think about it, I used the standard method of using this control, and that’s in union with a web.sitemap xml file.

I then did this to the node in question.

<siteMapNode url="BLOCKED SCRIPTOpenHome();" title="HOME" description="" >

Now all that’s cool and all notice it opens home. Well my problem and why I had to come up with this solution is that one of the pages in the application required frames. Yes I could have purchased or did my own little splitter control or something but in the end, all browsers understand framesets (was having trouble with JS in different browsers).

Plus this was only for one single part of the application which isn’t publicly exposed.

Also note I did this with master page with the sitemappath control on that page. So I then just put this little JS script on the master page and all was well.

<script language="javascript" type="text/javascript">

if (self.location.href.indexOf("PageInFrameThatUsesMasterPage.aspx")< 0)

{

if (self != top) {

    top.location.href = self.location.href;

}

}

function OpenHome()

{

top.location.href = "http://www.google.com";

}

</script>

Now the script above makes it so I don’t break out of frames on the one page that I don’t want to break out. Now of course I could have just made a small function that takes a string for the URL that I put in the XML. That would have made it even smaller. This is the first draft solution that worked ok for me.

That’s it, nice and simple, though I didn’t find many answer out there on my problem. I couldn’t use my break out code on the home page since it was another site all together, hence I didn’t have control of that site. Plus don’t try onunload event, that fires on every refresh and postback.

Enjoy

Joe