Permissions issue

I have an ASP website that uses SQL Server 2000 as its back end. It is
running successfully on SBS 2003--all on one machine. I am moving over to a
new domain which has the web site on one server and SQL Server 2000 on
another. I have progressed to the point where the web site comes up, but I
get error messages regarding permissions to SELECT, INSERT, etc. I can make
it work by setting the permission levels for each table, but I didn't need
to do that for the SBS setup. As far as I can tell, everything else is
configured the same way. I realize that I'm not giving you much information
at this point, but I'm hoping that this rings a bell of some sort and that
there is something I can do without having to set the permissions for each
table. Any ideas?
Hi
In the SBS world, the user that was connecting to the DB was probably SA or
had dbo role, so no object level permissions would be required.
Now, you need them as probably you have different permission set. The old
way would not have been very secure at all, as a hacker could have free
reign of your DB.
Are you using SQL Security, and what roles does the login have?
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"WC Justice" <wcjhome@.cox-internet.com> wrote in message
news:I8Koe.8490$I_1.2047@.okepread02...
>I have an ASP website that uses SQL Server 2000 as its back end. It is
> running successfully on SBS 2003--all on one machine. I am moving over to
> a
> new domain which has the web site on one server and SQL Server 2000 on
> another. I have progressed to the point where the web site comes up, but
> I
> get error messages regarding permissions to SELECT, INSERT, etc. I can
> make
> it work by setting the permission levels for each table, but I didn't need
> to do that for the SBS setup. As far as I can tell, everything else is
> configured the same way. I realize that I'm not giving you much
> information
> at this point, but I'm hoping that this rings a bell of some sort and that
> there is something I can do without having to set the permissions for each
> table. Any ideas?
>
|||I was using IUSR, with read permission only, and was using the following
connection string:
DSN=RLDP_SQL; UID=IUSR_WCJE05S;PWD=<>;DATABASE=RLDP_SQL;APP=ASPS cript;
TRUSTED_CONNECTION=YES
I have made the necessary changes to the connection string to allow for the
new DSN and ServerName, and it works, except for the permissions issue. If
I have to set the permission levels by table, that's not a problem. I just
wanted to make sure that I wasn't missing anything obvious.
"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:%23fHHIZhaFHA.3712@.TK2MSFTNGP09.phx.gbl...
> Hi
> In the SBS world, the user that was connecting to the DB was probably SA
or[vbcol=seagreen]
> had dbo role, so no object level permissions would be required.
> Now, you need them as probably you have different permission set. The old
> way would not have been very secure at all, as a hacker could have free
> reign of your DB.
> Are you using SQL Security, and what roles does the login have?
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "WC Justice" <wcjhome@.cox-internet.com> wrote in message
> news:I8Koe.8490$I_1.2047@.okepread02...
to[vbcol=seagreen]
but[vbcol=seagreen]
need[vbcol=seagreen]
that[vbcol=seagreen]
each
>
|||I was using IUSR, with read permission only, and was using the following
connection string:
DSN=RLDP_SQL; UID=IUSR_WCJE05S;PWD=<>;DATABASE=RLDP_SQL;APP=ASPS cript;
TRUSTED_CONNECTION=YES
I have made the necessary changes to the connection string to allow for the
new DSN and ServerName, and it works, except for the permissions issue. If
I have to set the permission levels by table, that's not a problem. I just
wanted to make sure that I wasn't missing anything obvious.
Follow-Up: I found that if I make the IUSR a dbo, then it works great. Is
this a mistake from a security standpoint?
"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:%23fHHIZhaFHA.3712@.TK2MSFTNGP09.phx.gbl...
> Hi
> In the SBS world, the user that was connecting to the DB was probably SA
> or had dbo role, so no object level permissions would be required.
> Now, you need them as probably you have different permission set. The old
> way would not have been very secure at all, as a hacker could have free
> reign of your DB.
> Are you using SQL Security, and what roles does the login have?
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "WC Justice" <wcjhome@.cox-internet.com> wrote in message
> news:I8Koe.8490$I_1.2047@.okepread02...
>

Permissions issue

