Need help with connecting to SQL Server using Windows authentication by different users logging in to the clients using their domain account. We have thousands of users and is there a easy way to use a specific AD service account even though users login to these client machines using their windows account. I see some examples of that online if using IIS. But we need this to work with a client server app. Please help if there is a workaround. Thanks!
Typically you would either provision SQL Logins for the AD Groups containing the users, or (less secure) use a SQL Login with user/name and password embedded in the application configuration.
Related
I have a web application (on IIS 7.0) developed with ASP.NET MVC 4. The application manages a database on a SQL Server 2008 R2. Only Windows Authentication is enabled on the site. In my intranet, the domain users access the program without authentication requests. web.config sets a connection string on the site that uses a sql user. All operations on the database are done by this last user. The application should access the database with a windows user instead of a sql user. For this, I created a windows user “MyUser” on Sql Server. I thought I could set a new “connection string” with windows authentication but I wasn't able to pass the credential of “MyUser”. When I set windows authentication on the connection string it uses the client user, and I don't want this.
How I can operate on the database with a different user? I would like all operations on database to be performed by a single windows user (MyUser).
You can give "MyUser" privileges over the folder where your app is. Then you can create an application pool and set the identity to "MyUser" (read this) and assign your app to this application pool.
Your application will be executing with "MyUser" account thus login into SQL with its credentials.
Hope it helps.
I have a website that is backed by a database. I requested a SQL Server login with read/write/execute privileges to be created in our Production environment, and our DBA indicated that a non-interactive service account would be preferred.
Are there any potential issues with using a service account in this manner over a SQL Server login?
According to Microsoft, it is a "best practice" to use a service account (i.e. Windows account) and use SQL logins only for legacy applications that are not able to use Windows accounts (see Microsoft Recommendation).
So, only if your website is based on a non Microsoft technology or not hosted by IIS an SQL login might be the better choice.
At my current employer's we've been using non interactive Windows accounts to connect from our ASP.NET applications to SQL server all the time without any problems. It also makes managing and deploying connection strings easier because you don't have to care about securing them.
If you have an ASP.NET application it's good to add the account under which the IIS app pool runs (or a domain group it's in) as a login on the SQL Server.
However an SQL login might also have the practical advantage to be easier to test with: E.g. you can connect to the server using this account with SQL Management Studio to check if the permissions are sufficient.
We're a team of 4 developers that all have access to all servers (dev, test, uat, production) and we are trying to choose the best (secure, reliable, simple etc) way to connect SQL Server (currently 2008 R2).
Things we considering:
Windows / SQL Server authentication?
What roles?
Same for all servers or different for the production servers?
Please let me know what you do and what you recommend.
If you all require the same permissions, assuming that you are working on a domain and the servers are also on the domain.
Create a Developers group on the windows domain.
Add the 4 developers to that group.
Create a Login on each sql server mapped to that group. CREATE LOGIN [domain\group] FROM WINDOWS
Assign permissions to that login, depending on what you need.
Then a new developer just needs to be added to the domain group to get the permissions to all the servers. Also any changes to permissions only have to be done once to that group.
To answer your considerations.
You should use Windows authentication over SQL Authentication where possible.
The roles you need and whether to have them the same on all servers can only be answered by yourselves IMO, but you should use the principle of least privilege and give only the minimum permissions required by the developers per server.
What we use:
Dev/test servers - Windows Authentication for ease and simplicity
UAT - SQL Server authentication (because it's usually in a different domain)
Production - No direct access - you have to use RDP. You don't want anyone accidentally connecting to production when they think they're connecting to something else.
Development
Windows authentication
Member of the db_owner role
test
Windows authentication
Member of "End user" roles
uat
Windows authentication
Member of the db_datareader role
prod
No access
We only use windows authentication because we set permissions on a domain group.
We use windows authentication
Developer Group under PDC.
Developer have full access to development/testing server and only
selects on production server some(confidential data tables even though the data is encrypted) are though not allowed like pricelist etc.
I have a setup where I impersonate an AD user as described here. The app connects to the (Oracle) database using integrated security, but the impersonated credentials are not propagated to the database.
Are there any known issues with impersonating AD users and accessing the database with integrated security?
I've seen this in Windows Web Applications where AD impersonation would not work because SQL Server would not trust the relaying party, i.e. IIS. In my example, basically IIS was telling SQL Server that the credentials provided are legitimate, but SQL Server would not trust the web server to present these credentials, some times called the double hop issue. Have you tried in AD to trust your application/web server for delegation?
I'm researching whether or not it makes sense for my company to use Azure for some outward facing applications. We need it to integrate with Active Directory so that it knows who they are without having to login to the site, kind of a single sign-on. Has anyone done anything like this or what tools I'd need to use to do it?
To elaborate a little, currently all of our intranet apps use Window Authentication with AD groups to determine who has what access and what level of access they have to the apps. So, once they log onto their machines, they don't have to login again to access any of our home grown apps. We're looking at using the Cloud but we want to keep the same login paradigm if at all possible. Ideas?
Thanks,
Jeremy
You can federate AD to Azure - you will need at least 1 server (on premise) running Windows Server 2008 R2 to get the ADFS bits (code name was Geneva). Then on the Azure side, you use the Azure App Fabric authentication. See MSDN.
An observation on Pat's answer:
*Then on the Azure side, you use the Azure App Fabric authentication. See MSDN
That is not necessarily correct. In the simplest form, which looks like what Jeremy needs, the web site on Windows Azure would simply trust the local ADFS server on-premises. To do this you would use WIF (Windows Identity Foundation).
This scenario is extensibly described in multiple documents. Check Here
A scenario in which you would use Windows Azure AppFabric (the latest CTP) is one in which the app would trust multiple identities simultaneously, and Appfabric would act as an "Identity Hub".