I've just changed the account under which SQL Server starts on my
development server. The new account has admin rights, and a corresponding
Exchange email account - so I can now receive alerts at various points.
I've restarted the server, and the SQL Server service seems to be running
OK.
However, I cant get the SQLServerAgent service running. It comes up with the
following error:
Service Control Failure:
An error 1069 - (The service did not start due to a logon failure) occured
while performing this service operation on th SQLServerAgent service.
To be honest, I'm not sure if the Agent service was running previously, so
the change in account details might be a red herring.
To get it working, I changed the account from a Windows account, to the
System Account - under this setup, the Agent started fine, but then I found
the SQL Mail test failed.
Now the SQLServer service uses the Windows Account, but the SQLServerAgent
service uses the System Account, and... touch wood... they both appear to be
working...
I'm just curious if my setup is correct, ie. is this a common scenario or
should both services be under the same (Windows?) account? It seems a little
odd to use differing accounts.
Thanks
ChrisIdeally, from a security perspective, you should use 2 different domain
accounts. Then you can audit what each one is doing.
The SQLServerAgent account, did it have log on locally rights, and if the
server is a domain controller, it needs more than just a Domain User rights.
Regards
--
Mike Epprecht
Epprecht Consulting (PTY) LTD
Johannesburg, South Africa
Mobile: +27-82-552-0268
Specialist SQL Server Solutions and Consulting
"CJM" <cjmwork@.yahoo.co.uk> wrote in message
news:%23BvtlNJcDHA.2632@.TK2MSFTNGP12.phx.gbl...
> I've just changed the account under which SQL Server starts on my
> development server. The new account has admin rights, and a corresponding
> Exchange email account - so I can now receive alerts at various points.
> I've restarted the server, and the SQL Server service seems to be running
> OK.
> However, I cant get the SQLServerAgent service running. It comes up with
the
> following error:
> Service Control Failure:
> An error 1069 - (The service did not start due to a logon failure) occured
> while performing this service operation on th SQLServerAgent service.
> To be honest, I'm not sure if the Agent service was running previously, so
> the change in account details might be a red herring.
> To get it working, I changed the account from a Windows account, to the
> System Account - under this setup, the Agent started fine, but then I
found
> the SQL Mail test failed.
> Now the SQLServer service uses the Windows Account, but the SQLServerAgent
> service uses the System Account, and... touch wood... they both appear to
be
> working...
> I'm just curious if my setup is correct, ie. is this a common scenario or
> should both services be under the same (Windows?) account? It seems a
little
> odd to use differing accounts.
> Thanks
> Chris
>
>|||"Mike Epprecht" <mike@.epprecht.net> wrote in message
news:uTBJHTJcDHA.1128@.tk2msftngp13.phx.gbl...
> Ideally, from a security perspective, you should use 2 different domain
> accounts. Then you can audit what each one is doing.
How do you mean?
> The SQLServerAgent account, did it have log on locally rights, and if the
> server is a domain controller, it needs more than just a Domain User
rights.
SQL Server has its own domain account, with admin rights.
The SQL Server Agent uses the 'System Account'
CJM|||Hi Chris,
Form your description, I understand that SQL Server has its own domain
account, with admin rights and the SQL Server Agent uses the 'System
Account' on your computer. Currently, the SQL Mail test failed in the SQL
Server Agent Properties. If I have misunderstood, please feel free to let
me know.
Based on my knowledge, when the SQLServer service uses the Windows Account
and the SQLServerAgent service uses the System Account, the two services
could start as normal. But if you want to use SQL Mail successfully with
SQL Server Agent, you need to have a domain account for SQL Server Agent
service. SQL Mail could not work fine using System Account with SQL Server
Agent.
Also, I found some related information below:
Troubleshooting MSSQLServer or SQLServerAgent Services User Accounts
http://doc.ddart.net/mssql/sql2000/html/trblsql/tr_servdatabse_3c37.htm
Hope it helps
Regards,
Michael Shao
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
Showing posts with label admin. Show all posts
Showing posts with label admin. Show all posts
Tuesday, March 6, 2012
Saturday, February 25, 2012
Account to Run SQL under?
Currently, our network/server/domain admins have admin control of our sql
servers. One manager wants to run sql under a special local admin account
to restrict this access, but then we will be effected by the password change
requirement, which could break sql every 90 days.
What is the best way to run sql so that the server admins don't have sql
admin access? Can I run it under "local system", and restrict machine
admins?Its not a wise choice to make the User IDs local to the
server, the reason is that non local user id's (i.e.
domain accounts) can be allocated email accounts so sql
server can send emails, whereas local userid's cannot.
If you do not want local administrators to have system
admin access rights then all you need to so is restrict
the BUILTIN\Administrators rights.
Peter
"Only two things are infinite, the universe and human
stupidity, and I'm not sure about the former."
Albert Einstein
>--Original Message--
>Currently, our network/server/domain admins have admin
control of our sql
>servers. One manager wants to run sql under a special
local admin account
>to restrict this access, but then we will be effected by
the password change
>requirement, which could break sql every 90 days.
>What is the best way to run sql so that the server admins
don't have sql
>admin access? Can I run it under "local system", and
restrict machine
>admins?
>
>.
>|||First of all, it is imposible to stop God from having access. And, in the
domain, Domain Administrators are God. However, you can slow them down
quite a bit. Here is a KB that details the procedures. Also know that if
you use AD Global Groups to grant the SQL Server DBAs administrative access,
which is a Best Practice, all the Domain Admin has to do is add themself or
the Domain Admins group to yours.
How to impede Windows NT administrators from administering a clustered
instance of SQL Server
http://support.microsoft.com/kb/263712/EN-US/
How to change the SQL Server or SQL Server Agent Service account without
using SQL Enterprise Manager in SQL Server 2000
http://support.microsoft.com/default.aspx?scid=kb;en-us;283811
If you suspect foul play, it would be better to run some sort of Audit
Logging on your system and then once captured, bring it the attention of the
Data Center Director's attention. Keep in mind that just like the DBAs,
with great power comes great responsibility. No one should be placed in a
role that they are not qualified, and responsible for, to perform.
Just like the DBAs have the authority to delete every user/system database,
the responsibility is to preserve that data. It is no different for the
Domain Admins. They have the authority to disrupt operations but the
responsibility to preserve them. If you find an individual, or team, that
does not play by these rules, that must be made know to the Operations
Manager, regardless of the title or the position of the offender.
Sincerely,
Anthony Thomas
"Peter The Spate" <anonymous@.discussions.microsoft.com> wrote in message
news:05b901c51b4e$87a454e0$a501280a@.phx.gbl...
Its not a wise choice to make the User IDs local to the
server, the reason is that non local user id's (i.e.
domain accounts) can be allocated email accounts so sql
server can send emails, whereas local userid's cannot.
If you do not want local administrators to have system
admin access rights then all you need to so is restrict
the BUILTIN\Administrators rights.
Peter
"Only two things are infinite, the universe and human
stupidity, and I'm not sure about the former."
Albert Einstein
>--Original Message--
>Currently, our network/server/domain admins have admin
control of our sql
>servers. One manager wants to run sql under a special
local admin account
>to restrict this access, but then we will be effected by
the password change
>requirement, which could break sql every 90 days.
>What is the best way to run sql so that the server admins
don't have sql
>admin access? Can I run it under "local system", and
restrict machine
>admins?
>
>.
>
servers. One manager wants to run sql under a special local admin account
to restrict this access, but then we will be effected by the password change
requirement, which could break sql every 90 days.
What is the best way to run sql so that the server admins don't have sql
admin access? Can I run it under "local system", and restrict machine
admins?Its not a wise choice to make the User IDs local to the
server, the reason is that non local user id's (i.e.
domain accounts) can be allocated email accounts so sql
server can send emails, whereas local userid's cannot.
If you do not want local administrators to have system
admin access rights then all you need to so is restrict
the BUILTIN\Administrators rights.
Peter
"Only two things are infinite, the universe and human
stupidity, and I'm not sure about the former."
Albert Einstein
>--Original Message--
>Currently, our network/server/domain admins have admin
control of our sql
>servers. One manager wants to run sql under a special
local admin account
>to restrict this access, but then we will be effected by
the password change
>requirement, which could break sql every 90 days.
>What is the best way to run sql so that the server admins
don't have sql
>admin access? Can I run it under "local system", and
restrict machine
>admins?
>
>.
>|||First of all, it is imposible to stop God from having access. And, in the
domain, Domain Administrators are God. However, you can slow them down
quite a bit. Here is a KB that details the procedures. Also know that if
you use AD Global Groups to grant the SQL Server DBAs administrative access,
which is a Best Practice, all the Domain Admin has to do is add themself or
the Domain Admins group to yours.
How to impede Windows NT administrators from administering a clustered
instance of SQL Server
http://support.microsoft.com/kb/263712/EN-US/
How to change the SQL Server or SQL Server Agent Service account without
using SQL Enterprise Manager in SQL Server 2000
http://support.microsoft.com/default.aspx?scid=kb;en-us;283811
If you suspect foul play, it would be better to run some sort of Audit
Logging on your system and then once captured, bring it the attention of the
Data Center Director's attention. Keep in mind that just like the DBAs,
with great power comes great responsibility. No one should be placed in a
role that they are not qualified, and responsible for, to perform.
Just like the DBAs have the authority to delete every user/system database,
the responsibility is to preserve that data. It is no different for the
Domain Admins. They have the authority to disrupt operations but the
responsibility to preserve them. If you find an individual, or team, that
does not play by these rules, that must be made know to the Operations
Manager, regardless of the title or the position of the offender.
Sincerely,
Anthony Thomas
"Peter The Spate" <anonymous@.discussions.microsoft.com> wrote in message
news:05b901c51b4e$87a454e0$a501280a@.phx.gbl...
Its not a wise choice to make the User IDs local to the
server, the reason is that non local user id's (i.e.
domain accounts) can be allocated email accounts so sql
server can send emails, whereas local userid's cannot.
If you do not want local administrators to have system
admin access rights then all you need to so is restrict
the BUILTIN\Administrators rights.
Peter
"Only two things are infinite, the universe and human
stupidity, and I'm not sure about the former."
Albert Einstein
>--Original Message--
>Currently, our network/server/domain admins have admin
control of our sql
>servers. One manager wants to run sql under a special
local admin account
>to restrict this access, but then we will be effected by
the password change
>requirement, which could break sql every 90 days.
>What is the best way to run sql so that the server admins
don't have sql
>admin access? Can I run it under "local system", and
restrict machine
>admins?
>
>.
>
Accidentally disable admin login
Hi, I have accidentally disabled the Administrator account in Sql Server 2005 (Douh!) on my clients server (double Dough!) & now I can login to enable it.
The <BuiltIn\Administartors> account is still active, The accout i disabled was <Domain\Administrator> (forgot I was logined via Terminal server).
Any help/assistance would be much appreciate!!
Cheers,
Nez
HI, i was unable to delte this post so may as well put the answer here.
to enable it again i used the SQLCMD.exe in the ".../90/tools/binn" folder
sp_grantlogin etc...
Cheers
Subscribe to:
Posts (Atom)