Playing with SSO in BizTalk 2004

Today I had the pleasure (?!) of getting to grips with SSO, the Single Sign-on Component that comes built into BizTalk 2004. It’s bundled in to make integration with third-party systems simpler and to provide a consistent credential repository for BizTalk. The only problem is that it’s quite daunting for the uninitiated as the documentation is quite thin on the ground and it’s command line driven. So I thought I’d capture a few screenshots and share them out; hopefully this might reduce someone else’s pain.

It all started when a colleague of mine was trying to create a Receive Port and getting an Access Denied error. After checking he was in the correct user groups and the box he was on had all the necessary patches, I had a look in the event log and found this error:

SSO was complaining that the user in question was failing authorisation in application {6DE00B1A-F2FA-49D5-A06C-DEC5DCB8AB25}. Time to look under the hood and find out what was happening in SSO.

SSO is managed through a command line utility called “SSOManage“. This lives under C:\Program Files\Common Files\Enterprise Single Sign-On\. If you just type SSOManage without any parameters you will be shown a list of available commands. So I started off with a -displayapp to get more information about the application which was causing the problem.

The result showed that the user groups assigned as Users and Administrators of this application were wrong. We had originally used these groups but changed them for different ones. Our new users were under the new group which explained why SSO wasn’t granting permission to this particular application. All we had to do was change the group names.

To change anything in SSO, you have to create an XML file with the required parameters and get SSOManage to parse this file. So after hunting around in the docs for the exact structure of this, I put together an XML file with the change I needed, essentially changing the User and Administration group for that application:

This chunk of XML is executed by passing the filename into the -updateapps option in SSOManage which shows you if the file is parsed correctly and the changes put in place.

Voila! Problem solved.

(p.s. Hmm .. seem to have lost the screenshots for that one .. Sorry!)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.