I have an Octopus server setup using defaults in most configuraiton options; for example, it runs under the LOCAL SYSTEM account, and has created its own database on the local SQL server instance.
For reasons related to the deployment process of one of our projects, I need to switch the account under which the Octopus service runs, but when I do, it looses access to the database. When I try to use the own account to add the required permissions, I too am denied access.
The only two logins defined on the server are BUILTIN\Users and sa; I've made my domain account a member of the former group, but that's apparently not enough, and I don't have the password to sa.
Is there any way I can gain access to this database without completely re-installing Octopus?
As administrator on the local machine, you will be administrator on the SQL Server installation. But you will need to start Management Studio with "Run as administrator".
Related
I read this article and concluded that the file system permissions needs to be manually set when I change the service account for my SQL server instance.
So I changed the service account for my SQL server instance to a brand new local account via SQL Server Configuration Manager and got surprised that the SQL server service can start, even though I haven't set any file or folder permissions for the new account yet. So the service now runs as the local user, but that user does not have access to the default SQL data folder when I check from Windows. I can also read and write to the default backup folder. Why does it work despite the missing permissions?
It works because you used SQL Server Configuration Manager to change the service account. It does all the extra legwork with permissions so that you don't have to.
If, on the other hand, you would use the standard "Services" snap-in found in Control Panel -> Administrative Tools, then nothing would work out of the box, and it would be a truly harrowing experience to set it all up by hand.
From this article we get the answer:
SQL Server service accounts must have access to resources. Access control lists are set for the per-service SID or the local Windows group
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 recently installed Microsoft SQL Server 2012 on a fresh Windows 7 installation, but whenever I want to run the server, I get the following error:
Error 1069: The service did not start due to a logon failure.
The following user is configured to start the service: NT Service\MSSQL$SQLEXPRESS
How can I fix this problem?
The answer to this may be identical to the problem with full blown SQL Server (NTService\MSSQLSERVER) and this is to reset the password. The ironic thing is, there is no password.
Steps are:
Right click on the Service in the Services mmc
Click Properties
Click on the Log On tab
The password fields will appear to have entries in them...
Blank out both Password fields
Click "OK"
This should re-grant access to the service and it should start up again. Weird?
NOTE: if the problem comes back after a few hours or days, then you probably have a group policy which is overriding your settings and it's coming and taking the right away again.
This happened to me. A policy on the domain was taking away the SQL Server user account's "Log on as a service" rights. You can work around this using JLo's solution, but does not address the group policy problem specifically and it will return next time the group policies are refreshed on the machine.
The specific policy causing the issue for me was:
Under, Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignments: Log on as a service
You can see which policies are being applied to your machine by running the command "rsop" from the command line. Follow the path to the policy listed above and you will see its current value as well as which GPO set the value.
While ("run as SYSTEM") works, people should be advised this means going from a minimum-permissions type account to an account which has all permissions in the world. Which is very much not a recommended setup best practices or security-wise.
If you know what you are doing and know your SQL Server will always be run in an isolated environment (i.e. not on hotel or airport wifi) it's probably fine, but this creates a very real attack vector which can completely compromise a machine if on open internets.
This seems to be an error on Microsoft's part and people should be aware of the implications of the workaround posted.
Short answer:
install Remote Server Administration tools on your SQL Server (it's an optional feature of Windows Server), reboot, then run SQL Server configuration manager, access the service settings for each of the services whose logon account starts with "NT Service...", clear out the password fields and restart the service. Under the covers, SQL Server Config manager will assign these virtual accounts the Log On as a Service right, and you'll be on your way.
tl;dr;
There is a catch-22 between default settings for a windows domain and default install of SQL Server 2012.
As mentioned above, default Windows domain setup will indeed prevent you from defining the "log on as a service" right via Group Policy Edit at the local machine (via GUI at least; if you install Powershell ActiveDirectory module (via Remote Server Administration tools download) you can do it by scripting.
And, by default, SQL Server 2012 setup runs services in "virtual accounts" (NT Service\ prefix, e.g, NT Service\MSSQLServer. These are like local machine accounts, not domain accounts, but you still can't assign them log on as service rights if your server is joined to a domain. SQL Server setup attempts to assign the right at install, and the SQL Server Config Management tool likewise attempts to assign the right when you change logon account.
And the beautiful catch-22 is this: SQL Server tools depend on (some component of) RSAT to assign the logon as service right. If you don't happen to have RSAT installed on your member server, SQL Server Config Manager fails silently trying to apply the setting (despite all the gaudy pre-installation verification it runs) and you end up with services that won't start.
The one hint of this requirement that I was able to find in the blizzard of SQL Server and Virtual Account doc was this: https://msdn.microsoft.com/en-us/library/ms143504.aspx#New_Accounts, search for RSAT.
I had a similar issue that was resolved with the following:
In Services.MSC click on the Log On tab and add the user with minimum privileges and password (on the service that is throwing the login error)
By Starting Sql Server to run as Administrator
If the user is a domain user use Domain username and password
One possibility is when installed sql server data tools Bi,
while sql server was already set up.
Solution:-
1.Just Repair the sql server with the set up instance
if solution does not work ,
than its worth your time meddling with services.msc
I don't know how good of a solution this is it, but after following some of the other answer to this question without success, i resolved setting the connection user of the service MSSQLSERVER to "Local Service".
N.B: i'm using SQL Server 2017.
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.