Hi Folks - first off, apologies for the cross post but I'm not really sure
which group would be most appropriate for these questions - no offence
intended!
Porting an app from MS Access to VS with C# and SQLServer, I've come across
a few design challenges that are new to me.
Here's what I had before in MSAccess:
==========================
Frontend / Backend, using User/Group security. Security MDW resides on
Server with the Backend.
App (frontend) has a table to allow user to connect to correct backend -
assuming he has necessary permission to do so (based on the form to make the
connection and the .mdw file permissions).
Each of my client installations will usually have multiple users, connecting
to multiple databases (backends), each backend being a separate business
unit for the Client. Some users have access to all Db's and some to only one
or two. When a user logs in to the app - if there is no current backend link
then he is prompted to go to the connect form and browse for the backend
using a common dialog box. The selected backend is then linked to the app
and the current database name (backend) shown in the status bar.
Client DBA's / Network Manager's have access to the backend to copy / paste
/ move etc. They are not expected to manage the database.
One secure table in each backend has a single column with the number of
licenses the Client has purchased for the business unit and the app code
counts down the number of concurrent users from that number and blocks
further connections until there is a license available (the app checks for
activity on each connected frontend every 5 mins - and releases the license
if none).
Using the above structure (backend / frontend, license and .mdw) I can cater
for this format.
Moving to VS & SQLServer:
==========================
It seems this will be tricky now in SQLServer! I have tables and code to
ensure security, so users are limited to specific menu selections.
Challenge is (right now) three fold -
1. Since the app (C#) needs a connection string before it can see any of
these security / set-up tables, then there needs to be a current connection
string in place. On a newly installed app how can that be - the app doesn't
know where the SQLServer is?
2. We really don't want users to have to set config files etc, so initial
start-up and connection to the various business units Db's needs to be
automated / made click and selectable.
3. We really don't want the Client DBA's to have access to the tables in the
Db (backends). Obviously they would be able to set license and user
permissions if they do.
==========================
Trying to understand these challenges, my questions are:
a. Would it be appropriate to have a separate (secure) file to hold the
initial location of the SQLServer, then have a browse to the actual Db in
SQLServer - then have the app build the connection string?
b. Is it possible to browse the Dbs in a SQLServer, from an app, so the user
can select the correct one to connect to?
c. What type of file would be most appropriate for this (SQLExpress /
MSAccess/Encrypted XML etc)?
d. Is it possible to 'Secure' a single table in a SQLServer Db so I could
access it but the Client DBA could not (to hold license info etc)?
e. Is it possible to 'Secure' a single 'Db' in a SQLServer so I could access
it but the Client DBA could not (to hold all the app info and data etc)?
f. If I used SQLExpress as a standalone server (for the entire system or
just for these start-up tables), would that impact tremendously on the
performance of Client network systems if they already had instances of
SQLServer / Express installed for other purposes?
This initial connection (and Db swapping) must be a challenge for others
too - how do you deal with this conundrum in your apps?
Appreciate any feedback.
Kahuna
--Kahuna (none@.gonewest.com) writes:
> a. Would it be appropriate to have a separate (secure) file to hold the
> initial location of the SQLServer, then have a browse to the actual Db in
> SQLServer - then have the app build the connection string?
Don't really know why this would be a secure file. In our application
we prompt the user for the server and database. But there are also
situations when users needs to log into a different server. (Test a
new version, report database etc.) If you want to save the users from
the hassle of selecting a server, you could read this from a config
file. I think that could used be a plain text file.
> b. Is it possible to browse the Dbs in a SQLServer, from an app, so the
> user can select the correct one to connect to?
Once you are connected you can select the available databases in the
server. While "SELECT name FORM sys.databases" is simple, it will list
all databases, even if the user has no access to them. You could
check all databases for access, but with many databases on the server
this could be expensive. An alternative is to have a master application
for the app, where you have a table with user-database connections. But
then you will also will need to find a way to maintain this table
reliably, so it does not goes out of sync with the actual database
permissions.
> d. Is it possible to 'Secure' a single table in a SQLServer Db so I could
> access it but the Client DBA could not (to hold license info etc)?
Depends. If the Client DBA, or someone else at the site have admin
privileges in Windows it gets difficult. You could remove
BUILTIN\Administrators from the server, and keep the sa password to
yourself. But as long as they can access the file, they can always
stop the server, attach it to another instance, fiddle with the
table, detach it again, and the start your instance.
Then again, I can't but see that you must have the same problem with
your Access solution today as well.
> e. Is it possible to 'Secure' a single 'Db' in a SQLServer so I could
> access it but the Client DBA could not (to hold all the app info and
> data etc)?
See above.
I should add that while you cannot technically prevent the client staff
from accessing the database, by removing BUILTIN\Administrators you
can set up signs that says "NO TRESPASSING" making it clear that if
they fiddle with the database, they are violating the license agreement.
Provided that you have this covered in the license agreement, that is.
> f. If I used SQLExpress as a standalone server (for the entire system or
> just for these start-up tables), would that impact tremendously on the
> performance of Client network systems if they already had instances of
> SQLServer / Express installed for other purposes?
Not really sure what your concern is. But if there are other SQL Server
instances on the same machine, and you don't set max server memory for
the instances, the server can compete about memory on the machine,
and thus interfer with each other.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Thanks for the feedback Erland
"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns9A16A6079EECEYazorman@.127.0.0.1...
> Kahuna (none@.gonewest.com) writes:
> Don't really know why this would be a secure file. In our application
> we prompt the user for the server and database. But there are also
> situations when users needs to log into a different server. (Test a
> new version, report database etc.) If you want to save the users from
> the hassle of selecting a server, you could read this from a config
> file. I think that could used be a plain text file.
>
You're right Erland - this woldnt need to be secure - though I guess we'd
need a copy of that file in the same dir as the app (frontend) so it wouldnt
need to find it! But I guess if thats were the case then we'd be as well
creating the entire connection strings in that file and using it to allow
the user to change Db's. Thats would then need to be deployed with the front
end and re-deployed if the Server was moved.
> Once you are connected you can select the available databases in the
> server. While "SELECT name FORM sys.databases" is simple, it will list
> all databases, even if the user has no access to them. You could
> check all databases for access, but with many databases on the server
> this could be expensive. An alternative is to have a master application
> for the app, where you have a table with user-database connections. But
> then you will also will need to find a way to maintain this table
> reliably, so it does not goes out of sync with the actual database
> permissions.
Could use a prefix just on our Db names of course to make it easy to find in
that instance.
> Depends. If the Client DBA, or someone else at the site have admin
> privileges in Windows it gets difficult. You could remove
> BUILTIN\Administrators from the server, and keep the sa password to
> yourself. But as long as they can access the file, they can always
> stop the server, attach it to another instance, fiddle with the
> table, detach it again, and the start your instance.
> Then again, I can't but see that you must have the same problem with
> your Access solution today as well.
No I'm able to remove admin rights to the Access Db's but with a Client
instal of SQLServer - I dont see that he'll be too happy if I were to remove
his rights!!! Or did I miss the poit Erland?
> See above.
> I should add that while you cannot technically prevent the client staff
> from accessing the database, by removing BUILTIN\Administrators you
> can set up signs that says "NO TRESPASSING" making it clear that if
> they fiddle with the database, they are violating the license agreement.
> Provided that you have this covered in the license agreement, that is.
>
> Not really sure what your concern is. But if there are other SQL Server
> instances on the same machine, and you don't set max server memory for
> the instances, the server can compete about memory on the machine,
> and thus interfer with each other.
>
This is looking more and more like I will need to have an instance of a
SQLServer (probably express) installed, that only we can access, and with
only our admin rights - is this possible Erland - can we install a Server
that the Client DBA could not get into?
Even with a config file we need to have a secure table someplace to record
licensed access (concurrent users), so a locked server or file seems like
the only possibility really?
Kahuna
--|||Kahuna (none@.gonewest.com) writes:
> "Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
> news:Xns9A16A6079EECEYazorman@.127.0.0.1...
> Could use a prefix just on our Db names of course to make it easy to
> find in that instance.
I got the impression that different users were permitted in different
databases. If all users have access to all databases, it's a little
easier.
> No I'm able to remove admin rights to the Access Db's but with a Client
> instal of SQLServer - I dont see that he'll be too happy if I were to
> remove his rights!!! Or did I miss the poit Erland?
>...
> This is looking more and more like I will need to have an instance of a
> SQLServer (probably express) installed, that only we can access, and with
> only our admin rights - is this possible Erland - can we install a Server
> that the Client DBA could not get into?
It all boils down to who is the system administrator for the machine.
It's not clear from your posts where the client machines are located
and who administer them. If you are an application provider and
administer the boxes, then you should have no problems in restricting
where you clients may go.
But if the boxes are located at the client sites, and the clients are
responsible for their administration, hardware etc, then there is no
way you can lock them out, be that Access or SQL Server. The only way
you can keep them out is that you agree to be the system administrator
for the machines. (You say above that you remove admin rights for the
Access file. Yes, you can do that. But if the client is the sysadmin
on these boxes, he can add those permissions back at any time.)
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||> It all boils down to who is the system administrator for the machine.
> It's not clear from your posts where the client machines are located
> and who administer them. If you are an application provider and
> administer the boxes, then you should have no problems in restricting
> where you clients may go.
> But if the boxes are located at the client sites, and the clients are
> responsible for their administration, hardware etc, then there is no
> way you can lock them out, be that Access or SQL Server. The only way
> you can keep them out is that you agree to be the system administrator
> for the machines. (You say above that you remove admin rights for the
> Access file. Yes, you can do that. But if the client is the sysadmin
> on these boxes, he can add those permissions back at any time.)
>
Boxes are Client's, at Client's sites.
Using User/Group security, through an .mdw file, I don't believe there is
any way for a sysadmin to gain access without my explicit permissions in an
MSAccess .mdb file Erland!
Kahuna
--
"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns9A16C6DC4F16FYazorman@.127.0.0.1...
> Kahuna (none@.gonewest.com) writes:
> I got the impression that different users were permitted in different
> databases. If all users have access to all databases, it's a little
> easier.
>
> It all boils down to who is the system administrator for the machine.
> It's not clear from your posts where the client machines are located
> and who administer them. If you are an application provider and
> administer the boxes, then you should have no problems in restricting
> where you clients may go.
> But if the boxes are located at the client sites, and the clients are
> responsible for their administration, hardware etc, then there is no
> way you can lock them out, be that Access or SQL Server. The only way
> you can keep them out is that you agree to be the system administrator
> for the machines. (You say above that you remove admin rights for the
> Access file. Yes, you can do that. But if the client is the sysadmin
> on these boxes, he can add those permissions back at any time.)
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/pr...oads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodin...ions/books.mspx
Showing posts with label security. Show all posts
Showing posts with label security. Show all posts
Friday, February 24, 2012
'Crosspost' Structure a New App (SQLServer C# - Security & Db Connecctions)
Hi Folks - first off, apologies for the cross post but I'm not really sure
which group would be most appropriate for these questions - no offence
intended!
Porting an app from MS Access to VS with C# and SQLServer, I've come across
a few design challenges that are new to me.
Here's what I had before in MSAccess:
==========================
Frontend / Backend, using User/Group security. Security MDW resides on
Server with the Backend.
App (frontend) has a table to allow user to connect to correct backend -
assuming he has necessary permission to do so (based on the form to make the
connection and the .mdw file permissions).
Each of my client installations will usually have multiple users, connecting
to multiple databases (backends), each backend being a separate business
unit for the Client. Some users have access to all Db's and some to only one
or two. When a user logs in to the app - if there is no current backend link
then he is prompted to go to the connect form and browse for the backend
using a common dialog box. The selected backend is then linked to the app
and the current database name (backend) shown in the status bar.
Client DBA's / Network Manager's have access to the backend to copy / paste
/ move etc. They are not expected to manage the database.
One secure table in each backend has a single column with the number of
licenses the Client has purchased for the business unit and the app code
counts down the number of concurrent users from that number and blocks
further connections until there is a license available (the app checks for
activity on each connected frontend every 5 mins - and releases the license
if none).
Using the above structure (backend / frontend, license and .mdw) I can cater
for this format.
Moving to VS & SQLServer:
==========================
It seems this will be tricky now in SQLServer! I have tables and code to
ensure security, so users are limited to specific menu selections.
Challenge is (right now) three fold -
1. Since the app (C#) needs a connection string before it can see any of
these security / set-up tables, then there needs to be a current connection
string in place. On a newly installed app how can that be - the app doesn't
know where the SQLServer is?
2. We really don't want users to have to set config files etc, so initial
start-up and connection to the various business units Db's needs to be
automated / made click and selectable.
3. We really don't want the Client DBA's to have access to the tables in the
Db (backends). Obviously they would be able to set license and user
permissions if they do.
==========================
Trying to understand these challenges, my questions are:
a. Would it be appropriate to have a separate (secure) file to hold the
initial location of the SQLServer, then have a browse to the actual Db in
SQLServer - then have the app build the connection string?
b. Is it possible to browse the Dbs in a SQLServer, from an app, so the user
can select the correct one to connect to?
c. What type of file would be most appropriate for this (SQLExpress /
MSAccess/Encrypted XML etc)?
d. Is it possible to 'Secure' a single table in a SQLServer Db so I could
access it but the Client DBA could not (to hold license info etc)?
e. Is it possible to 'Secure' a single 'Db' in a SQLServer so I could access
it but the Client DBA could not (to hold all the app info and data etc)?
f. If I used SQLExpress as a standalone server (for the entire system or
just for these start-up tables), would that impact tremendously on the
performance of Client network systems if they already had instances of
SQLServer / Express installed for other purposes?
This initial connection (and Db swapping) must be a challenge for others
too - how do you deal with this conundrum in your apps?
Appreciate any feedback.
Kahuna
Kahuna (none@.gonewest.com) writes:
> a. Would it be appropriate to have a separate (secure) file to hold the
> initial location of the SQLServer, then have a browse to the actual Db in
> SQLServer - then have the app build the connection string?
Don't really know why this would be a secure file. In our application
we prompt the user for the server and database. But there are also
situations when users needs to log into a different server. (Test a
new version, report database etc.) If you want to save the users from
the hassle of selecting a server, you could read this from a config
file. I think that could used be a plain text file.
> b. Is it possible to browse the Dbs in a SQLServer, from an app, so the
> user can select the correct one to connect to?
Once you are connected you can select the available databases in the
server. While "SELECT name FORM sys.databases" is simple, it will list
all databases, even if the user has no access to them. You could
check all databases for access, but with many databases on the server
this could be expensive. An alternative is to have a master application
for the app, where you have a table with user-database connections. But
then you will also will need to find a way to maintain this table
reliably, so it does not goes out of sync with the actual database
permissions.
> d. Is it possible to 'Secure' a single table in a SQLServer Db so I could
> access it but the Client DBA could not (to hold license info etc)?
Depends. If the Client DBA, or someone else at the site have admin
privileges in Windows it gets difficult. You could remove
BUILTIN\Administrators from the server, and keep the sa password to
yourself. But as long as they can access the file, they can always
stop the server, attach it to another instance, fiddle with the
table, detach it again, and the start your instance.
Then again, I can't but see that you must have the same problem with
your Access solution today as well.
> e. Is it possible to 'Secure' a single 'Db' in a SQLServer so I could
> access it but the Client DBA could not (to hold all the app info and
> data etc)?
See above.
I should add that while you cannot technically prevent the client staff
from accessing the database, by removing BUILTIN\Administrators you
can set up signs that says "NO TRESPASSING" making it clear that if
they fiddle with the database, they are violating the license agreement.
Provided that you have this covered in the license agreement, that is.
> f. If I used SQLExpress as a standalone server (for the entire system or
> just for these start-up tables), would that impact tremendously on the
> performance of Client network systems if they already had instances of
> SQLServer / Express installed for other purposes?
Not really sure what your concern is. But if there are other SQL Server
instances on the same machine, and you don't set max server memory for
the instances, the server can compete about memory on the machine,
and thus interfer with each other.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
|||Thanks for the feedback Erland
"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns9A16A6079EECEYazorman@.127.0.0.1...
> Kahuna (none@.gonewest.com) writes:
> Don't really know why this would be a secure file. In our application
> we prompt the user for the server and database. But there are also
> situations when users needs to log into a different server. (Test a
> new version, report database etc.) If you want to save the users from
> the hassle of selecting a server, you could read this from a config
> file. I think that could used be a plain text file.
>
You're right Erland - this woldnt need to be secure - though I guess we'd
need a copy of that file in the same dir as the app (frontend) so it wouldnt
need to find it! But I guess if thats were the case then we'd be as well
creating the entire connection strings in that file and using it to allow
the user to change Db's. Thats would then need to be deployed with the front
end and re-deployed if the Server was moved.
> Once you are connected you can select the available databases in the
> server. While "SELECT name FORM sys.databases" is simple, it will list
> all databases, even if the user has no access to them. You could
> check all databases for access, but with many databases on the server
> this could be expensive. An alternative is to have a master application
> for the app, where you have a table with user-database connections. But
> then you will also will need to find a way to maintain this table
> reliably, so it does not goes out of sync with the actual database
> permissions.
Could use a prefix just on our Db names of course to make it easy to find in
that instance.
> Depends. If the Client DBA, or someone else at the site have admin
> privileges in Windows it gets difficult. You could remove
> BUILTIN\Administrators from the server, and keep the sa password to
> yourself. But as long as they can access the file, they can always
> stop the server, attach it to another instance, fiddle with the
> table, detach it again, and the start your instance.
> Then again, I can't but see that you must have the same problem with
> your Access solution today as well.
No I'm able to remove admin rights to the Access Db's but with a Client
instal of SQLServer - I dont see that he'll be too happy if I were to remove
his rights!!! Or did I miss the poit Erland?
> See above.
> I should add that while you cannot technically prevent the client staff
> from accessing the database, by removing BUILTIN\Administrators you
> can set up signs that says "NO TRESPASSING" making it clear that if
> they fiddle with the database, they are violating the license agreement.
> Provided that you have this covered in the license agreement, that is.
>
> Not really sure what your concern is. But if there are other SQL Server
> instances on the same machine, and you don't set max server memory for
> the instances, the server can compete about memory on the machine,
> and thus interfer with each other.
>
This is looking more and more like I will need to have an instance of a
SQLServer (probably express) installed, that only we can access, and with
only our admin rights - is this possible Erland - can we install a Server
that the Client DBA could not get into?
Even with a config file we need to have a secure table someplace to record
licensed access (concurrent users), so a locked server or file seems like
the only possibility really?
Kahuna
|||Kahuna (none@.gonewest.com) writes:
> "Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
> news:Xns9A16A6079EECEYazorman@.127.0.0.1...
> Could use a prefix just on our Db names of course to make it easy to
> find in that instance.
I got the impression that different users were permitted in different
databases. If all users have access to all databases, it's a little
easier.
> No I'm able to remove admin rights to the Access Db's but with a Client
> instal of SQLServer - I dont see that he'll be too happy if I were to
> remove his rights!!! Or did I miss the poit Erland?
>...
> This is looking more and more like I will need to have an instance of a
> SQLServer (probably express) installed, that only we can access, and with
> only our admin rights - is this possible Erland - can we install a Server
> that the Client DBA could not get into?
It all boils down to who is the system administrator for the machine.
It's not clear from your posts where the client machines are located
and who administer them. If you are an application provider and
administer the boxes, then you should have no problems in restricting
where you clients may go.
But if the boxes are located at the client sites, and the clients are
responsible for their administration, hardware etc, then there is no
way you can lock them out, be that Access or SQL Server. The only way
you can keep them out is that you agree to be the system administrator
for the machines. (You say above that you remove admin rights for the
Access file. Yes, you can do that. But if the client is the sysadmin
on these boxes, he can add those permissions back at any time.)
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
|||> It all boils down to who is the system administrator for the machine.
> It's not clear from your posts where the client machines are located
> and who administer them. If you are an application provider and
> administer the boxes, then you should have no problems in restricting
> where you clients may go.
> But if the boxes are located at the client sites, and the clients are
> responsible for their administration, hardware etc, then there is no
> way you can lock them out, be that Access or SQL Server. The only way
> you can keep them out is that you agree to be the system administrator
> for the machines. (You say above that you remove admin rights for the
> Access file. Yes, you can do that. But if the client is the sysadmin
> on these boxes, he can add those permissions back at any time.)
>
Boxes are Client's, at Client's sites.
Using User/Group security, through an .mdw file, I don't believe there is
any way for a sysadmin to gain access without my explicit permissions in an
MSAccess .mdb file Erland!
Kahuna
"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns9A16C6DC4F16FYazorman@.127.0.0.1...
> Kahuna (none@.gonewest.com) writes:
> I got the impression that different users were permitted in different
> databases. If all users have access to all databases, it's a little
> easier.
>
> It all boils down to who is the system administrator for the machine.
> It's not clear from your posts where the client machines are located
> and who administer them. If you are an application provider and
> administer the boxes, then you should have no problems in restricting
> where you clients may go.
> But if the boxes are located at the client sites, and the clients are
> responsible for their administration, hardware etc, then there is no
> way you can lock them out, be that Access or SQL Server. The only way
> you can keep them out is that you agree to be the system administrator
> for the machines. (You say above that you remove admin rights for the
> Access file. Yes, you can do that. But if the client is the sysadmin
> on these boxes, he can add those permissions back at any time.)
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
which group would be most appropriate for these questions - no offence
intended!
Porting an app from MS Access to VS with C# and SQLServer, I've come across
a few design challenges that are new to me.
Here's what I had before in MSAccess:
==========================
Frontend / Backend, using User/Group security. Security MDW resides on
Server with the Backend.
App (frontend) has a table to allow user to connect to correct backend -
assuming he has necessary permission to do so (based on the form to make the
connection and the .mdw file permissions).
Each of my client installations will usually have multiple users, connecting
to multiple databases (backends), each backend being a separate business
unit for the Client. Some users have access to all Db's and some to only one
or two. When a user logs in to the app - if there is no current backend link
then he is prompted to go to the connect form and browse for the backend
using a common dialog box. The selected backend is then linked to the app
and the current database name (backend) shown in the status bar.
Client DBA's / Network Manager's have access to the backend to copy / paste
/ move etc. They are not expected to manage the database.
One secure table in each backend has a single column with the number of
licenses the Client has purchased for the business unit and the app code
counts down the number of concurrent users from that number and blocks
further connections until there is a license available (the app checks for
activity on each connected frontend every 5 mins - and releases the license
if none).
Using the above structure (backend / frontend, license and .mdw) I can cater
for this format.
Moving to VS & SQLServer:
==========================
It seems this will be tricky now in SQLServer! I have tables and code to
ensure security, so users are limited to specific menu selections.
Challenge is (right now) three fold -
1. Since the app (C#) needs a connection string before it can see any of
these security / set-up tables, then there needs to be a current connection
string in place. On a newly installed app how can that be - the app doesn't
know where the SQLServer is?
2. We really don't want users to have to set config files etc, so initial
start-up and connection to the various business units Db's needs to be
automated / made click and selectable.
3. We really don't want the Client DBA's to have access to the tables in the
Db (backends). Obviously they would be able to set license and user
permissions if they do.
==========================
Trying to understand these challenges, my questions are:
a. Would it be appropriate to have a separate (secure) file to hold the
initial location of the SQLServer, then have a browse to the actual Db in
SQLServer - then have the app build the connection string?
b. Is it possible to browse the Dbs in a SQLServer, from an app, so the user
can select the correct one to connect to?
c. What type of file would be most appropriate for this (SQLExpress /
MSAccess/Encrypted XML etc)?
d. Is it possible to 'Secure' a single table in a SQLServer Db so I could
access it but the Client DBA could not (to hold license info etc)?
e. Is it possible to 'Secure' a single 'Db' in a SQLServer so I could access
it but the Client DBA could not (to hold all the app info and data etc)?
f. If I used SQLExpress as a standalone server (for the entire system or
just for these start-up tables), would that impact tremendously on the
performance of Client network systems if they already had instances of
SQLServer / Express installed for other purposes?
This initial connection (and Db swapping) must be a challenge for others
too - how do you deal with this conundrum in your apps?
Appreciate any feedback.
Kahuna
Kahuna (none@.gonewest.com) writes:
> a. Would it be appropriate to have a separate (secure) file to hold the
> initial location of the SQLServer, then have a browse to the actual Db in
> SQLServer - then have the app build the connection string?
Don't really know why this would be a secure file. In our application
we prompt the user for the server and database. But there are also
situations when users needs to log into a different server. (Test a
new version, report database etc.) If you want to save the users from
the hassle of selecting a server, you could read this from a config
file. I think that could used be a plain text file.
> b. Is it possible to browse the Dbs in a SQLServer, from an app, so the
> user can select the correct one to connect to?
Once you are connected you can select the available databases in the
server. While "SELECT name FORM sys.databases" is simple, it will list
all databases, even if the user has no access to them. You could
check all databases for access, but with many databases on the server
this could be expensive. An alternative is to have a master application
for the app, where you have a table with user-database connections. But
then you will also will need to find a way to maintain this table
reliably, so it does not goes out of sync with the actual database
permissions.
> d. Is it possible to 'Secure' a single table in a SQLServer Db so I could
> access it but the Client DBA could not (to hold license info etc)?
Depends. If the Client DBA, or someone else at the site have admin
privileges in Windows it gets difficult. You could remove
BUILTIN\Administrators from the server, and keep the sa password to
yourself. But as long as they can access the file, they can always
stop the server, attach it to another instance, fiddle with the
table, detach it again, and the start your instance.
Then again, I can't but see that you must have the same problem with
your Access solution today as well.
> e. Is it possible to 'Secure' a single 'Db' in a SQLServer so I could
> access it but the Client DBA could not (to hold all the app info and
> data etc)?
See above.
I should add that while you cannot technically prevent the client staff
from accessing the database, by removing BUILTIN\Administrators you
can set up signs that says "NO TRESPASSING" making it clear that if
they fiddle with the database, they are violating the license agreement.
Provided that you have this covered in the license agreement, that is.
> f. If I used SQLExpress as a standalone server (for the entire system or
> just for these start-up tables), would that impact tremendously on the
> performance of Client network systems if they already had instances of
> SQLServer / Express installed for other purposes?
Not really sure what your concern is. But if there are other SQL Server
instances on the same machine, and you don't set max server memory for
the instances, the server can compete about memory on the machine,
and thus interfer with each other.
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
|||Thanks for the feedback Erland
"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns9A16A6079EECEYazorman@.127.0.0.1...
> Kahuna (none@.gonewest.com) writes:
> Don't really know why this would be a secure file. In our application
> we prompt the user for the server and database. But there are also
> situations when users needs to log into a different server. (Test a
> new version, report database etc.) If you want to save the users from
> the hassle of selecting a server, you could read this from a config
> file. I think that could used be a plain text file.
>
You're right Erland - this woldnt need to be secure - though I guess we'd
need a copy of that file in the same dir as the app (frontend) so it wouldnt
need to find it! But I guess if thats were the case then we'd be as well
creating the entire connection strings in that file and using it to allow
the user to change Db's. Thats would then need to be deployed with the front
end and re-deployed if the Server was moved.
> Once you are connected you can select the available databases in the
> server. While "SELECT name FORM sys.databases" is simple, it will list
> all databases, even if the user has no access to them. You could
> check all databases for access, but with many databases on the server
> this could be expensive. An alternative is to have a master application
> for the app, where you have a table with user-database connections. But
> then you will also will need to find a way to maintain this table
> reliably, so it does not goes out of sync with the actual database
> permissions.
Could use a prefix just on our Db names of course to make it easy to find in
that instance.
> Depends. If the Client DBA, or someone else at the site have admin
> privileges in Windows it gets difficult. You could remove
> BUILTIN\Administrators from the server, and keep the sa password to
> yourself. But as long as they can access the file, they can always
> stop the server, attach it to another instance, fiddle with the
> table, detach it again, and the start your instance.
> Then again, I can't but see that you must have the same problem with
> your Access solution today as well.
No I'm able to remove admin rights to the Access Db's but with a Client
instal of SQLServer - I dont see that he'll be too happy if I were to remove
his rights!!! Or did I miss the poit Erland?
> See above.
> I should add that while you cannot technically prevent the client staff
> from accessing the database, by removing BUILTIN\Administrators you
> can set up signs that says "NO TRESPASSING" making it clear that if
> they fiddle with the database, they are violating the license agreement.
> Provided that you have this covered in the license agreement, that is.
>
> Not really sure what your concern is. But if there are other SQL Server
> instances on the same machine, and you don't set max server memory for
> the instances, the server can compete about memory on the machine,
> and thus interfer with each other.
>
This is looking more and more like I will need to have an instance of a
SQLServer (probably express) installed, that only we can access, and with
only our admin rights - is this possible Erland - can we install a Server
that the Client DBA could not get into?
Even with a config file we need to have a secure table someplace to record
licensed access (concurrent users), so a locked server or file seems like
the only possibility really?
Kahuna
|||Kahuna (none@.gonewest.com) writes:
> "Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
> news:Xns9A16A6079EECEYazorman@.127.0.0.1...
> Could use a prefix just on our Db names of course to make it easy to
> find in that instance.
I got the impression that different users were permitted in different
databases. If all users have access to all databases, it's a little
easier.
> No I'm able to remove admin rights to the Access Db's but with a Client
> instal of SQLServer - I dont see that he'll be too happy if I were to
> remove his rights!!! Or did I miss the poit Erland?
>...
> This is looking more and more like I will need to have an instance of a
> SQLServer (probably express) installed, that only we can access, and with
> only our admin rights - is this possible Erland - can we install a Server
> that the Client DBA could not get into?
It all boils down to who is the system administrator for the machine.
It's not clear from your posts where the client machines are located
and who administer them. If you are an application provider and
administer the boxes, then you should have no problems in restricting
where you clients may go.
But if the boxes are located at the client sites, and the clients are
responsible for their administration, hardware etc, then there is no
way you can lock them out, be that Access or SQL Server. The only way
you can keep them out is that you agree to be the system administrator
for the machines. (You say above that you remove admin rights for the
Access file. Yes, you can do that. But if the client is the sysadmin
on these boxes, he can add those permissions back at any time.)
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
|||> It all boils down to who is the system administrator for the machine.
> It's not clear from your posts where the client machines are located
> and who administer them. If you are an application provider and
> administer the boxes, then you should have no problems in restricting
> where you clients may go.
> But if the boxes are located at the client sites, and the clients are
> responsible for their administration, hardware etc, then there is no
> way you can lock them out, be that Access or SQL Server. The only way
> you can keep them out is that you agree to be the system administrator
> for the machines. (You say above that you remove admin rights for the
> Access file. Yes, you can do that. But if the client is the sysadmin
> on these boxes, he can add those permissions back at any time.)
>
Boxes are Client's, at Client's sites.
Using User/Group security, through an .mdw file, I don't believe there is
any way for a sysadmin to gain access without my explicit permissions in an
MSAccess .mdb file Erland!
Kahuna
"Erland Sommarskog" <esquel@.sommarskog.se> wrote in message
news:Xns9A16C6DC4F16FYazorman@.127.0.0.1...
> Kahuna (none@.gonewest.com) writes:
> I got the impression that different users were permitted in different
> databases. If all users have access to all databases, it's a little
> easier.
>
> It all boils down to who is the system administrator for the machine.
> It's not clear from your posts where the client machines are located
> and who administer them. If you are an application provider and
> administer the boxes, then you should have no problems in restricting
> where you clients may go.
> But if the boxes are located at the client sites, and the clients are
> responsible for their administration, hardware etc, then there is no
> way you can lock them out, be that Access or SQL Server. The only way
> you can keep them out is that you agree to be the system administrator
> for the machines. (You say above that you remove admin rights for the
> Access file. Yes, you can do that. But if the client is the sysadmin
> on these boxes, he can add those permissions back at any time.)
>
> --
> Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
> Books Online for SQL Server 2005 at
> http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
> Books Online for SQL Server 2000 at
> http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
Cross-dimension Security Dilemma
Here are my simplified security requirements:
1. The cube has a Customer dimension (some 150,000 members) and Account dimension (over 1 mil members). A customer can have one or more accounts.
2. Complex security rules in the operational database dictate which customers the user can view based on her identity and application role membership. Therefore, I need to implement dynamic security to retrieve the allowed set of the customer members from the source database.
3. Instead of retrieving the allowed members for the other dimensions, I would like to propagate the security filter of the Customer dimension, e.g. to the Account dimension, so the user could only see the accounts of the allowed customers.
What’s the recommended approach to implement this? I tried EXISTS on the Account dimension but I still get all accounts.
EXISTS ([Customer].[Customer].[Customer].Members,
[Account].[ Account].[ Account].Members, 'Accounts')
However, if I use this expression in an MDX query, I get indeed the allowed accounts only. It seems like the security filter is applied before the Customer allowed set filter is constructed.
When expressions for dimension security are evaluated, they are evaluated in the context which doesn't have any restrictions. There is a very detailed blog which describes every step during cube initialization, including the context for dimension security - http://sqljunkies.com/WebLog/mosha/archive/2005/12/31/cube_init.aspx
You will have to do Exists with the allowed set of Accounts - sorry that's your only option here.
|||So sad to hear this. Essentially, with dynamic security this wil require several calls to security layer to get the allowed set filter. It could have been nice if there was [Hierarchy].AllowedMembers/[Hierarchy].DeniedMembers to address such scenarios. Even better, it could have been nice if there was an option to apply a global allowed set filter (similar to setting a filter in the cube browser) which will slice the cube across all dimensions.|||I think you should log this suggestion on connect. In the meantime, you may need to implement some caching inside your sprocs if perf of multiple calls becomes a problem.Thursday, February 16, 2012
Cross Server Communication Issue
We are having a problem getting the security to properly authenticate
cross-server logins where the user is logged in using windows
authentication. We are currently running SQL Server on a W2K3 cluster in a
W2K3 domain. There are actually four servers, two physical, the cluster
virtual server, and the SQL virtual server. We'll call them SQL1P
(primary), SQL1F (failover), SQL (cluster virtual server), and SQLV(SQL
virtual server). All servers have been set up for delegation in AD for
kerberos, and the sql service account has all of the proper permissions.
The problem now is that cross server communication with the other SQL
servers (not in the cluster) will work using standard SQL accounts, but not
using windows authentication. Has anyone else had this problem and if so
how did you resolve it? Thanks in advance for your answers.
What error are you getting when you try to connect?
Rand
This posting is provided "as is" with no warranties and confers no rights.
|||This is the query that is being run:
select * from odewhsevprod.master.dbo.sysdatabases
Here is the error we are receiving:
Server: Msg 18452, Level 14, State 1, Line 1 Login failed for user '(null)'.
Reason: Not associated with a trusted SQL Server connection.
"Rand Boyd [MSFT]" <rboyd@.onlinemicrosoft.com> wrote in message
news:4H#0BElTEHA.3328@.cpmsftngxa10.phx.gbl...
> What error are you getting when you try to connect?
> Rand
> This posting is provided "as is" with no warranties and confers no rights.
>
|||We fixed the issue. We basically went in and reset the SPN's on the server
names and the sqlservice account as well as the mscs account, and now it
works fine.
"-DB" <server.team@.ode.state.or.us> wrote in message
news:eMYaAFjTEHA.2944@.tk2msftngp13.phx.gbl...
> We are having a problem getting the security to properly authenticate
> cross-server logins where the user is logged in using windows
> authentication. We are currently running SQL Server on a W2K3 cluster in
a
> W2K3 domain. There are actually four servers, two physical, the cluster
> virtual server, and the SQL virtual server. We'll call them SQL1P
> (primary), SQL1F (failover), SQL (cluster virtual server), and SQLV(SQL
> virtual server). All servers have been set up for delegation in AD for
> kerberos, and the sql service account has all of the proper permissions.
> The problem now is that cross server communication with the other SQL
> servers (not in the cluster) will work using standard SQL accounts, but
not
> using windows authentication. Has anyone else had this problem and if so
> how did you resolve it? Thanks in advance for your answers.
>
cross-server logins where the user is logged in using windows
authentication. We are currently running SQL Server on a W2K3 cluster in a
W2K3 domain. There are actually four servers, two physical, the cluster
virtual server, and the SQL virtual server. We'll call them SQL1P
(primary), SQL1F (failover), SQL (cluster virtual server), and SQLV(SQL
virtual server). All servers have been set up for delegation in AD for
kerberos, and the sql service account has all of the proper permissions.
The problem now is that cross server communication with the other SQL
servers (not in the cluster) will work using standard SQL accounts, but not
using windows authentication. Has anyone else had this problem and if so
how did you resolve it? Thanks in advance for your answers.
What error are you getting when you try to connect?
Rand
This posting is provided "as is" with no warranties and confers no rights.
|||This is the query that is being run:
select * from odewhsevprod.master.dbo.sysdatabases
Here is the error we are receiving:
Server: Msg 18452, Level 14, State 1, Line 1 Login failed for user '(null)'.
Reason: Not associated with a trusted SQL Server connection.
"Rand Boyd [MSFT]" <rboyd@.onlinemicrosoft.com> wrote in message
news:4H#0BElTEHA.3328@.cpmsftngxa10.phx.gbl...
> What error are you getting when you try to connect?
> Rand
> This posting is provided "as is" with no warranties and confers no rights.
>
|||We fixed the issue. We basically went in and reset the SPN's on the server
names and the sqlservice account as well as the mscs account, and now it
works fine.
"-DB" <server.team@.ode.state.or.us> wrote in message
news:eMYaAFjTEHA.2944@.tk2msftngp13.phx.gbl...
> We are having a problem getting the security to properly authenticate
> cross-server logins where the user is logged in using windows
> authentication. We are currently running SQL Server on a W2K3 cluster in
a
> W2K3 domain. There are actually four servers, two physical, the cluster
> virtual server, and the SQL virtual server. We'll call them SQL1P
> (primary), SQL1F (failover), SQL (cluster virtual server), and SQLV(SQL
> virtual server). All servers have been set up for delegation in AD for
> kerberos, and the sql service account has all of the proper permissions.
> The problem now is that cross server communication with the other SQL
> servers (not in the cluster) will work using standard SQL accounts, but
not
> using windows authentication. Has anyone else had this problem and if so
> how did you resolve it? Thanks in advance for your answers.
>
Tuesday, February 14, 2012
Cross dimension security filtering
If i have for example dimensions like Country and City (both containing a huge list). If i don't set a hierarchy for this and i create a report and i filter on Country and my second filter is City than i will get ALL city's listed instead of only the city's in the Country i've selected in my first filter.
We can easily fix this by making a hierarchy.
But my problem is now that my cube contains 15 dimensions and i want them all to filter each other in the dimension list in my reports. I cannot build one hierarchy that covers everything. Isn't there an alternative way to make dimensions filter each other as parameters ?
I've researched this for a while now and i'm starting to think there is no other way which is a huge sitback for analysis services as now people who only have access to the country Netherland can see all SalesRepresentatives from all over the world. I would have to add a hierarchy to filter them out but its not that easy. Certain SalesReps are in multiple country's and versa vi. This is only one of my problem dimensions i have alot of them like this. There should be a way that they automaticly filter each other without hierarchy building. But that is impossible right ?
Take a look at the NON EMPTY keyword. I think you'll find what you are looking for there.
There is also a NONEMPTY function. (Note the lack of a space between the two words.) That function, the EXISTS function, and the EXISTING keyword have behaviors you might also find helpful in different scenarios.
Good luck,
Bryan
Cross DB dialog security issues. Was: Can't Route to another LOCAL Broker Instance
Hi Remus,
I am experiencing the same problem, and I can't get the easy fix to work. I drop and create the DB's in between tests, so it is not related to having an old certificate in the DB, as in the case of Tilfried.
The situation is as follows:
DB1 owned by login1, has a user for login2; this DB is for the initiator
DB2 owned by login2, has a user for login1; this DB hosts the target
Both DB's have TRUSTWORTHY flag set to ON
Error in sys.transmission_queue: 'Error 916, State 3: The server principal "Login1" is not able to access the database "DB2" under the current security context.
Going on a limp, I decide to add a remote service binding in DB1, binding the user for Login2 to the target service, even though BOL explicitly states that this is only required for cross-server communications. This does change the situation - I still get an error, but a new message is sys.transmission_queue: "Dialog security is unavailable for this covnersation because there is no certificate bound to the database principal (Id: 5). Either create a certificate for the principal, or specify ENCRYPTION = OFF when beginning the conversation." I already know that the first option works, but I wanted to get the simple solution running. As for the second option, I doublechecked and the initiating procedure DOES already specify ENCRYPTION = OFF in the BEGIN DIALOG CONVERSATION command. My theory is that the remote service binding somehow forces SB to use encryption, but (a) that is not stated in the error message, and (b) if so, then how to get the messages sent over to the target service without using the binding?
==> EDIT: Just saw that you confirmed this theory in your last reply to Tlifried. So I am indeed back to having to find out how to get this to work without remote service binding - it should be possible, but how?
BTW, SELECT @.@.VERSION shows that I'm on build 3054, in case it matters.
Between all the errors in BOL and less than helpfull error messages produced by SB, I feel like I'm slowly losing my sanity. Please help!
Best regards,
Hugo Kornelis
Hi Remus (or whoever is listening),
Just to make sure that I'm not looking in the wrong corner, I decided to make sure that the absence of certificates is the ONLY reason that the services won't talk to each other. So I made certificates for the dbo owner in each of the DBs, dumped them to file and used those files to create certificates for the corresponding users in the other DBs.
After setting up certificates like that, I still got the same error (Error 916, State 3) - but once I added a remote service binding, my dialog ran without further problems.
I still don't understand why a remote service binding is required even though BOL says (quote from the CREATE REMOTE SERVICE BINDING page): "A remote service binding is only necessary for initiating services that communicate with target services outside of the SQL Server instance." - but at least I am now certain that my problems with the version without certificates and with the trustworthy option set on are not related to any other errors in my setup.
Best, Hugo
|||On the interaction between ENCRYPTION = ON/OFF and the presence/absence of a remote service binding see http://blogs.msdn.com/remusrusanu/archive/2006/07/07/659319.aspx. When a RSB is present, the login mapping between databases is discarded in favour of certificates. This is intentional, as a way to circumvent the problem of no wanting to enable TRUSTWORTHY bit (with all the instance level implications).
To map users trough logins, having TRUSTWORTHY ON is a required condition, but not suficcient. The complete story is detailed at http://msdn2.microsoft.com/en-us/library/ms188304.aspx. What you need is for DB2 to grant AUTHENTICATE permision to login1. TRUSTWORTHY bit is required only on DB1. This is nothing specific to Service Broker, using EXECUTE AS user = 'foo' in DB1 and then issue a USE DB2 statement would run into the same error.
I understand the errors are somehow cryptic and misterious, now the cat is out of the bag we hope to get better at next iteration. Tools would shorley help, give a shot to www.codeplex.com/slm
|||
Hugo Kornelis wrote:
I still don't understand why a remote service binding is required even though BOL says (quote from the CREATE REMOTE SERVICE BINDING page): "A remote service binding is only necessary for initiating services that communicate with target services outside of the SQL Server instance."
Remote service bindings are required for remote dialog security. However, altough not required, if present, they are honored for local dialogs.
|||without reading the whole thread in detail, I found that the SQL Profiler lets you find problems within minutes, for which you would normally take hours or days of checking everything!
Trace shows messages and errors, you will never receive through SSB directly!
Cross Database Queries in SQL Server 2000
Outside of security considerations, are there any performance issues
that should be addressed when using cross database queries on the same
server?Not for SELECT. There is a slight overhead for cross-database transactions b
ecause they involve
several databases transaction logs so an internal 2-phase commit protocol is
used.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Paul Sinclair" <paul.sinclair@.gmails.com> wrote in message
news:enV%23GO1UGHA.4944@.TK2MSFTNGP10.phx.gbl...
> Outside of security considerations, are there any performance issues that
should be addressed when
> using cross database queries on the same server?|||Tibor Karaszi wrote:
> Not for SELECT. There is a slight overhead for cross-database
> transactions because they involve several databases transaction logs so
> an internal 2-phase commit protocol is used.
>
Great, that's what I was seeing in my execution plans against recreated
objects in the same database vs objects in another database - but wasn't
sure if I was missing something or not. Thanks again for the help.
Paul
that should be addressed when using cross database queries on the same
server?Not for SELECT. There is a slight overhead for cross-database transactions b
ecause they involve
several databases transaction logs so an internal 2-phase commit protocol is
used.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Paul Sinclair" <paul.sinclair@.gmails.com> wrote in message
news:enV%23GO1UGHA.4944@.TK2MSFTNGP10.phx.gbl...
> Outside of security considerations, are there any performance issues that
should be addressed when
> using cross database queries on the same server?|||Tibor Karaszi wrote:
> Not for SELECT. There is a slight overhead for cross-database
> transactions because they involve several databases transaction logs so
> an internal 2-phase commit protocol is used.
>
Great, that's what I was seeing in my execution plans against recreated
objects in the same database vs objects in another database - but wasn't
sure if I was missing something or not. Thanks again for the help.
Paul
Cross Database Activation Security
I have two databases Basket_ODS and Intelligence_ODS.
I created a user in the Basket_ODS and Intelligence_ODS databases as follows:
USE Basket_ods
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '*******'
CREATE USER BasketServiceUser WITHOUT LOGIN
ALTER AUTHORIZATION ON SERVICE::[Order Send] TO BasketServiceUser
GRANT CONTROL ON SERVICE::[Order Send]
TO BasketServiceUser
CREATE CERTIFICATE BasketServiceCertPriv
AUTHORIZATION BasketServiceUser
WITH SUBJECT = 'ForBasketService'
BACKUP CERTIFICATE BasketServiceCertPriv
TO FILE = 'BasketServiceCertPub'
In the other database...
I created the following:
USE Intelligence_ODS
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '************
USE Intelligence_ODS
GO
CREATE USER BasketServiceUser WITHOUT LOGIN
CREATE CERTIFICATE BasketServiceCertPub
AUTHORIZATION BasketServiceUser
FROM FILE = 'BasketServiceCertPub'
My Queue is in BASKET_ODS and is set up as:
ALTER QUEUE ODS.[Order Process Queue] WITH
ACTIVATION (
STATUS = ON,
PROCEDURE_NAME = ODS.ProcessOrderQueue,
MAX_QUEUE_READERS = 4,
EXECUTE AS 'BasketServiceUser'
)
I have performed the following grants in Basket_ODS
grant execute on ODS.ProcessOrderQueue to BasketServiceUser
ProcessOrderQueue calls [ODS].[MoveOrderTotals_Core] in the Intelligence_ODS database.
grant execute on [ODS].[MoveOrderTotals_Core] to BasketServiceUser
ProcessOrderQueue proc is set as follows:
ALTER procedure [ODS].[ProcessOrderQueue]
WITH EXECUTE AS 'BasketServiceUser'
[ODS].[MoveOrderTotals_Core] is set up as follows:
when I run ProcessOrderQueue I get an error message:
ALTER procedure [ODS].[MoveOrderTotals_Core](@.Orderid uniqueidentifier)
with execute as 'BasketServiceUser'
I just don't understand when I run ProcessOrderQueue I get the following error message (when database trust is turned off)
The server principal "sa" is not able to access the database "Intelligence_ODS" under the current security context.
Can you help me figure out what I'm doing wrong. I've spent so much time on this security stuff. Is there another way to do this that is more straight forward without using database trust?
Something key that I left out...
ProcessOrderQueue calls [Basket_ODS].[ODS].GenericProcessor which is defined as follows:
ALTER Procedure [ODS].[GenericProcessor](@.procName nvarchar(128), @.orderID uniqueidentifier)
WITH EXECUTE AS 'BasketServiceUser'
as
DECLARE @.sql nvarchar(4000)
Select @.sql = 'exec ' + @.procName + ' @.orderID'
print @.sql
EXEC sp_executesql @.sql,
-- PARAMETER DECLARATIONS
N'@.orderID uniqueidentifier',
-- PARAMETER VALUES
@.orderID
This procedure is called based on the message read from the queue by ProcessOrderQueue. It then looks up what stored procedure needs to be called as per the message and then calls GenericProcessor with the name of the stored procedure to call along with the associated OrderID. When I changed this proc from 'Execute as OWNER' to Execute as 'BasketServiceUser' I now get the following error message :
The server principal "S-1-9-3-3317550566-1317506277-4110005931-648375857." is not able to access the database "Intelligence_ODS" under the current security context.
The stored procedure [Intelligence_ODS].[ODS].[MoveOrderTotals_Core] does an Insert into [Intelligence_ODS].... Select from [Basket_ODS]. That is the cross database portion.
|||In order to get the cross database EXECUTE AS context to work, the key ingredient is the signing of the procedure. I see this is missing from you example. In code signing, is really irelevant who owns the certificate in [Basket_ods]. The important thing is for this certificate to sign the procedure that attempts to call another procedure cross database (I think is the [ODS].[ProcessOrderQueue]):
ADD SIGNATURE TO OBJECT::[ODS].[ProcessOrderQueue] BY CERTIFICATE [BasketServiceCertPriv]
Note that once the signature is added, the procedure should not be altered in any way, or the signature will be lost.
In database Intelligence_ODS you have to create a user derived from the [BasketServiceCertPub] certificate and grant him the appropiate permissions, including AUTHENTICATE:
CREATE USER [BasketServiceCertPubUser] FROM CERTIFICATE [BasketServiceCertPub];
GRANT AUTHENTICATE TO [BasketServiceCertPubUser];
GRANT EXECUTE ON [MoveOrderTotals_Core] TO [BasketServiceCertPubUser];
This should be it. The EXECUTE AS clauses on the queue activation, as well as on the [ProcessOrderQueue] procedure, should be probably OWNER. The procedure [MoveOrderTotals_Core] does not need an EXECUTE AS.
I think you are mixing some concepts related to the process of setting up dialog security (users w/o login, certificate ownership) with the concepts related to EXECUTE AS and code signing procedures. The two concepts are very distinct. The EXECUTE AS relies on signing the procedures and users derived from certificates to achieve it's goals.
HTH,
~ Remus
Subscribe to:
Posts (Atom)