views:

765

answers:

3

I am attempting to access a queue and receiving an access denied error. The confusing part is the queue is setup to allow everyone at full control as well as anonymous and machinename$ (all three are full control - it's a test system so not a big deal). I am able to successfully write to the queue but can't Peek/Read/Receive from it. I found one article on here that suggested using the FormatName method but unfortunately I am already doing this.

The catch to this is my system is on one AD domain and the test server is running against another domain entirely (my client's). Am I trying to accomplish the impossible with this?

My platform is Vista x64 and the server is 2008 (not R2).

The code looks like this:

    Do While Not m_boolCancel

        '**Code dies on this line**
        l_ar = m_mq.BeginPeek

        'block thread till message arrived or shutdown is signalled
        If WaitHandle.WaitAny(New WaitHandle() {m_sig, l_ar.AsyncWaitHandle}) > 0 Then

            l_msg = m_mq.EndPeek(l_ar)

            If l_msg IsNot Nothing Then

                'doing stuff here

            End If

            Exit Do
        End If
A: 

It shouldn't be a problem that the systems are on different domains unless you are using the domain for authentication. What happens when you give "System" full control? Please edit your question to include the code you are using to open the queue and the exact error you receive if this doesn't solve the problem.

olle
I edited the post to include the code. I also tried adding System with full control to the queue in question and no luck.
digitall
can you include the code where you actually construct m_mq ? where you assign the queue path and then tell it to open it?
olle
Well...not really. The code for that looks like this: m_mq = New MessageQueue(Me.ManagerConfiguration.RequestQueue) m_sig = New Threading.AutoResetEvent(False)The ManagerConfiguration.RequestQueue is a string and that's where my entry with "FormatName" is. The code works perfectly if I run it directly on the server - it's only when I connect remotely that it dies.
digitall
+2  A: 

For MSMQ to work across domains the domains in question have to have a two way trust established. The message queue has to be a public queue. If you have it set as a transactional queue, both client and server must be using MSMQ 4.0 (part of windows server 2008 and later)

Joe Caffeine
Ah, we don't have a trust but that does make perfect sense. So even if I set it up as a public queue will I still have to have the trust in place?I'm using Vista -> Server 2008 so I should be on MSMQ 4.0 already.
digitall
The information that defines a public queue is stored in Active Directory under the computer object hosting the queue. MSMQ relies on kerberos for security.
Joe Caffeine
Is there any way to disable security or no? The queues are internal only so there's no risk of them being accessed by anything unauthorized anyway.
digitall
Not that I am aware of, however, MSMQ can be configured to communicate over http but I haven't tried it.
Joe Caffeine
+1  A: 

Just for the test give anonymous full control.

Igal Serban
I did - anonymous, everyone, system and server$ (where server is the computer name) all have full control. No other permissions are listed on it but it's still the same error.
digitall