Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > ASP .Net Security > Login failed for user '(null)'.

Reply
Thread Tools

Login failed for user '(null)'.

 
 
Herb
Guest
Posts: n/a
 
      07-26-2006
I get the error message:
Login failed for user '(null)'. Reason: Not associated with a trusted SQL
Server connection.

in my ASP.NET CLR 2 website.

I am using Forms authentication, is this the cause? Shouldn't there be a
default user?

Other info:
SQL Server 7
aspnetdb

Thanks
 
Reply With Quote
 
 
 
 
PolarBears
Guest
Posts: n/a
 
      07-26-2006
I'm getting the error too. However, an interesting twist on what I am getting.
I have Sql Server 2000, Web Server is on separate machine from Database
Server. I ran the ASP.NET script that creates a Membership Database. And
that part seems to work fine.

I can even access a table in the Membership Database and display it in a
table on our intranet website, and it works. HOWEVER, where I am having
difficulty is when I create a separate Login Application. I have the
original application displaying the table first point to the login page, and
it does. Then I log in, and when I hit the submit button I get the error.

So the membership tables will display in a table or grid fine, but in
putting the membership table into practice with a login page, I get the
error. I know its got to be something small, but those are usually the
things that drive people nuts.

Thanks,

Danny


"Herb" wrote:

> I get the error message:
> Login failed for user '(null)'. Reason: Not associated with a trusted SQL
> Server connection.
>
> in my ASP.NET CLR 2 website.
>
> I am using Forms authentication, is this the cause? Shouldn't there be a
> default user?
>
> Other info:
> SQL Server 7
> aspnetdb
>
> Thanks

 
Reply With Quote
 
 
 
 
Steven Cheng[MSFT]
Guest
Posts: n/a
 
      07-27-2006
Hello Herb and Danny,

The "Login failed for user '(null)'." error message is a typical access
permission error of SQL Server. And the "(null)" indicate that the user
try to access the SQL Server is not a valid account(not recognizable) on
the SQL Server machine(suppose the SQL Server is on a remote box in your
environment).

Since you're encountering the error when running the ASP.NET web
application, I'd like to confirm the following things with you:

1. In addition to the FormsAuthentication(which use SQL Server provider to
connect the remote SQL Server database), is there any other data accessing
operation to that remote sqlserver. You need to make sure which
one/connection cause the login fail error.

