Re: Preventing login as 'NT AUTHORITY\ANONYMOUS LOGON'

re:
> So the identity impersonate needs to be there so we can connect to sql.

You should look a bit deeper into what impersonation is.

The *reason* you are impersonating is because the account which you have
designated ASP.NET to run under has login credentials to your sql database.

If one is an external web server (the one that works) and the one that doesn't
work is an internal web server, maybe you need to impersonate with one server,
but not with the other.

IOW, your SQL server ( which I assume is within your domain ) may be able to
grant login rights to your internal web server's account *without* needing to
impersonate a custom account which the external web server needs to authenticate.

You can't expect *both* servers ( internal and external )
to use the same authentication credentials.





Juan T. Llibre
ASP.NET MVP
http://asp.net.do/foros/
Foros de ASP.NET en Español
Ven, y hablemos de ASP.NET...
======================

"et" <eagletender2001@xxxxxxxxx> wrote in message
news:O%23plLogcFHA.1404@xxxxxxxxxxxxxxxxxxxxxxx
> Well, no that didn't work, now I get the error: Login failed; Reason not associated
> with a trust sql server connection. So the identity impersonate needs to be there so we
> can connect to sql.
>
> "Daniel Walzenbach" <daniel.walzenbach@xxxxxxxxxxxxxxxx> wrote in message
> news:%23kpJCzecFHA.3504@xxxxxxxxxxxxxxxxxxxxxxx
>> why do you impersonate? In your configuration every user who wants to use your
>> application has to have file access (NTFS) on your application! This might be the
>> problem. This configuration also creates one connection pool per user which (I assume
>> by now) is nothing you really want.
>>
>> Does this help?
>>
>> Daniel
>>
>>
>>
>> "et" <eagletender2001@xxxxxxxxx> schrieb im Newsbeitrag
>> news:OIgUmgecFHA.3464@xxxxxxxxxxxxxxxxxxxxxxx
>>> Yes, servers are in the same domain, however one is an external web server (the one
>>> that works) and the one that doesn't work is an internal web server. Below is the
>>> web.config, obviously the change between servers being the server name and the
>>> database name. Thanks so much for your help.
>>>
>>>
>>> <?xml version="1.0" encoding="utf-8" ?>
>>> <configuration>
>>>
>>> <configSections>
>>> <section name="AppConfig" type="WebCommonVB.WebAppConfig, WebCommonVB" />
>>> <section name="exceptionManagement"
>>> type="Microsoft.ApplicationBlocks.ExceptionManagement.ExceptionManagerSectionHandler,
>>> Microsoft.ApplicationBlocks.ExceptionManagement" />
>>> </configSections>
>>> <appSettings>
>>> <add key="SQLConnectionString" value="Data Source=Server6;Initial
>>> Catalog=Server6DB;Integrated Security=SSPI;Persist Security Info=False;Packet
>>> Size=4096" />
>>> </appSettings>
>>>
>>>
>>> <system.web>
>>>
>>> <!-- DYNAMIC DEBUG COMPILATION
>>> Set compilation debug="true" to insert debugging symbols (.pdb information)
>>> into the compiled page. Because this creates a larger file that executes
>>> more slowly, you should set this value to true only when debugging and to
>>> false at all other times. For more information, refer to the documentation
>>> about
>>> debugging ASP.NET files.
>>> -->
>>> <compilation defaultLanguage="vb" debug="true" />
>>>
>>> <!-- CUSTOM ERROR MESSAGES
>>> Set customErrors mode="On" or "RemoteOnly" to enable custom error messages,
>>> "Off" to disable.
>>> Add <error> tags for each of the errors you want to handle.
>>>
>>> "On" Always display custom (friendly) messages.
>>> "Off" Always display detailed ASP.NET error information.
>>> "RemoteOnly" Display custom (friendly) messages only to users not running
>>> on the local Web server. This setting is recommended for security purposes,
>>> so
>>> that you do not display application detail information to remote clients.
>>> -->
>>> <customErrors mode="Off" />
>>>
>>> <!-- AUTHENTICATION
>>> This section sets the authentication policies of the application. Possible
>>> modes are "Windows",
>>> "Forms", "Passport" and "None"
>>>
>>> "None" No authentication is performed.
>>> "Windows" IIS performs authentication (Basic, Digest, or Integrated Windows)
>>> according to
>>> its settings for the application. Anonymous access must be disabled in IIS.
>>> "Forms" You provide a custom form (Web page) for users to enter their
>>> credentials, and then
>>> you authenticate them in your application. A user credential token is stored
>>> in a cookie.
>>> "Passport" Authentication is performed via a centralized authentication
>>> service provided
>>> by Microsoft that offers a single logon and core profile services for member
>>> sites.
>>> -->
>>> <authentication mode="Windows" />
>>> <identity impersonate="true"/>
>>>
>>> <!-- AUTHORIZATION
>>> This section sets the authorization policies of the application. You can
>>> allow or deny access
>>> to application resources by user or role. Wildcards: "*" mean everyone, "?"
>>> means anonymous
>>> (unauthenticated) users.
>>> -->
>>> <authorization>
>>> <allow users="*" /> <!-- Allow all users -->
>>>
>>> <!-- <allow users="[comma separated list of users]"
>>> roles="[comma separated list of roles]"/>
>>> <deny users="[comma separated list of users]"
>>> roles="[comma separated list of roles]"/>
>>> -->
>>> </authorization>
>>>
>>> <!-- APPLICATION-LEVEL TRACE LOGGING
>>> Application-level tracing enables trace log output for every page within an
>>> application.
>>> Set trace enabled="true" to enable application trace logging. If
>>> pageOutput="true", the
>>> trace information will be displayed at the bottom of each page. Otherwise,
>>> you can view the
>>> application trace log by browsing the "trace.axd" page from your web
>>> application
>>> root.
>>> -->
>>> <trace enabled="false" requestLimit="1000" pageOutput="true" traceMode="SortByTime"
>>> localOnly="true" />
>>>
>>>
>>> <!-- SESSION STATE SETTINGS
>>> By default ASP.NET uses cookies to identify which requests belong to a
>>> particular session.
>>> If cookies are not available, a session can be tracked by adding a session
>>> identifier to the URL.
>>> To disable cookies, set sessionState cookieless="true".
>>> -->
>>> <sessionState
>>> mode="InProc"
>>> stateConnectionString="tcpip=127.0.0.1:42424"
>>> sqlConnectionString="data source=127.0.0.1;Trusted_Connection=yes"
>>> cookieless="false"
>>> timeout="20"
>>> />
>>>
>>> <!-- GLOBALIZATION
>>> This section sets the globalization settings of the application.
>>> -->
>>> <globalization requestEncoding="utf-8" responseEncoding="utf-8" />
>>>
>>> </system.web>
>>>
>>> </configuration>
>>>
>>>
>>>
>>>
>>> "Daniel Walzenbach" <daniel.walzenbach@xxxxxxxxxxxxxxxx> wrote in message
>>> news:OjboltVcFHA.456@xxxxxxxxxxxxxxxxxxxxxxx
>>>> are your server in the same domain? can you post your web.config?
>>>>
>>>>
>>>> "et" <eagletender2001@xxxxxxxxx> schrieb im Newsbeitrag
>>>> news:ewbSeFScFHA.3560@xxxxxxxxxxxxxxxxxxxxxxx
>>>>>I have an asp.net program that uses a connection string, using integrated security to
>>>>>connect to a sql database. It runs fine on one server, but the other server gives me
>>>>>the error that
>>>>> "Login failed for user "NT AUTHORITY/ANONYMOUS LOGON". Why would this be? There is
>>>>> no reason it should even be trying to login to using NT Authority/Anonymous login.
>>>>> The IIS Server is set to turn off anonymous logins, and use integrated security, and
>>>>> my program uses a connection string with integrated security. And sometimes it does
>>>>> run, almost like there's a contest between which logon the program is going to use
>>>>> and in about five minutes it connects properly. But I have no idea why it would be
>>>>> losing the connection string I have in the web.config. And as I mentioned, it works
>>>>> fine on another server, the difference being the other server forces the user to
>>>>> login first. I have one or two forms, with several user controls that are loaded
>>>>> depending on what the user selects.
>>>>>
>>>>> Thanks for any assistance you can send my way.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