I have an ASP website that uses SQL Server 2000 as its back end. It is
running successfully on SBS 2003--all on one machine. I am moving over to a
new domain which has the web site on one server and SQL Server 2000 on
another. I have progressed to the point where the web site comes up, but I
get error messages regarding permissions to SELECT, INSERT, etc. I can make
it work by setting the permission levels for each table, but I didn't need
to do that for the SBS setup. As far as I can tell, everything else is
configured the same way. I realize that I'm not giving you much information
at this point, but I'm hoping that this rings a bell of some sort and that
there is something I can do without having to set the permissions for each
table. Any ideas?Hi
In the SBS world, the user that was connecting to the DB was probably SA or
had dbo role, so no object level permissions would be required.
Now, you need them as probably you have different permission set. The old
way would not have been very secure at all, as a hacker could have free
reign of your DB.
Are you using SQL Security, and what roles does the login have?
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"WC Justice" <wcjhome@.cox-internet.com> wrote in message
news:I8Koe.8490$I_1.2047@.okepread02...
>I have an ASP website that uses SQL Server 2000 as its back end. It is
> running successfully on SBS 2003--all on one machine. I am moving over to
> a
> new domain which has the web site on one server and SQL Server 2000 on
> another. I have progressed to the point where the web site comes up, but
> I
> get error messages regarding permissions to SELECT, INSERT, etc. I can
> make
> it work by setting the permission levels for each table, but I didn't need
> to do that for the SBS setup. As far as I can tell, everything else is
> configured the same way. I realize that I'm not giving you much
> information
> at this point, but I'm hoping that this rings a bell of some sort and that
> there is something I can do without having to set the permissions for each
> table. Any ideas?
>|||I was using IUSR, with read permission only, and was using the following
connection string:
DSN=RLDP_SQL; UID=IUSR_WCJE05S;PWD=<>;DATABASE=RLDP_SQL;APP=ASPScript;
TRUSTED_CONNECTION=YES
I have made the necessary changes to the connection string to allow for the
new DSN and ServerName, and it works, except for the permissions issue. If
I have to set the permission levels by table, that's not a problem. I just
wanted to make sure that I wasn't missing anything obvious.
"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:%23fHHIZhaFHA.3712@.TK2MSFTNGP09.phx.gbl...
> Hi
> In the SBS world, the user that was connecting to the DB was probably SA
or
> had dbo role, so no object level permissions would be required.
> Now, you need them as probably you have different permission set. The old
> way would not have been very secure at all, as a hacker could have free
> reign of your DB.
> Are you using SQL Security, and what roles does the login have?
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "WC Justice" <wcjhome@.cox-internet.com> wrote in message
> news:I8Koe.8490$I_1.2047@.okepread02...
to[vbcol=seagreen]
but[vbcol=seagreen]
need[vbcol=seagreen]
that[vbcol=seagreen]
each[vbcol=seagreen]
>|||I was using IUSR, with read permission only, and was using the following
connection string:
DSN=RLDP_SQL; UID=IUSR_WCJE05S;PWD=<>;DATABASE=RLDP_SQL;APP=ASPScript;
TRUSTED_CONNECTION=YES
I have made the necessary changes to the connection string to allow for the
new DSN and ServerName, and it works, except for the permissions issue. If
I have to set the permission levels by table, that's not a problem. I just
wanted to make sure that I wasn't missing anything obvious.
Follow-Up: I found that if I make the IUSR a dbo, then it works great. Is
this a mistake from a security standpoint?
"Mike Epprecht (SQL MVP)" <mike@.epprecht.net> wrote in message
news:%23fHHIZhaFHA.3712@.TK2MSFTNGP09.phx.gbl...
> Hi
> In the SBS world, the user that was connecting to the DB was probably SA
> or had dbo role, so no object level permissions would be required.
> Now, you need them as probably you have different permission set. The old
> way would not have been very secure at all, as a hacker could have free
> reign of your DB.
> Are you using SQL Security, and what roles does the login have?
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> IM: mike@.epprecht.net
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
> "WC Justice" <wcjhome@.cox-internet.com> wrote in message
> news:I8Koe.8490$I_1.2047@.okepread02...
>

Permission Error again

I am using an ERP system with SQL Server as the back end. When our user tried to run a function in ERP system, they got the following error:

229,"42000",[Microsoft][ODBC SQL Server Driver][SQL Server]SELECT permission denied on object 'Grant', database 'HEI', owner 'dbo'

I ran "sp_helprotect Grant" to check the permission, it looks okay.

When I used the administrator's User ID to login to the machine and ran the same function in ERP, it works fine.

Anyone knows how to fix it?

The error means that the principal used by your system to connect to SQL Server and SELECT from object [Grant] doesn’t have permission to select on that object.

When you connect as an administrator and try to select from the same object, the system will use your current context (administrator) and allow the call, but most likely (and actually I would recommend against it) your ERP system is not using administrator credentials and it requires explicit permissions in order to execute the SELECT statement.

Can you tell us what was the result of the sp_helprpotect call? It should be similar to this output:

OwnerObjectGranteeGrantor ProtectType ActionColumn

-- -- - -- --

dboGrant<<ERP user>> dboGrantSelect .

As an additional note: choosing an object name that may conflict with SQL Server syntax (such as [Grant]) is not a practice I would personally recommend as it may cause conflicts when parsing the statements (forcing you to always use the quoted [] name form) and making the statements a lot more difficult to read.

I hope this information helps

-Raul Garcia

SDE/T

SQL Server Engine

Permission Denied to object

We recently brought up SQL Server and migrated our Access 2000 back end DB t
o
it. The SQL Server security seemed pretty straight forward to me...I set up
the users and the roles and assigned the roles rights to my tables. The
problem is that my users get a Permission Denied error when ever the Access
2000 front end tries to access any SQL Server table unless I add them to the
System Administrator server role. I've gone over everything and I can't see
m
to figure this out. The only thing I can find that seems strange is that on
that database, my login name is associated with the "dbo" name. I think tha
t
makes me the owner of the db and I'm wondering if that is what is causing my
issue. I'd greatly appreciate any insight on how to get this issue taken
care of.
Thanks in advance!
JimNevermind, I found the answer to my problem in another post. Don't assign
the db_denydatareader or db_denydatawriter role to the user. That cleared u
p
my problem.
"Jim" wrote:

> We recently brought up SQL Server and migrated our Access 2000 back end DB
to
> it. The SQL Server security seemed pretty straight forward to me...I set
up
> the users and the roles and assigned the roles rights to my tables. The
> problem is that my users get a Permission Denied error when ever the Acces
s
> 2000 front end tries to access any SQL Server table unless I add them to t
he
> System Administrator server role. I've gone over everything and I can't s
eem
> to figure this out. The only thing I can find that seems strange is that
on
> that database, my login name is associated with the "dbo" name. I think t
hat
> makes me the owner of the db and I'm wondering if that is what is causing
my
> issue. I'd greatly appreciate any insight on how to get this issue taken
> care of.
> Thanks in advance!
> Jim