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
Related
I am working on recommendations of Microsoft using RAP tool.
we have got 2 exceptions
The SQL Server Agent service is not using a recommended account
The SQL Server Full-text service is not using a recommended account
problem is login which is used for running SQL server agent which has some rights
my login doesn't have rights to view that login
when I am running query
select * from sys.logins
I can only see logins which I have rights too how to see all logins with their access data
Please help me.
You can't...and a moment thinking about it should tell you why.
Any access model permits you to view exactly what you are allowed to view. You need to ask someone with higher level permissions for the information or access you require.
I recently did a backup/restore of some catalogs from one server to another. Both servers are still up. User access to the servers is controlled via Active Directory and server roles. On the old server, there is no issue with continued user access. On the new server, however, we get log on errors. As near as I can tell (I may not have total access), the group set-up are the same on both servers. Where can I look for differences?
Databases: SQL Server 2012 11.0.3000
OS: Windows Server 2008 R2 Enterprise SP 1
Testing: access was tested through Access (used only for the UI) and Excel connecting to SQL Server.
User accounts: Access is done through a domain lookup, not a local account.
My hope for an answer is some direction in investigation. I am not a DBA. support process is moving too slow. It is a production issue so I am hoping to get a resolution quickly.
Michael
What I found out was that the ad group must be in both the server security group as well as the catalog security. for the affected ad group, it was only in the catalog security group, not the server. thanks.
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.
I am using SQL Server 2008. I am confused about which account will be used when a SQL Server agent job runs. My confusions are,
SQL Server agent as a Windows Service which we could control from Windows Service Management Console, from there we could set the account to run SQL Server Agent (LocalSystem in my computer);
Could I set SQL Server agent job level account to run on?
Could I set in each step which account SQL Server agent job step will run on?
I have above confusions because 3 different account systems may be used and my concern is what is the actual account each step will run on, and I want to avoid any permisson issues (i.e. I want to make sure the account have enough permission.). Any comments or advice? Appreciate anyone could clarify the 3 levels of accounts, which makes me very confused.
thanks in advance,
George
I would typically run the SQL Server Agent jobs under the same account as your app accesses the database.
If that account is too limited in its permissions (which might be a good thing!), I would create a single account for that app and all its SQL jobs (if that's possible) and run all SQL jobs under that account.
You could potentially run each step under a different account, but I wouldn't use that in general (it just makes it really hard to know and understand what is run under which account). Only use it if you have to run a particularly sensitive step that needs a bunch of extra permissions and those permissions are only available to a particular system account or something.
The account under which the SQL Server Agent windows service runs really doesn't have an impact on what your job steps will be run under.
So it boils down to really just two accounts:
one account is needed to run the SQL Server Agent Windows service - this is a Windows account on your machine / server which needs to have enough permissions to run the service, start and stop it - either use LocalSystem, Network Service, or whatever other Windows account you have to run services with
The other account would be the account to run your SQL Server Agent steps under - that's typically a SQL Server account (which could be based on a Windows account), and it needs enough privileges inside SQL Server to do its job, e.g. it needs access to the database objects and all. I would strive to have just one account for each app that runs the SQL Server jobs - makes life a whole lot easier!
Marc
PS: To set the user to run a step under, you need to use the "Advanced" page on the Job step property dialog and select the user from a popup window:
You can create Credentials in SQL Server (use Mgt Studio, under Security). Then create a Proxy in SQL Agent to use those credentials, telling it what kind of job steps can be used by the proxy. Then you get the choice to use that Proxy in the job step itself.
So... I make accounts for various SSIS packages to run under, so that I can keep the SQL Agent Service Account low privilege, and use a proxied credential with slightly higher privilege (not admin though, just enough permission to connect to other systems, including the File System).
Rob
I am trying to replicate a database from SQL server 2000 to 2005 they are located on two different servers both running Windows Server 2003 R2. Im am using SERVER1(SQL2000) as the Transactional publisher and distributor and SERVER2(SQL2005) is the subscriber. I can set up the publication and subscription but when I try to syncronize them I get the following error:
SERVER1-TestReplication-TestReplication-IBSCNVII-ReplicationCNVII_2-99956FE2-402A-48D5-B801-2CBADF12BD3E has server access (reason: Could not obtain information about Windows NT group/user '', error code 0x5. [SQLSTATE 42000] (Error 15404)).
Do I need to add my domain user to a certain user group on server? Any ideas?
0x5 means "access denied" and that you're not allowed to query active directory user information. Likely, the sql server service account does not have proper domain privileges to perform look ups in AD. This could be caused by an account password simply being expired and therefore not enabling SQL to validate against AD or some other issue like services running as local system and not a domain account.
I would recommend confirming that both SQL servers are using a valid domain account and not something like local system. Then check that that domain account isn't locked up or expired.
make sure that the service account you are using to execute the replication has the appropriate rights to both your SQL servers
Aye, check your SqlAgent account in services.msc. Make sure it is a user with rights (in the domain and in SQL). If that fixes it, make sure you lookup the minimum rights required before you go into production.