Hi, We are building a web part to display user specific data from SQL Server. The Sharepoint application and SQL database are on two different servers. But when we use Integrated security to to connect to the database from the web part it gives the following error Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' Since the data being displayed in the web part is user specific, we cannot use sql authentication. The user that we are using to connect exists in the database. We have also tried impersonating the current windows identity to itself using WindowIdentity.GetCurrent().Impersonate(), but that does not work either. We cannot use an admin account for impersonation becuase user specific display is needed. Any help or pointers regarding this issue will be greatly appreciated. Thanks -- Vedanshu Mandvikar

I have the same problem. Tried this doc: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx#ENE but it can not help me.

I have a similar problem after installing WSS SP1 on my MOSS machine. The update seemed to run fine until step 8 of 9 and just hang all weekend. The logs keep showing a Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. Non of the SharePoint sites on that machineallow anonymous access so I'm surprised to see any reference to it. I've used SQL Authentication between SharePoint and SQL Server and the farm administrator is dbowner on all databases using its Integrated Security login. Any ideas?

Hi Vedanshu, Are you running NTLM or Kerberos authentication. You can have a look in Central Administration. "Login failed for user ..." is a common sympton when Kerberos is not configured correctly or at all as the credentials are getting lost when the packet hops from the one server to the next.

Hi, did you ever find a solution to this issue? I have exactly same issue with MOSS and custom webpart connecting to SQL with Integrated Security. We have kerberos setup correctly but it is still now working. Any help would be appreciated. Thanks Dee

This is an over nine month old thread you are posting to. It would be better to start a new thread describing exactly your problem and with a new title that reflects exactly your problem. (Moderator) WSS FAQ sites: WSS 2.0: http://wssv2faq.mindsharp.com WSS 3.0 and MOSS 2007: http://wssv3faq.mindsharp.com Total list of WSS 3.0 and MOSS 2007 Books (including foreign language titles) http://wssv3faq.mindsharp.com/Lists/v3%20WSS%20FAQ/V%20Books.aspx

Hi I know its a litlle late reply, but I also stumbled into the same problem and resolved this. Thought to share with you all. I can understand why you may not want to introduce SQL authentication as client may not be in favour of that. To make Windows Authentication to work, you may folow following steps: 1) In web.config specify authentication to windows 2) In web.config Impersonate identity to true 3) Create a new domain virtual user for the application, say abc@mydomain.com, with some password 4) In the impersonation section, specify this userid and password 5) In IIS, remove anonymous access and check integrated windows authentication 6) Provide access to this new user access to IIS metabase using aspnet_regiis -ga "mydomain\username" 7) Provide access to this user access to physical directory of your virtual directory. You will need to add this user there. 8) Note that if your application is writing to some log file, you will also need to provide 'write' rights as well 9) Note that if your application is accessing some database with execution of some stored procs, you will need to add this user to sql server logins with dbowner right to the application database. Also, you may not want to fall into the security trap by providing access to NT Authority/Anonymous Logon, so in this case creating your own application user will help. I hope it helps and if it does request you to make this as 'Answer' Project Lead

Hello Vishal Dogra, Thankz....it is workinf for me ya...last one day i was searching...now i got.......really happpppy aaa.........

Hi Vedanshu, Are you running NTLM or Kerberos authentication. You can have a look in Central Administration. "Login failed for user ..." is a common sympton when Kerberos is not configured correctly or at all as the credentials are getting lost when the packet hops from the one server to the next. I'm sorry to drudge up an old post but I was curious to know if this person's response was the reason they were having issues. We run kerberos and I'm expereincing the same issues. I was wondering what configurations they changed in the CA to make this work so I could forward it to my Site admin so he can make similar changes? Assuming it was what was wrong which i'm guessing it is since the original posted did not post anything after this suggestion. If anyone has any kerberos configuration suggestions that would be great too.