Login failed for user '(null)'.

Discussion in 'ASP .Net Security' started by Herb, Jul 26, 2006.

  1. Herb

    Herb Guest

    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
     
    Herb, Jul 26, 2006
    #1
    1. Advertising

  2. Herb

    PolarBears Guest

    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
     
    PolarBears, Jul 26, 2006
    #2
    1. Advertising

  3. 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.GetCurrent().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-us/dnpag2/html/paght000009.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/subscriptions/managednewsgroups/default.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/subscriptions/support/default.aspx.

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



    This posting is provided "AS IS" with no warranties, and confers no rights.
     
    Steven Cheng[MSFT], Jul 27, 2006
    #3
  4. Herb

    Herb Guest

    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.GetCurrent().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-us/dnpag2/html/paght000009.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/subscriptions/managednewsgroups/default.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/subscriptions/support/default.aspx.
    >
    > ==================================================
    >
    >
    >
    > This posting is provided "AS IS" with no warranties, and confers no rights.
    >
    >
     
    Herb, Jul 27, 2006
    #4
  5. 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.
     
    Steven Cheng[MSFT], Jul 28, 2006
    #5
  6. Herb

    PolarBears Guest

    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.
    >
    >
    >
    >
     
    PolarBears, Jul 28, 2006
    #6
  7. 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.
     
    Steven Cheng[MSFT], Jul 31, 2006
    #7
  8. Herb

    PolarBears Guest

    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.
    >
    >
     
    PolarBears, Sep 22, 2006
    #8
  9. Herb

    Joe Kaplan Guest

    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.GetCurrent().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" <> wrote in message
    news:...
    > 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
    >
     
    Joe Kaplan, Sep 23, 2006
    #9
  10. Herb

    PolarBears Guest

    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.GetCurrent().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" <> wrote in message
    > news:...
    > > 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
    > >

    >
    >
    >
     
    PolarBears, Sep 28, 2006
    #10
  11. Herb

    PolarBears Guest

    Authentication Sharing Across Apps

    Ok. For my part "B" question that I had (Login App was not returning
    authentication to calling app), I found the solution. I did not realize
    there were additional requirements for having applications communicate in
    ..NET 2.0. Basically, in both the Login App and Calling App Web.Config, I did
    the following:

    <authentication mode="Forms">

    <forms name=".ASPXAUTH" loginUrl="./Login.aspx"
    protection="All" enableCrossAppRedirects="true" path="/"/>

    </authentication>

    Notice the addition of enableCrossAppRedirects="true". That was different
    from .NET 1.1. Name, Path, and Protection must be identical on both the
    Login and Calling Apps.

    Also, the validationKey and DecryptionKey must be identical on both apps.
    By default, they are autogenerated and different among apps, so you have to
    manually generate them, for example put something like this in the Web Config:

    <machineKey
    validationKey="32F090935F6E49C2C797F69BBAAD9702ABD2FD0B667A8B44EA7DD4374267A75D7AD977461DB1DC347C1A63AE5F1CCFAACFF1B72A7F0A281B"


    decryptionKey="CBAA84D7EC4BB56D75D217CECFFB9629908CEB8BF91CFCD64568A145BE59719F"

    validation="SHA1"

    decryption="AES"

    />


    I hope this helps somebody out there. I know sometimes finding the answer
    you are looking for can be real challenging if you don't ask the question a
    certain way.

    Thanks,

    Danny




    "PolarBears" wrote:

    > 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.GetCurrent().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" <> wrote in message
    > > news:...
    > > > 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
    > > >

    > >
    > >
    > >
     
    PolarBears, Sep 29, 2006
    #11
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Blake Versiga
    Replies:
    2
    Views:
    19,785
    Yan-Hong Huang[MSFT]
    Jul 9, 2003
  2. rl30
    Replies:
    1
    Views:
    629
    emachine
    Aug 15, 2003
  3. Calvin I

    Login Failed for user (null)

    Calvin I, Aug 18, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    390
    Steven Campbell
    Aug 20, 2003
  4. Frederik
    Replies:
    0
    Views:
    1,416
    Frederik
    Nov 25, 2003
  5. Tony Johansson
    Replies:
    3
    Views:
    16,241
    Patrice
    Jan 2, 2010
Loading...

Share This Page