The requirement is to find which OS user logs in to a SQL Server database whenever the login is Windows Authentication or SQL Server authentication. Need to know WHO (AD account on the client PC) used which db account logged into SQL Server with what application.
The problem is I could not get the client's OS username when a SQL Server authentication user logs in.
For example, I used my AD account Domain name on a laptop， laptop123. Domain name is Stackoverflow, username is developer1, started Microsoft SQL Server Management Studio, connected with DB account (SQL Server authentication) ERPAPPUSER. I need to record the domain user Stackoverflow/developer1.
I can easily get the information that user ERPAPPUSER logged in from laptop123 using Microsoft SQL Server Management Studio.
I created a database logon trigger and could get the client username, hostname, logon time, application name and so on, but could not get the client OS username.
CREATE TRIGGER DB_ServerLogon
ON ALL SERVER
WITH EXECUTE AS 'sa'
FOR LOGON
AS
BEGIN
INSERT INTO audit_history.dbo.db_logon_history
SELECT
ORIGINAL_DB_NAME(),
ORIGINAL_LOGIN(),
##SPID,GETDATE(),
HOST_NAME(),
APP_NAME()
END
GO
Many thanks!
-- Added 'WITH EXECUTE AS 'as' ', otherwise for all users who don't have access to the db_logon_history will not be able to login.
Short answer is no, it is not possible.
Long answer, SQL Server supports 2 security modes. These are a) "Windows Authenitcation mode" and b) "Mixed Mode" - which is "SQL Server and Windows Authentication Mode". This second mode means that you can log in with a SQL Server login or a Windows Account. The Windows Account would be the same as in (a) above. Now when you log in with Windows it is a trusted connection, so you have to have the Windows Account/Group authorized to access your SQL Server instance. The connection is authentication against a token which is created when the user logs in to windows. This token is passed to SQL Server and can thus be parsed to return the information that you have described above. However when you log on with SQL Server Mode you are not logging on with a domain account and thus no domain account is passed to SQL Server. Rather you log in with a SQL Server native account that is running in the context of the server. Now, you could be logging on with any sort of device, not just a windows client. If you wish to pass the client details to SQL Server when using SQL Server mode, you have to pass it as a parameter from the front end. i.e. using a stored procedure or similar. (Good question by the way. and well asked.)
Related
The authentication mode is "Mixed" for my SQL Server 2016.
I'm using SSMS to run cross-server queries.
I've checked the user account & have ensured that the account has proper authority. I can use a different account and run cross-server queries as expected. The account has proper authority to the databases in question and it has authority to them. I've tried everything I've seen on the internet searches I've done and no luck. The account can login using SSMS.
My linked server properties are:
The account's login properties are:
Has anyone else seen this & have a resolution?
** EDIT: rebooting the target server fixed the issue
When creating a linked server you choose the authentication mechanism by which the remote connection will be made. If you select the fourth option (pictured), the remote login must be a Sql Server authenticated login. It cannot be a windows login.
The only way to connect through a linked server using windows authentication is to forward the credentials of the login on the local server. There is no option to specify a windows username and password.
Indeed, there is no way, ever, to specify a password when connecting to a Sql Server with windows credentials, since the whole point of windows credentials is that you're already authenticated. That happened when you logged in to windows in the morning*
You can only (and must always) specify a password if you are using Sql Server authentication.
What seems to be going on in your case is that the linked server may have been created with the wrong security options. This is just easier to explain with an image:
* More precisely, a connection will be made using the account that the client is running under. If you start SSMS using a "runas /user ..." command, then the windows credentials used to connect to servers will be the credentials specified in runas
I'm trying to connect to a remote SQL Server database. It's being hosted on another server within the network at my workplace, but I keep getting an error when trying to connect while being logged in under a specific Windows (AD) account.
I'm using SQL Server Management Studio from my local server. I tried logging in with account "x". When specifying the connection string I'm using a SQL Server authenticated user. This is when I get the error below:
I logged in with a different account "y" to the server and attempted the database connection again (with the same SQL Server authenticated user), and it worked.
Why would I be able to connect under one Windows account and not the other (from the same server) when I'm trying to connect with a SQL Server authenticated user?
Could this be that the Windows account is not part of the correct administrator group?
Any thoughts or insights are appreciated.
Thank you,
Could somebody explain how you can have different databases/security when connecting in via Windows Authentication from when someone connects via SQL authentication?
I have a customer who had to put a computer onto their network. When they did this, the computer name changed. When connecting into SQL it now has a different server name.
The thing is if I connect using a SQL username and password, I get the databases that were installed before. However If I connect using windows authentication, I do not get the database.
I would like to know what needs to be changed in order for windows authentication to see the same as a user logging in via SQL authentication.
How can I go about changing the permissions of windows authentication?
Within SQL Server, there are Logins (at the server level) and Users (at the database level). Your SQL Server login obviously has permission to the database(s) you want to see. The logins can also be windows users and/or groups. So, if you add a named windows user as a server login, you can extend that login as users in different databases. You can do the same thing with a group. So, you could have a single login to your sql server that represents all authenticated users in your domain, etc...
So, I think you need to get into SSMS (SQL Server Management Studio) and see what logins and users are defined on your SQL Server.
I am trying to send an email using the sp_send_dbmail stored procedure of SQL Server with an attachement,
My account doesn't have sysadmin privileges, when an attachement is sent as normal SQL Server user, I get this error
The client connection security context could not be impersonated.
Attaching files requires an integrated client login
Is there is any way to send SQL Server email with attachement without using sysadmin privileges?
Well, if you would have looked at the MSDN documentation for sp_send_dbmail, it says:
Database Mail uses the Microsoft Windows security context of the current user to control access to files. Therefore, users who are authenticated with SQL Server Authentication cannot attach files using #file_attachments. Windows does not allow SQL Server to provide credentials from a remote computer to another remote computer. Therefore, Database Mail may not be able to attach files from a network share in cases where the command is run from a computer other than the computer that SQL Server runs on.
So from this it's clear you have to be connected to SQL Server using Windows authentication (with Integrated Security=SSPI; in your connection string) in order to be able to attach files to e-mails.
This will solve the problem , you just need to provide sysadmin rights to the sql user ,
Command :
sp_addsrvrolemember 'User', 'sysadmin'
This is rather embarrassing, but I accidentally deleted my Windows account from the list of SQL Server 2008 users and I cannot for the life of me figure out how to re-add myself now that I don't have login privileges.
The server is running on my machine and the only other Windows users with access are IUSR, NETWORK SERVICE and SYSTEM. Is there anything I can do short of re-installing?
I also recently deleted my windows account from my local development 2008 server. I was able to use SQL server's Single User Mode to recreate my login and add it to the sysadmin role. It took just a few minutes, and I didn't have to admit my terrible error to anyone.
From MSDN:
Starting SQL Server in single-user mode enables any member of the
computer's local Administrators group to connect to the instance of SQL
Server as a member of the sysadmin fixed server role.
Here's how I reinstated myself:
Exit out of SSMS
Stop any SQL related services. I had to stop Reporting Services. Other SQL services such as SQL Agent will also use up your one, valuable connection.
Stop the SQL service
Start the SQL service with the extra parameter -m. This will put the SQL into Single User Mode. This means that SQL will only accept one connection.
Use sqlcmd to connect to your server with the -E trusted connection option. SQL will accept you into the sysadmin role if you're a local administrator.
In the interactive session, create your login and add to the sysadmins role.
USE master
GO
CREATE LOGIN [domain\username] FROM WINDOWS WITH DEFAULT_DATABASE=[Master]
GO
EXEC sp_addsrvrolemember #loginame=N'domain\username', #rolename=N'sysadmin'
GO
Stop the SQL service, remove the -m parameter and restart the service. You should now be able to go back into SSMS and continue using the server normally.
If you get the message:
Login failed for user 'domain\username'. Reason: Server is in single user
mode. Only one administrator can connect at this time.
Then there is something using your single connection. You'll need to find that service or connection and stop it before you can log in. Check SQL Agent, SQL Reporting Services, SQL Analysis Services etc.
Luckily, this wasn't too hard to fix (not that it should have been hard...)!
This blog post explains the steps for starting SQL Server in Single User Mode, which (for some reason) allowed me to login as my Windows administrator account, add the account to the user list (with CREATE LOGIN), enable the SA user and set its password to something I actually knew, and finally login as SA and give the Windows account sysadmin privileges.
Edit 07/05/13: Try this link instead.
Often SQL Server is installed so that any any local administrator is a SQL Server sysadmin.
If this is your case you can run Management Studio as administrator and then add any other windows user as a login in the Security section.
This solution worked for me.