Security Access Issues

[willisj318]

We have a pretty unique setup here where we have roughly 150 divisions who all need to do basic admin tasks such as create collections, packages, etc, and to be able to deploy them to collections which they manage.

 

We don't want them to be able to edit packages and task sequences that are not theirs. I have figured out a method to do this, however it seems it isn't the best way. But looking at alternatives leaves me confused.

 

For example I created two custom security roles and scopes, read and write basically. I have a package and have assigned the read security scope to that.

 

When the user is just assigned the read, they can see the package as expected, and do nothing with it, as all that is granted via the read role is the read right.

 

Now, when I grant the user the write role, they automatically get that access to the package, even thought he package does not have that role assigned to it.

 

So I feel that I am confused as to why this is happening.

 

My user has been granted both roles, and for Security Scopes I have it set to "Only the instances of objects...." I read this as, yes you can have the write role, but only when assigned. However I am obviously wrong about this, as users are granted write on existing objects regardless.

 

Using the "Associate assigned security...." option fixes this, to a point. However doing it this way seems are to script via powershell.

 

 

[Peter van der Woude]

It's all about the Security Roles configured within the "Only the instances of objects...". With a Security Role you define the rights that a user has and with a Security Scope you define on which objects the user has those rights. For more information, see: http://technet.microsoft.com/en-us/library/gg712284.aspx#BKMK_PlanningForRBA

[willisj318]

Thanks Peter. Yes looks like I simply cant use the Only Instances method. I understand the concept (I think, god knows I should I've read enough about it), but not the deployment of them. With the scope I am defining the object, in this case, Adobe Reader. I apply the 'READ' scope. Which is associated with the 'READ' role. If this role is all the user has assigned, the user has read access as anticipated. The second I give the USER the 'WRITE' role, regardless of what happens in the "Only the instances...." section. The user can now make edits to Adobe, even though I did not assign the write scope to the Adobe Package.

 

The way I understand it is that since we have only applied the read scope to Adobe, that is what rights users should have. However that is not the case.

 

To do it that way I'm thinking it should work, or does work in this case, I need to use the Associate Assigned option. Doing it there lets me (so far) assign rights how I need them. Since it is here that I can assign the read role with the read scope. As the other method, there is no way.

 

This leads me to my greater problem. Scripting this out or copying the admin user. I have found no way in powershell to add admin users and their rights to the Associate assigned security.... section. it always adds it to the top part. We are thinking of working with our SQL guys and monitoring the DB and editing it directly. But we would really like a script for when we bring on new divisions and whatnot.

[Peter van der Woude]

You should see the Role and the Scope separate from eachother. With the role you define the rights of the user, in this case read + write (from the two roles together) and with the scope you define the objects the user can access, so if that's that specific package that means that the user has read + write access to that specific package.

[willisj318]

Indeed, which is what I don't want. So it is now clear to me why the Only Instance of objects method wont work for us. Thank you.