.

Relevant Pages

  • Re: SQLServer Connection Problems...
    ... making it all the way to SQL but its failing at the SQL login. ... Only take this step if your server is protected inside a good firewall... ... Most good judgment comes from experience. ... I can ping the SBS server from the Web Server on a local ip address ...
    (microsoft.public.sqlserver.connect)
  • Re: Using Access to access an sql database on a webserver
    ... a open sql port is not available. ... that very same web server has complete and free rein to access those files, ... Well, yes, if you are taking about ASP pages hosted on that site...right? ...
    (comp.databases.ms-access)
  • Re: Using Access to access an sql database on a webserver
    ... a open sql port is not available. ... way of directly getting to the database to execute arbitrary SQL ... This is exactly the same concept for that web server ...
    (comp.databases.ms-access)
  • Re: Preventing login as NT AUTHORITYANONYMOUS LOGON
    ... >> So the identity impersonate needs to be there so we can connect to sql. ... > work is an internal web server, maybe you need to impersonate with one ... > grant login rights to your internal web server's account *without* needing ...
    (microsoft.public.dotnet.framework.aspnet)
  • SQL server authentication using impersonation
    ... I have a web server on a SBS 2003 box, ... I want to impersonate the current user when executing SQL procedures. ... The database filters rows depending on who the windows user is, ...
    (microsoft.public.dotnet.framework.adonet)