May 31, 2012 at 9:36 am
Hello, all,
In digging around on one of our servers, I found what appears to be someone logging in as the SQL Server/Agent service account and running jobs. I'm trying to verify that what I'm seeing is true. When I query the jobs tables in msdb, sysjobhistory.message displays this:
The job succeeded. The Job was invoked by User DOMAIN\SVC_ACCT. The last step to run was step 1 (Job Name).
I read somewhere that if a user is in the sysadmin role, the job will be executed as the Agent service account. However, I found another message that mentions a different user. That user is not only in all the SQLAgent roles in msdb, but is also a sysadmin. I also checked for messages for users who are in sysadmin, but not the SQLAgent roles, to see if they appear. My account falls into that category, and I found instances of my username. No proxy accounts are set up. None of the steps I investigated are defined with a Run As user.
My only conclusion is that someone is logging in using this service account and running the jobs. Can anyone out there think of any other reasons I would see the service account appearing in the log? This could be a huge security hole I need to plug as soon as possible.
thanks...
May 31, 2012 at 12:20 pm
that's probably sharepoint service.
May 31, 2012 at 12:24 pm
AlexSQLForums (5/31/2012)
that's probably sharepoint service.
No SharePoint installations at this site.
Apologies - I did not mention that all of the jobs I saw this for are created by the developers. They are not jobs that a SharePoint or some of Quest's tools might create.
May 31, 2012 at 12:28 pm
Scheduled jobs run under the service account for SQL Server Agent.
Jared
CE - Microsoft
May 31, 2012 at 12:33 pm
Do you have any kind of replication setup?
May 31, 2012 at 12:40 pm
SQLKnowItAll (5/31/2012)
Scheduled jobs run under the service account for SQL Server Agent.
True, but these jobs are not scheduled. If they are scheduled, you will see the following in the messages column:
The job succeeded. The Job was invoked by Schedule 24 (SCHED_NAME). The last step to run was step 1 (STEP_NAME).
I think I may have just answered my own question with this. If the only way a username can make it in here is if that user logs in and manually kicks off a job, then I have a big problem. It's rather disturbing to me that someone would be logging in using the service account to run jobs. I need to fix this immediately, if this is the case.
AlexSQLForums (5/31/2012)
Do you have any kind of replication setup?
Nope, no replication.
May 31, 2012 at 12:40 pm
EDIT: I see the difference in the messages now between schedule and what you are displaying.
Jared
CE - Microsoft
May 31, 2012 at 12:53 pm
It could be that a script is being run via task scheduler or some other windows/web application is kicking off the job.
Jared
CE - Microsoft
May 31, 2012 at 1:07 pm
Since it is a domain account, why not just change the password and see who comes complaining to you? Who all needs to know that password? Hopefully only you...
Jared
CE - Microsoft
May 31, 2012 at 1:13 pm
SQLKnowItAll (5/31/2012)
Since it is a domain account, why not just change the password and see who comes complaining to you? Who all needs to know that password? Hopefully only you...
It's the service account for SQL Server and SQL Agent. You can't just change the password on that. It requires SQL Server reboots and coordination with the business for the down time.
May 31, 2012 at 1:15 pm
Create a logon trigger, and capture everything you can -- app_name, host_id, host_name (most people don't bother to fake this) and original_login (just in case).
You could of course then also explicitly reject the logon -- but this way you may get some idea of where it came from first.
SQL DBA,SQL Server MVP(07, 08, 09) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".
May 31, 2012 at 1:18 pm
If you are logging successful logins, you should be able to use the default trace and/or errorlog to track who is logging in and running jobs.
May 31, 2012 at 1:23 pm
pveilleux (5/31/2012)
SQLKnowItAll (5/31/2012)
Since it is a domain account, why not just change the password and see who comes complaining to you? Who all needs to know that password? Hopefully only you...It's the service account for SQL Server and SQL Agent. You can't just change the password on that. It requires SQL Server reboots and coordination with the business for the down time.
Hmm... Not sure that is true. It uses Windows Authentication for the services, so should not require reboot on a password change. The password change will only keep people from logging in.
Jared
CE - Microsoft
May 31, 2012 at 1:25 pm
May 31, 2012 at 1:32 pm
SQLKnowItAll (5/31/2012)
http://beyondrelational.com/modules/2/blogs/77/posts/11360/changing-sql-server-service-account-or-password-avoid-restarting-sql-server.aspx
Good point. I have always done a reboot to be on the safe side. This client has many, many, many processes that move data among multiple servers, write files/logs to shares on different servers....the books may tell me I don't need to reboot, but I'd rather be safe than sorry. Scheduling 15 minutes of downtime is better than having a client chew me out because the Agent can't write to a share.
Viewing 15 posts - 1 through 15 (of 30 total)
You must be logged in to reply to this topic. Login to reply