Can't Route to another LOCAL Broker Instance

Hi Remus,

I am experiencing the same problem, and I can't get the easy fix to work. I drop and create the DB's in between tests, so it is not related to having an old certificate in the DB, as in the case of Tilfried.

The situation is as follows:

DB1 owned by login1, has a user for login2; this DB is for the initiator

DB2 owned by login2, has a user for login1; this DB hosts the target

Both DB's have TRUSTWORTHY flag set to ON

Error in sys.transmission_queue: 'Error 916, State 3: The server principal "Login1" is not able to access the database "DB2" under the current security context.

Going on a limp, I decide to add a remote service binding in DB1, binding the user for Login2 to the target service, even though BOL explicitly states that this is only required for cross-server communications. This does change the situation - I still get an error, but a new message is sys.transmission_queue: "Dialog security is unavailable for this covnersation because there is no certificate bound to the database principal (Id: 5). Either create a certificate for the principal, or specify ENCRYPTION = OFF when beginning the conversation." I already know that the first option works, but I wanted to get the simple solution running. As for the second option, I doublechecked and the initiating procedure DOES already specify ENCRYPTION = OFF in the BEGIN DIALOG CONVERSATION command. My theory is that the remote service binding somehow forces SB to use encryption, but (a) that is not stated in the error message, and (b) if so, then how to get the messages sent over to the target service without using the binding?

==> EDIT: Just saw that you confirmed this theory in your last reply to Tlifried. So I am indeed back to having to find out how to get this to work without remote service binding - it should be possible, but how?

BTW, SELECT @.@.VERSION shows that I'm on build 3054, in case it matters.

Between all the errors in BOL and less than helpfull error messages produced by SB, I feel like I'm slowly losing my sanity. Please help!

Best regards,

Hugo Kornelis

Hi Remus (or whoever is listening),

Just to make sure that I'm not looking in the wrong corner, I decided to make sure that the absence of certificates is the ONLY reason that the services won't talk to each other. So I made certificates for the dbo owner in each of the DBs, dumped them to file and used those files to create certificates for the corresponding users in the other DBs.

After setting up certificates like that, I still got the same error (Error 916, State 3) - but once I added a remote service binding, my dialog ran without further problems.

I still don't understand why a remote service binding is required even though BOL says (quote from the CREATE REMOTE SERVICE BINDING page): "A remote service binding is only necessary for initiating services that communicate with target services outside of the SQL Server instance." - but at least I am now certain that my problems with the version without certificates and with the trustworthy option set on are not related to any other errors in my setup.

Best, Hugo

|||

On the interaction between ENCRYPTION = ON/OFF and the presence/absence of a remote service binding see http://blogs.msdn.com/remusrusanu/archive/2006/07/07/659319.aspx. When a RSB is present, the login mapping between databases is discarded in favour of certificates. This is intentional, as a way to circumvent the problem of no wanting to enable TRUSTWORTHY bit (with all the instance level implications).

To map users trough logins, having TRUSTWORTHY ON is a required condition, but not suficcient. The complete story is detailed at http://msdn2.microsoft.com/en-us/library/ms188304.aspx. What you need is for DB2 to grant AUTHENTICATE permision to login1. TRUSTWORTHY bit is required only on DB1. This is nothing specific to Service Broker, using EXECUTE AS user = 'foo' in DB1 and then issue a USE DB2 statement would run into the same error.

I understand the errors are somehow cryptic and misterious, now the cat is out of the bag we hope to get better at next iteration. Tools would shorley help, give a shot to www.codeplex.com/slm

|||

Hugo Kornelis wrote:

I still don't understand why a remote service binding is required even though BOL says (quote from the CREATE REMOTE SERVICE BINDING page): "A remote service binding is only necessary for initiating services that communicate with target services outside of the SQL Server instance."

Remote service bindings are required for remote dialog security. However, altough not required, if present, they are honored for local dialogs.

|||

without reading the whole thread in detail, I found that the SQL Profiler lets you find problems within minutes, for which you would normally take hours or days of checking everything!

Trace shows messages and errors, you will never receive through SSB directly!