Showing posts with label w2k. Show all posts
Showing posts with label w2k. Show all posts

Tuesday, February 14, 2012

Cannot generate SSPI context

Hi All,
I am experiencing problems with a remote user (w2k pro,sql 7) attempting
to connect and replicate with a Sql Server 7 on NT server.
They are receiving 'Cannot generate SSPI context' messages when trying to
use a vb app over a vpn. This problem cleared (perhaps due to a server
reboot) but then they experienced replication failure:
'The process could not connect to Publisher 'xyz''.'Cannot generate SSPI
context'.
There has been no re-configuration of the server and I am assured none at
the client end. However I experienced the problem once recently and it has
not occurred since. No other users are experiencing the same problem.I am co
nfused as to why it should start now.
Any help appreciated,
DaveD.I'm having a similar problem and am desperate for help. Please let me know
if you find a solution. I'm running Server 2003 (with Active Directory) and
SQL Server 2000. Nothing that I've read in any of the existing knowlege ba
se seems to help. Also, st
rangely, a friend at a completely unrelated company started getting the same
problem on the same day. We are wondering if it was a result of a virus or
Windows Update.
In my case, I see SQL for a while from a client computer but then seem to lo
se my connection. I'm fine as long as I keep Query Analyzer open but as soo
n as I close it and try to re-open it I get the error.|||"Cannot Generate SSPI Context" indicates a problem with Kerberos or with
the configuration of Kerberos. If it is a consistent problem it may be a
bad SPN (often the SPN incorrectly belongs to the computer instead of to
the account used to start the SQL Server service). If it is an intermittent
problem it may have to do with communications to the PDC or KDC.
811889 HOW TO: Troubleshoot the "Cannot Generate SSPI Context" Error Message
http://support.microsoft.com/?id=811889
Cindy Gross, MCDBA, MCSE
http://cindygross.tripod.com
This posting is provided "AS IS" with no warranties, and confers no rights.

cannot generate SSPI context

Hi,
This only happens on a particular user's machine so far. the user is using
ms access, using odbc link to connect to SQL Server 2000 SP3a on W2k server.
With the MS Access running , suddenly the error happend when i ping the sql
server i can get its ip addr
i have checked the ms article on the SSPI but it does not seem to apply for
me in my case
appreciate any advise
tks & rdgs
Message posted via droptable.com
http://www.droptable.com/Uwe/Forums...ivity/200512/1
One thing to check is the SQL Client Network stack. This is configured in the
(SQL Server) Client Network Utility. What you will probably find is that the
working clients either have Named Pipes before TCP/IP, or left out TCP/IP.
While the problem client will have TCP/IP first, or left out Named Pipes.
At a guess, you are running the SQL Server with a Domain Account, but it
does not have the permission to register the SQL Server's SPN (Service
Principal Name). This means that it cannot use delegation, which probably
isn't a problem for you guys. But when someone tries to attach using TCP/IP,
it can't use Kerberos and throws the error.
Clients that connect Named Pipes just by-pass Kerberos and security account
delegation.
I may have gotten a couple of the details mixed up, I'm not 100% on this.
There is a good Trouble Shooting page in the SQL Support and in BOL, under
Administering SQL Server is a page called "Security Account Delegation" that
is worth a read.
Good luck
"maxzsim via droptable.com" wrote:

> Hi,
>
> This only happens on a particular user's machine so far. the user is using
> ms access, using odbc link to connect to SQL Server 2000 SP3a on W2k server.
> With the MS Access running , suddenly the error happend when i ping the sql
> server i can get its ip addr
> i have checked the ms article on the SSPI but it does not seem to apply for
> me in my case
> appreciate any advise
> tks & rdgs
> --
> Message posted via droptable.com
> http://www.droptable.com/Uwe/Forums...ivity/200512/1
>