After setting up a new SQL Server 2014 instance, my boss told me I forgot to add an account during the Account Provisioning section of the installation.
My user is a sysadmin, but not serveradmin. What exactly is the difference?
With sysadmin, you can control the server and with serveradmin, you can change setting, shutdown, alter resource etc.
So the members of the sysadmin fixed server role can perform any activity in the server and Members of the serveradmin fixed server role can change server-wide configuration options and shut down the server.
For more information on rights, you can get from https://msdn.microsoft.com/en-us/library/ms188659.aspx
Related
DBA needs to remove some TFS 2013 permissions from SQL Server 2012. Which permissions TFS should contain on SQL Server after your first installation? FULL TFS has been installed
SQL Server permissions to first TFS installation I've found but daily permission I couldn't
Another specifics questions are:
Can we remove Optimize Database Job (Release Management)?
This TFS job basically executes Update Statistics and as we are working with shared SQL Server, this routing already exists on our DB
What is impact for TFS to remove "Agent User Role" from MSDB database?
You can check these two links for the details about Database Permissions requirements for TFS: https://msdn.microsoft.com/en-us/library/bb552341.aspx http://blogs.msdn.com/b/bharry/archive/2010/08/20/database-permissions-required-to-configure-tfs.aspx
The followings are some highlight points for your quick reference:
sysadmin and serveradmin for all databases that TFS uses.
CREATE DATABASE - We need this permission to be able to create configuration, collection, and warehouse database.
Reporting Services: Team Foundation Content Manager and either sysadmin or the db_owner group membership for the configuration database, the reporting and analysis databases, and the databases for team project collections.
If you want the user to have sufficient permissions to create a database as part of creating a team project collection, you must grant that user membership in the sysadmin role in SQL Server
To install, upgrade, and configure TFS, the user running the Team Foundation Administration console requires the following permissions and role memberships.
-Membership in the serveradmin server role
-ALTER ANY LOGIN, CREATE ANY DATABASE, and VIEW ANY DEFINITION server scoped permissions
-CONTROL permission on the master database
In addition, I don't it is a good idea to remove the Optimize Database job; and I think it is OK to remove the SQLAgentUserRole, but why do you want to do that?
I'm looking at using SQL LocalDB as the client side database which will replace the current SQL CE 3.5 database inside an in-house application developed in .net 4.
I've come across a problem that I'm not sure how to get around and that's with security setup of the LocalDB instance.
If I setup a script inside .net to create a private LocalDB instance, e.g. (localdb)\T1, then create a new database inside that instance plus add a SQL user account + password (non domain account), how do I stop the local windows users (like my own AD account) with admin level privileges from accessing the 'T1' instance + database using SSMS?
I could see a scenario playing out where we deploy the application, then we have some IT savvy user who goes snooping around and decides to install SSMS and connect to (localdb)\T1 with their windows account, which would give him/her full access to the database, which is exactly what I'm trying to stop from happening.
Some of our staff work remotely with no connection to a domain so we give them local admin rights to their pc so they can install software, so even if I could block their assigned windows login name, there would be nothing stopping them from setting up a new local admin account and logging in with that, opening SSMS then accessing the database.
Any pointers on this would be greatly appreciated!
In fact, it shouldn't be so hard. Install SQL Server on client machine using local admin account. To make you life easier, use Mixed Authentication.
After you have your instance installed, local admin account should have sysadmin server role assigned (that's normal security settings). Now, use the following:
Create new SQL Server user and assign sysadmin server role to that account. Close SSMS and log-in using new credentials. Or simply use sa account (not so good practice but in this case it's OK).
Go to "Security - Logins" and remove sysadmin role from local admin. Also, check in user mappings and take all rights "away" from local admin.
As a test, try to log-in as local admin, I guess you won't be able to log-in into server because there is no "home" database for that user. But even if you can log-in, it has only "public" role.
It's up to you to install your database and secure it - assign permission to user of your choice.
Regarding you fear that local admin can install MSSQL again: he/she can install it, but it would be another instance. That instance knows nothing about users in your instance so you should be safe.
You can also consider usage of application roles in SQL server.
I am trying to install DNN using Web Platform Installer. It tries to connect to .\SQLEXPRESS, which I have installed along with SQL Server, and wants me password for sa. When I provide it
with a password, it says "password invalid or cannot connect to database".
I thought to myself there might be a problem with the sa account. I opened SSMS 2012. There is a red arrow downward sign on the sa account. Whenever I am trying to change login status to Granted it opens up an error message:
error 15151
Cannot alter the login 'sa' because it does not exist or you don't have permission.
Nonetheless I tried it with administrator account and also by disabling UAC. None worked. Screen shot follows:
Details:
SQLEXPRESS version: 10.0.2531
SQL Server version: 11.0.2100
Update: Following some guidelines I tried to change authentication in SQL Server Management Studio from Windows Authentication to Mixed Authentication, but it failed with the following permission error:
Make sure you're connecting with a server login that has the sysadmin server-level role. You'll need that permissions level to do what you're trying.
Check the server authentication mode. If it is or was Windows Auth only, the sa account is automatically disabled. Note that if SQL Authentication was disabled and later turned back on, the sa account will still be disabled.
If you find that nobody is in the sysadmin server-level role, you'll need to stop the server and restart it in single-user mode so you can add at least one login to the sysadmin server-level role. In single-user mode, the Administrators group has sysadmin access, but you'll have a limited subset of commands to manipulate data in tables (single user is for fixing servers, not running applications). NB: Only one connection is allowed in this mode, so if you have a broker or service that's trying to connect you'll need to disable that or it can take the session you were planning to use with SSMS.
Is it wise to use Domain Administrator as a SQL Windows Authentication log-in?
No. Local admin, perhaps, yes: never domain admin
For example, xp_cmdshell would allow complete control over AD and your environment. CLR code could do the same. Although these are disabled by default, you can't rely on that to protect your entire network.
Edit:
Logging in as a user as domain admin is no different to using Exchange or similar with the same acount. For SQL Server. no extra rights are conferred or implied because all permissions are defined within SQL Server.
So if you only have a "SQL Server Admin" group as sysadmin, and the domain and local admins are not in this group or set up as logins, then they get normal user rights as per their login. Or they can't even connect.
Of course, as domain or enterprise admins they could just add themselves to the "SQL Server Admin" group... but this requires an extra step and restricts your sysadmin to the correct admin group.
After all, you wouldn't let me as SQL God near your Exchange server...
I think some of the posts have assumed you mean to run the SQL Server service under a domain administrator account (which I agree, would be a security hole), but as you have said in your clarification, it is just to log in to do stuff against the database, I don't see a problem with it....As long as the user in question (I'm guessing it's you here), knows not to drop the production database etc.!
Certain things you need to do against an install require DBA priveleges, if you acquire those by being a domain admin, then what difference does it make?
a. If you have no security problems than - it doesn't matter.
b. if you are connected to the internet, you shouldn't. someone can attack your domain using holes in sql code if the app you're using uses the domain admin authentication. or if someone get access to your administration machine.
c. there is no linkage between domain admin and sql server admin - so why do it ?
Just to be clear - It is not wise !
In my opinion, I wouldn't use an Administrator account for anything management related (that's my Linux background telling me that root accounts shouldn't be used).
It depends a lot about - well - your size and security practices. It does show a security risk, but whethe rit is wise o wnot depends on the rest of the setup.
Best practices recommend not installing Sql Server to run as SYSTEM. What is the bare minumum you need to give the user account you create for it?
By default, SQL Server 2005 installation will create a security group called SQLServer2005MSSQLUser$ComputerName$MSSQLSERVER with the correct rights. You just need to create a domain user or local user and make it a member of that group.
More details are available in the SQL Server Books Online: Reviewing Windows NT Rights and Privileges Granted for SQL Server Service Accounts
Typically I create a Domain User with only the specific rights on the network which I will require the server to have (i.e. to write to the network backup drive), I then add the account to local power users or local administrators depending on what needs to be done on the machine, however this isn't required. I've installed SQL a number of times using a standard user as a Service Account but you need to ensure that the user has access to write to the resources as listed at https://web.archive.org/web/20081223155956/http://support.microsoft.com/kb/283811 . Its probably not as defined an answer as you wanted but I'm only a developer (not a professional DBA / System Engineer).
Mauro
PS dont downmark me for saying "only a developer" :P