Ask Learn
Preview
Ask Learn is an AI assistant that can answer questions, clarify concepts, and define terms using trusted Microsoft documentation.
Please sign in to use Ask Learn.
Sign inThis browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
MSMQ makes use of several protocols to do its work, including:
This blog post will focus on the main obstacles to using remote operations and RPC.
Over the years, Windows security has been beefed up and this means a lot of unsecured ways to interact with MSMQ have been disabled by default. The three that come to mind are:
By default, an encrypted channel is required which is not possible with machines in a different forest, running in workgroup or using local (not domain) accounts. This is covered in my MSMQ 3.0 too secure for you? blog post.
To reduce the number of ports exposed to attack, port 135 is blocked by default. Without this port, clients cannot determine what port the server's MSMQ service is listening on. This is covered in my Getting MSMQ messages out of Windows Server 2008 remotely blog post.
ReferencesThis is part of the changes made with Windows 2003 sp1. Remote anonymous access to RPC interfaces on the system was disabled and now the authentication of callers is required which reduces the risk of being attacked by means of buffer overruns invoked anonymously and remotely.The user interface for changing this just for MSMQ is covered in my MSMQ 4.0 - what's new in Computer Management? blog post.
Ask Learn is an AI assistant that can answer questions, clarify concepts, and define terms using trusted Microsoft documentation.
Please sign in to use Ask Learn.
Sign in