I want to connect the SQL Server with Windows authentication but
Database is on a different server
IIS(Application) is on a different server(Both on the same network/domain)
Want to connect the database through windows authentication.
What configuration/settings I need to do to enable this? At present, When I log in through the application, I'm getting this error message
"Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'."
Related
I have successfully created the Self Hosted Integration Runtime and it is showing up and running in ADF as well.
However when I try to create a linked service to connect to SQL database on the on prem system - I am getting the below error:
Cannot connect to SQL Database: '(localdb)\mssqllocaldb', Database: 'XXXX', User: 'XXXXX'.
Check the linked service configuration is correct, and make sure the SQL Database firewall allows the integration runtime to access.
Cannot open database "XXXX" requested by the login. The login failed.
Login failed for user 'NT SERVICE\DIAHostService'., SqlErrorNumber=4060,Class=11,State=1..
The login failed. Login failed for user 'NT SERVICE\DIAHostService'.
This is not a firewall error this is an authentication error.
You have not granted that windows user account NT SERVICE\DIAHostService access to your database.
This issue is identical to this one, which has instructions on how to solve:
Login failed for user 'IIS APPPOOL\ASP.NET v4.0'
To select data from a table in SQL Server you need three things set up:
Network connectivity (this is fine for you, otherwise you'd get a network error)
The user account granted connect access to the server / db (this is what the error is complaining about - you need to do this)
The user account granted sufficient access to select from the table (you also need to do this)
Please do the below :
Allow outbound TCP communication on port 1433 for both the Windows firewall [
Windows-firewall-setup ] and the corporate firewall [ Ports-and-firewalls ]
Configure the firewall settings of the SQL Database to add the IP address of the self-hosted integration runtime machine to the list of allowed IP addresses.
SHIR setup reference
I want to connect to SQL Server with Windows authentication and create a SQL Server user.
The error I get while doing this is:
Login failed for user 'PCNAME\UserName'. Reason: The account is disabled. (Microsoft SQL Server, Error: 18470)
I also get the following error when I try to connect with PsTools:
Unable to connect: Login failed for user 'NT AUTHORITY\SYSTEM'.
Reason: The account is disabled.
What kind of process should I provide to activate the NT AUTHORITY\SYSTEM user? Or how can I act?
Thank you in advance for your help.
Well, you are trying to connect while logged on as pcname\username. If this user is not created as a Windows user in SQL Server or is disabled in SQL Server, then you will not be able to connect. What you need to do is use an authorized account to created the windows authenticated user in pcname\username in SQL Server then you will be able to connect.
As for pcname\SYSTEM, this is a built in SID that is used by services. There is no reason you could not add this as a Windows authenticated user in SQL Server.
I am trying to connect to an Azure SQL database using SSMS. I know the credentials are correct but I keep getting the error message
Login failed for user xxxxxx
I am using SQL Server authentication and I have already added my client IP address to the server in Azure.
The error is an SQL server error, so your login request is reaching the database. It is therefore not a network problem.
There is therefore something wrong with the user account or related configuration. Things it could be:
SQL Server account authentication is not turned on (Only AD authentication by default)
The user is configured with a default database, that he does not have access to
One of our SQL servers is configured to use both Windows and SQL Authentication, however, we are seeing the continues error "An attempt to login using SQL authentication failed. Server is configured for Windows authentication" in the log. From SQL Management studio we are able to access the server using the same user credentials using SQL Authentication but when one of the applications is using the same user credentials to connect to the SQL server then we are getting the same error.
You may need to restart the SQL Engine Service for the change to be applied. Whoever changed the authentication may not have restarted the service.
I have an IIS 7.0 server connecting to an SQL 2012 Database. On the SQL database I have added a number of linked servers and created a distributed partitioned view to consolidate data from the multiple linked servers. I have a common Windows account on the main server and the linked servers that is common to all (same password). Querying this view from SSMS on the SQL server works fine logged in as the common user. The application pool I am using uses this same user (also on the IIS server) to connect to the SQL server using Integrated Security. I have a simple query of SELECT SYSTEM_USER when run from IIS reports the common user. When trying to retrieve the data from the linked server view I get Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. instead of the data in the view.
Help appreciated
This is basically what is happening: If you are running Active Directory, this is the famous "double-hop" problem. Double-hop is a term used to describe Microsoft's method of maintaining Kerberos authentication credentials over two or more connections. You must configure Kerberos delegation on the AD account running the application pool so that it can forward credentials to the SQL 2012 database server. You configure this on the Delegation tab of the AD account. Without Kerberos delegation, the AD credentials are not forwarded and instead local credentials are sent by the IIS server and get denied by the SQL server. Since the SQL Server doesn't understand the local credentials of the IIS 7 server it denies it as an anonymous logon attempt. The link I provided describes the resolution to this problem in full detail and explains how to expand it out to other servers. Note that if you are not using Active Directory and only local authentication then NTLM is being used and NTLM credentials cannot be delegated off the system so authentication to the SQL server will be in the form of anonymous authentication.