Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'

[Justin]

I know this has been out there a thousand times. I've looked and looked and
can't find anything that will solve my problem. I'm not even sure it is
solveable.

I have a client that I VPN into. My computer is not on their domain.

I have a local webservice and I was to use to access a SQL server on their
domain. I have set impersonation to true and put the username and password
of the domain user in the web.config.

<identity impersonate="true" userName="domain\user" password="password" />

I also created a local user on my computer with the same username and
password. (This is how I was able to get the webservice asmx page to
successfully load and display the available webservices).

However, when I try to actually call the webservice and access the sql
server I get the classic "Login failed for user 'NT AUTHORITY\ANONYMOUS
LOGON'" error.

I've tried everything I can think of, even creating a
WindowsImpersonationContext object. No luck.

The sql server *has* to use integrated security so a connection string is
"right out".

Any ideas?

Thanks,

Justin

 

[Keko]

please try;
SqlConnection YourConn = new SqlConnection( "Data Source=xxx.xxx.xxx.xxx;
Initial Catalog=yuorDB;User ID=WebSqlUser;Password=WebSqlUserPass" );

YourConn = your connection string.
Data Source=xxx.xxx.xxx.xxx = sql server ip.
Catalog=yuorDB = sql server database.
ID=WebSqlUser = web acces sql user ( be carrefull )
Password=WebSqlUserPass = web acces sql user pass ( be carrefull )

 

[Joe Kaplan \(MVP - ADSI\)]

Why would you recommend this? Did he not say he needed to use integrated
security in his post?

Joe K.

 

[Joe Kaplan \(MVP - ADSI\)]

Is the SQL server box in the same domain as the web server (or do they have
a trust)? When you impersonate via web.config this way, it should work.
There should be no reason to have machine accounts with matching IDs if the
domain stuff is configured correctly.

As you have discovered, these types of issues can be really painful to debug
as there is no well known, straightforward technique for diagnosing what
went wrong with your impersonation.

Joe K.

 

[Justin]

Hi Joe,

Thank you for responding. Unfortunately I'm running the webserver on my
computer, which is not on the same domain as the SQL Server. This is because
I just VPN into my client to do my work. I know that there is "the rub".

 

[Joe Kaplan \(MVP - ADSI\)]

Yeah, I'm not sure if you can get this to work in that case. You would
essentially be looking for the "hack" way of doing this with matching local
machine accounts. I'm not really too familiar with how or why that even
works, so I'm probably not the right guy to ask.

Is there any way that you can actually just get this working correctly,
possibly by using a machine that is a domain member? It seems like a bad
idea to pin your integration scenario on what is basically a hack.

Joe K.

 

[Justin]

Yeah, I was afraid that that was the answer. At least I can rest assured in
my knowledge that the answer wasn't completely obvious.

I was trying to get this working so I could develop on my local machine, no
intention of putting it into production in this way. Actually, the project
is already in production where the IIS server and SQL are on the same domain
and no impersonation problems there.

Well, thanks for the time.

Justin

 

[Joe Kaplan \(MVP - ADSI\)]

Don't get me wrong, I'm not saying this can't be made to work. I'm just
saying that I don't know what the magic is and it is definitely kind of a
hack.

Best of luck!

Joe K.