Re: SQL Server windows authentication issue

From: Steve Thompson (stevethompson_at_nomail.please)
Date: 10/04/04 

Date: Mon, 4 Oct 2004 15:11:21 -0400

You may want to check the following as a first step.

How to troubleshoot connectivity issues in SQL Server
http://support.microsoft.com/default.aspx?kbid=827422

There was a post recently that suggested setting impersonation (the other
"work around" you've already discovered, removing the TCP/IP library):

Impersonate SQL Server users.

Usually you can impersonate users by going to the Local security policy in
Administrative Tools, then to Impersonate a client after authentication.
However, if you deal with the Domain controller, most of the controls there
are disabled. So:

1. Go to the Active Directory, right-click on Domain Controllers and select
Properties
2. Go to the Group Policy tab and highlight Default Domain Controller
Policy, click Edit
3. Go to Windows Settings - Security Settings - Local Policies - User Rights
Assignment
4. Double-click Impersonate a client after authentication

Then Microsoft suggested to uncheck the box Define these policy settings,
then go to the Local security policy and add users there. It worked.
However, I think it would be better just add the users right there, without
going to the Local security policy.

Steve

"Richard" <Rich@xyz.com> wrote in message
news:eaRUkIjqEHA.1668@TK2MSFTNGP14.phx.gbl...
> I have a SQL 2000 server that is running sp 3a. Everything has been
working
> fine using mixed mode authentication. This morning when I try to connect
> using enterprise manager or query analyser (using windows authentication)
> and it fails with the following message:-
>
> A connection could not be established to [machine name].
> Reason: Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
> Please verify SQL server is running and check your SQL registration
> properties and try again.
>
> I can log into the server using SQL authentication or a local account on
the
> machine but I cannot log on using any domain account. We recently
upgraded
> from an NT 4 domain to a windows 2003 (mixed mode) domain, though
everything
> has worked fine for well over a week.
>
> I have noticed if I change the client network setting to make named pipes
> higher priority than TCP/IP it also works, although this is a workaround I
> really want to solve the issue.
>
> Please can anyone suggest any possible resolution.
>
> Thanks
>
>
> Richard
>
>

Relevant Pages

  • Re: Impersonation ASPNET SQL Server
    ... I think you need to impersonate those user accounts in asp.net ... !Subject: Re: Impersonation ASPNET SQL Server ... Authentication, and Secure Communication is just one ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Login failed for user (null)
    ... Go to SQL Server properties, then to General tab - Network configuration. ... Impersonate SQL Server users. ... then go to the Local security policy and add users there. ... > connect to SQL Server 2000, using trusted connection. ...
    (microsoft.public.sqlserver.clients)
  • Re: Connecting to SQLServer 2000 from ASP.NET
    ... Integrated windows authentication or Forms authentication) and it should ... with a developer's domain account. ... It should be OK to have the impersonate settings in machine.config ... meant to be a remedy in the development enviroment, whereby the SQL Server ...
    (microsoft.public.dotnet.framework.aspnet)
  • Login failed for user (null). Reason: Not associated with a trusted SQL Server connection
    ... Not associated with a trusted SQL Server connection. ... Impersonate SQL Server users. ... However, if you deal with the Domain controller, most of the controls there ... then go to the Local security policy and add users there. ...
    (microsoft.public.sqlserver.server)
  • Login failed for user (null). Reason: Not associated with a trusted SQL Server connection
    ... Not associated with a trusted SQL Server connection. ... Impersonate SQL Server users. ... However, if you deal with the Domain controller, most of the controls there ... then go to the Local security policy and add users there. ...
    (microsoft.public.windows.server.security)