Our earlier examples used public MSMQ queues and unencrypted messages, simply sending text or objects between one site and another. We chose to send them using
delivery methods because this provides the most robust environment. However it means that the messages are held on disk in all the machines that handle it while travelling between the source and destination queues.RECOVERABLE
Worse than that, we used unsecured public queues, so any inquisitive user could access the queue with an appropriate application and read, change or remove the messages it contains before our application gets to see them. Obviously, we have to consider configuring MSMQ to keep the messages private and safe from interference.
An Overview of MSMQ Security
What follows is a brief look at the different aspects of security and configuration that you'll need to take into account when you create your own MSMQ enterprise. The levels of security you adopt, and the way that you configure each part of the enterprise, will depend on what kind of messages you will be sending, the nature of the network over which they'll travel, and of course the size and complexity of your organization.
The MSMQ Help files contain a lot of detailed information about setting up each security feature. The topic Securing Your MSMQ Enterprise (under Administrators Guide in the Message Queue Server section of the contents) provides a good starting point. There's also a section named MSMQ Security Services under the MSMQ Guide heading in the Programmers Reference section.
The Enterprise and Domains
Windows NT is a domain-based system, where all the machines within a domain can use the security services of the domain controllers to check global access rights of users for any part of the domain. This provides a tidy way to control access to the entire domain from one machine—the primary domain controller (PDC).
Unfortunately MSMQ doesn’t sit well with the domain security model, as its main purpose is to allow messages to be passed between computers that are at opposite ends of a slow or unreliable network. Thus, the places where MSMQ is least useful are likely to be within your own local domain. You're only like to use the MSMQ within the same domain when the domain itself is widely distributed, perhaps using the Internet or leased lines to connect users.
MSMQ can only provide a fully secure environment for computers that log onto an NT domain. Workgroup users cannot use MSMQ secured queues or message authentication features, although message encryption and all the other MSMQ features are still available.
In many cases, messages will have to cross domain boundaries. This is where the notion of an MSMQ enterprise differs from that of the Windows NT domain. In the following diagram there are two domains, labeled A and B. Each domain contains one or more MSMQ sites, with their own selection of other servers and clients. Together they make up our theoretical enterprise:
PEC - Primary Enterprise Controller
PSC - Primary Site Controller
BSC - Backup Site Controller
An MSMQ enterprise is centered on the Message Queue Information Store (MQIS). In Windows NT4 this is based on a SQL Server database, though it will migrate to Active Directory in NT5. However, the problem still remains. Each site controller keeps a read-only copy of the enterprise information, replicated from the MQIS. To do this, it needs to have access permissions to the Primary Enterprise Controller (PEC) in domain A. The result is that you must ensure that a trust relationship has been set up so that the domain containing the PEC (domain A in our example) trusts all the other domains within the enterprise.
Admin and User Access Permissions
MSMQ allows the Enterprise Administrator (the person who installed MSMQ) to control the permissions for all other users, who by default have read-only permission to the MQIS and the other objects within the enterprise. To be able to do anything other than send a message to an existing queue (for which permission is enabled for all users by default), you must assign appropriate permissions to your users.
Remember that if you are using MTS with declarative security enabled, the users will be the accounts you assigned to the identity of the components that access the MSMQ service, not the 'real' original users.
In particular, the Get Properties permission is required to be able to search for a queue and retrieve its properties. Other permissions include Peek Message, Receive Message and Receive Journal, to view and retrieve messages and journals from queues; and Create Queue, Set Properties and Delete Queue for manipulating queues.
The Enterprise Administrator can assign permissions to each Site Administrator that allow them to deal with the setting of permissions within a single site. In fact this is the recommended way to set up an enterprise. Create two Windows NT account groups in User Manager, one for Enterprise Administrators and one for Site Administrators, then add the appropriate users to each group. In MSMQ Explorer on the enterprise controller give the Enterprise Administrators group Full Control permission for all the sites, connected networks and computers in the enterprise.
Then give the Site Administrators (who should also have Windows NT Administrator permissions for that site) Full Control permission for the site and each computer in that site. This allows them to install and configure computers in their own site, but prevents them from adding sites or changing the enterprise configuration.
There may be occasions where MSMQ will be used without any requirements for security, such as in a small office environment. In this situation you can run it in an unsecured fashion by giving the Windows NT Everyone group Full Control for the entire enterprise. This is set in MSMQ Explorer, in the Security tab of the Properties dialog for the primary enterprise controller machine.
Message Authentication
When MSMQ is installed it adds all the CA root certificates registered in Internet Explorer 4 to the MSMQ service. These are used to digitally sign messages that are in transit, and allow the receiving queue manager to positively identify the message sender and be assured that the message has not been tampered with en route. The process is transparent, and if the message cannot be verified it is automatically deleted from the receiving queue and returned to the sender. This is referred to as internal certificate authentication. We'll look at how it's done in code later in the chapter.
A message that is successfully sent and received with authentication has its
property set to IsAuthenticated
, and 1
property set to a value indicating the authentication type used. The default, unless specified when sending the message, is the message digest authentication technique MD5. MSMQ also sets the values of the HashAlgorithm
and SenderID
properties, which identify the user by their internal security identifier. In general, however, you would only need to use the SenderIDType
property—and only then if the queue is configured to accept both authenticated and non-authenticated messages. If it is configured to accept only authenticated messages, an attempt to send a non-authenticated message will result in an error at the sending application. IsAuthenticated
At the time of writing, the authentication and encryption methods available in MSMQ were limited, and liable to change. For the latest details check out the Authentication and Encryption topics in the Securing Your MSMQ Enterprise section of the Microsoft Message Queue Server Administrator's Guide.
MSMQ can also use external certificates from other CA's. However, in this case the verification is not automatic, and it is left up to the receiving application to validate the message.
Message Encryption
As well as authenticating the message to ensure that it hasn’t been changed, we can instruct MSMQ to encrypt messages while they are in transit. Again, this is reasonably transparent from the programmers' and users' points of view. We just set the
property (and optionally the PrivLevel
property) of the message to specify that it should be encrypted by MSMQ before it is sent. When received by the destination queue it is automatically unencrypted. Queues can be configured to accept both encrypted messages and unencrypted messages, or to accept just one or the other. Again, we'll see how it's done in code later in the chapter.EncryptAlgorithm
Notice that the messages are not held in encrypted form within the receiving queue. This allows the receiving applications to peek and retrieve messages without the delays that would appear if they all had to be unencrypted each time. Therefore it's important to set appropriate access permissions to receiving queues to protect the messages they contain.
Like authentication, the encryption process uses certificates and the Microsoft Base Cryptographic Provider service that is installed with MSMQ (and with Internet Explorer). Both the authentication and encryption of messages affect performance of MSMQ, and should only be used where necessary.
Auditing Events
Like many Windows services and NT itself, MSMQ can create audit log entries that allow administrators to monitor the actions taken by users and their applications. Audit control settings are changed in MSMQ Explorer. Each type of object (Message, Queue, Computer, Site, etc.) can create audit entries, for example a queue can be set up to log the receiving of messages, the reading and changing of properties, and the deletion of queues. The audit log entries take the form of messages placed into the Windows NT Event Log, and can be viewed using Event Viewer in the usual way. Computers can be set up to log things like the creation of queues, the receiving of dead letters and journals, and attempts to change properties or set permissions.
One point to watch is that the audit log messages are written to the audit log of the computer that performs the operation, and this will not generally be the Primary Enterprise Controller. For example, audit entries for the creation of a queue and the setting of its properties are logged on the machine that actually creates the queue. And if this is a remote queue (on a different machine) the actions of opening the queue to send or receive messages will be logged on the computer that contains the queue instead.