2. What's the security identity used to access the remote SQL Server, I
suppose you're using windows authentication for the SQL Server
connectionstring. Thus, it will use the current running program's security
context. And for ASP.NET application, it is the ASP.NET worker process's
identity(if you're not using impersonate). For ASP.NET worker process
identity, here are the candidates you can refer to :

1. For II5 on win2k or xp, it by default use the MACHINE\ASPNET account as
the worker process identity(aspnet_wp.exe process).

2. For II6 on win2k3 server, it use the IIS appliation pool's security
identity as the worker process security identity, and the default one is
"NT AUTHORITY\NETWORK SERVICE".

also, you can use the following code to printout the current security
identity of the ASP.NET worker process/thread(if impersonate is not used):

Response.Write("<br/>Identity: " +
System.Security.Principal.WindowsIdentity.GetCurre nt().Name);


Based on my experience, your ASP.NET application is likely running under
the MACHINE\ASPNET (or any other local account) which is not
valid/recognizable by remote machine.

After you verify the current security context of your ASP.NET web
application, we'd determine the approach we'll choose to resolve the
problem. Here is the available options:

1. Change the ASP.NET application's worker process account to another
custom account(local account or domain account) , which can be recogniazble
at remote machine(for local account, we need to create a duplicated account
has the same username and password at the remote machine). Then, at remote
machine(where SQL Server runs), we grant the custom process identity the
sufficient permission to access certain database tables.

#Configuring ASP.NET Process Identity
http://msdn2.microsoft.com/en-us/library/dwc1xthy.aspx

#How To: Create a Service Account for an ASP.NET 2.0 Application
http://msdn.microsoft.com/library/en...9.asp?frame=tr
ue


2. Instead of changing the worker process identity, we can also choose to
do impersonation in our ASP.NET appliation. We can impersonate in
web.config file or programmtically impersonate in code. Here is a knowledge
base article describing ASP.NET impersonate:

#How to implement impersonation in an ASP.NET application
http://support.microsoft.com/kb/306158/en-us



Please verify the above things and let me know if you have anything unclear
or have any further questions.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead



==================================================

Get notification to my posts through email? Please refer to

http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.



Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial

response from the community or a Microsoft Support Engineer within 1
business day is

acceptable. Please note that each follow up response may take approximately
2 business days

as the support professional working with you may need further investigation
to reach the

most efficient resolution. The offering is not appropriate for situations
that require

urgent, real-time or phone-based interactions or complex project analysis
and dump analysis

issues. Issues of this nature are best handled working with a dedicated
Microsoft Support

Engineer by contacting Microsoft Customer Support Services (CSS) at

http://msdn.microsoft.com/subscripti...t/default.aspx.

==================================================



This posting is provided "AS IS" with no warranties, and confers no rights.

 
Reply With Quote
 
Herb
Guest
Posts: n/a
 
      07-27-2006
Steven, Thanks for the reply.

On the development machine everything runs fine. I use one connection string
for db access in the application, and another for security. I have the
following in my web.config:
<connectionStrings>
<add name="myConn1"
connectionString="Provider=SQLOLEDB;
Data Source=MySQLServer;
Integrated Security=SSPI;Initial Catalog=myDB"
providerName="System.Data.OleDb"
/>
<add name="loginConnection"
connectionString="Data Source=MySQLServer;
Integrated Security=SSPI;Initial Catalog=aspnetdb"
/>
</connectionStrings>

My login works fine. I am redirected to the login.aspx when I try to go to
default.aspx and login works correctly.

I am sure it is my non-aspnetdb connection which is failing.

My application has several different levels of access. I want to use the ID
used at signon to authenticate in SQL Server.

I will read your comments more closely and post my results.

Thanks.

"Steven Cheng[MSFT]" wrote:

> Hello Herb and Danny,
>
> The "Login failed for user '(null)'." error message is a typical access
> permission error of SQL Server. And the "(null)" indicate that the user
> try to access the SQL Server is not a valid account(not recognizable) on
> the SQL Server machine(suppose the SQL Server is on a remote box in your
> environment).
>
> Since you're encountering the error when running the ASP.NET web
> application, I'd like to confirm the following things with you:
>
> 1. In addition to the FormsAuthentication(which use SQL Server provider to
> connect the remote SQL Server database), is there any other data accessing
> operation to that remote sqlserver. You need to make sure which
> one/connection cause the login fail error.
>
> 2. What's the security identity used to access the remote SQL Server, I
> suppose you're using windows authentication for the SQL Server
> connectionstring. Thus, it will use the current running program's security
> context. And for ASP.NET application, it is the ASP.NET worker process's
> identity(if you're not using impersonate). For ASP.NET worker process
> identity, here are the candidates you can refer to :
>
> 1. For II5 on win2k or xp, it by default use the MACHINE\ASPNET account as
> the worker process identity(aspnet_wp.exe process).
>
> 2. For II6 on win2k3 server, it use the IIS appliation pool's security
> identity as the worker process security identity, and the default one is
> "NT AUTHORITY\NETWORK SERVICE".
>
> also, you can use the following code to printout the current security
> identity of the ASP.NET worker process/thread(if impersonate is not used):
>
> Response.Write("<br/>Identity: " +
> System.Security.Principal.WindowsIdentity.GetCurre nt().Name);
>
>
> Based on my experience, your ASP.NET application is likely running under
> the MACHINE\ASPNET (or any other local account) which is not
> valid/recognizable by remote machine.
>
> After you verify the current security context of your ASP.NET web
> application, we'd determine the approach we'll choose to resolve the
> problem. Here is the available options:
>
> 1. Change the ASP.NET application's worker process account to another
> custom account(local account or domain account) , which can be recogniazble
> at remote machine(for local account, we need to create a duplicated account
> has the same username and password at the remote machine). Then, at remote
> machine(where SQL Server runs), we grant the custom process identity the
> sufficient permission to access certain database tables.
>
> #Configuring ASP.NET Process Identity
> http://msdn2.microsoft.com/en-us/library/dwc1xthy.aspx
>
> #How To: Create a Service Account for an ASP.NET 2.0 Application
> http://msdn.microsoft.com/library/en...9.asp?frame=tr
> ue
>
>
> 2. Instead of changing the worker process identity, we can also choose to
> do impersonation in our ASP.NET appliation. We can impersonate in
> web.config file or programmtically impersonate in code. Here is a knowledge
> base article describing ASP.NET impersonate:
>
> #How to implement impersonation in an ASP.NET application
> http://support.microsoft.com/kb/306158/en-us
>
>
>
> Please verify the above things and let me know if you have anything unclear
> or have any further questions.
>
> Sincerely,
>
> Steven Cheng
>
> Microsoft MSDN Online Support Lead
>
>
>
> ==================================================
>
> Get notification to my posts through email? Please refer to
>
> http://msdn.microsoft.com/subscripti...ult.aspx#notif
> ications.
>
>
>
> Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
> where an initial
>
> response from the community or a Microsoft Support Engineer within 1
> business day is
>
> acceptable. Please note that each follow up response may take approximately
> 2 business days
>
> as the support professional working with you may need further investigation
> to reach the
>
> most efficient resolution. The offering is not appropriate for situations
> that require
>
> urgent, real-time or phone-based interactions or complex project analysis
> and dump analysis
>
> issues. Issues of this nature are best handled working with a dedicated
> Microsoft Support
>
> Engineer by contacting Microsoft Customer Support Services (CSS) at
>
> http://msdn.microsoft.com/subscripti...t/default.aspx.
>
> ==================================================
>
>
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>

 
Reply With Quote
 
Steven Cheng[MSFT]
Guest
Posts: n/a
 
      07-28-2006
Thanks for your response Herb,

As you said it runs fine on development machine, are you using file system
based project and run the application in VS 2005 Test WebServer instead of
IIS? If so, this is expected because when using TestWebServer, the
server(WebDev.WebServer.exe) and our ASP.NET application is running under
the current logon user's identity which is generaly a powerful account and
have sufficient permission for both local and remote resources. Does this
make sense to your case?

Since you can make sure that it is the non-aspnetdb connection that fails,
you can create a simple test page which access the remote database through
the certain connectionstring.(I've seen that you're using windows
authentication for all those SQL connection strings) Thus, you can
concentrate on this test page according to the troubleshoot tips I
mentioned in the last message.

Anyway, if you have anything unclear in my pervious reply or meet any
further difficulties, please feel free to let me know.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.



 
Reply With Quote
 
PolarBears
Guest
Posts: n/a
 
      07-28-2006
Ok. I've been playing around with this whole setup and by following the
impersonation instructions, I get the error to go away. However, the Login
Page does not redirect back to the application that called it. It just
blanks the Login Form and pretty much wants you to redo the login. The query
string is up in the address part of the form to redirect, but it doesn't.

What would that mean?

Thanks,

Danny

"Steven Cheng[MSFT]" wrote:

> Thanks for your response Herb,
>
> As you said it runs fine on development machine, are you using file system
> based project and run the application in VS 2005 Test WebServer instead of
> IIS? If so, this is expected because when using TestWebServer, the
> server(WebDev.WebServer.exe) and our ASP.NET application is running under
> the current logon user's identity which is generaly a powerful account and
> have sufficient permission for both local and remote resources. Does this
> make sense to your case?
>
> Since you can make sure that it is the non-aspnetdb connection that fails,
> you can create a simple test page which access the remote database through
> the certain connectionstring.(I've seen that you're using windows
> authentication for all those SQL connection strings) Thus, you can
> concentrate on this test page according to the troubleshoot tips I
> mentioned in the last message.
>
> Anyway, if you have anything unclear in my pervious reply or meet any
> further difficulties, please feel free to let me know.
>
> Sincerely,
>
> Steven Cheng
>
> Microsoft MSDN Online Support Lead
>
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>
>
>

 
Reply With Quote
 
Steven Cheng[MSFT]
Guest
Posts: n/a
 
      07-31-2006
Thanks for your reply Danny,

From your further description, the data access "login failed..." error went
away, but the forms authentication's login behavior become strange(user
never sucessfully login and redirect to the target page), correct?

Though I can not rapidly get what's actually happened inside, it is
apparently related to the changes you've made. Would you please provide me
the detailed information what's the changes you've made in your application
and what's the current security settings in your application.

Also, since there are two data access connectionstring you used in the
application to visit SQL Server, in addition to the forms
authentication/membership connectionstring, does the other connection work
correctly now?

BTW, do you have the sufficient permission to perform database trace on the
remote SQL Server machine(store your formsauthentication/membership data)?
If so, I suggest you peform some tracing through the SQL Server Profiler to
see whether there is any error occured when your ASP.NET application do
login authentication against it.

Please feel free to let me know if you have any other finding or if I've
missed anything.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead


This posting is provided "AS IS" with no warranties, and confers no rights.

 
Reply With Quote
 
PolarBears
Guest
Posts: n/a
 
      09-22-2006
I've been away from this issue for a while, with other things. Here's an
interesting twist that may shed some light. Again, let me set it up. SQL
Server 2000 is on one machine with the database in question. Web Server is
on a second machine.

Approaching from a different direction, I tried this. Using Visual Studio
Tools for Office 2005, I created two buttons and two datagrids. The first
datagrid accesses file "X" via a .NET 1.1 Web Service. The second datagrid
accesses the same file "X" via a .NET 2.0 Web Service. The web services are
on the same machine.

Visual Studio Tools for Office 2005 is running on .NET 2.0. Now, here's the
interesting part, when I click the button to load the data from the .NET 1.1
Web Service, everything loads fine. Duplicated the same process with the
..NET 2.0 Web Service, Login failed for User "Null". This tells me this is
probably something specific to .NET 2.0 and not SQL Server or the Web Server,
else it wouldn't work with .NET 1.1.

-- Danny

"Steven Cheng[MSFT]" wrote:

> Thanks for your reply Danny,
>
> From your further description, the data access "login failed..." error went
> away, but the forms authentication's login behavior become strange(user
> never sucessfully login and redirect to the target page), correct?
>
> Though I can not rapidly get what's actually happened inside, it is
> apparently related to the changes you've made. Would you please provide me
> the detailed information what's the changes you've made in your application
> and what's the current security settings in your application.
>
> Also, since there are two data access connectionstring you used in the
> application to visit SQL Server, in addition to the forms
> authentication/membership connectionstring, does the other connection work
> correctly now?
>
> BTW, do you have the sufficient permission to perform database trace on the
> remote SQL Server machine(store your formsauthentication/membership data)?
> If so, I suggest you peform some tracing through the SQL Server Profiler to
> see whether there is any error occured when your ASP.NET application do
> login authentication against it.
>
> Please feel free to let me know if you have any other finding or if I've
> missed anything.
>
> Sincerely,
>
> Steven Cheng
>
> Microsoft MSDN Online Support Lead
>
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
>

 
Reply With Quote
 
