On IIS 8.5, the only authentication method I have enabled is Windows Authentication, with Negotiate and NTLM. When I use a connection string in any ASP.NET application, running under an app pool who's identity is a domain account, I'm able to connect fine. In classic asp I get:
Microsoft OLE DB Provider for SQL Server error '80040e4d'
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
As far as I know the servers aren't configured for delegation, and I didn't explicitly set the SPN. I'm accessing the box via the FQDN which is netbiosname.mydomain.com .
Why is it working in ASP.NET, but failing in classic asp? Am I experiencing the double hop? Is there a way to confirm it is in fact the double hop?
Here's the error I'm getting:
Microsoft OLE DB Provider for SQL Server error '80040e4d'
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
I found out how to resolve this issue, I believe the last step was the only one that helped, but here's what I did:
Disabled all authentication methods other than Windows Authentication
In IIS Manager, I used the "Convert to Application" option to mark
the folder containing the classic asp code as an application
Assigned the application to app pool running under AD account with access to SQL server
Enabled 32-Bit application support on the app pool
Set pipeline mode to integrated for app pool
At this point I still was getting the same error
I right clicked on the application and set the Physical Path Credentials to the same domain account that the app pool runs under and everything started to work correctly
I would imagine you need to set the classic asp IIS website to run as the domain account you're using for integrated security.
To get ASP to connect to the database, in IIS 6, Directory Security -> Authentication Methods, Under Enable Anonymous Access, I set the anonymous access account to the AD account with permissions to the database.
i was tearing my hair out for a while. then i tried creating a windows user account, with the proper permissions in SQL Server, and used "Integrated Security=SSPI" in the connection string. it worked like a charm - no AD required:
SQLconnex = "PROVIDER=SQLOLEDB;DATA SOURCE={server};DATABASE={db};UID={uid};PWD={pwd};Integrated Security=SSPI"
hope it helps and saves your hair.
In my case to solve it I set the "anonymous authentication" the use of the "application pool identity".
Sites > Authentication > anonymous authentication > Edit > application pool identity
Related
I'm trying to access a sql server database from an ASP NET app configured to work with IIS.
I have several questions now,
1) Authentication in IIS: I need to know if my authentication settings for the site are ok:
I tried with Windows Authentication set to Disabled, but the problem continues.
2) Are the settings for the user NT AUTHORITY\Sericio de red well configured? ("Servicio de red" means Network Service)
3) When I added the login for network service, I only found "Servicio de red", I guess it's the equivalent for NetworkService, I'm I right?, My windows 7 ultimate is an spanish version, I just changed the windows interface by using a windows upgrade to make it appear in english. Is there a problem with it?, I guess it's right because the access to the database is being done through the IIS APPPOOL\Servicio de red user.
My DefaultAppPool identity is set to to AppPoolIdentity
If you want to see what I have tried, see this thread.
The whole project, along with a backup of the database I'm using can be found here, called MyServiceSolutionInIIS
What I'm trying is to build a WCF Data Service that offers information that comes from an entity data model generated from a sql server database. This service will be used by a WPF App as a client.
I'd like to avoid creating a user for it, I think it can be done with the App Pool
Okay so the way this works is, whatever application pool your endpoint is running under passes its credentials to the SQL Server. So, you have two options:
Run the default application pool under NetworkService, or;
Use SQL Authentication when connecting with your web service to the SQL Server.
Honestly, the latter is the most common, but in your situation you may be just fine by changing the default application pool to run under NetworkService.
This has nothing to do with the authentication you've chosen (well, mostly nothing.. you can control which credentials anonymous users run under). Every website runs in an app pool, and this app pool has an AppPoolIdentity.
I'm a little confused as to why it would be claiming it's IIS AppPool\NetworkService, since NetworkService should be NT AUTHORITY\NetworkService, or IIS AppPool\MyAspService or IIS AppPool\DefaultAppPool.
There is a lot more information on App Pool Identities here:
http://www.iis.net/learn/manage/configuring-security/application-pool-identities
Note: There is a bug in IIS 7.5 (the version of IIS that comes with Windows 7 and Windows Server 2008 R2) that sometimes causes authentication problems with AppPoolIdentities if the users password changes (say, if you have mandatory password change policies). There is a hotfix here:
http://support.microsoft.com/kb/2545850/en-us
More info here:
IIS application using application pool identity loses primary token?
There so many scenarios in which this issue occurs.
First thing you need to clear if you are using windows authentication and you are not mentioning any username password in your connection string then:
What happens when you run your code through localhost: when you run your wcf test client from localhost, it will be able to communicate to database as local debug mode application is calling database by your account's service. So it has access to database because devenv.exe is running under your user account.
But when you deploy your web service in IIS. Now understand this service runs under IIS not under your account. So you need to assign access rights to IIS service to access the sql server for windows authentication. Here your web service would not be able to communicate to the SQL server because of access rights issue and Login Failed for user_______ (here your user will come)
So if you are using windows authentication to connect your database, you just have to change the IIS Application pool settings. You need to change IIS Application pool's identity to:
local System (for single windows user).
Network Service (for intranet users or domain users)
Below are the Steps for windows authentication WCF:
•Open IIS (windows+R (run) then type inetmgr, then click ok)
•double click your PC name under Connections
•Click Application Pools
•Select your app pool (DefaultAppPool)
•Then under actions on the right click Advanced Settings:
•Go to Process Model section and
•click on Identity.
•Now select LocalSystem (for single windows authentication user).
or select Network Service (for Intranet users)
Now open your sql server management studio: open run-> then type ssms then press ok in ssms, login using your windows authentication account. open security tab expand logins tab then you will be able to view your account.
Now open properties of your account go to userMapping then select the database you want to connect then check the role membership services you want to use for the selected database click ok. (For network services i.e. intranet users you need to configure above settings for NT AUTHORITY\SYSTEM user too)
add Trusted_Connection=True; property in your connection string. Save it & deploy the web service. Restart app pool.
you will be able to connect the database now.
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'm trying to get an ASP.NET website running on Vista (IIS7), using SQL Server and Windows Authentication. No matter what I do, when I connect to the database, I get the exception:
SqlException was unhandled
Login failed for user 'MyDomain\MachineName$'.
It doesn't seem to matter what settings I apply, I cannot get IIS7 to pass through my Windows login credentials.
Extra details:
Both the SQL Server and my local machine are on ActiveDirectory
Vista Enterprise, IIS7
SQL Server 2005
Anonymous Authentication disabled, Windows Authentication enabled
Impersonation on/off makes no difference
All Identities (NetworkService, LocalSystem, etc) give the same result
Classic and integrated pipelines give the same result
Help!
Impersonation on/off makes all the difference, when properly configured. What you want is caled 'constrained delegation' and you need to configure IIS and ASP for it:
How To: Use Protocol Transition and Constrained Delegation in ASP.NET 2.0
Configure ASP.NET Impersonation Authentication (IIS 7)
Configuring Servers for Delegation
By default, the IIS server is not allowed to impersonate you towards the SQL Server. There's an MSDN article on how to configure it. The configuration process is complex and error prone.
If your production ISS and SQL Server run on different servers, you'll need a domain admin to configure impersonation trust between the two servers. This is typically a no-go in a big organization.
In addition to not being deployed by normal admins, impersonation also prevents users from sharing their connections in the SQL connection pool. This results in a very noticeable performance penalty for even small (5+ users) websites.
Did you try to create a new user account for your application, grant it the appropriate rights on the Sql Server, and then set the application pool to run under this new account?
This is what I usually do, and it works. I'm not running my application under NetworkService, LocalSystem or other builtin accounts.
Does your connection string contain Integrated Security=SSPI?
Have you switched the asp.net context to be a domain user as well?
Here is an MSDN article on this topic
http://msdn.microsoft.com/en-us/library/2xzyzb0f.aspx
My ASP.NET v3.5 web application is throwing the following exception when it attempts to open a connection to a SQL Server 2008 database:
System.Data.SqlClient.SqlException:
Cannot open database "MyDbName"
requested by the login. The login
failed. Login failed for user 'NT
AUTHORITY\IUSR'.
The thing is, I've added NT AUTHORITY\IUSR to the server's list of logins, and to the database's list of users. For the server, I've granted the user the Public role, and for the database I've granted db_datareader permissions.
I've also granted the same for NT AUTHORITY\NETWORK SERVICE, which is the identity that the application pool is running under.
The web application is hosted by IIS7, if that makes a difference. The problem repros when the DB and IIS are on the same physical machine as well.
The trick here is that NT AUTHORITY\NETWORK SERVICE actually appears to the database as DOMAINNAME\MACHINENAME$ (note the $ sign!). That is, when you cross the machine boundary from your web server to the SQL Server, SQL Server sees the machine account if you use the NETWORK SERVICE or LOCAL SYSTEM accounts. If you use any other non-domain account, SQL Server will not receive your credentials.
I'm a bit puzzled by your error message. Truth be told, I don't think that when the DB is on another box, you'll see anything other than Login Failed for NT AUTHORITY\ANONYMOUS LOGON.
IUSR is used for anonymous websites, and can't pass over the wire to SQL Server. You may find a way for it to work if you're doing everything on the same machine, but I'd never know because I'd never do it that way... ;-)
In case it helps someone, in web.config I added <identity impersonate="false" /> for this error to go away (under <system.web>)
It's important to note that you'll get this error, as I just did, if you don't have IIS configured to allow impersonation, but you do have your web.config attempting to do impersonation.
I just came across this exact error, and all of the following steps are required:
Ensure ASP.NET impersonation is enabled on your IIS web server:
Combine that with configuring your site to use impersonation (web.config):
<system.web>
<identity impersonate="true" userName="your_service_acct" password="***" />
</system.web>
The above steps presume that you have a SQL Login setup on your MSSQL for 'your_service_acct' with permissions
When running on localhost, against a localdb, or even a remote db that you personally have permissions on, the development IIS runs as if it were YOU - and everything just magically works. So, in debug mode, you don't need to create a special web.config..
As soon as you deploy your site onto some kind of server (in my case, our TEST environment) you'll likely need to have done the above steps I just detailed, because IIS will try to connect as the application pool user, which is not usually what you want administratively speaking. So, that's when you want to start using web.config transformations, so Visual Studio will insert the appropriate identity impersonate="true" during your 'Publish...' deployment step.
I would suggest to create a separate (preferably domain) account and specify it in the connection string (usually in web.config)
Then you can limit permissions on the web server what this account can and cannot do.
Then you can grant this account required permissions in SQL server.
I had had the same problem and solved this by changing application pool.
Instead of using Integrated Security=True; in connection string, just use username and password authentication user=sa; pwd=mypassword;
The simple solution is to check your web.config file and make sure one of these is part of the db connection string:
Trusted Connection=false
OR
Integrated Security=True
This problem is shown when you restore a new database on your last database.
To resolve this you must go to sqlserver, then security and then set your apppool again.
this worked for me:
Open the IIS Manager (inetmgr)
In the "Connections" panel, drill down to your site's node and select it
In the right-hand panel, under the "IIS" group, double click the "Authentication" icon.
Right-click on "Anonymous Authentication" and choose "Edit..." from the context menu.
In the popup dialog, select the "Application pool identity" radio button.
Click OK.
I am using SQLServer2005 and VS2008. My connection string in web.config is:
add name="library" connectionString="Data source=KMT; Initial Catalog=Library;Integrated Security=SSPI"
Here, KMT is my server name, Library is my database.
When I run my page through VS2008 localhost, it's fine. However, when viewing through IIS it shows an error message like "login failed for user, 'KMT/ASP.NET'". My sqlserver authentication mode is windows and it's ok in web.config. What will be the solution?
Using "Integrated Security" means logging in to the database with the identity of the user running the process. When you run the local VS web server, it runs as your login. But in IIS, the web server worker process runs as a predefined user account. Your worker process identity must have rights to your SQL Server and database.
Check the properties of your App Pool in IIS. If you are running as Network Service for example, go into SQL and create a new user, enter Network Service as the Windows user name, and grant that user rights to your database.
one of my friends helped me to solve this problem as
i executed the SQL to add ASPNET as a login to
my DB and setup DA permissions
exec sp_grantlogin N'MACHINE\ASPNET'
exec sp_defaultdb N'MACHINE\ASPNET', N'Database'
use Database
exec sp_grantdbaccess N'MACHINE\ASPNET', N'ASPNET'
exec sp_addrolemember N'db_owner', N'ASPNET'
here MACHINE is machine name and database is my database name.
but through this the ASPNET user has total
control over that DB.
VS2008 uses your credentials to authorize to the db, IIS is using different account.
Make sure the IIS account has enough permissions.
If you use Integrated Security=SSPI, the credentials of the current user (in VS that would be YOU) are used to connect to SQL Server.
From an IIS app, the user associated with the IIS service is used for log in.
Solutions:
Assign the IIS service a special user that's allowed to connect to SQL
Use SQL Server authentification to access the database, and stored username/password in the connection string
Were you planning to use the ASP.NET system account or the users windows account?
If the latter you need impersonation. That works if SQL and IIS are on the same machine, otherwise it is a double hop and requires a non trivial amount of work to set up delegation.
If the server is windows 2003 you can give the Network Service the permissions to access to SQL Server