On phpmyadmin I changed a database's user account privilege to require ssl and now I cannot access my databases. I have these Errors:
MySQL said: Documentation Cannot connect: invalid settings.
mysqli::real_connect(): (HY000/1045): Access denied for user 'root'#'localhost' (using password: NO)
phpMyAdmin tried to connect to the MySQL server, and the server rejected the connection. You should check the host, username and password in your configuration and make sure that they correspond to the information given by the administrator of the MySQL server.
I changed global privilege of user from REQUIRE NONE to REQUIRE SSL. Now I cannot connect to my database. Please help me with a solution to change this setting and connect back.
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 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
I have and old asp application that need to access a sql database I want to use network user but I'm getting this error
[SqlException (0x80131904): Login failed for user 'DLU\DLU09$'.]
I have added DLU\DLU09$ as a user to the database and granted it access rights to the tables.
A local account can't be used to access network resources. A work around is to use the machine account. You do not specify the password. This will work only for machines in the same domain. The infrastructure has to be working. There's plenty that can go wrong...KERBEROS, SPN, trust, etc.
A better approach is to set the application pool to run as a domain account. Then the web app runs as that account and that account can be granted access in SQL. Or perhaps set the connection string to use a sql server login rather than a trusted connection. (I don't like it when folks put passwords in plain text.)
The security event log might have some information if the machine account is not working.
Since a few week, there is a lot of attempt of connection on user 'SA' on my Database, Sql server.
Login failed for user 'sa'. Reason: Password did not match that for the login provided. [CLIENT: xxx.xx.xx.xx]
The IP adresses are all from China.
I think that a hacker try to connect to my Database.
What is the best practices to protect user 'SA' against hackers ?
I need to connect to the Database with Sql server authentification mode.
If i disable the user 'SA', can i still connect with Sql authentification ?
Thanks for any advices.
You may disable SA and enable it only to connect from internal network.
Either you can put your DB behind a firewall.
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