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'
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 have a Microsoft Access Application which generates a connection string like:
Provider=SQLNCLI11;Server=servername;Database=db_name;Trusted_Connection=yes;
This works without any problem.
What I want to do is to connect to a SQL Server instance where the user must insert his Active Directory name and password.
Like this:
Provider=SQLNCLI11;Server=servername;Database=db_name;Uid=username;Pwd=password;
This only works for users which are created on the SQL Server directly.
I tried Uid=DOMAIN\username, but it isn't working.
Is this possible? Or is there another way how I can get through this?
The environment:
The User is using a local PC with a local account and then he's doing a "NetworkConnect" with his AD-User and password.
After that, "RunAs" as his AD-User is working BUT there is another Application that is started from the Access Application and this App must be started with the local User-Account.
SQL-Server and the AD-User are member of the same domain.
Your choices are
Login to SQL Server using your the Windows Domain account that you are currently logged into. You do this automatically by specifying Trusted_Connection=yes;, or
Login to SQL Server using a SQL Login.
Those are the only two choices possible using a SQL provider connection string. Specifically, you cannot use the SQL access provider to do impersonation, that is, to login to SQL Server using a different Windows domain account than the one that you are currently logged into.
Microsoft designed the AD integration with SQL Server to use the account of the client application, not to be able to handle logging in as a part of the connection string. If the user isn't going to be logged into the machine using the account needed for the database access, the next best option may be something like ShellRunAs in order to let the user run your client app as the correct AD account.
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.)
Our custom SharePoint site uses a standard connection string (in web.config) to a remote sql server using a sql server authentication. I need to know if it is possible to change this connection to use a SharePoint service account instead of a sql server account. If so, how do specify the service account in the connection string and how do you create a login and user for an sp service account when that user does not exist on the sql server machine and nor is it available on Active Directory.
Update:
I think I need to use integrated security in the connection string and run db calls within SPSecurity.RunWithElevatedPrivileges block. If i use this as a delegate, what sp account will the code be executed under and how do i assign a sql server login to a sharepoint account on a remote machine. Any links to sample code or articles explaining this process would be helpful.
Thanks.
From the SQL Server side, you should create a domain account for Sharepoint in AD. Then you log in to SQL Server via Management Studio (SQL2005 or later), on the left hand side click on security tab, and add a new login - you'll enter the domain Sharepoint service account, and give it the relevant permissions to the databases it needs to access.
For the Sharepoint side, you probably can edit web.config but there must be a Sharepoint admin tool to take care of this properly.
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.