Hi All
Is it possible to grant a user permissons so they are
only able to execute a SQL Job and not have access to
anything else in a database.
Thanks
Hi
Yes, altough not with job, but with stored procecdure.
Andras Jakus MCDBA
"anonymous@.discussions.microsoft.com" wrote:
> Hi All
> Is it possible to grant a user permissons so they are
> only able to execute a SQL Job and not have access to
> anything else in a database.
> Thanks
>
Showing posts with label job. Show all posts
Showing posts with label job. Show all posts
Monday, March 26, 2012
Permissons Question
Labels:
access,
allis,
areonly,
database,
execute,
grant,
job,
microsoft,
mysql,
oracle,
permissons,
server,
sql,
toanything,
user
Tuesday, March 20, 2012
Permissions Issue Not Allowing Job Run
Hi,
I'm having a problem running jobs. I can not get my test
backup job to work. The job history indicates that
Servername\Administrator can't be determined to have
server access. I recently changed from Windows
Authentication to SQL and Windows.
I'm going through the SQL Server 2000 Administration
Training Kit. I believe that the account that should have
been used is Domainname\Administrator. Also, when I setup
my server initially, which is a domain controller, I used
SelfPacedSQL.local rather than SelfPacedSQL.msft as
instructed, because I could get the .msft domain suffix.
I'm new to Active Directory. Please help.You may be running into a problem with Domain local groups.
825042 FIX: SQL Server Jobs That Are Owned by Non-sysadmin Users May Not
Start
http://support.microsoft.com/?id=825042
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
I'm having a problem running jobs. I can not get my test
backup job to work. The job history indicates that
Servername\Administrator can't be determined to have
server access. I recently changed from Windows
Authentication to SQL and Windows.
I'm going through the SQL Server 2000 Administration
Training Kit. I believe that the account that should have
been used is Domainname\Administrator. Also, when I setup
my server initially, which is a domain controller, I used
SelfPacedSQL.local rather than SelfPacedSQL.msft as
instructed, because I could get the .msft domain suffix.
I'm new to Active Directory. Please help.You may be running into a problem with Domain local groups.
825042 FIX: SQL Server Jobs That Are Owned by Non-sysadmin Users May Not
Start
http://support.microsoft.com/?id=825042
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
Labels:
administrator,
allowing,
database,
history,
indicates,
job,
jobs,
microsoft,
mysql,
oracle,
permissions,
run,
running,
server,
sql,
testbackup,
thatservername
Friday, March 9, 2012
Permissions
Hi All
I would like to run a job that checks for any stored procedures without
PUBLIC access and grant them public access. What would be the best way to d
o
this and which tables/sp do i have to use? Thank you in advance.If you are using SQL Server 2005 you can do that easily with only this
command:
grant execute on database::mydb to public
Ben Nevarez, MCDBA, OCP
Database Administrator
"Baldy" wrote:
> Hi All
> I would like to run a job that checks for any stored procedures without
> PUBLIC access and grant them public access. What would be the best way to
do
> this and which tables/sp do i have to use? Thank you in advance.
I would like to run a job that checks for any stored procedures without
PUBLIC access and grant them public access. What would be the best way to d
o
this and which tables/sp do i have to use? Thank you in advance.If you are using SQL Server 2005 you can do that easily with only this
command:
grant execute on database::mydb to public
Ben Nevarez, MCDBA, OCP
Database Administrator
"Baldy" wrote:
> Hi All
> I would like to run a job that checks for any stored procedures without
> PUBLIC access and grant them public access. What would be the best way to
do
> this and which tables/sp do i have to use? Thank you in advance.
Labels:
access,
alli,
checks,
database,
grant,
job,
microsoft,
mysql,
oracle,
permissions,
procedures,
public,
run,
server,
sql,
stored,
withoutpublic
Wednesday, March 7, 2012
Permission to execute a job
I have a stored proc that refreshes data and then does a table swap.
As part of the table swap I need to drop and create a table. This requires
basically dbo permissions.
So I create a job to run my proc and the job runs under the sa accout.
But I need an account that is not sa or dbo to have the the ability to run
this job as needed rather than just having it run when scheduled.
Is it possible to grant permissions to a non-sa/dbo account so that it can
call this job?
IOW, I don't want my non-sa/dbo account to have any special dbo-like
permissions except the ability to execute a table swap within the context of
my stored proc.
How can I best accomplish this?Create a table for your sp to add a row to when it wants to run the job.
Have a scheduled job poll that table and when it sees a new row it starts
your job.
"Dave" wrote:
> I have a stored proc that refreshes data and then does a table swap.
> As part of the table swap I need to drop and create a table. This require
s
> basically dbo permissions.
> So I create a job to run my proc and the job runs under the sa accout.
> But I need an account that is not sa or dbo to have the the ability to run
> this job as needed rather than just having it run when scheduled.
> Is it possible to grant permissions to a non-sa/dbo account so that it can
> call this job?
> IOW, I don't want my non-sa/dbo account to have any special dbo-like
> permissions except the ability to execute a table swap within the context
of
> my stored proc.
> How can I best accomplish this?
>
>
As part of the table swap I need to drop and create a table. This requires
basically dbo permissions.
So I create a job to run my proc and the job runs under the sa accout.
But I need an account that is not sa or dbo to have the the ability to run
this job as needed rather than just having it run when scheduled.
Is it possible to grant permissions to a non-sa/dbo account so that it can
call this job?
IOW, I don't want my non-sa/dbo account to have any special dbo-like
permissions except the ability to execute a table swap within the context of
my stored proc.
How can I best accomplish this?Create a table for your sp to add a row to when it wants to run the job.
Have a scheduled job poll that table and when it sees a new row it starts
your job.
"Dave" wrote:
> I have a stored proc that refreshes data and then does a table swap.
> As part of the table swap I need to drop and create a table. This require
s
> basically dbo permissions.
> So I create a job to run my proc and the job runs under the sa accout.
> But I need an account that is not sa or dbo to have the the ability to run
> this job as needed rather than just having it run when scheduled.
> Is it possible to grant permissions to a non-sa/dbo account so that it can
> call this job?
> IOW, I don't want my non-sa/dbo account to have any special dbo-like
> permissions except the ability to execute a table swap within the context
of
> my stored proc.
> How can I best accomplish this?
>
>
Saturday, February 25, 2012
permission needed to run CmdExec job steps
Hi, Can someone tell me what permissions are needed for logins to be able
to run CmdExec Jobs'
I recently removed everyone from System Admin and have been working through
all kind of issues. I now have some jobs that fail and here is the message
that they fail with>> "Non-SysAdmins have been denied permission to run
CmdExec job steps. The step failed." There are 3 Analysts who create DTS
packages and schedule them to run at various times, so they need to own
their jobs, but what it the minimum permissions they can be provided to be
able to run these type of jobs'
Thank you..How you would go about this depends on the version of SQL
Server - it's different for all versions. Since you mention
DTS I am guessing you are on SQL Server 2000.
On 2000, if a non-sysadmin is going to be running a CmdExec
job, first you need to enable SQL Agent to allow
non-sysadmins to execute CmdExec steps. Right click on SQL
Agent, select properties and then go to the Job System tab.
From here, remove the check which restricts CmdExec and
ActiveX job steps to Sysadmins only.
You will then need to configure the proxy account. The proxy
account is the security context that will be used for the
jobs. You can find information on the proxy account as well
as some of the security issues you are running into in books
online under: xp_sqlagent_proxy_account
-Sue
On Tue, 5 Sep 2006 16:08:48 -0500, "WANNABE" <breichenbach
AT istate DOT com> wrote:
>Hi, Can someone tell me what permissions are needed for logins to be able
>to run CmdExec Jobs'
>I recently removed everyone from System Admin and have been working through
>all kind of issues. I now have some jobs that fail and here is the message
>that they fail with>> "Non-SysAdmins have been denied permission to run
>CmdExec job steps. The step failed." There are 3 Analysts who create DTS
>packages and schedule them to run at various times, so they need to own
>their jobs, but what it the minimum permissions they can be provided to be
>able to run these type of jobs'
>Thank you..
>|||Thanks Sue, You are correct SQL2000 is what I speak of. I believe you have
provided me with all the right stuff. I will read what I can find under
xp_sqlagent_proxy_account.. Thanks again.
=======================================
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:nfvrf2dp55icp6a9r02i0hfdndjp77dr4k@.
4ax.com...
> How you would go about this depends on the version of SQL
> Server - it's different for all versions. Since you mention
> DTS I am guessing you are on SQL Server 2000.
> On 2000, if a non-sysadmin is going to be running a CmdExec
> job, first you need to enable SQL Agent to allow
> non-sysadmins to execute CmdExec steps. Right click on SQL
> Agent, select properties and then go to the Job System tab.
> From here, remove the check which restricts CmdExec and
> ActiveX job steps to Sysadmins only.
> You will then need to configure the proxy account. The proxy
> account is the security context that will be used for the
> jobs. You can find information on the proxy account as well
> as some of the security issues you are running into in books
> online under: xp_sqlagent_proxy_account
> -Sue
> On Tue, 5 Sep 2006 16:08:48 -0500, "WANNABE" <breichenbach
> AT istate DOT com> wrote:
>
>
to run CmdExec Jobs'
I recently removed everyone from System Admin and have been working through
all kind of issues. I now have some jobs that fail and here is the message
that they fail with>> "Non-SysAdmins have been denied permission to run
CmdExec job steps. The step failed." There are 3 Analysts who create DTS
packages and schedule them to run at various times, so they need to own
their jobs, but what it the minimum permissions they can be provided to be
able to run these type of jobs'
Thank you..How you would go about this depends on the version of SQL
Server - it's different for all versions. Since you mention
DTS I am guessing you are on SQL Server 2000.
On 2000, if a non-sysadmin is going to be running a CmdExec
job, first you need to enable SQL Agent to allow
non-sysadmins to execute CmdExec steps. Right click on SQL
Agent, select properties and then go to the Job System tab.
From here, remove the check which restricts CmdExec and
ActiveX job steps to Sysadmins only.
You will then need to configure the proxy account. The proxy
account is the security context that will be used for the
jobs. You can find information on the proxy account as well
as some of the security issues you are running into in books
online under: xp_sqlagent_proxy_account
-Sue
On Tue, 5 Sep 2006 16:08:48 -0500, "WANNABE" <breichenbach
AT istate DOT com> wrote:
>Hi, Can someone tell me what permissions are needed for logins to be able
>to run CmdExec Jobs'
>I recently removed everyone from System Admin and have been working through
>all kind of issues. I now have some jobs that fail and here is the message
>that they fail with>> "Non-SysAdmins have been denied permission to run
>CmdExec job steps. The step failed." There are 3 Analysts who create DTS
>packages and schedule them to run at various times, so they need to own
>their jobs, but what it the minimum permissions they can be provided to be
>able to run these type of jobs'
>Thank you..
>|||Thanks Sue, You are correct SQL2000 is what I speak of. I believe you have
provided me with all the right stuff. I will read what I can find under
xp_sqlagent_proxy_account.. Thanks again.
=======================================
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:nfvrf2dp55icp6a9r02i0hfdndjp77dr4k@.
4ax.com...
> How you would go about this depends on the version of SQL
> Server - it's different for all versions. Since you mention
> DTS I am guessing you are on SQL Server 2000.
> On 2000, if a non-sysadmin is going to be running a CmdExec
> job, first you need to enable SQL Agent to allow
> non-sysadmins to execute CmdExec steps. Right click on SQL
> Agent, select properties and then go to the Job System tab.
> From here, remove the check which restricts CmdExec and
> ActiveX job steps to Sysadmins only.
> You will then need to configure the proxy account. The proxy
> account is the security context that will be used for the
> jobs. You can find information on the proxy account as well
> as some of the security issues you are running into in books
> online under: xp_sqlagent_proxy_account
> -Sue
> On Tue, 5 Sep 2006 16:08:48 -0500, "WANNABE" <breichenbach
> AT istate DOT com> wrote:
>
>
Labels:
ableto,
admin,
cmdexec,
database,
job,
jobs,
logins,
microsoft,
mysql,
oracle,
permission,
permissions,
run,
server,
sql,
steps,
system
Subscribe to:
Posts (Atom)