There are many threads about this error but I did not find the answer yet.
We have Azure SQL database and the employees use 1 login to connect.
One colleague has problem with aonnectivity as recently her Azure account was deleted and then restored.
The account deletion may have triggered the issue.
Error Number: 18456
Severity: 14
State: 1
Line Number: 65536
Do you have any ideas what causes this error?
Any hints where I should dig to get an answer?
I have found Error 18456 with State 1 only during Microsoft Azure outages as shown here. To make sure visit #AzureSupport on Twitter or visit Azure Status. Sometimes Azure Support and Azure Status do not show any issues because issues may not be affecting a good number of customers, but you can still find out what is happening by going to Help + Support, choose Service Health, then examine "Health History" and "Resource Health" as shown on this article.
Another possible cause of this error is the status of your Azure Subscription. Maybe your subscription requires your attention.
Related
we've recently set up alerts for failed connections to database using Azure Monitor. We started getting a bunch of failed connection alerts from all of our databases.
After some investigation in system log using etc query
SELECT *
FROM sys.event_log
WHERE event_type = 'connection_failed'
ORDER BY start_time DESC
I can see that there are lost of 'Login failed for user.' and 'Login failed for user '%.*ls'.%.*ls%.*ls' messages.
Now I was able to find that this seems to be specifically Error 18456 with State 122 https://learn.microsoft.com/en-us/sql/relational-databases/errors-events/mssqlserver-18456-database-engine-error?view=sql-server-ver15 which according to documentation is 'Failure due to empty user name or password.'
All of our applications seem to work in a correct way but the error occurs on all 4 databases including 'master' almost all the time. I'm not sure how to debug exactly what's causing this. I've looked at some potential reasons but nothing seems to be the case.
Edit:
I just talked with some developers. They mentioned that sometimes when they login to SQL Azure Db from their local PC's using SQl management studio they have network issues after some time and they are logged out. I'm just not sure whether this is the real reason for these since logs don't tell that much.
Regards.
Please enable Auditing on your Azure SQL Database to further investigate. After that you can click "View Audit logs" and search for Event type "Login" and action not successful.
Once you filter login events, make a click on any event, scroll the window that shows the detail of the event you just clicked on, and you will see important information like IP address of the host.
If you use the dashboard available on the "View Audit Logs" you can have details by type, by IP address and by principal. Just click on the type you would like to see details, and you will get all related events, each one will all details.
Make a click on the IP addresses that you don't recognize (left side on below image), make a click on the failed login attempts for each principal (right side on below image, where you see the Pie chart).
I have an Azure Webjob that can't connect to the database with the error "login failed for user". (Incidentally, the Web App uses the same connection string to connect without a problem).
Here are the details from the error log:
Error code: 18456
Error state: 123
I can't find any documentation on state 123. Can anyone tell me what it means?
We don't document the error state codes because they don't mean anything. They represent unique instances of an error in out code base to help us debug customer issues faster. So, it more or less maps to line x in source code file y.
Thanks,
Conor Cunningham
Architect, SQL Core Engine
I had some help from the Microsoft guys and they've updated the documentation: https://learn.microsoft.com/en-us/sql/relational-databases/errors-events/mssqlserver-18456-database-engine-error
States 122 - 124 means "Failure due to empty user name or password."
Error 18456 is a generic connection error and may have many causes. I would not pay too much attention to 123
Thanks,
Mirek
I am running into an issue when trying to start a service for SQL Server 2014 Express. Each time I try to manually start my server from the SQL Server Configuration Manager, I get an error message reporting
The request failed or the service did not respond in a timely fashion. Consult the event log or other application error logs for details.
I started by looking at some posts on this and other forums for similar issues and the suggested fixes didn't solve my problem. I concluded that the error message I saw was intended as a catch-all message that describes any error that could happen. Furthermore, I concluded that I would need to consult the event logs in order to get any useful feedback on what the underlying issue is.
So I went into the service properties -> Advanced -> Dump Directory where it lead me to a collection of log files. However, the log files I saw in the directory came from a few days ago when I first set up the server. They contain some login attempts from a few days ago, but today's attempts to start the server do not have any matching logs in that location. My question is where can I find Logs for the server start up or what other tools can I use to track down what the actual issue is? any help would be greatly appreciated.
Thanks in advance.
You can use the Event Viewer that you can find in the Control Panel. The SQL Server logs events to the Application log.
I have error in my log for a few weeks, I searched a lot but I couldn't found useful answer.
I did close SQL Server port for public IP, But I have problem yet.
Error: 17806, Severity: 20, State: 14.
SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. The logon attempt failed [CLIENT: 10.10.3.25]
Time raised: 27 Jan 2015 2:23 PM
It was raised error while this system was off.
The Scenario –
A couple of separate individual Windows ID’s started generating these errors while attempting connections, all other windows logins were working properly. The connections were initially happening through applications, but also occurred through sqlcmd. When logged in to the server locally with the offending ID’s the connections to SQL would succeed.
The Troubleshooting process –
Check all the regular SSPI issues, I wont bore you with the details as they are easily searchable
A relatively easy way of checking the “easy” authentication issues If possible/appropriate is to log into the SQL Server locally with the offending ID and fire up sqlcmd and connect to the server via sqlcmd –Sservername,port –E (by specifying the port you force TCP/IP instead of LPC, thereby forcing the network into the equation)
Verify whether the login is trying to use NTLM or Kerberos (many ways to do this but simplest is to see if there are any other KERBEROS connections on the machine)
SELECT DISTINCT auth_scheme FROM sys.dm_exec_connections
If Kerberos is in use, there are a few additional things to verify related to SPN’s, since only NTLM was in use on this server I skipped that
Determine if the accounts were excluded from connecting to the machine through the network through a group policy or some other AD setting
After all of these checked out OK, I began to try and figure out what the error code 0x8009030c meant, turns out, its fairly obvious what the description is : sec_e_logon_denied. This description was so helpful I thought about making this server into a boat anchor but, luckily for my employer the server room is located many miles away and has armed guards.
Since I knew we could logon locally to the SQL Server with the ID that SQL was rejecting with logon denied something else was trying to make my life miserable.
We didn’t have logon failure security auditing turned on so, I had no way of getting a better error description, As luck would have it though this would prove instrumental in finding the root cause. To get a better error message, I found this handy KB article detailing steps needed to put net logon into debug mode.
Say hello to my new best friend! — nltest.exe
After downloading nltest & using it to enable netlogon debugging on the SQL Server, I got this slightly better message in the netlogon.log file
06/15 14:15:39 [LOGON] SamLogon: Network logon of DOMAIN\USER from Laptop Entered
06/15 14:15:39 [CRITICAL] NlPrintRpcDebug: Couldn’t get EEInfo for I_NetLogonSamLogonEx: 1761 (may be legitimate for 0xc0000064)
06/15 14:15:39 [LOGON] SamLogon: Network logon of DOMAIN\USER from Laptop Returns 0xC0000064
The error code 0XC0000064 maps to “NO_SUCH_USER”
Since I was currently logged in to the server with the ID that was returning no such user, something else was obviously wrong, and luckily at this point I knew it wasn’t SQL.
Running “set log” on the server revealed that a local DC (call it DC1) was servicing the local logon request.
After asking our AD guys about DC1 and its synchronization status, as well as whether the user actually existed there, everything still looked OK.
After looking around a bit more I discovered this gem of a command for nltest to determine which DC will handle a logon request
C:\>nltest /whowill:Domain Account
[16:32:45] Mail message 0 sent successfully (\MAILSLOT\NET\GETDC579)
[16:32:45] Response 0: DC2 D:Domain A:Account (Act found)
The command completed successfully
Even though this command returned “act found” it was returning from DC2. (I dont exactly understand why the same account would authenticate against 2 different DC’s based on a local desktop login or a SQL login but it apparently can)
After asking the AD guys about DC2 the light bulbs apparently went off for them as that server actually exists behind a different set of firewalls, in a totally different location. While DC2 would return a ping, the console wouldn’t allow logons for some reason. After a quick reboot of DC2, and some magic AD pixie dust (I am not an AD admin, if it wasn’t totally obvious from my newfound friend nltest) the windows Id’s that were having trouble started authenticating against DC3 and our SSPI errors went away.
Interesting tidbit — During troubleshooting, I found that this particular SQL Server was authenticating accounts against at least 5 different DC’s. Some of this might be expected since there are different domains at play but, I haven’t heard a final answer from the AD guys about whether it should work that way.
The solution
Reboot the misbehaving DC, of course there may be other ways to fix this by redirecting requests to a different DC without a reboot but, since it was misbehaving anyway, and the AD experts wanted to reboot so we went with that. A reboot of SQL would have likely solved this problem too but, I hate reboot fixes of issues, they always seem to come back!
reference
So I'm trying to setup Railo and I want to add a datasource.
For the database I'm using Microsoft SQL server Management Studio.
But now I've run into the classical problem: "Login failed for user 'sa'. ClientConnectionId:afd80ac2-0744-4a7d-a9f7-083d93adee0d"
What I've done so far:
With the SQL Server Configuration Manager in the TCP/IP settings I enabled the IPs I had to.
I set the password for the user 'sa' in MSSQL and I added a user mapping for the table I want to use.
I made the user 'sa' the owner of the DB i want to connect to
Restarted the SQL service, my computer and Railo multiple times.
I'm pretty much out of ideas.
After Leigh mentioned in the comments to look at my logs it had the following message: "Login failed for user 'max'. Reason: Failed to open the explicitly specified database 'test'. [CLIENT: 127.0.0.1]"
I then tried to make a connection without mentioning a database and that worked.
I would also point to Leigh's answer here which explains how to turn Mixed-Mode authentication on, as this can also cause this error. Since the cause of this isn't on Railo/Lucee's end, this issue still arises in 2018.
I just don't want a useful answer to get lost to history, nor plagiarize an answer I barely found.