I have an asp.net application that should access data from two SQL Servers. One of the SQL Servers is present on the same machine as IIS (let us call it SQLSERVER1) whereas the other SQL server is present on another machine (SQLSERVER2).
The connection strings are trusted for both the SQL servers. Impersonation has been set to true in my web.config file. I am using Windows authentication in both IIS and web.config.
When I try to access data from SQLSERVER2, I get login failed for user(null) error. The user through which I have logged in through Windows exists as a SQL server account in SQLSERVER2.
What could be the possible reason?
NOTE: This is a newbie question IMHO.
NOTE: The IIS used is 6.0 (Windows 2003). It is not set to IIS 5.0 isolation mode.
EDIT:The user getting impersonated is a domain user
Addition:
I also want to state that I get this error message when I access it as a client of the server where IIS is running. In other words, let me say I am working on machine A, the IIS and SQLSERVER1 are on machine B, and SQLSERVER2 is on machine C.
I do not get this error message when I am working on machine B. This is stumping me more.
This is absolutely a delegation problem. As one person pointed out, you need to make sure Kereberos authentication is being used. The old style NTLM isn't going to cut it. Here's more on Kerberos vs. NTLM.
In a nutshell, if you have a webserver and a database and you want the webserver to impersonate the user when making database requests (so that you can set up permissions on the database directly on a per-user or user-group basis) you're performing a double-hop. Credentials must past first from the user's computer to the webserver and again to the database. As you can imagine, the database has to trust the webserver to "do no evil" or this could be an extremely dangerous security hole. As a result, you have to set up what is called in the Windows Server world "delegation"...
Microsoft has a good article about all this here. Further, you can look over an article like this to get an idea of how to set it all up. We've run into this frequently, and it can be a pain at first, especially since as a developer you're probably not in control of the servers directly (especially production ones) and you'll have to spend a lot of time with the server guys down the hall.
You're probably running into this problem because non-Kerberos based impersonation (NTLM) is only valid on the local machine (the webserver). If you want to be able to use those credentials to access another machine, you're going to need to make sure you're using Kerberos.
Try this: http://support.microsoft.com/kb/810572
Your authentication to the webserver is not passed through to the sql server. The web server is authenticating to the SQL Server using the account that your application pool is running under.
You should check that the machine account for SQLSERVER1 has trusted for delegation enabled. Otherwise SQLSERVER2 won't trust the impersonation running on SQLSERVER1. This is in addition to confirming that Kerberos is used to set up the impersonation in the first place. This also assumes that the servers and the users are all members of the same domain.
BTW, are sure you want to do things this way, you end up creating a lot more connections because they end up being unique to a user?
Have you tried to access the database on server2 using SQL SErver administrator from Server1 and made a successful connection?
If not then this could be because by default SQL Server installs itself with tcp turned off by default.
You will need to make sure that this is turned on for server2 to allow server1 to connect.
server1 has no problems connecting due to the fact it can use the shared memory connection.
Related
I have an ASP.NET 2 (very old) web app that I am trying to migrate to a new server. BTW, I am a complete ASP.NET noob but have a good amount experience with other web technologies.
In the web.config, I can see the following connection string XML:
<connectionStrings>
<add name="myCon"
connectionString="Data Source=DEVELOP\DEV_SQL2008R2;Initial Catalog=QO2_New;Persist Security Info=True;User ID=sa;Password=q"/>
</connectionStrings>
I did "nslookup" on the machine name 'DEVELOP' and RDP into the server. To my surprise, I don't see any SQL Server process running. Also, there is no SQL Server installed on that server. I am 100% that the app is running and I am very confident that there are content that comes from the database. I also did a search on the code base and it seems like the connection string is being used.
On a side note, we do have some other databases on separate machines. My questions are the following:
Can the machine DEVELOP somehow redirect the DB connection to somewhere else? If yes, how do I find out which IP is it being redirected at?
If DB connection cannot be redirected, then what is going here exactly?
Unfortunately, I have very little people whom I can ask what is going with this app. Any tips that you can share is much appreciated.
Nslookup uses DNS but there is a chance your machine has a hosts file entry that points DEVELOP to somewhere else..
However, if you RDP'ed into DEVELOP (as in, used that name when connecting RDP, not the ip address given by nslookup) then you should have been able to see a sqlserver install in the list of services.
If there is surely no sqlserver installed there then, from within your RDP session, use TCPView from sysinternals to see what process is listening on port 1433. Could be some kind of TCP redirector like PortTunnel from SteelBytes, bouncing the connection somewhere else. Remember to run tcpview on the server, not your local machine
Perhaps you can try getting connected to the sqlserver using management studio, using the credentials in the web config, you can get sqlserver itself to tell you more about where it is running, such as:
SQL - Query to get server's IP address
Using Environment variables in T-SQL
I am truly ashamed to inform everyone that the database in the web config was never being used. Therefore, even though it is pointing to a non-existing database, it still works. The data from the old database have been converted to static files.
I should have checked this the first thing I came across it. Thanks again for all the help.
We have a web application which consists of an IIS web server which is on the internet, and a database server, which IIS accesses over a VPN link.
The problem we have is that we need to store the connectstring somewhere (which obviously can't be in the database).
I note that it is possible to encrypt web.config connect strings using aspnet_regiis :
https://msdn.microsoft.com/en-us/library/dx0f3cf2%28v=vs.85%29.aspx
Can anyone comment on how robust this is. What we do not want is the database being hacked from the internet.
One thing which concerns me is the aspnet_regiis is used to decrypt and encrypt and is installed on the machine itself. So if the machine was compromised and this exe was on there, discovering the passwords would not be that hard.
So assuming that this method of securing a password is not recommended, what other options do I have.
Note that in case it is relevant, IIS is running in the context of IIS APPPOOL\DefaultAppPool account.
Thanks.
You do not encrypt your configuration files to prevent being hacked from the internet. IIS will never serve *.config files. You encrypt configuration files to hide the information therein from server administrators.
If a remote attacker has access to the server and can run arbitrary executables, all bets are off. There's nothing you can do to secure the server after that.
How to prevent the server from being accessed remotely is too broad to answer, check OWASP for general hints.
If possible, give your app pool identity (in your case IIS APPPOOL\DefaultAppPool) access to the SQL Server.
Then use integrated authentication instead of password and username in your connection string:
Server=myServerAddress;Database=myDataBase;Trusted_Connection=True;
Here's the desired setup:
Service with wsHttpBinding is on IIS 6 on Machine 1 behind the firewall.
Client is front end website on IIS 6 on Machine 2 on a DMZ.
We are currently able to authenticate the client using Windows authentication, but with impersonation
<identity impersonate="true" userName="OurCompany\Me" password="Blahblahblah" />
since the website would use the "ASPNET" as username, which is not in the domain.
We now want to move away from this method, because of safety issue; we don't want to expose this kind of info on the DMZ.
Is there any way to get authenticated properly without using
the impersonate on the client
config?
If we changed so that we use
certificate authentication, would it
affect service operations that
require impersonations (needed
impersonations for file access on
the network for example)?
thanks.
This has been resolved now, and I think it'd be constructive to share the solutions.
In terms of my original question - whether it's able to do impersonation without setting it explicitly in the config or in the front end code. As mentioned by the above, the App Pool method does work, but only when both the client and server are on the same domain.
Since the web site client being situated in the DMZ has no access of the local network at all, meaning we are unable to impersonate any network user (this is a flaw in my original question, saying the impersonation works - it was actually not working).
So the only way to go was using certificate. Since this is internal communications, I have generated a test certificate on each of the server / client sides with the makecert. Using peer trust certificate authentications, I am able to get the communication working between the client and the server. This will ensure that no Windows / network user account information is presented in the DMZ zone.
ASP.NET Login control is very slow making the initial connection to AD when authenticating to a different domain than the domain the web server is a member of. Problem occurs for the IIS server and when using with the Visual Studio's built in web server.
It takes about 30 seconds the first time when attempting to use the control to connect against another domain. There is no trust relationship bewteen the web server's domain and the other domains (attempted connecting to several different domains). Subsequent connections execute quickly until the connection times out.
Using Systernals Process Monitor to troubleshoot, there are two OpenQuery operations right before the delay to "C:\WINDOWS\asembly\GAC_MSIL\System.DirectoryServices\2.0.0.0_b03f5f7f11d50a3a\Netapi32.dll with a result NAME NOT FOUND" and right after the 30 second delay the TCP Send and TCP Recieves indicate communication begins with the AD server.
Things we have tried:
Impersonating an administrator on the web server in the web.config;
Granting permissions to the CryptoKeys to the NetworkService and ASPNET;
Specifying by IP instead of DNS name;
Multiple variations of specifying the name and ldap server with domains and OU's;
Local host entries;
Looked for ports being blocked (SYN_SENT) with netstat -an.
Nslookup resolves all the domains and systems involved correectly.
TraceRt shows the Correct routes
Any Idea or hints are greately appreicated.
we finaly fixed it with
connectionProtection="None"
To turn off all attmepts to connetc on the secure port and only use 389.
We also had to specify the Connection username like "ad/bob" instead of just "bob" after the connetionProtection change.
Thanks,
Eric-
I had the same issue. Following this advice seems to have sorted it.
https://elgg.leeds.ac.uk/webteam/weblog/15385.html
We had a custom user running as the app pool user, giving the user read access to this directory 'C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys' Sorts the issue.
If you have the .NET 2.0 SP1 installed
just add the following to the
machine.config (of course all sites
will not check verisign any longer)
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
http://forums.asp.net/t/968778.aspx
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.