Does SQL Server has an external log file or internal table for attempted connections, or is that kind of info put somewhere in the Windows Event Log?
You can enable connection logging. For SQL Server 2008, you can enable Login Auditing. In SQL Server Management Studio, open SQL Server Properties > Security > Login Auditing select "Both failed and successful logins".
Make sure to restart the SQL Server service.
Once you've done that, connection attempts should be logged into SQL's error log. The physical logs location can be determined here.
Another way to check on connection attempts is to look at the server's event log. On my Windows 2008 R2 Enterprise machine I opened the server manager (right-click on Computer and select Manage. Then choose Diagnostics -> Event Viewer -> Windows Logs -> Applcation.
You can filter the log to isolate the MSSQLSERVER events.
I found a number that looked like this
Login failed for user 'bogus'. The user is not associated with a trusted SQL Server connection. [CLIENT: 10.12.3.126]
If you'd like to track only failed logins, you can use the SQL Server Audit feature (available in SQL Server 2008 and above). You will need to add the SQL server instance you want to audit, and check the failed login operation to audit.
Note: tracking failed logins via SQL Server Audit has its disadvantages. For example - it doesn't provide the names of client applications used.
If you want to audit a client application name along with each failed login, you can use an Extended Events session.
To get you started, I recommend reading this article: http://www.sqlshack.com/using-extended-events-review-sql-server-failed-logins/
Related
Do you think it is possible to create a SQL server ODBC Connection for an active directory user who doesn't log in into the windows.
Ideally this type of users will be used in the batch process. So, Another person logs in and creates a batch process and runs it with another user.
Note: I dont want to create a SQL server authentication. Instead would like to use active directory.
Thanks.
You can't save alternate windows authentication credentials into an ODBC connection for SQL Server. You can only save credentials into the ODBC setting if you use SQL Server authentication.
There are other options though.
You can create a windows authentication ODBC connection to SQL server even if the account you create the connection with doesn't have database access. You just have to untick the "Connect to SQL Server to obtain default settings for the additional configuration options" and you can't use the "Test connection" feature. You just have to create the connection on faith.
With that connection, it will only work if your batch process or application is running as a different account to the logged-in user. Services that run as system accounts do this sort of thing. If you create an application that can be run as a service then you can change the account it runs under.
You can also run as another account manually. Using explorer you can [shift] + right-click on an application and choose "Run As different user" and then enter the other account credentials. Then when the process or application uses the ODBC connection, it will be the correct credentials and work.
There's also "ShellRunAs" https://technet.microsoft.com/en-us/sysinternals/shellrunas.aspx
I have been trying all kinds of tricks - from enabling TCP/IP, adding exception to firewalls to poking bill gates vodoo doll. But nothing seems to work for me. Is it really that difficult to connect to sql server 2008 via management studio ? Maybe, robbing a bank would be easier.
While i figure out which bank to rob, can you help me to fix the problem ?
When I try to login to sql server 2008, this is the error i get-
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) (Microsoft SQL Server, Error: 2)
The links i tried so far -
blog.sqlauthority.com/2009/05/21/sql-server-fix-error-provider-named-pipes-provider-error-40-could-not-open-a-connection-to-sql-server-microsoft-sql-server-error/
and some more random links on the net.
When you installed SQLServer, there are several options that may affect the way SQLServer runs and how you have to connect to it. The link you included in your question that points to the sqlauthority blog has an additional thread posted by Vince. Be sure to follow those instructions so that SQLServer will be set to listen on port 1433 and not a dynamic port.
Also, when you log-in, if it tells you that the login fails (e.g., for xxx\yyy), then you probably missed the option in the install to add the current user as an authorized users. In that case, you will have to log in through SSMS using SQL Server Authentication, and provide sa as the username and the password that you set during the install.
After you log in, you can add your Windows user account to the list of authorized users by expanding the root Security folder in the SSMS object explorer, right-click Logins and select New Login. From there you can search for your user account and add a Windows authentication user. That will make it possible for you to log in using Windows Authentication so you won't have to type your password every time you launch SSMS.
I am unable to kill some SQL Server agent jobs. The task state continues to be running and the command stays in KILLED/ROLLBACK. The job executes queries against OSI's PI system via OLEDB linked server and Oracle. The only way I have found so far to kill these jobs is by restarting SQL server (not a preferred method).
I found following article
https://connect.microsoft.com/SQLServer/feedback/details/187192/openquery-to-linked-server-hangs-leaving-spid-with-open-tran-that-cannot-be-killed-then-templog-ldf-grows-without-limit-requires-sql-server-restart-on-production-servers
Apparently several people have this issue using openquery through a linked server that is not SQL Server. I'm reposting the work-around that BReuter posted on above article:
posted by BReuter on 1/30/2007 at 2:21 PM
*I have experianced the exact behavior and have found a combination of software which stablized our environment.
There were three key ingredients I found:
1) Make sure you do not have ANY linked servers using Microsoft OLEDB Provider for Oracle, instead use Oracle Provider for Oracle(version 9.2.0.4 is what I have in production).
2) Do not allow the linked server to run "in process". This took some research, but it is possible to run the linked server out of the SQL memory space by following the directions below.
3) I'm running SQL 2005 SP1 on W2K3, but I believe the OLEDB Provider is the key and not the OS or DB version.
The default security settings are too tight to run the Oracle OLEDB provider (OraOLEDB) out-of-process. Further, the default settings for MS DTC do not allow network communication.
Control Panel-> Administrative Tools-> Component Services
Drill to Component Services-> Computers
a. Right-click My Computer-> Properties
MSDTC tab -> Security Configuration button (screenshot below)
a. Network DTC Access – checked.
b. Allow Inbound / Outbound – checked.
c. No Authentication Required – This simulates the windows 2000 security settings.
d. Enable XA transactions – the type of transaction implemented by OraOLEDB provider.
Drill to Component Services-> Computers-> My Computer-> DCOM Config
a. Right-click MSDAINITALIZE-> Properties
Security tab (screenshot below)
a. Access Permissions -> Customize.
b. Press “Access Permissions” Edit button.
c. Give the SQL Server Service account “Local Access” permission.
d. Repeat for “Launch and Activation”.*
If they are large transactions, it might be that the server is actually still performing the rollback which might take some time.
This page
http://www.jaygeiger.com/index.php/2015/03/03/how-to-kill-a-frozen-linked-sql-server-connection/
provides a workaround.
It consist in manual TCP connection termination. It's not an ideal solution but it's the best one I know. It's better than having to restart the entire SQL Server.
Btw. I found that link at https://connect.microsoft.com/SQLServer/feedback/details/187192/openquery-to-linked-server-hangs-leaving-spid-with-open-tran-that-cannot-be-killed-then-templog-ldf-grows-without-limit-requires-sql-server-restart-on-production-servers page mentioned in Ahd's post
for me killing the OLEDB external resources did not worked and i unfortunately had to restart the SQL server instance to fix this issue always
i my cases it have select with OPENQUERY from oracle linked servers or SharePoint lists which simply has a simple error like bad password and it cannot resolve the error and goes and never come back until you restart the service
Transactions that get stuck in KILLED/ROLLBACK can be canceled by killing transactions on local server. If the query is cross-server and you don't want to wait for the rollback, you have to go to the remote server and kill the transaction as well as kill it on the local server.
This applies to any database system.
Sqlcmd: Error: Microsoft SQL Server Native Client 10.0 : Unable to
complete login process due to delay in opening server connection.
When I execute the first query in SQL Server 2008 R2 there was no problems but when I executed the second query there is problem shown above. My database is connected to the local PC and there is no remote connection.
Can anyone help me for finding the above remedy?
Raise your timeouts (connection and command)
Give the sql server more memory
Stop any heavy background processes
Play with netlibs, turn off shared memory and tcpip+netbios turn on and vice versa
Disabling the shared memory worked like a charm for me.
Instructions:
Start SQL Server Configuration Manager.
In SQL Server Configuration Manager, expand SQL Server Network Configuration, and then click Protocols for MSSQLSERVER.
Right-click Shared Memory, and then click Disable.
Click SQL Server Services, right-click SQL Server (MSSQLSERVER), and then click restart.
My office switched to a MultiSubnetFailover (load-balanced) system for our SQL set-up. Our connection manager previously had been set to OLEDB, and as it turns out OLEDB cannot accommodate MultiSubnetFailover=True; that's why we were getting the above error message.
As a result, we switched to an ODBC connection manager instead, and that worked.
When i am creating users in SQL management studio i create them under the server name and then i create them under the database but when i try to log on using the user name and password i cant. getting erro saying
> TITLE: Connect to Server
Cannot connect to LAPTOP-RED\SQLEXPRESS.
ADDITIONAL INFORMATION:
A connection was successfully established with the server, but then an error occurred during the login process. (provider: Shared Memory Provider, error: 0 - No process is on the other end of the pipe.) (Microsoft SQL Server, Error: 233)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&EvtSrc=MSSQLServer&EvtID=233&LinkId=20476
BUTTONS:
OK
And the suggested solution from the help link is:
User Action
Use the SQL Server Surface Area Configuration tool to allow SQL Server
to accept remote connections. For more information about the SQL
Server Surface Area Configuration Tool, see Surface Area Configuration
for Services and Connections.
Which is what you have to do. By default the SQL Express Server isn't configured to allow remote connections.
hi I faced same issue in MicroSoft sql server 2008.
this error occurs while user limit exceeded, as you have set max connection to 1 and if someone is already logged in (or using any webpage which access your server) then it will not allow anyone to access directly or indirectly. to solve this issue simply follow following steps:
stop all web services.
open services.msc using RUN and ****restart sql server** and do not start any service which uses your sql server, so that you will be able to log in using sql server management studio.
now open sql server management studio and click on New Query button.
It will ask for user name and password use your login name and password.
run these scripts one by one sp_configure 'user connections', 0
go
6.reconfigure with override
after this restart your sql server it will show a confirmation message click on OK.
Bingo
It works. please don't forgot to vote ;-)