BizTalk Security – Adding permissions to the BizTalk Operator role

Every BizTalk administrator has probably already received complaints from BizTalk operators that operators can see the number of suspended messages but can’t view the message itself. Another common remark might be that the operators cannot use the Orchestration debugger. Debugging in production is not advised but with the debugger you can at least verify where the orchestration has halted.

Off course, for organisations where IT operations needs to comply with security regulations like Sarbanes Oxley or other compliance rules, the Microsoft best practices for BizTalk security apply. These can be found here. When these compliance rules do not apply for your organisation and after checking with the security responsible you can tackle these problems.

The super operator

There is a way to make it possible for operators to view and save messages with the administration console and let them use the orchestration debugger. Most of the BizTalk security resides in SQL server. In the form of two roles: BTS_OPERATOR for the Operators and BTS_ADMIN_USERS for the BizTalk Administrators. These roles are defined at database level. They can be found in every BizTalk database.

When configuring the BizTalk group these roles are created for operators and administrators with the relevant permissions (securables) on database objects. The Windows groups specified for operators and administrators in the BizTalk group configuration are given a SQL login and granted the accompanying role.Each role has its own securables. These securables are permissions on objects such as stored procedures and tables.

The BizTalk Administrators have a lot more of these securables. Here under you will find the steps to creating a super operator role that delivers extra permissions to operators, for example the permission to save messages.

1. Create a windows group for the super operator.

First we need to create a windows local group, if you do not use active directory accounts and groups, or an active directory group.
Add the members who deserved the super operator rights. These members must already be member of the operator windows group.
This because the super operator group is only an extension to the operator permissions.

2. Create the SQL login for the super operators.

  • Open the SQL management studio and connect to the SQL server that is hosting the BizTalk group databases.
  • Open the server security tab and create a new login by right clicking login and selecting new login.
  • In the login textbox you specify the group you created in step 1.
  • On the user mapping tab you check the checkbox for every BizTalk database.

In this way a user is created for the group in every BizTalk database.

3. Create the super operator role.

A role must be created for the super operator in the necessary biztalk databases. In this scenario we only need to create a role in the BizTalkManagementDB and the BizTalkMessageBoxDB.
For other scenarios it might be possible to create such a role in the BAM databases too.

  • In the SQL management studio expand the Messagebox Database and right click on the roles node.
  • Select new database role.
  • Name this role BTS_SUPEROPERATOR. The owner can be DBO.
  • Add the group you created in step 1 to the role members.
  • Do the same in the BizTalkManagement database.

4. Adding the securables for saving/viewing messages permissions.

In the messagebox database doubleclick the super operator role. Open the tab securables and add the securables according to the screenshot following these steps:

  • Click add.
  • Select specific objects, click ok.
  • In object types check the stored procedures checkbox, click ok.
  • Click the browse button and put a check next to the stored procedures you see in the screenshot.
  • Select every securable one by one and grant the role the execute right.

Now you need to add the securables to the role in the management database.
Follow the steps above but this time add the securables seen in the next screenshot.

That’s it. With the new super operator group created we have an extra level of security. This can be really handy because there are only two roles out of the box. Now there are regular BizTalk operators, BizTalk super operators with save permissions and the BizTalk administrators.

5. Adding another permission, the Orchestration debugger.

To give the newly created BizTalk super operators this additional permission you just have to add some extra securables to the SQL super operator role. Add these securables to the super operator role in the BizTalkDTADb, and grant the execute right to the role for each securable:

We will continue to search for extra permissions to add to the super operator role. These permissions will be posted soon. If you have also found out which securables accompany certain rights or if you have any questions about this topic, feel free to comment them on this post.


7 comments on “BizTalk Security – Adding permissions to the BizTalk Operator role

  1. Marikina says:

    Very nice post!, exactly what I was looking for.

  2. Myra says:

    Great article. And it really works! Thanks.

    Can you also let me know how I can configure Read Only mode. That is I want them to have all these access, but they cannot start/stop orchestrations, send ports, receive locations etc. I don’t want them to do something that they are not supposed to. 😉

    Also, is there a way I can log whoever accessing the console using such permissions? Thanks.

  3. NathanM says:


    I have not yet put any time into creating a security rule you suggested. But it should be possible. You will have to enable execute rights to just the “get/load” stored procedures for the custom security role and deny execute rights to those that do updates. After some testing and adjusting you should be able to figure out which stored procedures are needed to create the exact role you want. I figured it out by using the SQL profiler to see which SP’s are called when performing certain actions. Also, some of the SP’s have comment on what they do.
    For logging/auditing those user actions in the console I think there are two options. Create a custom GUI that wraps those actions and adds logging. This will take you alot of time though.
    The second option could be to add a statement to the stored procedures who execute the actions you want to log. This statement will then execute a “logging/auditing” SP. You should be able to get the user with SQL (SELECT SYSTEM_USER?) for your insert statement in the logging SP. However, this adjusting of the SP’s is maybe not supported by MS.
    Please let me know what your solution will be.



  4. Gordon says:

    Admiring the time and energy you put into your blog and
    in depth information you present. It’s nice to come across a blog every once in a while that isn’t the same unwanted rehashed information.
    Fantastic read! I’ve bookmarked your site and I’m including your RSS feeds to my Google account.

  5. Kundan Karma says:

    securables screen shot for ManagementDB is not provided. Please can you provide that.

    • mitchke says:

      Hi Kundan,

      The screen shot for the ManagementDB was already present, but it did seem to be a bit confusing as the screen shot appeared above the line where it got referenced.
      I’ve edited the post, so that all should be clear now.

      Thanks for your reply, and hope this will help you.

  6. steveculshaw says:

    Excellent post

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s