Joe Kaplan
Guest
Posts: n/a
 
      09-23-2006
Unfortunately, your analysis here is most likely wrong. There is nothing
really different between how .NET 1.1 and 2.0 attempt to establish an
authenticated connection with SQL server. If you use a connection string
that uses Windows authentication in both cases, then the authenticated
connection will attempt to be established based on the security token that
is being used to execute the current thread at the time the code is called.
That will either be the security token of the process, or the security token
of some impersonated identity.

Whether or not the remote service accepts the authentication from client
(the web server in this case) depends on whether there is a trust
relationship between the account being authenticated and the remote service
and whether or not the identity being authenticated is being delegated by
the intermediate service (and whether delegation is allowed and configured).

You can discover whether you are getting an apples to apples comparison here
by determining first whether the current security context in both web
applications is the same account. Check
System.Security.Principal.WindowsIdentity.GetCurre nt().Name. If they are
both the same and one can authenticate to the remote SQL server but the
other can't, it is almost certainly because one web application can do
Kerberos delegation and the other one can't. If they aren't the same
account (one is the authenticated user and one is the web server process
account), then you aren't comparing the same thing.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"PolarBears" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> I've been away from this issue for a while, with other things. Here's an
> interesting twist that may shed some light. Again, let me set it up. SQL
> Server 2000 is on one machine with the database in question. Web Server
> is
> on a second machine.
>
> Approaching from a different direction, I tried this. Using Visual Studio
> Tools for Office 2005, I created two buttons and two datagrids. The first
> datagrid accesses file "X" via a .NET 1.1 Web Service. The second
> datagrid
> accesses the same file "X" via a .NET 2.0 Web Service. The web services
> are
> on the same machine.
>
> Visual Studio Tools for Office 2005 is running on .NET 2.0. Now, here's
> the
> interesting part, when I click the button to load the data from the .NET
> 1.1
> Web Service, everything loads fine. Duplicated the same process with the
> .NET 2.0 Web Service, Login failed for User "Null". This tells me this is
> probably something specific to .NET 2.0 and not SQL Server or the Web
> Server,
> else it wouldn't work with .NET 1.1.
>
> -- Danny
>



 
Reply With Quote
 
