I have an application developed in ASP.NET MVC using Entity Framework / Sql Server 2008
Actually, connections to the database are made with the "sa" account.
Is it possible to use, instead of "sa" the windows final user credentials ?
This would be helpful to control more efficiently the security limitations of each user.
I use, in my application windows authentication.
Thank's !
It is possible but whole your system must run inside windows domain, users must have domain accounts and your system infrastructure must be enabled for Kerberos delegation (belongs to ServerFault). The reason is that you have two hoops in the system - first user authenticates from his client machine to your web server and then web server delegates user credentials to database server. If client computer, web server and database server are different machine Kerberos delegation must be enabled (if db and web runs on the same server you should be fine without Kerberos). Your web application will have to use impersonation and your connection string will have to use windows integrated security.
Also using end user credentials will reduce performance of your system because EF will have to maintain separate connection pool per user. Administrator of SQL server will have to give access for every single user (or user group) using your application.
Related
I have two servers, let's say they are APPSVR (ASP.NET) and DBSVR (SQL Server). Currently, the application running smoothly with database connection using SQL Server authentication with User Id and Password.
In the future, it must be changed with Windows Authentication Integrated Security=True. I have tried to change this but can't worked (DB connection failure).
We have domain controller also and both server in the same domain. I am not sure which one that must be configured in our environment (Domain/SQL Server/IIS Manager). What's the right procedure to do this?
Is your asp.net application already running with domain user authentication?
Do you need per user login for SQL server because you set up the
access right on domain user rather than create your own access right
system on your asp.net application?
Why i am asking you this? Because You need to consider the differences between web application and desktop application. In web application, the web server contact the sql server not the user pc.
So this complicate the setup if you want the web server to use the windows authentication to login to sql server then you need to set up the web server to somehow masquerade as the domain users. You also need to consider the scenario if user are accessing the web application from the internet.
I suggest using strong application only password for sql server connection using local user rather than domain Users. For access right you can simply create a new table to store domain user login id and their access right. This set up still allow login to web application using the domain Users but the database connection is not. The Advantage is you can minimize the access to simply few or even one user application only user you need to maintain in sql server rather than every domain Users that need to be registered on sql server if you use windows authentication.
If you still need the Windows Authentication set up than you can see the info here.
We recently had to change over to using Windows Auth instead of a SQL Account to access the DB from our ASP site. The trick is to have the application pool start up with the same domain account you use to access the SQL Server and then you can just change your connection string to use Integrated Security.
The process is shown here:
https://thycotic.force.com/support/s/article/Using-Windows-Authentication-to-access-SQL-Server-Secret-Server
We have an internal asp.net web application which has ASP.NET authentication and Windows Authentication enabled so that users can be logged in as soon as they connect to the website using their domain credentials (this is a requirement that we cannot change).
We are currently looking to upgrade our SQL database and understand that SQL Authentication is less secure than integrated security (e.g. https://msdn.microsoft.com/en-us/library/bb669066(v=vs.110).aspx). Currently we use SQL Authentication.
We could easily change the connection string to run using integrated security, however IIS presents the user as the domain user connected to the website (e.g. domain\greg) instead of the service (domain\WebsiteServiceUser), because IIS impersonates the user. This impersonation is needed to access their Exchange Mailbox, files and other things.
If we were to go down this path, we would have to add logons for every user (using AD groups) to SQL Server. This is possible, but in itself presents a new security issue - users would be able to create a SQL connection outside of our web application and run whatever queries they like against the database. All of our authorization could be bypassed.
Is there a way to connect to SQL using Integrated Authentication using the user that the AppPool runs as (Domain\WebsiteServiceUser) instead of connecting as the currently logged on user (Domain\Greg)?
I've written a simple ASP.NET application that works as a frontend for a simple MSSQL database. The application is accessible over the Internet.
There are two physical servers involved: a WS2008R2 Active Directory domain controller which is also running MSQL Server 2008 R2, and another server, the webserver (WS2008R2/IIS7.5) where my application resides.
The Application Pool for my application "FooPool" has its own AD User identity it runs under "FooUser". FooUser does not have any permission to access the SQL Server database, instead only my own personal user account "MyUser" has that permission.
The idea is that attempts to access this web application first perform Windows Authentication with IIS, my web application then uses Impersonation to access the SQL Server database.
However my application does not work.
I tested the application without it touching SQL Server, just to test impersonation, so I did Response.Write( WindowsIdentity.GetCurrent(false).Name ); which correctly shows the application impersonating MyUser and not acting as FooUser. This works from all modern browsers and across the Internet.
But as soon as it touches MSSQL Server I get the error "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'." but that should not be happening because no user tokens are for Anonymous Logon.
I've done my homework and read all about Delegation and Impersonation in ASP.NET and I have set up delegation: The FooUser account has a Service Principal Name set-up (I set the SPN to an arbitrary string, is that doing it right?) and is marked for delegation in ADUC.
Finally, my connection string has SSPI enabled, Connection pooling disabled, and the network library set to "dbmssocn".
What else am I forgetting?
Finishing the Configuration for Delegation to Work you must enable constrained delegation:
Open Active Directory Users and Computers
Find the user account that the IIS Web site is using for the web application pool and double-click it
Select the option: Trust this user for delegation to specified
services only.
Make sure that the user is constrained to the
SPN associated with the MSSQLSvc service
Restart IIS
http://blogs.technet.com/b/askds/archive/2008/11/25/fun-with-the-kerberos-delegation-web-site.aspx
I was wondering when using Windows Authentication mode in a connection string from a web application. Application itself is using Windows Authentication for authorization. Which account will be used to login to SQL Server.
Is't the web application pool account?
User account who logged in to web application using windows auth?
Any other account?
Application is running under Win Ser 2008 64 bit and IIS 7. Application pool account is Network Service.
It depends on how you configure it. From http://msdn.microsoft.com/en-us/library/ms998292.aspx and http://msdn.microsoft.com/en-us/library/bsz5788z.aspx ...
ASP.NET applications do not impersonate by default. As a result, when they use Windows authentication to connect to SQL Server, they use the Web application's process identity. With this approach, your front-end Web application authenticates and authorizes its users and then uses a trusted identity to access the database. The database trusts the application's identity and trusts the application to properly authenticate and authorize callers. This approach is referred to as the trusted subsystem model.
The alternative model referred to as the impersonation/delegation model uses the original caller's Windows identity to access the database. This approach requires that your ASP.NET application is configured to use impersonation. See the section "Impersonation / Delegation vs. Trusted Subsystem" in this document.
So depending on how you have configured it, it could use either the app pool account (not when not using impersonation) or the account of the logged-in user that is using the web application (when using impersonation).
See http://msdn.microsoft.com/en-us/library/134ec8tc.aspx for impersonation information.
It's the application pool user who connects to the database, if you specified Integrated Security in your connection string.
The problem that i was having was that my application pool account in SQL Server needed to be set to the db_owner role before it worked. I spent a long time trying to figure this out.
I was using Windows Authentication, Windows 7 home premium, and IIS all on the same computer. I'm posting this in case someone else run into a similar problem. The book i used did not say to use db_owner but the reader and writer accounts instead.
I am having a problem with deploying a ASP.NET V2 web application to our deployment environment and am having trouble with the sql server setup .
When I run the website I get a Login failed for user 'MOETP\MOERSVPWLG$'. error when it tries to connect to the database.
This seems to be the network service user which is the behaviour I want from the application but I don't seem to be able to allow the network service user to access the database.
Some details about the setup. IIS 6 and SQL Server 2005 are both setup on the same server in the deployment environment. The only change from the test setup I made is to point the database connection string to the new live database and of course copy everything over.
My assumption at this point is that there is something that needs to be done to the SQL server setup to allow connections from asp.net. But I can't see what it could be.
Any Ideas?
It sounds like you're able to connect to the database alright and you're using integrated windows authentication.
With integrated windows authentication your connection to your database is going to use whatever your application pool user identity is using. You have to make sure that the user identity that asp.net is using is on the database server.
If it is a fresh install not everything may be setup. Check SQL Server Configuration Manager, http://msdn.microsoft.com/en-us/library/ms174212.aspx. Step by step instructions http://download.pro.parallels.com/10.3.1/docs/windows/Guides/pcpw_upgrade_guide/7351.htm.
The user name you've indicated in your post is what the Network Service account on one machine looks like to other machines, ie "DOMAIN\MACHINENAME$".
If you are connecting from IIS6 on one machine to SQL Server on another machine and you are using Network Service for the application pool's process identity then you need to explicitly add 'MOETP\MOERSVPWLG$' as a login to the SQL Server, and map it to an appropriate database user and role. Type that name in exactly as the login name (minus quotes, of course).
Make sure there is a login created for the user you are trying to log in as on the sql server.
There's a few different things it could be.
Are you using integrated windows authentication? If so, you need to make sure the user ASP.net is running as can talk to the database (or impersonate one that can).
Does the web server have permission to talk to the database? Sometimes a web server is deployed in a DMZ.
If you are using a SQL Server login, does that same login exist on the production server with the same permissions?