I am working on an ASP.NET application that uses the AspNetSqlMembershipProvider for the authentication mechanism.
I am transferring the application to a cloud application in order to deploy it on windows azure.
Do I have to change the authentication mechanism that I use or will the AspNetSqlMembershipProvider will work normally?
Don't change the authentication mechanism, just use the Universal Providers and it will work normally.
You have no need to change the Authentication Mechanism for the reason of deployment. Just make the local machine database scripts to run on the sql azure database. Everything should be work same as you are doing authentication on local development machine.
Check these links to know regarding this deployment of sql authentication or database script etc:
Trying to deploy Asp.Net Memebership database to SQL Azure
Updated ASP.net scripts for use with Microsoft SQL Azure
After installing the scripts, just change the connection string in the webconfig that provide the authentication through database.
<connectionStrings>
<add name="LocalSqlServer"
connectionString="you azure connection string"
providerName="Provider..." />
</connectionStrings>
Related
I'm having problems connecting to an MSSQL database in an ASP.NET Web Forms application. The error I get the is the user corp\earth3 can't connect. earth3 is the name of the computer ... the logged in user is corp\earth (a domain administrator) which is what works when connecting to the database using MSSQL Management Studio. I'm building the web app on Windows 10 and its being deployed for production use on a Windows 2012 server (which has the same connection problem as the win10 machine).
I've tried each of the following in web.config. This works while connecting to other database instances on the db server, but not on this one.
<add key="sqlConnectString" value="Data Source=db01\pd; Initial Catalog=PDB; Trusted_Connection=Yes;"/>
<add key="sqlConnectString" value="Data Source=db01\pd; Initial Catalog=PDB; Integrated Security=SSPI;"/>
What am I doing wrong here? Why can't I connect to the db using corp\earth?
Thanks.
Modify the Identity in the application pool with a user that can connect to the database. Create a custom app pool if you don't want to make a change that would affect other web sites it uses.
I have read that it is recommended to remove the username/password for database connection strings from the web.config file for an ASP.Net web application, and instead use an IIS application pool identity for authenticating access to the database.
While this is easy to do and a straightforward process for connecting to a Microsoft SQL Server database using an active directory service account, that's not the same, from the research that I have done on this question, for connecting to an Oracle database.
We can't figure out how to connect to an Oracle database using IIS 7.5 Integrated Managed Pipeline Mode. We want to use integrated security because we don't want to include the Oracle database username and password in the connection string in the web.config file for the ASP.Net web site.
We also want to avoid creating the possibility for a malicious user to "spoof" a Windows account, giving them sys.admin access to Oracle if an Oracle database account is found that matches the Windows account.
What is the industry standard for connection to an Oracle database using integrated pipeline mode with an ASP.Net application through IIS 7.5?
How is this accomplished, in order to remove the Oracle database username and password from the web.config file?
Instead of figuring out connecting to an Oracle Database through IIS with integrated security (which I'm not sure of how to do or if it's possible), try an alternative.
Instead of setting it in web.config, programmatically obtain the username/password from an encrypted file or secure web service
Or encrypt the .config file itself. MSDN has some directions for that.
I have a site that's running off windows azure and I have hooked up the database via a linked resource and it looks like the site should be using the database. I've also included the proper connection string in my web.config file.
When I run the website locally and use the azure database's connection string for my default connection, everything works and I've seen that updating data from my local machine is reflected in the remote database.
Whenever I try to access any page that makes database hits (ie, logging in or looking at the basic index (from scaffolded out views)), I get a 500 error. I tried turning on custom errors but the 500 error is all I get. I tried to debug it from my local machine but that didn't help at all since everything worked properly when running the site locally and connecting with the azure database.
I have also pulled down the web.config files and the web.configs on both sides are identical.
I figure that this has to do with a configuration issue, but I'm not sure what.
Is there maybe something I'd have to do with asp.net mvc 5 to make it work with windows azure? It looks like the .net framework is properly set on azure to .net 4.5. I'm guessing it has something to do with the fact that Azure just doesn't know it should be using the database supplied in the web.config.
Here are the web.config connection strings:
<add name="DefaultConnection" connectionString="Data Source=####.database.windows.net,1433;Initial Catalog=####_db;Persist Security Info=True;User ID=####;Password=####" providerName="System.Data.SqlClient" />
<add name="DefaultConnectionDeploy" connectionString="Data Source=####.database.windows.net;Initial Catalog=####_db;Persist Security Info=True;User ID=####;Password=####" providerName="System.Data.SqlClient" />
<add name="DefaultConnection_DatabasePublish" connectionString="Data Source=####.database.windows.net,1433;Initial Catalog=####_db;Persist Security Info=True;User ID=####;Password=####" providerName="System.Data.SqlClient" />
Windows Azure makes use of transforms to manage connection strings. The connection strings are merged in at runtime, and can be controlled from the configure tab on the Web Site management page. whenever you set up an Azure Database as a linked resource, it automatically configures the Azure Database server with firewall rules to allow connection from the web server, and adds a connection string. By using this connection string, naming it the same as the string used in development, it is not necessary to modify any code prior to deployment. If you don't set the Azure Database up as a linked resource, it is necessary to modify the firewall rules by hand, which doesn't play nicely with the scalability of Azure Websites, so it's not recommended.
As per Andrew-counts' suggestion, I went and checked out my EF migrations (after pulling down the Azure web.config file using the "Replace web.config from server" option so that I had the exact copy that the server is using. I then enabled custom errors. It turns out that the pages were failing to load because of an error that stated that the table dbo.AspNetRoles already exists.
It appeared as though it was trying to run the EF migrations despite the fact that the tables already existed. To remedy this, I decided to go and wipe out my current database (I had just setup the database today so no harm doing that) and then, from the package console in visual studio, ran the Update-Database script before deploying anything to the server. When I did that, it correctly added the records inside of the dbo.__MigrationHistory table. I then checked in my changes so that the visualstudio.com build I have connected to my solution would build and deploy to Azure. The problem persisted, but what I realized was that I need to disable the automatic build + deploy that I was using and instead use the right click + publish, since doing it from the visual studio build wasn't connecting to the azure database properly (it wasn't transforming the web.config). When I used the publish from within visual studio, the site worked like a charm.
Thank you for all your help
I have created a website using asp.net every thing is running fine when i run this using visual studio development server but when i tried to run it by IIS server then Home page of website loads but it couldn't make connection with database server
<add connectionString="Data Source=ASHUTOSH-PC\SQLEXPRESS;Initial Catalog=CloudStorage;Integrated Security=True" name="connectionStr"/>
</connectionStrings>
this works fine on visual studio develoment server but not with IIS.... Please help
Since you are using Integrated Security=True you use the application pool identity to connect to the DB. When you run Cassini, you use your own credentials. You should set up the application pool identity with a user that has permissions to login and query SQL Server.
From MSDN:
When you run a page using the ASP.NET Development Server, the page runs in the context of your current user account. For example, if you are running as an administrator-level user, a page running in the ASP.NET Development Server will have administrator-level privileges. In contrast, in IIS, ASP.NET by default runs in the context of the special user (ASPNET or NETWORK SERVICES) that typically has limited privileges. The ASPNET or NETWORK SERVICES accounts are local to the server computer (not domain accounts), which restricts access to resources on other computers.
Database access
When working with the ASP.NET Development Server, you can typically rely on Windows Integrated authentication to access SQL Server. However, when the same page runs in IIS under the ASPNET or NETWORK SERVICES account, the page is running in the context of a local user, and you often have to configure the page to use a connection string that includes information about a user and password. For details, see Accessing SQL Server from a Web Application and ASP.NET Security Architecture.
I have an ASP.NET 4.0 application within which I need to forward the authentication to the database.
For the purposes of this request for assistance, lets call the web server "app1" and the database server "sql1".
The SQL2008R2 database service is running as a named instance "SQL2008R2" under a custom domain account "SqlServer". The server is running Windows Server 2008 R2 Enterprise Edition.
I have created an SPN for this...
setspn -a MSSQLSvc/sql1.mydomain.local:SQL2008R2 SqlServer
The ASP.NET application is running under an application pool using a custom domain account "WebApplicationUser", in Integrated Pipeline mode. It is currently running on my laptop running Windows 7 Enterprise, but will eventually be hosted on Windows Server 2008 R2 Standard Edition.
I have created 2 SPN's for the application (on the Windows 7 machine that I am currently running from)...
setspn -a http/app1 WebApplicationUser
setspn -a http/app1.mydomain.local WebApplicationUser
Within Active Directory users and Computers, I have selected the "WebApplicationUser" account and I have enabled constrained delegation to "MSSQLSvc/sql1.mydomain.local:SQL2008R2" using any protocol (I have also tried using Kerbero only).
The Application is setup in IIS 7.5 and the authentication is set to disable Anonymouse, Basic, Digest and Forms whilst enabling "ASP.NET Impersonation" and "Windows". The Windows authentication has "Extended protection" turned off and "Kernel-mode authentication" enabled. The providers are "Negotiate" and "NTLM" in that order.
The ASP.NET application uses EF, and the connection string is configured to use integrated security...
<connectionStrings>
<add name="MyContext"
connectionString="metadata=res://*/Data.MyModel.csdl|res://*/Data.MyModel.ssdl|res://*/Data.MyModel.msl;provider=System.Data.SqlClient;provider connection string="Data Source=sql1.mydomain.local\sql2008r2;Initial Catalog=MyDatabase;Persist Security Info=false;Integrated Security=True;MultipleActiveResultSets=True""
providerName="System.Data.EntityClient" />
</connectionStrings>
My web config specifies both Windows authentication and impersonation, since I a using async pages, I have also enabled inpersonation policy flowing...
<runtime>
<alwaysFlowImpersonationPolicy enabled="true" />
</runtime>
<system.web>
<authentication mode="Windows" />
<identity impersonate="true" />
</system.web>
If I log on locally (on "web1") and browse to the application (using IE), this all works - but this does not involve the double hop that I am trying to resolve.
If I log on to another machine and then browse to the application using IE, or I browse from the local machine using FireFox, this does not work - note: FireFox does prompt me for the login details. The connection to the database fails with "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'"
Unlike a lot of the articles (and here might be part of the problem), I am not using any custom code to impersonate the user. It is my understanding that the impersonation will be applied across the board to the application by the web.config settings above. All I do is to open the connection and then close it again when I am finished with it.
I have obviously missed a step (or two), but having looked at all of the documentation that I can find (and there has been a lot), I still cannot find what that step is. It does not help that 99% of the documentation that I can find is actually related to IIS6 and Windows 2003 but the principles should remain the same.
Has anybody suceeded in getting such a configuration to work on Windows 7 and/or Windows Server 2008?
Checklist for Double Hop issues {IIS and SQL Server}
http://blogs.technet.com/b/taraj/archive/2009/01/29/checklist-for-double-hop-issues-iis-and-sql-server.aspx
http://www.phishthis.com/2009/10/24/how-to-configure-ad-sql-and-iis-for-two-hop-kerberos-authentication-2/
http://support.microsoft.com/kb/810572
IIS to SQL Server kerberos auth issues
When you configure the SPNs for SQL Server, we have found that we need to include the PORT on which SQL Server listens (1433).
You should download and use Brian Booth's DelegConfig v2 tool to help you setup the correct configuration settings. http://blogs.iis.net/brian-murphy-booth/archive/2009/04/22/delegconfig-v2-beta.aspx
It will basically hold your hand the whole way through the process. We've found the tool to be invaluable.