Windows Authentication no longer works after service account chang

In the process of regular reviews and security, we found a SQL server 2000
that was using the administrator account as the service account for SQL
server.  All of our other SQL servers use a special sql service account with
stripped down rights.

Yesterday evening, we switched the account used by the SQL server from
administrator to the sql service account through Enterprise Manager.  After
performing this switch, our AD group used for Windows authentication in SQL
server no longer seemed to work.  We received the following message when
trying to connect via Query Analyzer:

Unable to connect to server xxx:
ODBC: Msg 0, Level 16, State 1
[Microsoft][ODBC SQL Server Driver]Cannot generate SSPI context.

What confuses us is that the same sql service account is used on all of our
other SQL servers.  I would state that the other SQL servers had that sql
service account from setup.

Are there any other steps needed beyond the change in Enterprise Manager to
move services from one logon account to another?

We can still connect using Windows Authentication using named pipes instead
of TCP/IP.

Thanks for your input.

Shannon,

Might check out:

How to troubleshoot the "Cannot generate SSPI context" error message.
http://support.microsoft.com/?id=811889

HTH

Jerry
"Shannon Broskie" < ShannonBroskie@discu
ssions.microsoft.com> wrote in
message news:50387E1A-EFD6-411E-93B8- 21A9531A4DF1@microso
ft.com...
> In the process of regular reviews and security, we found a SQL server 2000
> that was using the administrator account as the service account for SQL
> server.  All of our other SQL servers use a special sql service account
> with
> stripped down rights.
>
> Yesterday evening, we switched the account used by the SQL server from
> administrator to the sql service account through Enterprise Manager.
> After
> performing this switch, our AD group used for Windows authentication in
> SQL
> server no longer seemed to work.  We received the following message when
> trying to connect via Query Analyzer:
>
> Unable to connect to server xxx:
> ODBC: Msg 0, Level 16, State 1
> [Microsoft][ODBC SQL Server Driver]Cannot generate SSPI context.
>
> What confuses us is that the same sql service account is used on all of
> our
> other SQL servers.  I would state that the other SQL servers had that sql
> service account from setup.
>
> Are there any other steps needed beyond the change in Enterprise Manager
> to
> move services from one logon account to another?
>
> We can still connect using Windows Authentication using named pipes
> instead
> of TCP/IP.
>
> Thanks for your input.

Shannon,

Also:

http://support.microsoft.com/defaul...kb;en-us;827422
and
http://support.microsoft.com/defaul...kb;en-us;269541

HTH

Jerry
"Shannon Broskie" < ShannonBroskie@discu
ssions.microsoft.com> wrote in
message news:50387E1A-EFD6-411E-93B8- 21A9531A4DF1@microso
ft.com...
> In the process of regular reviews and security, we found a SQL server 2000
> that was using the administrator account as the service account for SQL
> server.  All of our other SQL servers use a special sql service account
> with
> stripped down rights.
>
> Yesterday evening, we switched the account used by the SQL server from
> administrator to the sql service account through Enterprise Manager.
> After
> performing this switch, our AD group used for Windows authentication in
> SQL
> server no longer seemed to work.  We received the following message when
> trying to connect via Query Analyzer:
>
> Unable to connect to server xxx:
> ODBC: Msg 0, Level 16, State 1
> [Microsoft][ODBC SQL Server Driver]Cannot generate SSPI context.
>
> What confuses us is that the same sql service account is used on all of
> our
> other SQL servers.  I would state that the other SQL servers had that sql
> service account from setup.
>
> Are there any other steps needed beyond the change in Enterprise Manager
> to
> move services from one logon account to another?
>
> We can still connect using Windows Authentication using named pipes
> instead
> of TCP/IP.
>
> Thanks for your input.