Re: Rights to execute jobs?
- From: "Chris Wood" <anonymous@xxxxxxxxxxxxx>
- Date: Tue, 14 Aug 2007 16:00:17 -0600
This is a method that we use in our SQL2005 servers so that lower level
users can get admin type jobs going. As Russell mentions you need a step in
your job that performs a RAISERROR with a high enough severity level and
with no logging specified. The alert then fires off your job that runs under
a higher user.
Chris
"Russell Fields" <russellfields@xxxxxxxxxx> wrote in message
news:%23wPjDjq3HHA.4680@xxxxxxxxxxxxxxxxxxxxxxx
Brian,
One way to let users in a DEV environment be able to start jobs is to
trigger them through alerts. But I do not believe you can control who can
raise the alert, so it could be anyone on the server.
You can add an alert something like this:
EXEC msdb.dbo.sp_add_alert @name=N'Start My #1 Job',
@message_id=50101,
@severity=0,
@enabled=1,
@database_name=N'FavoriteDB',
@job_name=N'My #1 Job'
Of course, you need to define the messages (e.g. 50101) in sysmessages and
so forth, but the user only has to do a RAISERROR with the proper message
number, and the alert will start the job. You can put that in a procedure,
or whatever works best for you.
If this is good enough for you, it leaves your job definitions in
development and production just alike. Only, in production you would
probably not define the alerts.
RLF
"Brian Laws" <BrianLaws@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E24E82B3-531F-4FA7-B91B-69783DD7EE7B@xxxxxxxxxxxxxxxx
Yes, SQL2000. In SQL 2005 there are the new roles in the MSDB database
which
will grant rights, but I need something similar in 2000. Since we're
using
Windows Authentication, we can't just have a shared SQL login. I could
create
a new account in common, but then there's no accountability. Plus, the
user
would then have to be the owner of the job, which breaks away from
standards
and makes development different from production.
"Chris Wood" wrote:
Brian,
Are you running SQL2000 or SQL2005? It looks like 2000 because you
mentioned
EM. We, just moving up to SQL2005, have a similar problem and have
created
an SQL login to run jobs. A Windows group cannot own a job and so, as
you
say, cannot create jobs with other owners unless it is a sysadmin. If
running with a created SQL Login seems okay to you I can detail the
permissions that we are giving.
Chris
"Brian Laws" <BrianLaws@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:AA330618-DB8C-48E9-A43B-BCD1C9053EF1@xxxxxxxxxxxxxxxx
Hello!
We're trying to lock down our environments (dev, qa, uat). One
requirement
is that a group needs to not be an admin but still be able to execute
any
job. I've looked and looked, but I haven't yet been able to find a
good
resource for job execution permissions. I know that a job owner can
execute a
job, but our standard is to make all jobs owned by SA. So, can
somebody
outline what permissions are required in order for a non-sysadmin to
run a
job not owned by themselves? Is that possible? It occurs to me that I
may
be
able to do this by making a stored proc to execute a passed-in job
name.
Since procs execute anything inside it (only permissions needed are to
the
proc itself), this may work. I'd like to avoid this, though, and let
them
run
through EM.
Thanks for the help!
.
- References:
- Re: Rights to execute jobs?
- From: Chris Wood
- Re: Rights to execute jobs?
- From: Russell Fields
- Re: Rights to execute jobs?
- Prev by Date: Re: Rights to execute jobs?
- Next by Date: Re: Windows Authentication fails after changing password
- Previous by thread: Re: Rights to execute jobs?
- Next by thread: Re: Rights to execute jobs?
- Index(es):
Relevant Pages
|
Loading