I realised a few minutes ago , in my sql server log; there was an error:
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: 222.186.61.15]
But i don't have an sqlclient ip 222.186.61.15
I research this ip and :
Continent: Asia
Country: China cn flag
State/Region: Jiangsu Sheng
City: Nanjing
Is my Sql Server under attack?:)
What is this?
Thanks for help.
Short answer; probably, but don't panic.
Someone tried to log onto your SQL server with invalid login credentials. If its coming from an IP that's totally out there, then it's probably not just someone mistyping their password. I wouldn't be overly worried about it, though. Its pretty common to see stuff like this every once in a while. Usually, its someone or some tool going through a list of SQL servers and trying common login credentials in hopes of getting lucky.
Just make sure you have solid login credentials, maybe update your firewall/IDS, and watch your logs to make sure that IP (or another weird one) logs in later.
Related
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.
Status : Failure -Test failed: ORA-01017: invalid username/password; logon denied
This status above I see when I'm trying to create new Connection in SQL Developer 11g EE.
I tried propably all possibilites with lower/uppercases and numbers.
Here is printscreen: http://i.imgur.com/Ztc3OAS.jpg
I was searching for that, but coulnd find solution for this kind of problem.
Thank you in advance and sorry if this problem is trivial, but I am beginner in this:(
I've noticed a number of similar topics but none of them either solved the issue or had quite the same circumstances so I figured I'd post the issue and then answer it to help anybody else.
IE/Chrome had no issue but in Firefox when accessing pages of my mvc intranet project running locally to dev test those pages that access my sql database, I would get the error 'The underlying provider failed on Open' which with debugging it told me 'Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
In most cases this seems to not be browser specific and was generally an issue with the connection string to the db, I had found a perfect question which listed most of the likely issues but can't find it now so if I do I'll link that.
As far as I could see my issue was to do with double hopping from my machine to iis then to the database and it lost my credentials in firefox at some point.
While most solutions to this indicated that you needed to set or add Integrated Security=True; to the connection string among other possible solutions.
I first found that if I set impersonate to true and passed in my own domain username and password that it fixed it but this was a bad solution as it required me to store my details.
The actual solution which solved this particular problem with least possible issues was to set impersonate to false and bam no further issues.
This is a database connection problem, not a browser problem, check that the sql service is opened, check also if your connection string is valid, you can post your code.
We have a very strange intermittent issue which has started coming up over the last month or so whereby some connections to mssql server fail with the error:
System.Data.SqlClient.SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)
The error does not bring down the site, nor does it require a db restart - if you simply rerun the same query will work the second time. This means a lot of users will hit an error every now and then and have to refresh the error page for things to work.
Now, my initial knee-jerk reaction was this could be due to:
Resource related issue - so I started running SQL profiler and perfmon, but did not find any issues with the serve struggling to keep up with the number of connections / sec. I've been looking at MSSQL:SQL Errors, MSSQL:Wait Statistics, MSSQL:Exec Statistics, MSSQL:Locks. Does anyone have any guidance on other stats I should be poking and prodding here?
Unclosed DB connections - I ruled this one out after going through all the data-tier code. We have all the fail safes in place to stop this from happening.
Connection / Network related issue: our SQL server sits on a separate server (MS SQL Server Standard 2008) to our application server (running ASP.Net on IIS7) - both servers run on xlarge Amazon EC2 instances with all security policies configured (as per Amazons direction). Anyone got guidance on how to test the connectivity between the two servers or if this could be the issue?
Is it a possible issue with the IIS connection string? I have not tested this but should we be fully qualifying the server with the computer name we are connecting to (just thought of it)? We use a connection string in the format: server=xxxxx;Database=xxxx;uid=xxxx;password=xxx;
Your thoughts and insight is very much appreciated!
Thanks in advance
Solved. After testing almost every possible performance metric and examining every piece of code, I discovered that the error was caused by a bit of deprecated database code. The main issue was being caused by code using:
SqlConnection.ClearPools;
For future reference, any other developers looking to debug their code and manage connection pools, an excellent resource can be found here: http://www.codeproject.com/KB/dotnet/ADONET_ConnectionPooling.aspx
Try changing the connection string to the FQDN+port
server=xxxxx.domain.tld,1234;
Note: you don't need any instance name if you use port
On our global corporate intranet... we had a similar issue that happened to remote clients: more often if they were further away, never in the same building as the server.
After some poking around, chatting to the DBAs and MS, it was said to be caused by timing/Kerberos/too many firewalls etc. Adding FQDN+port removed all our issues.
It may be solved by switching to TCP/IP instead of Named Pipes, if you can.
Perhaps you can test this by changing the server name to the server IP address.
I use server=tcp:servername in my connection string to force TCP.
KB313295
It seems like connection are not being closed correctly, and after some time you can't open any more new connections. As the total allowed connections to database is a constant digit.
If you are using C#/VB.net
Are you using "Using" statements to open the connections ?
using (System.Data.SqlClient.SqlConnection con = new SqlConnection("YourConnection string"))
{
con.Open();
}