March 14, 2012 at 8:24 am
I think you need to modify the linked server security information on server A.
On the security page of the linked server's properties on server A, tell it what security context (this needs to be an SQL security context valid on server B) to "emulate" when sa (or A\local_machine, or whatever you expect to be running as when you make the call) tries to use the link.
Tom
March 14, 2012 at 8:28 am
Alternatively, give the user who makes the linked server access from server A permission to execute as a (windows) login which is valid login which is valid on server B, then use EXECUTE AS LOGIN= that login before making the linked access, and REVERT after making it.
Tom
March 14, 2012 at 8:44 am
L' Eomot Inversé (3/14/2012)
I think you need to modify the linked server security information on server A.On the security page of the linked server's properties on server A, tell it what security context (this needs to be an SQL security context valid on server B) to "emulate" when sa (or A\local_machine, or whatever you expect to be running as when you make the call) tries to use the link.
+1
I think this is the way to go.
You can use the security page to map local logins to remote logins. Remember that the Remote User must be a SQL Server Authentication login.
-- Gianluca Sartori
March 14, 2012 at 9:04 am
The problem may be the fact you are using the local service account on one of the servers. From BOL:
Using the Local Service Account
The Local Service account is a special, built-in account that is similar to an authenticated user account. The Local Service account has the same level of access to resources and objects as members of the Users group. This limited access helps safeguard your system if individual services or processes are compromised. Services that run as the Local Service account access network resources as a null session with no credentials.
March 14, 2012 at 9:36 am
Lynn Pettis (3/14/2012)
The problem may be the fact you are using the local service account on one of the servers. From BOL:Using the Local Service Account
The Local Service account is a special, built-in account that is similar to an authenticated user account. The Local Service account has the same level of access to resources and objects as members of the Users group. This limited access helps safeguard your system if individual services or processes are compromised. Services that run as the Local Service account access network resources as a null session with no credentials.
I was under the impression you never want to actually run SQL under this account anyways for other security reasons.
And you should be able to see on the server being contacted an anonymous connection.
To validate some of the scenario, you might want to see if you can go from B to A.
Since B sounds like it runs under a domain user account, I would expect different results.
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply