BizTalk HTTP Receive Adapter does not work after upgrading from BizTalk Server 2004

Here is an interesting thing that may catch your attention, the BizTalk HTTP Receive Adapter will not work after you have upgraded your server(s) from BizTalk Server 2004 to BizTalk Server 2006.

I ran into this issue a couple weeks ago and the fact that the HTTP Receive adapter was not responding after the upgrade seemed odd, considering it was working perfectly fine with the 2004 version of BizTalk.

After a bit of investigation, I found out that the upgrade process does not apply for the HTTP Receive Adapter and the settings in IIS Manager were pointing to old paths and old assembly locations.

Here are the extra steps that you need to make:
- On the server(s) where you have the HTTP Receive Adapter configured use your IIS Manager and:

• On the BizTalk HTTP Receive Handler Web Service Extension change the path to the BTSHTTPReceive.dll to point to the new location. If you have configured your BizTalk Server 2006 with the default settings this path is: C:\Program Files\Microsoft BizTalk Server 2006\HttpReceive\BTSHTTPReceive.dll
• Change the Local path of the BizTalkHTTPReceive Virtual Directory to its new location. If you have configured your BizTalk Server 2006 with the default settings this path is:
  C:\Program Files\Microsoft BizTalk Server 2006\HttpReceive

Important: If you have multiple servers in your BizTalk Group(s) and/or Cluster(s) you will need to apply changes to all servers that had the BizTalk HTTP Receive Adapter configured prior to the upgrade process.

K2.net 2003 with Kerberos Delegation and Protocol Transition

If you have had the pleasure working with K2.net and made a bold attempt to set it up to work with Kerberos authentication, you may have stumbled upon a few issues like myself.

One of the recent challenges that I have encountered with K2.net was security.

Here is the scenario:

• Windows Server 2003 Active Directory
• Ms SQL Server 2005 - Server A
• K2.net Server 2003- Server B
• IIS/Windows SharePoint Services- Server C
• Kerberos Authentication configured

The business requirements asked for users (each user had an account configured on the AD domain) to be able to access their K2.net Workspace from the anywhere on the Internet. From a glance does not seem to be that complicated, but the complexity was introduced when Kerberos authentication was not working when accessing from the workspace from the Internet, however when users were accessing the workspace from the within the internal domain (where the K2.net infrastructure was implemented) the Kerberos authentication was working without any issues.

User authorization by the K2.net Server can only take place if the K2.net server receives the correct credentials of the user who is accessing K2.net resources.
These resources can be reports and Worklist items in the K2.net Workspace or any other K2.net Integrated Web Form. For this reason you must configure your environment for Kerberos Delegation.

You need to configure the Kerberos Delegation by using a Kerberos Extension called Protocol Transition. The protocol transition extension allows a service that uses Kerberos to obtain a Kerberos service ticket on behalf of a Kerberos principal to the service without requiring the principal to initially authenticate to the Kerberos Key Distribution Center (KDC) with a credential. An example of this scenario might be a user who needs to access K2.net resources from a Public Computer on the Internet.

The steps below will help you configure your platform to be available from the Internet, in the event that your workflow users will need to access the workspace from "the outside world" rather than Internal network.

1. Follow steps required to configure Kerberos Authentication for your K2.net Infrastructure.
2. If your users will access the Workspace from the Internet the following extra steps will be required:


a) Use SSL to encrypt HTTP traffic between users and the IIS server (optional but highly recommended)
b) Setup Protocol Transition/Constrained Delegation, this requires that you raise the Domain Functional level to Windows Server 2003 (use Active Directory Users and Computers)
c) Configure Delegation for the K2Workspace Application Pool Identity(use Active Directory Users and Computers):

· Locate the service account under which the Application Pool where Workspace resides is running.
· In the Delegate tab select the "Trust this user for delegation to specified services only" radio button.
· Select the "Use any authentication protocol" radio button.
· Click the Add button and locate/add:

-The 'K2Server2003' service type for the K2 service account.

-The 'HTTP' service type for the Workspace Application Pool service account.

e) Add the K2workspace Application Pool Identity service account to Domain\Windows Authorization Access Group
f) Use the Local Security Policy editor on the IIS server and the K2workspace Application Pool Identity service account and grant the “Act as part of the operating system” privilege


Reference Documentation

Kerberos Protocol Transition and Constrained Delegation
http://technet2.microsoft.com/WindowsServer/en/library/c312ba01-318f-46ca-990e-a597f3c294eb1033.mspx?mfr=true

How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0
http://msdn2.microsoft.com/en-us/library/ms998355.aspx

How To: Use Impersonation and Delegation in ASP.NET 2.0
http://msdn2.microsoft.com/en-us/library/ms998351.aspx

Basic Guide to enabling a K2.net® 2003 Implementation to use Kerberos Authentication
http://kb.k2workflow.com/Articles/KB000123.aspx