Not sure if this should go on this forum or on IIS forum...
I have an IIS 7.5 web site on a 2008 R2 box with the application pool configured to run under a local user called ProcessIIS.
This web site then connects to a sql database on the same box under windows authentication.
However every time it tries to make the connection it fails at the sql side with an error -Login failed for user ''. Reason: An attempt to login using SQL authentication failed. Server is configured for Windows authentication only. [CLIENT: ]
If I change the application pool identity to IUSR then the correct name is picked up ( although the login fails this time due to rights).
I have already configured a test box the exact same way and no issue was found - any ideas ?
Ok - solved this - not exactly sure what was wrong. But after deleting the user completely, removing the server from the domain. Readding the server back to the domain, recreating the user and finally adding the user back into SQL & IIS all works correctly ???
Related
I am deploying a web application with asp.net core 2.1 using IIS, the process completed successfully and the site is working as it should except for the database (which is a localdb instance) I always get this error:
SqlException: Cannot open database "Mydb" requested by the login. The login failed.
Login failed for user 'IIS APPPOOL\CORE'.
I already enabled loadUserProfile="true" and setProfileEnvironment="true"
in the applicationHost.config for the site pool
and using these links Link#1 - Link#2 I added the user 'IIS APPPOOL\CORE' with the right permissions to the database users and localdb with SSMS and using this Link I made sure all the SQL Server services are running and under the right port.
I also tried shared instances of localdb but didn't work either.
I saw some duplicates of this question but none of them worked for me.
I did manage to make it work under the local windows account the one I am logged in with, but I think it's not the right approach since it poses some security risks in case the site got hacked that's why virtual accounts are recommended for this use because they have limited access to system resources, so with this being said the connection string is fine and the problem should be with the virtual pool account not being able to access the database.
Is there something that I am missing?
I've been working to try and connect an ASP.NET application to an IIS Site running in an App Pool using Integrated Security. I was eventually unsuccessful in that attempt until I made the Login I'd created to represent the App Pool a Sysadmin, which I understand is not a good thing to leave in there. It's on localhost, but it still makes me uneasy.
So I decided to try to use a Login/Password combo instead of Integrated Security. To that end, I created a new Login in my SQL Server Management Studio:
And told it to use a password, making sure that I know what the password and username are.
My Default database is master
Server Roles is only 'public'
In User Mapping I added db_owner to one of my databases, and all the others are only 'public'
In Securables, 'Connect SQL' is Granted to the SQLEXPRESS server
I then disconnected from SSMS and tried to reconnect using my newly-created Login.
It didn't allow me to log in:
According to:
https://learn.microsoft.com/en-us/sql/relational-databases/security/authentication-access/create-a-login
After creating a login, the login can connect to SQL Server, but does not necessarily have sufficient permission to perform any useful work.
However, that appears to not be the case in this instance. What am I doing wrong?
I did make sure that my Server Authentication was set correctly, per SQL Server 2008 can't login with newly created user
Another data point: when I try (and fail) to log in 10 times in rapid succession and then go back in with Windows authentication, the 'Login is locked out' notification in the Status tab is not checked.
The thing I was missing was going to Windows Services, and restarting SQLEXPRESS to get the change to 'SQL Server and Windows Authentication Mode' to take effect.
After I did that, I was able to log in with my testuser.
I have installed SSMS (v17.1), created a new login at Security -> Logins, changed mode on the server (server: OWNER) to mixed mode. But the username/password combination doesn't seem to work. New Database Query -> SQL Server Authentication -> enter username/password and get error: Cannot connect to OWNER. Login failed for user 'myusername'. HELP!
According to Change Server Authentication Mode when the authentication mode is changed the server has to be restarted. Until restart SQL Server is still using Windows only authentication mode and that is what we can read is SQL Server error log as the reason of 18456 "login failed for user (...)"
I got this to work by following the instructions here: https://serverfault.com/questions/422269/where-can-i-find-the-user-in-this-iis-error-login-failed-for-user-iis-appool-w
All I did was create a user on the database, named IIS APPPOOL\DefaultAppPool, and a login, also named IIS APPPOOL\DefaultAppPool, using Windows authentication, and pointed the user at the login and it worked. Frankly, I'm still not sure why my custom SQL Server user didn't work, but at least I can move forward with my project.
When I try to query the linked server outside of IIS, from console application everything works fine without any additional configuration.
When I try to query the linked server from website hosted in IIS, I
get the following error: Login failed for user 'DOMAIN\USER'.
Obviously, I can "fix" this problem by adding that user to SQL
Server, but why is it trying to access the SQL from user account and
not from application's pool account? Why don't I get error Login
failed for user 'IIS AppPool\MyApplicationPool'? Is there a way to
force it to use application pool?
Obviously, I can't access the Linked Server data without giving that user a read permissions on the folder. If I give permissions to Everyone - it works. If I give permissions to Users - it works...but which user is accessing the linked server data? Is it the MSSQL user? Is it the DOMAIN\USER?
Is there a simple way to do the following: Force application in IIS to authenticate with IIS AppPool\MyApplicationPool instead of local account so that I can simply give the read permissions on the folder to that application pool.
If I somehow manage to force it to use the app pool and configure the required permissions, did I bypass the double hop problem? Is there a need for Kerberos delegation?
Thank you in advance.
MSSQL Server is in the "abc" domain and have mixed mode authentication.
I am connecting from the machine which is not in domain or in a domain "xyz" but with in the same network using MSSQL Jdbc driver 2.0. I have logged in as admin or account in xyz domain.
It works fine using following url for connection for "sa" or SQL Mode Authentication.
jdbc:sqlserver://%DB_IP%:%DB_PORT%;SelectMethod=cursor;DatabaseName=dbname
It doesn't work For window authentication using credential "MSSQLDomain\username" i.e "abc\username", using following url
jdbc:sqlserver://%DB_IP%:%DB_PORT%;SelectMethod=cursor;integratedSecurity=true;DatabaseName=dbname;
Gives following error.
Login failed for user ''. The user is not associated with a trusted
SQL Server connection.
I have tried adding property Trusted_Connection=Yes to url, but still gives same error.
I don't want to map the drive of the SQL Server. I am able to access the any shared folder of the SQL Server Machine by providing "MSSQLDomain\username" and password.
It works fine for both authentication mode, if both machine is in same domain.
If I am using jtDS Driver from the machine which is not in domain or in "xyz" domain within same network i.e same subnet, it works fine.
This is the deliberate and correct behaviour of Windows Authentication.
It is because the Domain from which you are connecting from, is not the same Windows Domain as the one where your SQL Server instance resides.
I believe there are methods for bridging the Domains so to speak, however they require custom and tricky implementation. You also will have to configure a trust relationship between the domains.
The following thread contains discussions which you will likely find useful.
http://sql-server-performance.com/Community/forums/p/24601/137574.aspx
Changing the login credentials might help,
use SQL authentication instead of nt authentication
https://support.microsoft.com/en-us/kb/555332
Symptoms
After you install Microsoft SQL Server 2014, SQL Server 2012, SQL Server 2008, SQL Server 2005, or SQL Server 2000 and you try to connect to the server that is running SQL Server, you receive one of the following error messages:
Login failed for user '%.*ls'. The login is a SQL Server login and cannot be used with Windows Authentication.%.*ls
Login failed for user ''. The user is not associated with a trusted SQL Server connection. (Microsoft SQL Server, Error: 18452)
Login failed for user ''. (Microsoft SQL Server, Error: 18456)
Resolution
This problem occurs if the user tries to log in with credentials that cannot be validated. This problem can occur in the following scenarios:
Scenario 1:
The login may be a SQL Server login but the server only accepts Windows Authentication
To resolve this issue, configure SQL Server in Mixed Authentication Mode.
Scenario 2:
You are trying to connect by using SQL Server Authentication but the login used does not exist on SQL Server
To resolve this issue, verify that the SQL Server login exists. For more information, see Create a login in SQL Server Books Online.
Scenario 3:
The login may use Windows Authentication but the login is an unrecognized Windows principal
An unrecognized Windows principal means that Windows can't verify the login. This might be because the Windows login is from an untrusted domain. To resolve this issue, verify that you are logged in to the correct domain.
I have been involved with making a SQL server connection cross to domains like that, and it is exceptionally painful. In order to use credentials from another domain, the domain where you are assigning the permissions has to trust the domain, where the account is coming from. IT Pro's are generally VERY reluctant to trust another domain in this manner, and for good reason, so if this trust relationship has not been established it might not be very likely to convince the admins to do this.
Once you have the trust relationship established, you will probably need to register the SPN's for your SQL server in Active Directory, and assign delegation permissions. This type of environment is very difficult to setup, troubleshoot and maintain.
I hope that there is some other way that you can do this, because it sounds like you are headed for a very difficult scenario.
Hope it helps
Rihan