I've a user account on a development SQL express on a remote server. This account has all privileges granted to it but when I use SQL express remotely then I'm not able to make changes to tables. If I log into the virtual machine and sign in with same user I can make changes.
It says I'm not database owner or system administrator. I think I may need to use ownership chaining or somehow designate my user account as administrator?
Thanks.
This is what I'm seeing:
http://fogcreek.com/FogBugz/kb/errors/SysAdminRole.html
I'm using SQL Server Authentication but I'm not the owner but have 'grant' all rights.
Got it! This explains how I can add my user to the appropriate role and that fixes the problem.
https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-1061781.html?tag=mantle_skin
Related
While disabling the logins of a server, I mistakenly disabled sysadmin logins as well. Now, none of the sysadmins can login. It would be helpful if anyone can suggest me the alternative to revert back the changes or to enable the sysadmin logins again.
This would be of great help. Thank you. :)
Put SQL Server into Single User Mode. You will need to do this as a local administrator on the server where SQL Server is running.
This mode allows only a single account to connect. If the account is a local administrator on the server, you will have permission to re-add an account back into the sysadmin group. You must then restart SQL Server back into multi-user mode.
Detailed instructions are provided here.
I cannot seem to find a definitive answer to this question.
The problem: I am using Octopus Deploy to run an executable that will run my database migration scripts. An error occurs as the Octopus "Tentacle" Windows service runs as localsystem which translates to NT AUTHORITY\System.
One solution is to change the SQL server security settings and grant an appropriate role to the NT AUTHORITY\System user which allows a process running as the localsystem user to create the database.
What are the security implications of making this change? It would allow any process running as localsystem to perform operations on the database but is this a bad thing given that I control what gets installed onto the server?
It would appear there was a change made circa SQL Server 2012 where by the localsystem account was previously by default a sysadmin but that got changed. One thing I saw was that this change prevents server administrators having access to the server but I can't see how this is possible given that you cannot log in as localsystem anyway.
What am I missing?
References:
https://support.microsoft.com/en-us/help/932881/how-to-make-unwanted-access-to-sql-server-2005-by-an-operating-system
https://dba.stackexchange.com/questions/142166/grant-sysadmin-permissions-to-nt-authority-system
https://serverfault.com/questions/130958/implications-and-benefits-of-removing-nt-authority-system-from-sysadmin-role
I answer to this one:
One thing I saw was that this change prevents server administrators
having access to the server but I can't see how this is possible given
that you cannot log in as localsystem anyway.
Local Windows administrator can access the server anyway, launching SQL Server in single user mode he will have a full control over it: Connect to SQL Server When System Administrators Are Locked Out
But this requires the server to be restarted.
Another option to access server as sysadmin without any restart is to use PsExec (-s) : you can log in as localsystem even through SSMS. And if this login is a sysadmin, you have a full control over the server
If someone is able to compromise your instance of Octopus Deploy the SA role provides enough access to drop every database on your server.
I imagine creating the initial database is a blue moon event. A safer option is to manually create the database and grant NT Authority the least amount of privileges to run your migration scripts.
We took this approach and worked back from SA, to db_owner, to a custom role with
[db_datareader]
[db_datawriter]
[db_ddladmin]
The NT AUTHORITY\SYSTEM account used to be sysadmin by default but not anymore because it's considered a "shared" account. It's not that it's a huge security issue, but when the time comes to point a finger at someone when something goes wrong, it's impossible to do so because using SYSTEM allows actions to be perfomed "anonymously". That's why SYSTEM is no longer recommended to be sysadmin.
"Any user with enough access to the server can execute a task that
will be run as NT AUTHORITY\SYSTEM either using task scheduler or
other tools. At this point, NT AUTHORITY\SYSTEM essentially becomes a
shared account because the operating system and SQL Server are unable
to determine who created the process. Prior to SQL Server 2012, NT
AUTHORITY\SYSTEM was a member of the sysadmin role by default. This
allowed jobs/tasks to be executed in SQL Server without the approval
or knowledge of the DBA because it looked like operating system
activity." (https://www.stigviewer.com/stig/ms_sql_server_2016_instance/2018-03-09/finding/V-79129)
I am having quite a problem with SQL Server.
When I installed it, my account was not an administrator, now it is. Apparently, since it was not an administrator of the machine, it is not an administrator of SQL Server, as a consequence I cannot create databases on my machine.
Now, I am on Windows 8, so it seems like SQL Server Configuration Manager is not as accesible as it was before, I managed to run it (I THINK!) from the MMC by running the following command: sqlservermanager10.msc.
Now, can anyone help me configure my current user as an SQL Server admin so I can create databases properly?
Thank you!
if I understand you correctly, you want your account to have sysadmin rights on SQL Server. You can either do this via SQL Server Management studio, or the SQLCMD command line utility. You don't use the SQL Server Configuration Manager.
You need to login as an existing SA (or whichever the identity has the sysadmin role).
Using TSQL via SQLCMD
Run the following command (replacing domain\user with your details)
USE [master]
GO
CREATE LOGIN [domain\user] FROM WINDOWS WITH DEFAULT_DATABASE=[master]
GO
ALTER SERVER ROLE [sysadmin] ADD MEMBER [domain\user]
GO
Via the UI
In SQL Server Management Studio
Navigate to the Security node of the server, and R-Click & Select New Login
In the New Login dialog enter your domain user into the Window Authentication box
Then on the Right side select Server Roles and then make sure SysAdmin is selected
Then Ok that dialog and the windows account will have SA rights. This means then you can full administer the SQL Server.
It's not clear at all what's going on here, but it sounds to me like you haven't got any sysadmins if #Preet isn't correct.
The local Administrators group is not a member of the sysadmin role on recent versions of SQL Server (2005+, IIRC), and if I recall the installer complains if you try to configure it that way. Instead, when you install the instance you specify the users or groups who will be granted the sysadmin role on the instance.
If you did not do this (I think it adds the account doing the installation by default) or used an account or group which was later deleted, had the SID changed, or some similar event, then you have an instance with no sysadmin logins that can authenticate. You may be able to add one by switching the server to single user mode or minimal configuration mode (-f instead of -m).
If none of that works, then you'll have to save your database files, nuke the instance, install the instance again, re-attach your database files, and go from there.
The only other thing I can think that it might be is that the instance is somehow running as a user account that doesn't have permissions to create files in the default database or log directory, but that seems highly unlikely.
I have installed SQL SERVER 2008 R2 on my system with Windows XP operating system installed.
Whenever I try to create a new database it displays an error:
CREATE DATABASE PERMISSION DENIED IN DATABASE 'master'.(Microsoft SQL Server, Error:262)
When you start SQL server management studio use 'sa' user and not Windows-User. Looks like Windows-user does not have permission.
Right-click and run "SQL Server Management Studio" as administrator.
Try to grant the user your loged in the CREATE ANY DATABASE Permission then try again.
Take a look at the documentation about creating a new Database
Cause of this error is insufficient permission. Give the user "dbcreater" role
Check it:
SqlSever>>Security>>Logins>>BUILTIN\Users rightClick -->Properties
-->Server Roles
...select sysadimn
If you are in a situation where you have public/view only access to a SQL database you should consider the following:
Do you have an alternate login or the sa user login credentials? If so, try this first and, if necessary, grant your other login sufficient privileges via the Security/Logins/.. section of your database in the Object Explorer panel (see Ahmet Arslan's answer).
If you have account access to another Windows user who has access via Windows Authentication, try running ssms.exe as the other user via the "runas" command. Full details and explanation here in the answer from SqlRyan.
If you have old databases from a previous Windows installation that had been configured with Windows Authentication (and you do not have/remember the sa account credentials). In this situation, you can recreate your past user account from your previous Windows installation. Be sure this new account has the same Domain and Username as your previous account. Login via the recreated account, and give your current (or "real") user account sufficient permissions (see #1. above). Once you confirm that you have restored access, you can then delete the recreated user account.
With this problem, I noticed I was connected using Windows Authentication. I then disconnected and used SQL Server Authentication. It is good now.
first you will login on windows authentication
then you will click on login (sa) properties and server role check in db creater then ok click then error is solved and after login within sa and create a database
I am a beginner in database field and this question might sound too stupid but I want to know why there is a login called sa and can I delete it?
I want to delete it because it seems to have pretty serious privileges on database server!
If it matters, I am using SQL Server Express 2008.
You can't remove the sa account but you can rename and/or disable it. Arguably this is good practice as otherwise you have a known username that an attacker could launch a brute force password attack against.
Just make sure if you disable the sa account that you have another account with administrator privileges.
sa is the admin account! do not delete it, give it a strong password that you provide to no one except the database admin and a backup person.
sa is the main administrator account, it was the owner of master database (holding data for user roles,schema,etc), so it can't be deleted.
just change the password (and i think it was asked in installation progress) and create guest/public account with more restrictive privileges for use with your application a.k.a don't use sa in your application (application you develop)
Also, dependent on your environment you can just turn off SQL Server Authentication whatsoever.
There are two types of authentication supported by SQL Server - Windows Authentication and SQL Authentication - you can have both or one of them active. If you switch off SQL Authentication then only valid Windows (as defined in the system) users will be able to use the server (normal permissions still apply, so each account has to be added to SQL Server as well, the fact that somebody has an account in the system doesn't mean they can access the SQL Server instance).
You can configure this in the server settings from the Management Studio.
Never do it . To understand more appropiately please refer http://blog.sqlauthority.com/2008/12/24/sql-server-disable-and-enable-user-sa/