A couple of weeks ago I was contacted by Maxime Labelle and Michel Hubert (BizTalk MVP) who accidentally found my PowerShell provider for BizTalk. The funny coincidence is that had just finished their own version of the provider without knowing about the existence of mine.
I didn’ttake much time for us to decide to join forces. […]
[Source: http://geekswithblogs.net/EltonStoneman]
If you have a solution with secure HTTPS endpoints but no suitable certificate for development and test environments, you can self-certify using a combination of IIS 6 Resource Kit tools, and manual steps. Chris Adams gives a good overview in this post, but there are a couple of additional things to consider in a distributed environment, which I’ll cover in this walkthrough.
The walkthrough is based on the following infrastructure:
– where XYZ-FRONTEND and XYZ-BACKEND are independent load-balanced Web farms, which each have SSL endpoints. XYZ-FRONTEND exposes an HTTPS website, and connects to XYZ-BACKEND via HTTPS Web services.
1. Get the IIS 6 Resource Kit Tools
Download it from here – it’s not limited to IIS6 so you can also use the tools in IIS5.
2. Self-certify the back-end farm
On XYZ-BACKEND-A install the resource kit and run SelfSSL.exe (by default in C:\Program Files\IIS Resources\SelfSSL) to create and apply an SSL certificate:
This creates, trusts and applies a certificate to the default website on the A node, which is valid for a year. Note that the DNS name of the farm is used, so requests to https://xyz-backend/url.svc will succeed, but requests to https://xyz-backend-a/utl.svc will fail, as the certificate does not apply to the resolved host names.
Export and deploy the new certificate to XYZ-BACKEND-B using IISCertDeploy.vbs (by default in C:\Program Files\IIS Resources\IISCertDeploy):
This applies the certificate to the default website on the B node, but does not trust it. To trust the certificate:
3. Self-certify the front-end farm
Similarly for the frontend, login to XYZ-FRONTEND-A:
4. Configure the front-end to trust the back-end
The farms now have trust relationships within themselves, but the front-end does not trust the back-end, as the certificate is self-published. To trust the back-end, copy the exported xyz-backend.pfx file to XYZ-FRONTEND-A and import the certificate to the trusted store:
5. Set up the sites to require SSL
In IIS manager, configure whole sites or individual pages to require SSL from the Directory Security tab, and specify whether client certificates are required.
This establishes a trust relationship within and between the farms. Web browsers will display a certificate warning when they connect to an https://xyz-frontend URL, which the user can ignore, but other types of client may fail the connection. If clients can’t connect, you’ll need to trust the certificate by importing xyz-frontend.pfx to the trusted store on the client machines, as in step 4.
Note that if one of the farms consists of BizTalk servers, the procedure is exactly the same. Ensure that the SSL configuration in your receive location matches the configuration in IIS, otherwise the service won’t activate – but it will give you a useful warning (“The SSL settings for the service ‘SslRequireCert’ does not match those of the IIS ‘Ssl'”) if there is a mismatch.
After a lull we are back on track with the Auckland Connected Systems User Group meetings. The next one is set for the 4th of June 2009 at Datacom in Auckland with the Windows Communication Foundation Primer presentation by Ulrich Roxburgh.
Please register if you are attending, and forward the meeting details below to […]
http://www.microsoft.com.au/teched
It’s on again – 8-11th September on the Gold Coast. *Nice*!
Creating several BizTalk 2009 VHDs on Windows Server 2008 for your development team? Need to rename a BizTalk 2009 development machine? Well look no further than the admin samples that are part of the BizTalk 2009 SDK.
It contains the scripts you need to rename the machine in the registry, databases, etc, so that BizTalk […]
Are you looking to try out BizTalk Server 2009 but don’t have the time to setup a full BizTalk environment? Then Microsoft’s Virtual labs might be right for you. The most popular labs for BizTalk Server have been updated for BizTalk Server 2009 and a few new ones focused on the features of BizTalk Server 2009. Check them out if you are interested.
In related news, I’m in the process of adding BizTalk Server 2009 content to the BizTalk Server Fundamentals course in Pluralsight On-Demand!. If you haven’t already subscribed, you should really check it out. I’m spending my free time these days learning about Agile Team Practices from David Starr and ASP.NET MVC from K. Scott Allen. It’s the next best thing to having these guys in a classroom with me. We’re continuing to expand the library too, so the subscription gets more valuable by the month – not many investments you can say that about today!
Today was one of those days that I couldn’t resist my need to find out what happens under the BizTalk covers. I think every BizTalk developer recognizes this.
In particular I wanted to examine the context properties of message stored in the spool table. The reason I wanted to do this is a little bit irrelevant […]
Following on from my previous article, one of my old colleagues has written up an article about how a project he worked on was able to simulate the behaviour of Dynamics AX by using one of the approaches I described in my article about how to simulate external systems in testing.
Check out Charlies article here: http://geekswithblogs.net/charliemott/archive/2009/05/13/stub-of-dynamics-ax-for-biztalk-development-and-bizunit-testing.aspx
You see quite a few code samples for retrieving “FullName” (or other properties) from an Active Directory that look like this:
string directoryPath = "WinNT://somedomain/someuser";
string fullName;
DirectoryEntry directoryEntry = new DirectoryEntry(directoryPath);
if (directoryEntry.Properties["FullName"].Value != null)
{
fullName = directoryEntry.Properties["FullName"].Value.ToString();
}
One issue with this code is that when “somedomain” actually corresponds to the local
machine name (because your are trying to retrieve the “FullName” of a local account),
it can take an extremely long time to run. This is probably because the underlying
framework is off trying to find a domain controller before falling back to the local
security store.
To work around this, consider code that would look like the following when formulating
the directory path:
string[] identities = windowsIdentity.Name.Split('\\');
string directoryPath;
if (Environment.UserDomainName.ToLower() == Environment.MachineName.ToLower())
{
// special case needed for "off domain" case.
directoryPath = "WinNT://localhost/" + identities[1];
}
else
{
directoryPath = "WinNT://" + identities[0] + "/" + identities[1];
}
Using “localhost” will cause the property retrieval to be just about instantaneous,
whereas using the computer name (from a local account Windows identity) results in
up to a twelve second delay.
If you were not able to get to the SDC Open day in Sydney earlier this month – you can watch the webcasts here: http://www.microsoft.com/australia/services/microsoftservices/sdc_openday.mspx