Vault Professional 2015 - Using Folder Security Overides

[tahdesign1]

We have a new project starting that will require me to set up a situation that only certain members can see areas of the Vault.

So as a test I made two user groups, one as a Doc level 2 user and one as an admin. I made a temp folder that I used security overrides to give role based permission to with those groups.

Both test users in those groups can access and see the folder as expected per the roles.

Also when you log into the Vault as a regular user not in one of those groups the folder does not exist, which is what I need.

However, if I log into the Vault as an admin that is not in one of those groups I can see the folder. It does have the lock on the icon but I can still see what is in there (previews and all). If I try to check something out from there is sometimes blocks me and sometimes allows it. So from an admin account it seems rather inconsistent in it behavior.

So at this point I believe I may have to go the route of a separate Vault on the server for this.

Unless someone can point t out something I may be doing wrong to tighten up this security as it pertains to other admin accounts. 

[minkd]

Administrators can always see "cloaked" entities. I'm not aware of any way around that.

-Dave

[tahdesign1]

The seeing the object is not so bad. However, the behavior of being able to check out the object is not consistent.

With the same user (an admin) that is not in the permissions group, I was able to have the Vault deny me the ability to check anything out of that folder and then on a second try it let me.

I guess I was right to assume the better way to do this is with a separate Vault.

[olearya]

Hi there,

If you like we can connect further on this but this is likely going to be a slippery slope for you here if you are trying to outsmart a user with admin level privledges 🙂  Because we do not differentiate between a "CAD Admin" and a "Vault Admin" - anything you block an admin from doing they can generally get around by enabling themselves.

Although you may be able to physically block access to the ADMS Console with windows permissions, they can modify Vault level access and file / folder permissions from the Vault Explorer.

This is a situation we are looking to address in the future based on a good deal of user feedback.

[tahdesign1]

Oh no that will not be an issue. The other members that I have given admin right to in the Vault can not see or log into the actual ADMS server. Only myself and my IT support can do that.

So the Members I give admin rights to are just so they can delete files and the like when needed.

However, I think what you are saying is if a user has admin rights that is throughout the ADMS server even being accessed just from Vault Explorer.

So they could actually edit there own id to have access to new Vault I would make. Hmmmmm

So we just recently came from Basic to Pro within the last few months and I have not had time to work with all the different users permissions I can set for members. Is there one that I can set these people to that will allow them to delete files (with the override) but not have them actually be admins?

[minkd]

The "Document Editor (Level 2)" role can delete files.  However, they cannot override delete restrictions on the files - only the Administrator can delete files unconditionally.

-Dave

[tahdesign1]

Correct so level is pretty much useless when it comes to deleting files.

We go through a design process where many different things are tried before the final design.

Within that will be some models that have been not used. However, because they exist in some versions of some assemblies somehwere they can not be directly deleted. They must be unconditionally deleted which then requires admin rights.

So that the people (admins) that I have given this permission to know what to get ride of, we instruct the regular users to Vault Rename the files with Delete_ in the front.

Does seem like a pain but that is the only way I have found that works for us.

Now moving foward I may start making groups for large designs where I can assign members to that group and give admin right on the design folder of that design.

So that being said, is that a "back door" method to do what I have asked?

For my existing Vault, could I use folder security overrides on the main working folder (the whole Vault) and then make two groups. One Doc2s with all the users and one Admin with just the few I have given that to. That way they can have the Admin rights that they need within the folders (whole Vault)to delete files but not admin right for the Vault itself?

[minkd]

As Allan mentioned, there is really no way around the fact that someone in the Administrators group can change the security to give themselves permission to do the delete.

-Dave

[tahdesign1]

OK but could we clear one point up then.

What if I had a member that the User Profile role was set to Doc2.

But that same member belonged to a group that had role set to admin.

That group was then used with security overides on specific folders.

Or is it that a user roles within the Vault would default to the highest setting. No matter that is was assigned by the User Profile Roles or with them being the member of a group.

[Anonymous]

About that,... is that ever going to be a feature? It would be so easy and it would make administration in an enterprise environment possible.

[olearya]

Something we get a lot of feedback on from large organisations and would like to address in the future.

[minkd]

Ok, so let's say userX has Document Level 2 role and belongs to a group which has the Administrator role.

This would give userX both the Document Level 2 and Administrator roles, essentially give userX full Administrative rights.

But it's not that userX gets the "highest" role, it is that userX has both roles.  It just so happens though that the Administrator role has most (if not all) permissions, so when you add Administrator to a user's list of roles, adding other roles becomes redundant.

While you can limit security via ACLs, anyone with an Administrator role can always override the security on any entity, and they can always see all entities (Administrators implicitly have read permission regardless of the ACL).  Therefore, giving a user the Administrator role is essentially giving them full access to do anything in Vault.

-Dave

[tahdesign1]

Thanks

Hopefully in the future we will have the ability to assign these permission on a folder level not a Vault level.

There is a huge need to give a designing group autonomy in a given folder (design project) in it's initial developmental stage.

Once the design has then gone through the initial release cycle it would then become controlled by the overall Vault permissions.

The folder level overrides would be taken away at the first release.

However, I see a much bigger issue here with large firms that are involved in multiple levels and areas of design (DOE, DOD, etc).

In that the need is to make these permissions persistent per a folder/project level on going.

That is exactly my issue at the moment.

So as it stands, I am going to have to make a separate Vault for this new project.

That in itself is still not a true fix since any of the few members I have given admin right could (not that they would) grant themselves access to that Vault.