I have setup 3 VMs:
(A) Active Directory in Windows 2008 R2.
(B) Microsoft SQL Server 2008 Express in Windows XP SP3.
(C) IIS in Windows XP SP3.
Both the SQL Server and IIS are joined in the Domain but the host PC is not. I've also created a domain administrator user with administrator privileges in the SQL Server. I can ping/access all the VMs from each other and from the PC hosting the VMs. I can connect to the SQL Server VM using Windows Authentication in SQL Server Management Studio inside the IIS VM with no problem.
I created a very simple application in ASP.Net application hosted in the IIS VM that opens a database connection in the SQL Server VM. I've set the web site to authenticate via Windows Authentication only. Here is my connection string:
Server=DATABASE;Database=HAP;Trusted_Connection=True;
Here is code:
SqlConnection connection = new SqlConnection(ConfigurationManager.ConnectionStrings["ConnectionString"].ConnectionString);
using(connection) {
connection.Open();
}
I've also set "Trust this computer for delegation to any service (Kerberos Only)" in AD for the IIS VM.
It throws "Login failed. The login is from an untrusted domain and cannot be used with Windows authentication." exception. If I change the connection string to this:
Server=DATABASE;Database=HAP;User ID=sa;Password=connectsql;
the application works fine.
I really need it to authenticate via Windows Authentication and not via SQL Server Authentication.
Note:
IIS prompts the user for his Windows credentials.
It's unclear to me whether you intend the application to authenticate as the logged in use, or whether you simply want to have the asp.net worker process be authenticated via AD.
If you want the user to authenticate with their account, then you need to set "imperasonate=true" in the web config. This will have performance ramifications, but that may be ok.
If you just want to authenticate via the worker process, then you need to set the identity of the worker process to a domain account.
Related
I'm trying to connect and getting an error like:
Login failed. The login cannot be used with Windows Authentication
I'm using mirrored local accounts on SQL Server and web server because I'm simply trying to use a trusted connection between machines not on the same domain. It seems like something that would be fairly common, but after days of trying to find an answer that applied to my situation, I do not recognize that any of the answers were applicable... that or the fact that I'm only a .NET developer and not a sysadmin or DBA means I have it and just don't know it.
Here's what I can say:
CMS web server: ASP.NET 4.0 web app running on Windows Server 2008, IIS7, on corporate DMZ
CMS database server: SQL Server 2008 R2 on a domain server
For various reasons that I won't go in to, encrypting the credentials is not sufficient.
The database port that the application needs to connect on is not the standard port and is set up to listen on a different port.
Setting up DB mirroring isn't an option and doesn't really address the requirements (in my way of thinking)
Also, FYI if this is helpful to know:
Content entry happens on internal web server which publishes content to same DB that is accessed by the DMZ web server.
Content server is set up to have the website run the app pool in integrated mode with a windows domain user that has been set as a service account using the -ga switch and given all the appropriate rights and everything runs perfect.
External web server, without domain access, using mirrored accounts (same username and password set up on the SQL Server machine and web machine).
Local account on the web server set as a service account using -ga switch and running as the app pool identity for my app.
On the SQL Server box, created local user with identical creds and given same permissions that the domain user identity has
Connecting to SQL Server via MGMT studio installed on web server with the SQL Server user creds works fine.
Now, if I put in the username in to the connection strings, everything is perfect. As soon as I put the trusted_connection=yes in the connection string like I did with the domain server connection strings, I get the trust error.
So if my connection string is like this, it works fine:
Server=myServerAddress;Database=myDataBase;Username=MyUser; Password=MyPassword;
If I change my connection string to either of these, it fails:
Server=myServerAddress;Database=myDataBase;Trusted_Connection=True;
or
Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=SSPI;
I'm working with one of the client's network admins and he's not necessarily a DBA and doesn't have experience with configuring web apps. So it's possible that we're missing something and any advice or ideas would help. What am I missing?
If using SQL credentials are not an option, then you should use Active Directory and create a one-way trust (have DMZ server domain trust your internal domain), create a service account in your internal domain which your DMZ application can use, and grant that account access to the database. Then it will be able to generate SSPI context.
I am using Amazon EC2 server, with Windows Server. It has installed SQL Server 2008 R2 Express and IIS7. I have made a web site, and want to test this web app. But it is not connecting to the SQL Server. I have tried different connection strings. But it is giving this error:
Server Error in '/' Application.
Cannot open database "Avon" requested
by the login. The login failed. Login
failed for user 'NT AUTHORITY\NETWORK
SERVICE'.
I have tried to change it from windows authentication to SQL Server authentication and vice versa. But same error.
My connection string is
connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|Avon.mdf;Integrated Security=True;User Instance=true;"
I have copied Avon.mdf and Avon.ldf file into App_data. I want it to connect either by local server, or by IP address.
I appreciate your answers.
Thanks
If the identity under which the application is running does not have access to the database, you will need to provide user name and password in the connection string.
Example:
Password=somepassword;Persist Security Info=True;User ID=someuserid;Initial Catalog=DatabaseName;Data Source=.\SQLEXPRESS
You could also try changing your Application pool identiy to a user that has access to the database. or set up asp.net impersonation
Application pool on II7 work in context of user NETWORK SERVICE. In your connection string you have Integrated Security=True.
Solutions:
1) Change connection string to use userId+password
2) Change application pool user - not recommended if you don't understand how it works
3) Allow user NETWORK SERVICE connect to your sql server\data base - not recommended because many others services use this technical account.
We have an ASP.NET 3.5 application running on Windows 2003. For migration purposes this application connects through ODBC to a very old version of SQL Server 4.21. It always worked until one day stop to work (server doesn't exists or access denied) on all the servers. After a week of research we realize that the problem is the account that run the application pool used in the web application (network service), if we change this account to "local service" or "local system" the connection works, but with these account many other problems appear. with "local system" account all works, but we think is not secure to use an account with admin privileges.
The goal would be:
Make the connection work with the application pool running with Network service account
Know why if it worked for a few months with network service, stop to work.
Maybe we need to grant some privileges to an odbc library or something like that, maybe some security update from windows update was causing the problem.
Some clues:
The web application is running through IIS under Windows 2003. This Windows 2003 is
over an Active Directory domain
The SQL Server is over a NT domain. (NT 3.51)
The ODBC system DSN is using "SQL Server" driver, with TCP/IP or Named Pipes on client
configuration.
The connection to the database use a SAL account, not a trusted connection.
The connection always worked, and stop to work at 24/02/2011 on all servers and
developers workstations
Any thoughts?
You can connect to SQL running as the network service account. On the SQL end, make sure that you have granted access to the DB for "\$". If you are in domain EMEA and the machine's name is "machine1", then the user to grant access to is "EMEA\machine1$".
If I have an ASP.NET web app using impersonation and a SQL Server connectionstring with Integrated Security = true, does the identity of the IIS application pool of the app play any role?
Does the identity need to be set to some specific user (LocalSystem, NetworkServices or a domain user)? This is on Windows 2003.
If the SQL Server is on a different box than IIS then the identity of the IIS application pool has to be trusted for constrained delegation. See How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0. If the IIS app is running as NETWORK SERVICE or SYSTEM then the IIS machine account has to be trusted for constrained delegation. The linked resource has all the steps to set this up.
If the SQL Server is on the same machine as IIS then there isn't any requirement afaik.
Our website connects to a database correctly when running the website locally using the built-in web server. But, when we deploy the site to our server running IIS, we get a database connection error. The database server is different from our IIS server. Note that a trusted connection to a different database on the SAME server as IIS works fine.
What do we need to do to connect to a SQL database on a different server with a trusted connection?
When you're running a web site using Cassini, the account used by the web server process is your own account that you use to log on to your Windows machine. That account will be different on IIS.
Consider the security implications of opening the database up to a broader access than you may need with trusted connection. Perhaps you could use Windows authentication with a service account. That is, create an application-specific user in SQL Server with limited permissions. Then, you will get the benefits of connection pooling while avoiding passing credentials.
I'd check the user account that app domain in IIS is using to connect to SQL Server. The account in IIS may not have access to network resources as well which would explain the trouble reaching the other database server.
Sounds like you need to configure the database server to provide access to the database you're trying to connect to.
Assuming SQL Server, log into SQL Server Enterprise Manager and under Security -> Logins, open the properties for the applicable user (probably the Network Service or ASP.NET account of the web server) and go to the Database Access tab and ensure that the Permit checkbox is ticked for the database you are connecting to.