Main | Amazon Marketplace Web Service (MWS) BizTalk WCF Adapter »
Tuesday
Nov062012

BizTalk MQSeries adapter cross domain Authentication

Had a requirement for BizTalk to communicate with a Websphere MQ server running on Windows 2008 R2 but in a separate domain. The domains were trusted which is important to note as I can’t see this working without the trust.

The domain that the BizTalk servers were in is called AMERICAS-BIZ and the MQ domain AMERICAS-CIB. Both operating systems are Windows Server 2008 R2 sp1 and all 64-bit. The MQ version is 7 or greater and BizTalk 2010.

BizTalk

We decided to use the MQSeries BizTalk MQ Adapter over the MQSC adapter although after we started having issues I did try the MQSC adapter but had similar problems. Strangely enough it seems the the MQSC adapter is using MSDTC, doesn’t make a lot of sense to me as that adapter uses the IBM MQ client and is meant to enable BizTalk to connect to MQ running on non windows operating systems.

The BizTalk configuration is pretty standard, we had a dedicated MQ BizTalk host which was using the service account AMERICAS-BIZ\SRV_BTSAppHost. The only component that needs configuring on the BizTalk side is MSDTC which should be setup as follows:

clip_image002

MQ

On the MQ Server you have to install the MQSAgent

Good documentation can be found here: http://msdn.microsoft.com/en-us/library/aa561858.aspx

For this environment we used a service account in the AMERICAS-CIB domain called SRV_BTS_WMQS.

Once the agent is in place Make sure MSDTC is configured the same as BizTalk.

clip_image002[6]

The next step is to grant the BIZ domains BizTalk service account access to the MQSAgent COM+ application. This is done in the Component Services MMC. You might have to enable changes which is done on the Advanced tab of the MQSAgent’s properties.

image

Notice the different domains, the MQSAgent will run on the MQ server as AMERICAS-CIB\SRV_BTS_WMQS and BizTalk will connect using AMERICAS-BIZ\SRV_BTSAppHost. All the MQ access will be performed by SRV_BTS_WMQS.

SRV_BTS_WMQS will need logon as a batch and service rights in the GPO.

These sorts of errors are fairly easy to see as you get security audit failures in the eventlog.

Make sure the COM+ Network Access role is installed.

image

Then add the BizTalk Domain service account to the local Distributed COM Users group

image

Add the MQSAgent and Network Service to the local mqm group for Websphere MQ. Not entirely convinced the Network Service is needed but haven’t tested it without it.

image

At this point you can create a queue in MQ and setup a BizTalk receive location making sure Transaction Support is enabled.

image

If there are no messages in the queue you should see BizTalk connecting in MQ.

image

Now PUT a test message on the queue.

image

If it works, great. For us we got this error on the BizTalk server:

The adapter "MQSeries" raised an error message. Details "Creating an instance of the COM component with CLSID {EEEF8325-B385-420D-A8A9-EABA4F51AF5C} from the IClassFactory failed due to the following error: 8004d01b."

We then noticed an error on the component services mmc on the MQ server.

There’s lots of information out there about this problem and most seem to narrow in on reinstalling MSDTC. Do it properly you have to delete registry keys. This didn’t help.

Found this excellent post.

http://blogs.msdn.com/b/distributedservices/archive/2009/03/13/troubleshooting-msdtc-permission-issues-when-a-distributed-transaction-starts.aspx

Given MQ was not clustered on this server (preproduction) we focused on permission for MSDTC and SCMANAGER.

Sc sdshow msdtc

D:(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)(A;;CCLCSWLOCRRC;;;IU)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

Sc sdshow SCManager

Just as the article explained in both cases Authenticated Users did not have required permissions to MSDTC.

sc sdset msdtc D:(A;;CCLCSWRPLOCRRC;;;S-1-2-0)(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCCR;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)(A;;CCLCSWRPRC;;;WD)(A;;CCLCSWRPLORC;;;NS)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

sc sdset SCMANAGER D:(A;;CCGR;;;AU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)

Running these commands resolved the issue. However once the servers the permissions were lost and we subsequently discovered the GPO was overriding our permissions.

Running gpresult /h <outputfilename.html>  showed the problem:

clip_image001

Authenticated Users is missing

clip_image001[7]

Resolved!

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>