I've created a custom Web Part for SharePoint that interacts with SQL.
Everything worked fine on my DEV server.
After I moved the WebPart to the client's server I started having problems.
I get Error Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection when I'm trying to open the WebPart.
I've searched for solution for a few hours by now and everything I have found doesn't seem to work in my case.
This is how my connection string looks like:
<add name="MyDataEntities" connectionString="metadata=res://*/MyDataModel.csdl|res://*/MyDataModel.ssdl|res://*/MyDataModel.msl;
provider=System.Data.SqlClient;provider connection string="Data Source=ServerName;Initial Catalog=DBName;
Trusted_Connection=yes;Integrated Security=True;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient" />
The SharePoint Web App with the web part and SQL DB are on two different machines.
Here's what I've tried:
1). Made sure SQL uses Mixed mode authentication
2). Made sure the account I'm using has rights to access SQL
3). Tried replacing Integrated Security=True; in the connection string with the User ID = UserID; Password=Password; where UserID and Password were the account IIS is running under.
I ran profiler while clicking on the link and it looks like the app is not using the account’s credentials and is trying to log in anonymously.
Any help is appreciated, I'm desperate because this must be up and running by tomorrow.
Thanks in advance!
Try SPSecurity.RunWithElevatedPrivileges: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsecurity.runwithelevatedprivileges.aspx
This method will run code as the ASP.Net application pool identity. Wrap your database calls with it.
Related
I have made application ASP.NET C# and my connection string is as follows:
<add name="ASPNETDB" connectionString="Server=tcp:MYDATA.database.windows.net,1433;Database=MYDATA;User ID=MYDATA;Password=MYDATA;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;" providerName="System.Data.SqlClient" />
Now it doesn't work at all, I mean I can't connect to my SQL server on Azure at all. When I want to login nothing happens, when I want to register nothing happens too. I get exception when I press to update DB, ie Publish->Settings-> Check box "Update database" Configure database updates . It seems to me that it doesn't work at all. The exception is of following type:
Error 22 Web deployment task failed. (Could not deploy package.
Unable to connect to target server.
Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_EXECUTING_METHOD.) 0 0
What should I do? Please help?
I would recommend logging into the azure management portal and re downloading the publish profile for the application. If you are not working using a publish profile , then at least re download the connection string that is setup for the app and the DB. while in there check that the application (web site or VM) is up and running, and that the database it is connected to is also up and running.
I had to set firewall rule 0.0.0.0 to 255.255.255.255. Even though my firewall rule was set for my address, somehow it didn't register, because communication was relying to my website-DB and ip address of my website wasn't included there too. So I put rule as said before and now it works like a charm. :-)
I'm just in the process of trying to properly configure asp.net 4.5 on our IIS servers.
I have been able to navigate and launch an ASPX page that contains no data conenctions sucessfully so I know that the application pool authentication to the local directories is working as it should.
Now though I have a seperate SQL server that is connected to the domain and have a connection string stored in the code that connects the ASPX page to the server using a trusted connection. When running in visual studio debug mode, the connection works fine - but at that point I assume it is using my login credentials.
My question is, when a user calls the aspx page via the browser when hosted on the new IIS7 server, which account is used to call the SQL server when using a trusted connection? - Is it the end users or is it a local account from the IIS server?
When I call a page with data connections embedded I get the error: Login failed for user ADMIN\PCNAME$ ... which is an indication that this is the account that it is using. However this account doesn't exist on the domain that I'm aware of. - Or does it ?!
Thanks in advance,
It will use the account that ASP.NET is running under, as you've worked out. What you usually should do is create a Domain Account (with the right privileges) and run your ASP.NET AppPool under that account. Then a Trusted Connection will use that account for connecting to the database, and as long as you've given it access (which as a Domain Account you can do) it should all work.
Added:
After some back and forth on comments, lets go back to the start: set the new AppPool to run with the domain users account, and recycle the AppPoolo. What is it that says the password is wrong? If it's IIS trying to start the AppPool, then it is extremeny likely that the Password you gave the AppPool IS wrong, or else that the password is set to change on first logon.
If its not IIS, but opening a Database connection, are you sure that the database allows this Domain Account access to the database and the tables within it it will need? What roles have you assigned to this account? Also, what SQL statement is it trying to execute (if it's got far enough to try and execute a statement at all)?
I suggest you put any response in you original question - comments get to be a drag if there are too many of them.
I'm developing a windows application using c# .Net Framework 4.
I have 2 machines; Test and production, connecting to a remote server which has the SQL Server here's my connection string:
<add name="MealConnectionString"
connectionString="Server=MySQLServer;Database=MEALDB;User Id=Meal;Password=Meal1;Trusted_Connection=True;"
providerName="System.Data.SqlClient" />`
When I run the program from the test machine there's no problem, but when I publish the program and run it from the production machine it gives the error mentioned in the title.
When I remove the trusted connection it gives me a different error: Login failed for user "Meal"
do you have any idea what could be the problem ??
Latest Update :
I tried the sa Sqlaccount and removed the trusted connection and it worked , when i try the same for the user meal it doesn't work whereas the MEAL suer has the same privileges as the sa account
I did it I just created a new sql account and gave it a db_owner permission over the database and it worked.
I have a web project which works perfectly locally.
But when I change the connection string in my published web site on Azure to connect to my database on SQL Azure it will start giving this error.
System.Data.Entity.Infrastructure.UnintentionalCodeFirstException: Code generated using the T4 templates for Database First and Model First development may not work correctly if used in Code First mode. To continue using Database First or Model First ensure that the Entity Framework connection string is specified in the config file of executing application. To use these classes, that were generated from Database First or Model First, with Code First add any additional configuration using attributes or the DbModelBuilder API and then remove the code that throws this exception.
at MyClass.OnModelCreating(DbModelBuilder modelBuilder) in c:\a\src\MyProject\Model.Context.cs:line 25
at System.Data.Entity.Internal.LazyInternalContext.CreateModelBuilder()
at System.Data.Entity.Internal.LazyInternalContext.CreateModel(LazyInternalContext internalContext)
at System.Data.Entity.Internal.RetryLazy`2.GetValue(TInput input)
at System.Data.Entity.Internal.LazyInternalContext.InitializeContext()
at System.Data.Entity.Internal.InternalContext.GetEntitySetAndBaseTypeForType(Type entityType)
at System.Data.Entity.Internal.Linq.InternalSet`1.Initialize()
at System.Data.Entity.Internal.Linq.InternalSet`1.get_InternalContext()
at System.Data.Entity.Infrastructure.DbQuery`1.System.Linq.IQueryable.get_Provider()
at System.Linq.Queryable.Select[TSource,TResult](IQueryable`1 source, Expression`1 selector)
My Config has:
<connectionStrings>
<add name="MyDBEntities" connectionString="metadata=res://*/MyModel.csdl|res://*/MyModel.ssdl|res://*/MyModel.msl;provider=System.Data.SqlClient;provider connection string="Server=tcp:[Removed].database.windows.net,1433;Database=MyDB;User ID=[Removed];Password=[Removed];Trusted_Connection=False;Encrypt=True;Connection Timeout=30;"" providerName="System.Data.EntityClient" />
<add name="MyDB" connectionString="metadata=res://*/Model.csdl|res://*/Model.ssdl|res://*/Model.msl;provider=System.Data.SqlClient;provider connection string="Server=tcp:[Removed].database.windows.net,1433;Database=MyDB;User ID=[Removed];Password=[Removed];Trusted_Connection=False;Encrypt=True;Connection Timeout=30;"" providerName="System.Data.EntityClient" />
</connectionStrings>
I tested using my unit test locally with that connection string and it works from my local machine connecting to SQL Azure database.
Any help appreciated.
I was having this exact problem today; it's my first time deploying to Azure. I've been pulling my hair out, except I don't have any left. I finally figured it out, and it's probably the same issue original poster here is having.
Just like the original poster, I tested in these configurations:
ran WCF Web App from Visual Studio against local DB -- success
deployed WCF Web App from Visual Studio to local IIS, ran against local DB -- success
ran WCF Web App from Visual Studio against Azure SQL DB -- success
deployed WCF App to Azure via Visual Studio, running against Azure SQL DB -- FAILURE!!
After reading another post (Code First vs. Database First) I got a hint. That post says that if "connection string has the metadata, EF thinks it is Model First or Database First" but if it's a "plain connection string, EF thinks it is Code First." I browsed the deployed Azure Web Site's web.config and confirmed that the connection string had the proper references to the Model-First metadata. So what was the problem???
I figured that perhaps the Azure Website wasn't reading the web.config's connection string. Thinking back to how I'd created the Azure Web Site, I remembered that I'd given the Azure SQL DB an alias with the exact same name as my connection string's 'label' in the web.config!! To clarify:
in the Azure admin console I went to the Website settings and reviewed the "connection string" settings "baked in" to my Azure web site as a side-effect of creating-website-with-DB -- connection string 'handle' was "SsnCustInfoModelContainer" -- I'd mistakenly given the connection the same 'handle'/'alias' as my web.config 'handle' for the connection string, thinking this would help. Instead, when EF looks for the connection string, it was finding this 'aliased' handle, which was a "plain" SQL connection string containing no metadata. This 'alias' masked the real connection string specified in the web.config.
So I destroyed my Azure SQL DB and my Azure Web Site. Then I recreated the Azure Web Site, but this time I asked for the connection string 'alias' of "SsnCustInfoModelContainer_Proto" for the connection to the associated Azure SQL Server. After initializing the Azure SQL DB from my local SQL Server Management Studio, I deployed the WCF web app again to the Azure Web Site (I had to download a new deployment profile, of course, to do this), I tried the app again. This time it worked -- the 'alias' "SsnCustInfoModelContainer_Proto" did not conflict with and was not found by EF. EF instead went on to find the true connection string, with all the proper metadata, in the web.config. Problem solved.
First off, I can connect to both databases with SQL Server Enterprise Manager, so I know the servers are up and available. One of them is SQL1, the other is SQLTEST.
In my program when I use the following connection string, it work connects just fine:
conn = New DBConnect("Data Source=SQL1;Initial Catalog=SignInspection;Integrated Security=SSPI")
However, if I change SQL1 to SQLTEST the connection times out I don't get any errors other than the timeout error.
I can run the profiler on SQLTest and see that it is most definitely NOT even attempting to connect. Nothing happens at all, not a peep, nor hellow.
Any ideas? Thanks
EDIT:
Well, it's a moot point now because I got authentication working properly on our SQL1 server.
I'll post the configuration here so perhaps someone else can benefit.
First off, the web server is running IIS and .NET. Users are logged in to the intranet using Active Directory, and the .NET page needs to retrieve their log-in credentials (username most notably). The database is SQL Server 2005, running on a different machine. But the .NET app needs to impersonate as another user to connect to the database.
To successfully do both of these things go to Windows > Run, enter inetmgr and hit run. Navigate to the site and right click > properties, then click on the tab titled Directory Security, click Edit.., make sure only Integrated Windows Authentication and Digest authentication are enabled. Enter your proper AD realm and click OK. Apply the settings/hit OK.
In web.config you need the following lines
<authentication mode="Windows" />
<identity impersonate="true" username="myDomain\MyUserName" password="123mypasswordgoeshere">
replacing, of course, myDomain\MyUserName and 123mypasswordgoeshere with the username and password that has login rights on both your domain and your sql server. The connection string can probably be modified, but this is mine and it works:
Server=SQL1;Database=SignInspection;Trusted_connection=True;
These are the steps that worked for me and hopefully they'll be of use to someone else.
When you connected with the enterprise manager, was that from the same machine as you're running the VB.Net code on?
Otherwise, it can be quite a few things, ranging from firewall or DNS as mdma mentions to being setup with the wrong network protocol or maybe not accepting remote connections.
This article contains a list of things to look at (it's for SQL 2000 but it's something to get you started at least).
The obvious question - does SQLTEST have a database called "SignInspection"? Also do you log on to SQLTEST via SQL Management Studio using Windows Authentication or SQL Authentication? I would expect if either of these were the problem you would get an exception, but its worth checking.