servers

Hello,
I am having trouble with creating a linked server (as simple as it should
be).
My Setup:
Server A: runs under a specific account, the account can be delegated, I
have used setspn on this machine (as per BOL), I have also created a linked
server to Server B (mapping each user context as they connect)
Server B: runs under the same account (which can be delegated), I have not
used setspn as I only want people to connect remotely from Server A.
If I log onto Server A, run a query like select * from
serverb.database.owner.table everything runs fine, I can connect remotely,
now, here is the hitch:
I work on Client machine C, when I try and run the same query that worked on
server A, I get:
Msg 18452, Level 14, State 1, Line 1
Login failed for user '(null)'. Reason: Not associated with a trusted SQL
Server connection.
What am I doing wrong?
Appreciate any insight into this
Malcolm.Mapping each user context to what? Sounds like the users are
authenticated using their Windows credentials and mapping is
set to their credentials so for their AD accounts, the
setting for:
Account is sensitive and cannot be delegated
needs to be turned off or deselected.
The server also needs to be trusted for delegation.
You also need to check your protocols and listening ports.
The books online article:
Security Account Delegation
has all of the requirements. If you are running on SP3 or
higher, make sure you are referencing the updated help
topic. You can also find it here:
http://msdn.microsoft.com/library/d...>
ity_2gmm.asp
-Sue
On Tue, 8 Nov 2005 12:21:17 -0500, "Malcolm Klotz"
<nonesuch23@.online.nospam> wrote:

>Hello,
>I am having trouble with creating a linked server (as simple as it should
>be).
>My Setup:
>Server A: runs under a specific account, the account can be delegated, I
>have used setspn on this machine (as per BOL), I have also created a linked
>server to Server B (mapping each user context as they connect)
>Server B: runs under the same account (which can be delegated), I have not
>used setspn as I only want people to connect remotely from Server A.
>If I log onto Server A, run a query like select * from
>serverb.database.owner.table everything runs fine, I can connect remotely,
>now, here is the hitch:
>I work on Client machine C, when I try and run the same query that worked o
n
>server A, I get:
>Msg 18452, Level 14, State 1, Line 1
>Login failed for user '(null)'. Reason: Not associated with a trusted SQL
>Server connection.
>What am I doing wrong?
>Appreciate any insight into this
>Malcolm.
>|||Hello,
To narrow down the issue, I suggest that you perform the following steps:
1. I assume both servers are SQL server 2000. If not, please provide more
detailed information about the linked server.
2. Set boh SQL server startup accounts to be a Domain account. Use SA to
connect to the SQL server A from the client, then check the issue again.
If it works fine, the cause is related to Security Account Delegation. If
so, please continue with the following steps:
3. Follow the steps on the following web site to set Delegation
Security Account Delegation
<http://msdn.microsoft.com/library/d...n-us/adminsql/a
d_security_2gmm.asp>
Run the "setspn -l" to verify it. For example, if you create an SPN for SQL
Server:
setspn -A MSSQLSvc/w2k3sqlsp4.test.com:1433
test\administrator
You can verify it by running
setspn -l test\administrator
It will return:
Registered ServicePrincipalNames for
CN= administrator, CN=users, DC=test, DC=com:
MSSQLSvc/envm-w2k3entsp1.test.com:1061
MSSQLSvc/w2k3sqlsp4:1433
MSSQLSvc/w2k3sqlsp4.test.com:1433
Please post here how you create the SPN for SQL Server and the results of
the "setspn -l".
4. Refer to the following article to troublshoot the issue:
http://support.microsoft.com/?id=319723#1
I hope the information is helpful.
Sophie Guo
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
========================================
=============
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
========================================
=============
This posting is provided "AS IS" with no warranties, and confers no rights.|||Thank you, this worked, I had used the wrong port for one of my instances.
Much appreciated.
Malcolm
"Sophie Guo [MSFT]" <v-sguo@.online.microsoft.com> wrote in message
news:O4UWYKR5FHA.1240@.TK2MSFTNGXA02.phx.gbl...
> Hello,
> To narrow down the issue, I suggest that you perform the following steps:
> 1. I assume both servers are SQL server 2000. If not, please provide more
> detailed information about the linked server.
> 2. Set boh SQL server startup accounts to be a Domain account. Use SA to
> connect to the SQL server A from the client, then check the issue again.
> If it works fine, the cause is related to Security Account Delegation. If
> so, please continue with the following steps:
> 3. Follow the steps on the following web site to set Delegation
> Security Account Delegation
> <[url]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adminsql/a[/ur
l]
> d_security_2gmm.asp>
> Run the "setspn -l" to verify it. For example, if you create an SPN for
> SQL
> Server:
> setspn -A MSSQLSvc/w2k3sqlsp4.test.com:1433
> test\administrator
> You can verify it by running
> setspn -l test\administrator
> It will return:
> Registered ServicePrincipalNames for
> CN= administrator, CN=users, DC=test, DC=com:
> MSSQLSvc/envm-w2k3entsp1.test.com:1061
> MSSQLSvc/w2k3sqlsp4:1433
> MSSQLSvc/w2k3sqlsp4.test.com:1433
> Please post here how you create the SPN for SQL Server and the results of
> the "setspn -l".
> 4. Refer to the following article to troublshoot the issue:
> http://support.microsoft.com/?id=319723#1
> I hope the information is helpful.
> Sophie Guo
> Microsoft Online Partner Support
> Get Secure! - www.microsoft.com/security
> ========================================
=============
> When responding to posts, please "Reply to Group" via your newsreader so
> that others may learn and benefit from your issue.
> ========================================
=============
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
>