Tag Info

Hot answers tagged

4

Unfortunately no, you can't exclude anything from a backup. If you are talking about Windows Logins then it probably isn't that big a deal. The SIDs won't match anything on their network (very unlikely anyway) so all they will have is the usernames without any of the permissions associated. SQL Logins of course will work fine as long as they create a ...


4

NO, With just Execute permission doesn't allow a user to execute a stored procedure successfully if it contains some DDL (CREATE, ALTER, DROP, TRUNCATE, RENAME) statements.


3

If there are faults found since it dropped out of the extended support period then unless you have paid Microsoft for extended extended support you can be pretty sure there is not a fix available to you. Obviously you can mitigate the risk considerably by following standard practise and making sure the only machines that can touch your SQL instance are a ...


3

Use module signing. Sign your procedures with a certificate and then grant the required permissions to a certificate-derived user. The link contains a full example.


1

It looks like what you want is row-level security. PostgreSQL will support this in version 9.5, but that's due to come out in over a year. For now, you'll need to use views. If you don't mind the fact that a clever user can trick the system into revealing information they're not meant to be able to see using malicious functions in the WHERE clause, you can ...


1

One option is create login with default database option and add role member to login user in database USE [master] GO CREATE LOGIN [CUREMD\NewLogin] FROM WINDOWS WITH DEFAULT_DATABASE=[AdventureWorks] GO USE [AdventureWorks]--- Change DB name to Sharepoint DB Name GO CREATE USER [CUREMD\NewLogin] FOR LOGIN [CUREMD\NewLogin] GO USE [AdventureWorks] --- ...


1

View the default database in user's properties, may be it is master, if so, then change it


1

Verify if your user has permision to connect to database Engine. Right click on Logins -> Properties -> Status. Or grant CONNECT for user. CREATE LOGIN [mydomain\mygroup] FROM WINDOWS; GRANT CONNECT SQL TO [mydomain\mygroup]


1

I got a SaaS product and the data is kinda sensitive. I want to give my customers 100% security on the fact that I can't read their data. If it's software as a service, and you do more than simply store blobs of data then give those blobs back when the customer asks, this is pretty much impossible. You're dreaming. You can't realistically combine SaaS ...


1

After some reading I think I got it. "NT SERVICE\SQLSERVERAGENT" is a member of the local group "SQLServerSQLAgentUser$RINUS$MSSQLSERVER". This group has al the right that a sql server agent account needs "NT SERVICE\SQLSERVERAGENT" is a part of the sql server fixed sysadmin role "NT SERVICE\SQLSERVERAGENT" can't be selected in the list of available ...


1

I was able to get guidance from the following MSDN link: Configure Windows Service Accounts and Permissions. The pertinent section (bookmarked in the link) is "File System Permissions Granted to SQL Server Per-service SIDs or Local Windows Groups". The short version for the solution is that either Read, Execute or Full Control are needed on the leaf-level ...


1

In short, no it won't work. There are two types of windows authentication, local and domain. Seeing as how you're asking about your domain logon, that's clearly the second kind. When you try to authenticate to a domain logon, the local machine will go up the chain in its domain group, and ask for a domain controller to authenticate your credentials. Seeing ...


1

Plan answer: No. Let me explain: Windows Authentication is just that, authenticating with a Window's login. So if you are dealing with a workgroup computer where you are on a domain it will not work, because that server can only authenticate a local account. If you are talking about connecting with SSMS, you can try the runas coomand through command ...



Only top voted, non community-wiki answers of a minimum length are eligible