PolarBears
Guest
Posts: n/a
 
      09-28-2006
Ok. Making progress. I had Windows Authentication and when I changed to SQL
Integrated, the web service worked. On the Web Page (my original problem) I
impersonated an account to get that working. Almost there!!! Just one little
glitch and I'm home free.

The situation now is. From a single web app, I have a login screen and
everything works fine, I get a message back "user logged in", that I had set
up. Great.

However. When I call the login page from another .NET application, the
login page does not return to the other application. The query string is up
in the address pane, ready to go, but it just clears the login boxes and sits
there. No error. I'm using the same Membership database and parameters on
both apps, both are .NET 2.0. It does everything but go back like it should.


The point being we want to create a single login application and have our
other applications all authenticate off of this application. We had it
working in 1.1, but I'm having a hangup here. Ideas?

Thanks!

Danny

"Joe Kaplan" wrote:

> Unfortunately, your analysis here is most likely wrong. There is nothing
> really different between how .NET 1.1 and 2.0 attempt to establish an
> authenticated connection with SQL server. If you use a connection string
> that uses Windows authentication in both cases, then the authenticated
> connection will attempt to be established based on the security token that
> is being used to execute the current thread at the time the code is called.
> That will either be the security token of the process, or the security token
> of some impersonated identity.
>
> Whether or not the remote service accepts the authentication from client
> (the web server in this case) depends on whether there is a trust
> relationship between the account being authenticated and the remote service
> and whether or not the identity being authenticated is being delegated by
> the intermediate service (and whether delegation is allowed and configured).
>
> You can discover whether you are getting an apples to apples comparison here
> by determining first whether the current security context in both web
> applications is the same account. Check
> System.Security.Principal.WindowsIdentity.GetCurre nt().Name. If they are
> both the same and one can authenticate to the remote SQL server but the
> other can't, it is almost certainly because one web application can do
> Kerberos delegation and the other one can't. If they aren't the same
> account (one is the authenticated user and one is the web server process
> account), then you aren't comparing the same thing.
>
> Joe K.
>
> --
> Joe Kaplan-MS MVP Directory Services Programming
> Co-author of "The .NET Developer's Guide to Directory Services Programming"
> http://www.directoryprogramming.net
> --
> "PolarBears" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > I've been away from this issue for a while, with other things. Here's an
> > interesting twist that may shed some light. Again, let me set it up. SQL
> > Server 2000 is on one machine with the database in question. Web Server
> > is
> > on a second machine.
> >
> > Approaching from a different direction, I tried this. Using Visual Studio
> > Tools for Office 2005, I created two buttons and two datagrids. The first
> > datagrid accesses file "X" via a .NET 1.1 Web Service. The second
> > datagrid
> > accesses the same file "X" via a .NET 2.0 Web Service. The web services
> > are
> > on the same machine.
> >
> > Visual Studio Tools for Office 2005 is running on .NET 2.0. Now, here's
> > the
> > interesting part, when I click the button to load the data from the .NET
> > 1.1
> > Web Service, everything loads fine. Duplicated the same process with the
> > .NET 2.0 Web Service, Login failed for User "Null". This tells me this is
> > probably something specific to .NET 2.0 and not SQL Server or the Web
> > Server,
> > else it wouldn't work with .NET 1.1.
> >
> > -- Danny
> >

>
>
>

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Cannot open user default database. Login failed. Login failed for user 'HEMPC\ASPNET' Tony Johansson ASP .Net 3 01-02-2010 04:09 PM
Cannot open database requested in login 'HumanResources'. Login failed for user 'companyDomain\BOSIIS$'. Homer ASP .Net 3 09-25-2007 07:45 PM
Error:Login failed for user ''. The user is not associated with a trusted SQL Server connection. CFTK ASP .Net 5 01-09-2007 10:51 AM
Login failed for user ''. The user is not associated with a trusted SQL Server connection. Dennis ASP .Net 0 06-26-2006 03:55 PM
Login failed for user ''. The user is not associated with a truste =?Utf-8?B?U3lsdmFu?= ASP .Net 4 11-26-2005 04:35 AM



Advertisments