Export (0) Print
Expand All


This topic is about managing the security of the deployed solution. See Checklist: Configuring Security Privileges for the security groups within BizTalk Server RFID.

Certain devices require opening up ports for firewall exceptions in order to operate with BizTalk Server RFID. It is critical to understand the specific set of ports. For a comprehensive list, refer to the device provider deployment kit supplied by the IHV point of contact.

For information about managing the Windows firewall, see Managing Windows Firewall (http://go.microsoft.com/fwlink/?LinkId=153201).

On Windows Server, certain BizTalk Server RFID operations require local administrator privileges. It is important to make sure that group policy does not incorrectly enforce restrictions on RFID Service Accounts or other accounts that need to perform these operations. The following section discusses the operations and the required privileges.

User Access Control (UAC) is by default ON in Windows Server 2008. If you see security access-related issues, consider turning this OFF.

By assigning specific privileges to appropriate accounts and users, BizTalk Server RFID controls access to resources. The following table indicates the type of privileges that various accounts and users have in terms of accessing resources.

Resource RFID Worker Process account (Windows Server only) RFID Service account Everyone

Installation Folder

Installation Folder\bin




DataDir Folder\Logs




Root of the Hosted Processes Directory

(DataDir Folder\Processes)

(DataDir Folder\Providers)




Message queues that the processes create


Windows Server: FC


WMI namespace


Windows Server: FW

Windows Server: R



Execute stored procedures in RFIDstore



Execute stored procedures exposed by RFIDsink




Execute stored procedures exposed by BizTalkRuleEngineDB











The abbreviations in the preceding table are: RW - Read/Write; R – Read; FC - Full Control; FW - Full Write; GR - Generic Read; GW - Generic Write; None - No Permissions

The Users part of the RFID_USER group can use all the Web service proxies and execute commands that do not change the state of an RFID process or a device. To use other Web service calls, the user must be part of the Administrators group.

In the case of device-related Web service calls, the user can be part of the Device Administrator group or the local machine administrators Windows group.

See Security Restrictions on Web Service Calls (http://go.microsoft.com/fwlink/?LinkID=150593) for a detailed breakdown of the security privileges required for the Web service calls.

Device security can be broken down as follows:

  • Authentication information (user name, password) used to connect to the device

  • Authorization access to perform administrative operations on the device

Authentication information

Most device providers support the authentication support that is used by the administrator while configuring the device. This information is also saved in the RFIDstore database as part of the device information.

Authorization access

In some situations, event handlers or synchronous applications need to perform administrative operations on a device. Such situations include setting device properties programmatically by using the System.IO.SensorServices.Rfid.Client.SetPropertyCommand API. The RFID administrator must enable the appropriate security privileges; otherwise administrative operations on the device will cause an exception.

To set administrative privileges on devices, the RFID administrator needs to add the user account of the Windows process to the device's Administrator account according to the following table.

Operating system Windows process

Windows Server 2003

Windows Server 2008

The RFID Worker Process account needs to be added to the device's Administrator account. For more information about the RFID Worker Process account, see RFID Worker Process Account.

These security settings can also be applied to a device group. If security is set for a device group, all devices within the group will inherit the permissions.

This section contains information about recommended best practices for BizTalk Server RFID in a production environment.

Setting Log File Folder Permissions

Log files can contain security-sensitive information, such as stack traces, tag information, and device properties. Therefore, it is important to ensure that the log file folder permissions are not changed from their default values, which are set during the installation process. For more information about the default permissions on the log file folder, see Security Restrictions on Resources (http://go.microsoft.com/fwlink/?LinkId=152831).

If you change the log file folder location, ensure that the folder is properly secured so that it does not disclose sensitive information to non-privileged users.

Setting Event Handler Permissions

An event handler is a custom component that is executed when a BizTalk Server RFID event is processed. Because your event handlers are executed under the context of the RFID Worker Process account (PSA), you need to take caution in the following ways:

  • Ensure that the PSA has only the minimal privileges required to operate correctly. For example, ensure that the PSA does not have administrative privileges on a BizTalk Server RFID computer, but does have read/write privileges to the event handlers, providers, and the %RFIDDATADIR%\logs folder.

  • Establish a process for the deployment of event handlers in your organization. Because event handlers are executed in the RFID process pipeline, BizTalk Server RFID cannot restrict what actions the custom event handlers perform. Therefore, the process you establish for deploying event handlers should include code or peer reviews, or at least you should understand exactly what the custom event handler does.

Encrypting Data Between BizTalk Server RFID and the Data Store

Depending on your company's security and compliance policies, you may need to encrypt data read by BizTalk Server RFID from the RFIDsink and RFIDstore databases. To encrypt data, you must configure your SQL Server installation. Additional details can be found in the SQL Server documentation according to the links in the following table.

Topic SQL Server 2005 SQL Server 2008

Encryption How-to Topics



Encryption Hierarchy



Securing SQL Server



Importing Devices and Processes from an XML File

When you import a device or a process by using an XML configuration file, the file may include a password or other sensitive information. Sensitive information in a configuration file is not stored in clear text, but as a byte array. This sensitive information may be read or modified by anyone who has privileges to read or write the file. Therefore, we recommend that you protect XML configuration files in the following ways:

  • If you need to have sensitive information stored in the XML configuration file, ensure that you protect the folder containing the XML file. Make sure that only the RFID Service account (RSA) has read privileges on the folder containing the file.

    For devices only: Even if security information is stored in the XML configuration file, it is used only when importing the file for the first time. After the device is created, any updates that are imported will explicitly ignore security credentials stored in the XML configuration file.

  • If there is no specific reason to have sensitive information stored in the XML configuration file, you can import the specified device or process by using the XML configuration file, but specify the sensitive information after the importing is complete. For more information about importing devices, see How to Import Devices (http://go.microsoft.com/fwlink/?LinkId=152835). For more information about importing processes, see How to Import or Export an RFID Process (http://go.microsoft.com/fwlink/?LinkId=152837).

  • RFID Manager and RFID Client Console do not export security credentials to the XML file. Therefore, to have security credentials in the XML file, the file must be edited manually or generated externally from the BizTalk Server RFID tools.

Configuring a Double-Hop Scenario from an Event Handler

A double-hop scenario is one where a client application is on Computer 1, BizTalk Server RFID is on Computer 2, and the resource that requires impersonated credentials (such as the RFIDsink SQL Server database) is stored on Computer 3.

A double-hop is an issue only when executing deploy and undeploy Web service operations because the caller is impersonated.

When deploying a process, the client credential from Computer 1 is passed to Computer 2, and then is passed from Computer 2 to Computer 3. However, Computer 2 cannot transmit its credentials to Computer 3. To make this scenario work, you can do one of the following:

  • Run RFID Manager on the BizTalk Server RFID computer, such as Computer 2 in the preceding scenario. This is the simplest option.

  • Use the RfidClientConsole.exe command-line utility to remotely start a process. For more information about RfidClientConsole.exe, see Using the RFID Client Console (http://go.microsoft.com/fwlink/?LinkId=152839).

  • Configure your SQL Server computer to use SQL Server and Windows Authentication mode instead of Windows Authentication mode. This eliminates the need for the SQL Server computer to authenticate a Windows account.

  • Enable delegation. Delegation requires Kerberos, so it can only be done in a pure Windows environment. Enabling delegation also requires that you log in as a domain administrator, so this may not be possible in your environment. More information about enabling delegation can be found in Allow a computer to be trusted for delegation for specific services (http://go.microsoft.com/fwlink/?LinkId=89238).

Authentication issues do not exist if BizTalk Server RFID is installed on the same computer as SQL Server.

For more information about configuring double-hop credentials, see Concerning the credentials double hop issue (http://go.microsoft.com/fwlink/?LinkId=89239).

Maintaining Virtual Directory and Application Pool Security

For BizTalk Server RFID to function, it is important that you do not modify the privileges that are automatically set up, as follows:

  • The virtual directories created for RFID providers need anonymous authentication. Anonymous authentication allows the RFID service to connect to the Worker Process account (PSA) However, only local administrators can communicate with the Web services that are hosted in the worker process.

  • The identity of the application pools that are created by the RFID service must be changed only during the setup process. The Worker Process account (PSA) has the permissions required to access the application directories. The PSA is also a member of the RFID_USER group, which enables hosted code to interact with the RFID service by using the Web Service API.

Maintaining a Secure BizTalk Server RFID Deployment

To maintain proper security of a BizTalk Server RFID deployment, we recommend the following best practices:

  • Because BizTalk Server RFID stores critical data, ensure that the database administrator assigns only minimal permissions to the BizTalk Server RFID data store. Only the RFID Service account (RSA) should have read/write privileges to BizTalk Server RFID data.

  • The Process and Suspended queues should allow read/write privileges only to the RSA. When the queues are created, the appropriate privileges are automatically set, so we recommend not altering these permissions after installation of BizTalk Server RFID.

  • Users who are members of the local Administrators security group should be controlled carefully. Members of this security group have system-wide privileges and can compromise security mechanisms, such as encrypted connection strings and passwords of other users. Incorrectly assigning administrative permissions can also result in Denial of Service (DOS) attacks.

  • The RFIDsink and BizTalkRuleEngineDb databases contain sensitive information. The database administrator should ensure that only the RSA or Worker Process account (PSA) have access to these databases.

  • If an RFID device supports security, the manufacturer may set a default user name and password on the device. These default values should be changed to maintain security of the device.

© 2014 Microsoft