Security Across Forests

[PTH]

We need to modify an application to send messages across a forest so will
have to use direct format names. I've done some tests and the only way I
could get it to work was to grant the 'anonymous logon' the send right on the
actual queue on the remote machine were the queue exists. Is there a more
secure way to do this so you can stop anyone potentially putting a message on
the queue?

Regards, Paul.

[John Breakwell]

Check out:

http://blogs.msdn.com/johnbreakwell/archive/2008/10/13/authenticating-msmq-messages-between-forests.aspx

http://blogs.msdn.com/johnbreakwell/archive/2008/06/27/cross-forest-msmq-you-need-to-be-trusting.aspx

http://blogs.msdn.com/johnbreakwell/archive/2008/02/14/how-do-i-send-msmq-messages-between-domains.aspx

Cheers
John Breakwell (MSFT)
--
http://blogs.msdn.com/johnbreakwell

[PTH]

Hi John,

Thanks for the response as always....

I've had a look through the articles, could you confirm whether my
understandings are correct for messages going across forests with no trusts.

1. The anonymous logon will have to have send permission on the destination
queue.
2. Only external certificates can be used to validate the message sender and
integrity of the message.
3. Anyone could put a message on the queue but the receiving application
would have to use the certificate to check its authenticaty before processing
it.

If the anonymous permission has to be used on the queue, does this weaken
security anywhere else in windows or have potential security issues/flaws or
does it only effect access to that queue?

Would using message queue in http/hardened mode give any better/standard
authentication methods or would it have the same principles? Do you have any
useful links to articles on authentication and encryption in http mode?

[John Breakwell]

Hi PTH

1 Anonymous Logon for Send is required as there is no shared/common
security database.
2 Again, no shared security means no common set of certificates; an
external certificate from a CA that is trusted by both sender and receiver
is required.
3 Queue open to all - yes, this is true. You could implement a service
with the sole purpose of moving authenticated messages to an "incoming"
queue for your application to use.

Potential security flaw is that a DenialOfService is possible where the
server could be taken down through lack of memory.
Check my "Insufficiuent Resources" blog post, specifically item 4, to see
how this attack works.
http://blogs.msdn.com/johnbreakwell/archive/2006/09/18/insufficient-resources-run-away-run-away.aspx
The solution to this is to ensure a system quota is applied that caps the
message volume at a safe level.
For example, if you only ever see 1MB of messages a day, you don't need a
quota of 1GB, so set a low quota.

Note that any security that relies on user accounts is not really much
protection.
The SID for any account can be easily spoofed so you need to be using
certificates if authenticationn is vital.

Using HTTP for sending messages offers you the option of using SSL.
If you assign client certificates to the senders then you would have
authentication and encryption on the wire, rather then in the message.
Note that I haven't tried this myself - it's on my "To Do" list for the
blog.

Cheers
John Breakwell (MSFT)

"PTH" <P...@discussions.microsoft.com> wrote in message
news:5CD823FF-26A4-47F9...@microsoft.com...