I have an azure web application running that need to connect to an Azure SQL Database.
My testing approach is to authenticate the web app by using Managed identity.
So in my web app I activated the managed identity, after that I logged into my database and run the following script:
CREATE USER [<identity-name>] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [<identity-name>];
ALTER ROLE db_datawriter ADD MEMBER [<identity-name>];
Saved and updated the connection string of my database into my web app and restarted.
Everything worked perfectly for a couple of hours, after that I start getting this error:
Microsoft.Data.SqlClient.SqlException (0x80131904): Login failed for user '<token-identified principal>'.
at Microsoft.Data.ProviderBase.DbConnectionPool.CheckPoolBlockingPeriod(Exception e)
at Microsoft.Data.ProviderBase.DbConnectionPool.CreateObject(DbConnection owningObject, DbConnectionOptions userOptions, DbConnectionInternal oldConnection)
This is kind f confusing me because after the restart of the wb app, I can see that the web app is able to connect to the database and retrieve data..but suddenly after a couple of hours it starts throwing that error.
Did this occurred to anybody before and can direct me on the right path to solve this issue?
Goes without saying that I updated my Entityframework and Data.SqlClient to the correct version to facilitate this approach as documented.
Thank you so much for any help you can provide
Related
I am runnig into the same problem that a few people run into but after reading a lot of threads I can not see where I am going wrong in order to fix the problem.
I have included my db user the the pool and the connection string in the web config. Any help would be appreciated.
<value>Data Source=(localdb)\MSSQLLocalDB;Initial
Catalog=TurnAroundDB; Persist Security Info=False; Integrated
Security=false; Initial Catalog=TurnAroundDB</value>
AppPool
DB User
In DB (DB User window), go to User Mapping and check TurnAroundDB on the top side of the window. While there, you can assign the permissions you want for this user from the lower side of that window.
I have a MVC Web Application deployed to a 2003 Server running IIS 6. There is an inconsistent behavior that started this week when we created a new Domain service account with God rights to be used as the identity for the Application Pool and the Anonymous User for the Website with Integrated Authentication set. This Service account has also been added to the SQL users with full rights to the data.
The inconsistent behavior is that the Web Application will run fine, hitting the data, etc..., then out of the blue the Application Pool gets automatically disabled. I check the event logs on the server and sure enough I see two warnings and an error saying that the Identity is INVALID and that the pool was disabled.
I turn it back on and then try to browse to the Website again and BOOM! It does it again. We finally after three attempts lock the account out and have to unlock it. Then it spirals back to the same issue.
Any ideas? Because I'm at my wits end!
This problem might be solved because the question is old, but anyway.
Try manual login with username and password, then
reapply the identity on the application pool, answer yes to apply user rights if questioned, restart the application pool and check the eventlog for errors.
Make sure the useraccount has the appropriate user rights , there will be complaints in the eventlog otherwise. Also make sure allow login to on the user account has the server entered or allow any.
Thanks
Andreas
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.
why this error comes?
I am using windows authentication. But i am getting error
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'
can any one help me in this how to solve this problem?
Most likely it means you're trying to connect from an impersonated context and you did not set up constrained delegation. See Manage Kerberos Authentication Issues in a Reporting Services Environment for details and troubleshooting.
First of all, I always prefer to use the 'impersonation' settings in the ISS configuration that do not set the user/password in the web.config. Everything was fine in the QA environment, but then I passed to the production environment and some options of the web site in production started to show the 'Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON' error.
The issue was that I copied the web-site configuration from the QA server, using the 'Save configuration to a file' option in IIS6 while creating a brand new Application Pool in the production server.
After several hours trying to solve this error, I just deleted the Application Pool, and used the 'Save configuration to a file' option to copy the Application Pool configuration and then restored it to the new server.
If you copy the web-site configuration, also copy the Application Pool configuration. That solved my problem, without changing anything about the authentication method, the database or the web-site itself.
Reporting Setup:
I had a report accessing datasource A, with a subreport which accessed datasource B.
The report connections were set to use Integrated Security.
From my development machine:
The "main" report would run perfectly fine from my development environment (as it was running everything as me.)
From the server:
I was able to execute the subreport directly, with no problem.
The main report would run, with the text "Error: Subreport could not be shown."
Actual Problem:
The subreport was executing under the NTAUTH\ANON user, because it was the Reporting Services code which was calling the sub-report. This error was in the SSRS Logs:
System.Data.SqlClient.SqlException: Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
Solution:
Set up the sub-report data connection to execute using a SQL User login.
Only grant that user execute on the particular procedure you're calling for the report.
This allowed me to get the report working without involving other departments that controlled the application servers (modifying web.configs or IIS configurations)
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.