I'm logging in to create a new database from CMD through sqlcmd with SA account. Its response is a message: CREATE DATABASE permission denied in database 'master'.
I'm using Windows server 2003 and SQL 2008. Please help me. Thanks in advance.
It doesn't sound like you're actually using the sa account, or else perhaps you haven't set up your service account properly using SQL config mgr. If you used Computer Manager | Services, then the service might not have permission to create the database files.
...Run As Administrator should do the trick.
Typically the user you're using to run the SQL Server service will not have access to certain folders, which is likely why you're getting this error.
Consider one of these alternatives:
change the credentials used for the service (ick!)
use runas /u:... or Run as...
add permission for the service to access those folders
move the database to a location that the service can access
I would check whether the user you are using indeed has CREATE DATABASE permission though. You can check what server roles it belongs to, because it seems it is not a sysadmin role.
You can use this query for example.
select suser_name(role_principal_id) [login ...],
suser_name(member_principal_id) [... belongs to]
from sys.server_role_members
Regards
Piotr
Related
I want to write in a shared folder inside my network through an T-SQL procedure but when I try to write, it says permission denied. I tried to grant full permission to everyone and it worked. I don't want to leave it like that though because that would just be another vulnerability in my companies network. What user does T-SQL use? And do you maybe know a way to write without granting everyone permission?
You need to grant the permissions to the account used by the windows service. You can find out which account this is in 2 ways.
SQL Configuration Manager
Open up SQL Configuration Manager on your server, and you see this. The account name you want I have highlighted in a red ellipse.
Command line
Use the command sc to get details of windows services. If your SQL Server instance is the default instance on 'Servername' use
sc \\Servername qc MSSQLSERVER
If you SQL Server instance is Servername\InstanceName use
sc \\Servername qc MSSQL$InstanceName
The account you want is listed as the SERVICE_START_NAME which should be on the last line.
I have a problem with sqlserver authentication .
When i connect to my instance using this information local,windows authentican i have this permission :
But with sqlserver authentication local,sa,12345 i have this permission:
Last day the both permissions was same ,but today the permission of windows authentication are removed and i need the permission of sqlauthentication in windowsauthentication how can i do that?
because my TFS use the windows authentication login .now my TFS doesn't work.
Best regards
i need the permission of sqlauthentication in windowsauthentication how can i do that?
No, you don't. The reason that your sa account can see all of those other logins is because it is a system administrator (i.e. a member of the sysadmin server role). Whatever you're doing with TFS, I can almost guarantee that it doesn't need that level of permission. Find out what permissions you actually need (this looks like a promising start) and grant those. Running any application with privileges it doesn't need is a bad idea in general.
In the past this command would work:
EXEC [linkedServerName].msdb.dbo.sp_start_job #job_name = 'test2'
Now I have to use the impersonate login and add the SQL service account (referenced in local login to impersonate) of calling server onto called server and giving it SA privilege: think I am doing something wrong, it shouldn't be so complicated should it?
Without the SA privilege on the impersonating account added to the remote server I receive error:
The EXECUTE permission was denied on the object 'sp_start_job', database 'msdb', schema 'dbo'.
Thank you
it shouldn't be so complicated should it?
This isn't any more complicated than the task you're doing. It's pretty basic security. If you want an account to be able to do things on a server, the account needs to have the proper access to that server. I'm not sure why you think it should be otherwise. Setting up proxy accounts isn't the most straightforward, but scheduling jobs from a remote server instead of the local agent isn't the most straightforward task, either.
Per the doc a user needs to be a member of the sysadmin, SQLAgentUserRole, SQLAgentReaderRole, or SQLAgentOperatorRole to be able to call sp_start_job.
The alternative is to configure the linked server to use a fixed security context or map a security context instead of impersonating one. This can be configured on the Security page of the Linked Server properties. Note that the account used for a fixed context still needs to be a member of one of the above roles to execute sp_start_job.
I executed the task Take offline of a SQL Server 2008 R2 database.
I cant bring it online!
I tried with
USE master;
GO
ALTER DATABASE [DBNAME] SET ONLINE
I get an error.
User does not have permission to alter database 'DBNAME', the database
does not exist, or the database is not in a state that allows access
checks.
I also tried using the task Bring online and I get the exact same error.
Can anyone help me asap?
I think you're going to need to login with the SA account, or some other account with sysadmin privileges, and then run your code to put it back online. While you're in there, add sysadmin to your account, too. If you don't own the database, you may need to talk to someone else to get the SA password, or ask them to do it for you. Unless you don't have the SA password or it's been dumbed down for security reasons.
Your error is too generic to be usable. Do you actually have the rights to alter the database (I guess you do if you managed to bring it offline)? Can you access teh SQL logs (accessible in the tree via Management > SQL Server logs)? Are you sure the user who is executing the script is the one you expect?
Also, you can try any of the following
* restart the service then retry
* Use the mouse GUI o bring it online (right click on the DB, Tasks, Bring Online)
Had same problem, same error. Even logged on as SA and returned same error. On both problem database the owner was not SA.
Solved by attaching the database. This gives you the opportunity to rename the database was well assign an owner. Assigned owner as SA.
Detached failed database the renamed the newly attached database to the original name.
A lesson in always give SA ownership of new databases.
Is there a way to prevent users from getting into SQL Server Management Studio so that they can't just edit table rows manually? They still need to access the tables by running my application.
You can use the DENY VIEW ANY DATABASE command for the particular user(s). This is a new feature available in SQL Server 2008.
It prevents the user from seeing the system catalog (sys.databases, sys.sysdatabases, etc.) and therefore makes the DB invisible to them in SQL Management Studio (SSMS).
Run this command from the Master Database:
DENY VIEW ANY DATABASE TO 'loginName'
The user is still able to access the database through your application. However, if they log in through SSMS, your database will not show up in the list of databases and if they open a query window, your database will not appear in the dropdown.
However, this is not fool-proof. If the user is smart enough to run the Query Command:
USE <YourDatabaseName>
Then they will see the database in the Query Analyzer.
Since this solution is taking you 90% there, I would give the database some obscure name not let the users know the name of the database.
You DO NOT need to worry about them having access to the tool. Simply make sure they do not know any of the SQL logins for the specific Databases that have read/write permissions, if they do, change the password. If they have access to the DB via Windows Authentication, make sure that they are in a datareader role. You can use roles to manage what the users can do in SQL.
You can use a trigger.
CREATE TRIGGER [TR_LOGON_APP]
ON ALL SERVER
FOR LOGON
AS
BEGIN
DECLARE #program_name nvarchar(128)
DECLARE #host_name nvarchar(128)
SELECT #program_name = program_name,
#host_name = host_name
FROM sys.dm_exec_sessions AS c
WHERE c.session_id = ##spid
IF ORIGINAL_LOGIN() IN('YOUR_APP_LOGIN_NAME')
AND #program_name LIKE '%Management%Studio%'
BEGIN
RAISERROR('This login is for application use only.',16,1)
ROLLBACK;
END
END;
https://www.sqlservercentral.com/Forums/1236514/How-to-prevent-user-login-to-SQL-Management-Studio-#bm1236562
I would suggest you lock down the database and give appropriate read-only (or other) rights to the user. That way the user can still use management studio to run select queries and such.
If you don't want the user to have any rights at all then you could do that as well.
If your application is running as a service/user account then only that account requires access to the database. The individual users' account do not require any access to the database and therefore they won't even have read access. Your app will be the gateway to the data.
If the users are running the application under their user accounts then grant them read-only permission. You can simply add them to the db_datareader role.
Hope this helps!
You can deny 'Users' access rights to the ssms.exe executable file, while granting the relevant users/administrators rights to it.
If your application only used stored procedures to modify the data, you could give the end users access to run the stored procs, but deny them access to modify the tables.
Don't let them know what the database login is.
If you can't restrict the login, use stored procedures exclusively for updates and disable any CREATE,DELETE,INSERT, or UPDATE permissions for that user.
An Application Role will allow you to secure database objects to your application instead of the logged on user.
I agree with Jon Erickson as a general rule
do not allow any users access to the tables, but only allow access through stored procs
do not allow general user accounts access to stored procs, but only the account your app runs under (whether it's an integrated login or SQL login)
Make well usage of Database Roles, if Users should only have SELECT (read) access assign them the db_datareader Role. Even if they login using SSMS they will can execute only SELECT statements.