Showing posts with label roles. Show all posts
Showing posts with label roles. Show all posts

Wednesday, March 28, 2012

Question related to Analysis Service Roles

Hi,

One of my users is supposed to have full access to all other dimesions except for one and thus I have defined a customized role on one of 4 dimensions that I have.

When I test the role (from the front-end), I am getting a strange message in my front-end :confused: and could it be that I also have to define a role for this user on all other dimensions? Should I define the role on the server or the client :confused: I am a bit confused and will appreciate your help.

Thanks.Are you testing the role from your machine or from the users machine? What happens when they log on to your machine? Can you post the error message that you are getting?|||Are you testing the role from your machine or from the users machine? What happens when they log on to your machine? Can you post the error message that you are getting?
Hi and thanks for the reply.

At the moment I am testing this from my own machine by logging in (from my machine) as the test user and then trying to use the cube. Could this be the reason? The front-end that I'm using is MSDA (Microsoft Data Analyzer) and the error message that I get is as follows:

Formula error - cannot bind: unknown member: "[Product].[_MAXIMAL_MIN_]"

Any clues please.sql

Monday, February 20, 2012

Question on Application roles.

sql2k
Im comparing a username/ password to an App role/ password and Im just not
seeing the logic here. An App either needs to supply a username/ password or
a "sp_setapprole @.rolename = 'TestRole' ,@.password ='test'". Either way they
are granted access to the DB. Either way they can only execute what I allow
them too(A user cant run a SELECT if I dont grant him access.). How is this
any safer?
TIA, ChrisR
Even in the case of using an app role, you still need a login to the server.
The benefit of an app role is that you can share server credentials amongst
a variety of apps, while still keeping data security partitioned. It's just
another way of slicing and dicing from a security point of view. I don't
see one method as any safer or less safe than any other method...
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
"ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
news:427310C9-210E-4A9F-A893-F8AE89A60E94@.microsoft.com...
> sql2k
> Im comparing a username/ password to an App role/ password and Im just not
> seeing the logic here. An App either needs to supply a username/ password
> or
> a "sp_setapprole @.rolename = 'TestRole' ,@.password ='test'". Either way
> they
> are granted access to the DB. Either way they can only execute what I
> allow
> them too(A user cant run a SELECT if I dont grant him access.). How is
> this
> any safer?
> TIA, ChrisR
|||Users do not have the password of the application role, only the application
has it.
One example is, users can have write access only thru the application role
but not using their Windows account. If they run the application they can
change data. If they use other tools like Query Analyzer or Access they would
not have write permissions.
Ben Nevarez, MCDBA, OCP
Database Administrator
"ChrisR" wrote:

> sql2k
> Im comparing a username/ password to an App role/ password and Im just not
> seeing the logic here. An App either needs to supply a username/ password or
> a "sp_setapprole @.rolename = 'TestRole' ,@.password ='test'". Either way they
> are granted access to the DB. Either way they can only execute what I allow
> them too(A user cant run a SELECT if I dont grant him access.). How is this
> any safer?
> TIA, ChrisR

Question on Application roles.

sql2k
Im comparing a username/ password to an App role/ password and Im just not
seeing the logic here. An App either needs to supply a username/ password or
a "sp_setapprole @.rolename = 'TestRole' ,@.password ='test'". Either way they
are granted access to the DB. Either way they can only execute what I allow
them too(A user cant run a SELECT if I dont grant him access.). How is this
any safer?
TIA, ChrisREven in the case of using an app role, you still need a login to the server.
The benefit of an app role is that you can share server credentials amongst
a variety of apps, while still keeping data security partitioned. It's just
another way of slicing and dicing from a security point of view. I don't
see one method as any safer or less safe than any other method...
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
--
"ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
news:427310C9-210E-4A9F-A893-F8AE89A60E94@.microsoft.com...
> sql2k
> Im comparing a username/ password to an App role/ password and Im just not
> seeing the logic here. An App either needs to supply a username/ password
> or
> a "sp_setapprole @.rolename = 'TestRole' ,@.password ='test'". Either way
> they
> are granted access to the DB. Either way they can only execute what I
> allow
> them too(A user cant run a SELECT if I dont grant him access.). How is
> this
> any safer?
> TIA, ChrisR|||Users do not have the password of the application role, only the application
has it.
One example is, users can have write access only thru the application role
but not using their Windows account. If they run the application they can
change data. If they use other tools like Query Analyzer or Access they woul
d
not have write permissions.
Ben Nevarez, MCDBA, OCP
Database Administrator
"ChrisR" wrote:

> sql2k
> Im comparing a username/ password to an App role/ password and Im just not
> seeing the logic here. An App either needs to supply a username/ password
or
> a "sp_setapprole @.rolename = 'TestRole' ,@.password ='test'". Either way th
ey
> are granted access to the DB. Either way they can only execute what I allo
w
> them too(A user cant run a SELECT if I dont grant him access.). How is thi
s
> any safer?
> TIA, ChrisR

Question on Application roles.

sql2k
Im comparing a username/ password to an App role/ password and Im just not
seeing the logic here. An App either needs to supply a username/ password or
a "sp_setapprole @.rolename = 'TestRole' ,@.password ='test'". Either way they
are granted access to the DB. Either way they can only execute what I allow
them too(A user cant run a SELECT if I dont grant him access.). How is this
any safer?
TIA, ChrisREven in the case of using an app role, you still need a login to the server.
The benefit of an app role is that you can share server credentials amongst
a variety of apps, while still keeping data security partitioned. It's just
another way of slicing and dicing from a security point of view. I don't
see one method as any safer or less safe than any other method...
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
--
"ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
news:427310C9-210E-4A9F-A893-F8AE89A60E94@.microsoft.com...
> sql2k
> Im comparing a username/ password to an App role/ password and Im just not
> seeing the logic here. An App either needs to supply a username/ password
> or
> a "sp_setapprole @.rolename = 'TestRole' ,@.password ='test'". Either way
> they
> are granted access to the DB. Either way they can only execute what I
> allow
> them too(A user cant run a SELECT if I dont grant him access.). How is
> this
> any safer?
> TIA, ChrisR|||Users do not have the password of the application role, only the application
has it.
One example is, users can have write access only thru the application role
but not using their Windows account. If they run the application they can
change data. If they use other tools like Query Analyzer or Access they would
not have write permissions.
Ben Nevarez, MCDBA, OCP
Database Administrator
"ChrisR" wrote:
> sql2k
> Im comparing a username/ password to an App role/ password and Im just not
> seeing the logic here. An App either needs to supply a username/ password or
> a "sp_setapprole @.rolename = 'TestRole' ,@.password ='test'". Either way they
> are granted access to the DB. Either way they can only execute what I allow
> them too(A user cant run a SELECT if I dont grant him access.). How is this
> any safer?
> TIA, ChrisR