permissions to run start and stop jobs

Using SS2000 SP4. I have a user who is able to start and stop jobs. The user
only has db_owner permissions in a few databases. Should someone who is in
the db_owner role be able to start and stop jobs or run dts packages?
The user didn't used to be able to even see the jobs so I'm not sure what
changed.
--
Dan D.Normally, a user needs to be a member of sysadmins SQL
server role to start and stop any and all jobs. If not a
sysadmin, the user can only start and stop jobs that they
own.
Who owns the jobs? If the user owns the jobs, they can start
and stop the job. Also, did you verify that the user is
really using their login? Maybe they have EM registered with
a sysadmin login - that wouldn't be too hard to see in
sysprocesses when the user is connected - just check with
the hostname, program_name, loginame.
Another thing to check would be if the user is actually in
the sysamin server role inherited through Windows group
membership. If you left the BUILTIN\Administrators login in
SQL Server set to the default, was the user added to the
local administrators group on the server? That would be one
way...other ways would depend on what Windows groups are in
the syadmin SQL Server role. Then check to see if that user
is a member of any Windows group.
-Sue
On Thu, 7 Sep 2006 07:42:02 -0700, Dan D.
<DanD@.discussions.microsoft.com> wrote:
>Using SS2000 SP4. I have a user who is able to start and stop jobs. The user
>only has db_owner permissions in a few databases. Should someone who is in
>the db_owner role be able to start and stop jobs or run dts packages?
>The user didn't used to be able to even see the jobs so I'm not sure what
>changed.|||BUILTIN\Administrators doesn't exist. Domain\Administrator and Administrator
exist but they do not have any sysadmin type permissions.
I have another domain user setup and is the login for the SQLServer Agent
service and that user owns all jobs.
We checked the administrator groups for the domain and locally and the users
are not in there or part of a group that is in the admin group.
How would the user show up in sysprocesses? I see several entries for 'sa'
but they're all in the master database and background except for one that has
'no database context' and is sleeping. Same for 'system' user.
There is an 'NT Authority\System' login that has sysadmin permisions. Is
there any way a user could use that login?
Thanks for so many choices.:)
--
Dan D.
"Sue Hoegemeier" wrote:
> Normally, a user needs to be a member of sysadmins SQL
> server role to start and stop any and all jobs. If not a
> sysadmin, the user can only start and stop jobs that they
> own.
> Who owns the jobs? If the user owns the jobs, they can start
> and stop the job. Also, did you verify that the user is
> really using their login? Maybe they have EM registered with
> a sysadmin login - that wouldn't be too hard to see in
> sysprocesses when the user is connected - just check with
> the hostname, program_name, loginame.
> Another thing to check would be if the user is actually in
> the sysamin server role inherited through Windows group
> membership. If you left the BUILTIN\Administrators login in
> SQL Server set to the default, was the user added to the
> local administrators group on the server? That would be one
> way...other ways would depend on what Windows groups are in
> the syadmin SQL Server role. Then check to see if that user
> is a member of any Windows group.
> -Sue
> On Thu, 7 Sep 2006 07:42:02 -0700, Dan D.
> <DanD@.discussions.microsoft.com> wrote:
> >Using SS2000 SP4. I have a user who is able to start and stop jobs. The user
> >only has db_owner permissions in a few databases. Should someone who is in
> >the db_owner role be able to start and stop jobs or run dts packages?
> >
> >The user didn't used to be able to even see the jobs so I'm not sure what
> >changed.
>|||Well...the user needs to be connected to see them in
sysprocesses. You'd want to know what PC they use - that
would show up in hostname.
But probably stepping back a bit is a good idea. All the
same things I posted apply but how do you know the user is
executing jobs? Do you know how the user is executing jobs -
such as does the user connect from Enterprise Manager and
just start and stop jobs at will?
-Sue
On Thu, 7 Sep 2006 09:14:02 -0700, Dan D.
<DanD@.discussions.microsoft.com> wrote:
>BUILTIN\Administrators doesn't exist. Domain\Administrator and Administrator
>exist but they do not have any sysadmin type permissions.
>I have another domain user setup and is the login for the SQLServer Agent
>service and that user owns all jobs.
>We checked the administrator groups for the domain and locally and the users
>are not in there or part of a group that is in the admin group.
>How would the user show up in sysprocesses? I see several entries for 'sa'
>but they're all in the master database and background except for one that has
>'no database context' and is sleeping. Same for 'system' user.
>There is an 'NT Authority\System' login that has sysadmin permisions. Is
>there any way a user could use that login?
>Thanks for so many choices.:)|||The user said that he could start a job. And I know that someone stopped a
job the other day. Also, the user said that he could backup the database.
I'll keep an eye on the hostname and see if anyone is logged on as 'sa'. I
also might change the 'sa' password on this server.
Thanks for your suggestions.
--
Dan D.
"Sue Hoegemeier" wrote:
> Well...the user needs to be connected to see them in
> sysprocesses. You'd want to know what PC they use - that
> would show up in hostname.
> But probably stepping back a bit is a good idea. All the
> same things I posted apply but how do you know the user is
> executing jobs? Do you know how the user is executing jobs -
> such as does the user connect from Enterprise Manager and
> just start and stop jobs at will?
> -Sue
> On Thu, 7 Sep 2006 09:14:02 -0700, Dan D.
> <DanD@.discussions.microsoft.com> wrote:
> >BUILTIN\Administrators doesn't exist. Domain\Administrator and Administrator
> >exist but they do not have any sysadmin type permissions.
> >
> >I have another domain user setup and is the login for the SQLServer Agent
> >service and that user owns all jobs.
> >
> >We checked the administrator groups for the domain and locally and the users
> >are not in there or part of a group that is in the admin group.
> >
> >How would the user show up in sysprocesses? I see several entries for 'sa'
> >but they're all in the master database and background except for one that has
> >'no database context' and is sleeping. Same for 'system' user.
> >
> >There is an 'NT Authority\System' login that has sysadmin permisions. Is
> >there any way a user could use that login?
> >
> >Thanks for so many choices.:)
>|||Yup...changing he password in case they got ahold of that is
a good idea. You may also want to run a trace when the user
is at work. Had to do those before. You tend to find other
more interesting activities they do. Often has some
entertainment value if nothing else.
-Sue
On Fri, 8 Sep 2006 11:22:01 -0700, Dan D.
<DanD@.discussions.microsoft.com> wrote:
>The user said that he could start a job. And I know that someone stopped a
>job the other day. Also, the user said that he could backup the database.
>I'll keep an eye on the hostname and see if anyone is logged on as 'sa'. I
>also might change the 'sa' password on this server.
>Thanks for your suggestions.|||A little extra entertainment is good. Thanks.
--
Dan D.
"Sue Hoegemeier" wrote:
> Yup...changing he password in case they got ahold of that is
> a good idea. You may also want to run a trace when the user
> is at work. Had to do those before. You tend to find other
> more interesting activities they do. Often has some
> entertainment value if nothing else.
> -Sue
> On Fri, 8 Sep 2006 11:22:01 -0700, Dan D.
> <DanD@.discussions.microsoft.com> wrote:
> >The user said that he could start a job. And I know that someone stopped a
> >job the other day. Also, the user said that he could backup the database.
> >
> >I'll keep an eye on the hostname and see if anyone is logged on as 'sa'. I
> >also might change the 'sa' password on this server.
> >
> >Thanks for your suggestions.
>