Delegation stops working after a while

I have a linked server set up between two servers (A & B).
Server A is running 2005 and Server B is running 2000.
Both servers SQL services are running using a domain user account and have
their SPN's registered in the AD.
The client connects to Server A using integrated security (TCP/IP and
Kerberos not NTLM) and runs disributed queries using the linked server to
server B.
Delegation is set up in the AD and is working, at least for some time.
After a while (sometimes a couple of minutes, sometimes a couple of hours)
the delegation seems to stop working and the client recieves the error
"Login
failed for user '(null)'. Reason: Not associated with a trusted SQL Server
connection." The client is still connected and authenticated using TCP/IP
and
Kerberos.
After a restart of SQL Server on server A the delegation starts working
again.
I cannt find anything in the eventlogs on either one of the servers or the
client, and nothing in the sql server logs.
Does anybody have any idea of what could be wrong, or give me a though on
where to start looking.
Thanks
/MattiasWe are encountering this problem also. I have contacted MS but they are
still gathering information.
There is at least one other unanswered post on this here as well, see
subject = "SQL2005 Linked server authentication drops".
Are you running sql server under under a domain account that is not in the
local admins group by any chance?
--
-b
"Mattias" wrote:

> I have a linked server set up between two servers (A & B).
> Server A is running 2005 and Server B is running 2000.
> Both servers SQL services are running using a domain user account and have
> their SPN's registered in the AD.
> The client connects to Server A using integrated security (TCP/IP and
> Kerberos not NTLM) and runs disributed queries using the linked server to
> server B.
> Delegation is set up in the AD and is working, at least for some time.
> After a while (sometimes a couple of minutes, sometimes a couple of hours)
> the delegation seems to stop working and the client recieves the error
> "Login
> failed for user '(null)'. Reason: Not associated with a trusted SQL Server
> connection." The client is still connected and authenticated using TCP/IP
> and
> Kerberos.
> After a restart of SQL Server on server A the delegation starts working
> again.
> I cannt find anything in the eventlogs on either one of the servers or the
> client, and nothing in the sql server logs.
> Does anybody have any idea of what could be wrong, or give me a though on
> where to start looking.
> Thanks
> /Mattias
>
>|||I am the other unanswered posting!
It fails intermittently when we run under 'sa' or a domain account that is
in the local admin group.
I have raised this through the Microsoft concierge service and they said
there are others with the same problem but no resolutions as yet!
Wendy
"BBogart" wrote:
[vbcol=seagreen]
> We are encountering this problem also. I have contacted MS but they are
> still gathering information.
> There is at least one other unanswered post on this here as well, see
> subject = "SQL2005 Linked server authentication drops".
> Are you running sql server under under a domain account that is not in the
> local admins group by any chance?
> --
> -b
>
> "Mattias" wrote:
>|||We have seen this in our environment too. One moment a linked server query
will work just fine with delegated Windows credentials, the next moment you
receive errors like the following:
OLE DB provider "SQLNCLI" for linked server "THESERVER" returned message
"Communication link failure".
Msg 10054, Level 16, State 1, Line 0
TCP Provider: An existing connection was forcibly closed by the remote host.
Msg 18452, Level 14, State 1, Line 0
Login failed for user '(null)'. Reason: Not associated with a trusted SQL
Server connection.
I am still working on a reproducable way of generating the message, but I
seem to have problems a lot when I initially generate a linked server within
SQL Management Studio 2005. My connections rarely last beyond 24 hours, and
I suspect that something in the Kerberos token is expiring. After I logout
and login, I can usually start a new session that works (just not today).
"Woo" wrote:
[vbcol=seagreen]
> I am the other unanswered posting!
> It fails intermittently when we run under 'sa' or a domain account that is
> in the local admin group.
> I have raised this through the Microsoft concierge service and they said
> there are others with the same problem but no resolutions as yet!
> Wendy
>
>
> "BBogart" wrote:
>|||I also suspect a ticket is expiring.
I am still working with MS on this with no resolution yet.
Once we see a failure, failures continue regardless of logging off and back
on until sql server is restarted. A reboot is not necessary as I previously
thought.
We have seen it take as little as a few hours or up to a week or more for
the failures to start again.
--
-b
"JD Qixcle" wrote:
[vbcol=seagreen]
> We have seen this in our environment too. One moment a linked server quer
y
> will work just fine with delegated Windows credentials, the next moment yo
u
> receive errors like the following:
> OLE DB provider "SQLNCLI" for linked server "THESERVER" returned message
> "Communication link failure".
> Msg 10054, Level 16, State 1, Line 0
> TCP Provider: An existing connection was forcibly closed by the remote hos
t.
> Msg 18452, Level 14, State 1, Line 0
> Login failed for user '(null)'. Reason: Not associated with a trusted SQL
> Server connection.
> I am still working on a reproducable way of generating the message, but I
> seem to have problems a lot when I initially generate a linked server with
in
> SQL Management Studio 2005. My connections rarely last beyond 24 hours, a
nd
> I suspect that something in the Kerberos token is expiring. After I logou
t
> and login, I can usually start a new session that works (just not today).
>
>
> "Woo" wrote:
>|||Did you have this issue resolved ?
Any hints / links /pointers/ thots will be appreciated
Thanks,
GA
"BBogart" wrote:
[vbcol=seagreen]
> I also suspect a ticket is expiring.
> I am still working with MS on this with no resolution yet.
> Once we see a failure, failures continue regardless of logging off and bac
k
> on until sql server is restarted. A reboot is not necessary as I previous
ly
> thought.
> We have seen it take as little as a few hours or up to a week or more for
> the failures to start again.
> --
> -b
> "JD Qixcle" wrote:
>|||-b
"DallasBlue" wrote:
[vbcol=seagreen]
> Did you have this issue resolved ?
> Any hints / links /pointers/ thots will be appreciated
> Thanks,
> GA
> "BBogart" wrote:
>