Preventing login as 'NT AUTHORITY\ANONYMOUS LOGON'

E

et

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.
 
E

et

It's in the web.config file, then in my class I have it as a property:
<appSettings>

<add key="SQLConnectionString" value="Data Source=Server6;Initial
Catalog=Server6DB;Integrated Security=SSPI;Persist Security Info=False" />

</appSettings>

Private mstrSQLConn As String =
ConfigurationSettings.AppSettings("SQLConnectionString")



Public ReadOnly Property ConnectionString() As String

Get

Return mstrSQLConn

End Get

End Property
 
E

et

I'm thinking that one control may be closing the connection while another
control is attempting to use it?? Does that mean I have to repeat the
connection process on every form and every user control, so that each
control uses it's own connection??
 
E

et

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>
 
D

Daniel Walzenbach

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 said:
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 said:
are your server in the same domain? can you post your web.config?
 
E

et

It might, I'll take out the impersonate and let you know. I had understood
the program will not run without the impersonate in there.

Thanks!

Daniel Walzenbach said:
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 said:
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 said:
are your server in the same domain? can you post your web.config?


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.
 
E

et

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 said:
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 said:
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 said:
are your server in the same domain? can you post your web.config?


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.
 
J

Juan T. Llibre

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.







et said:
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 said:
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 said:
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>




are your server in the same domain? can you post your web.config?


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.
 
E

et

That makes a lot of sense, I'll bet you've hit the nail on the head. I'll
keep you posted. Thanks so much!


Juan T. Llibre said:
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.







et said:
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 said:
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



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>




message are your server in the same domain? can you post your web.config?


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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top