Vault Pro - Do I need folder level security ACL for the following scenario?......

Vault Pro - Do I need folder level security ACL for the following scenario?......

andrew_gardner
Enthusiast Enthusiast
2,700 Views
8 Replies
Message 1 of 9

Vault Pro - Do I need folder level security ACL for the following scenario?......

andrew_gardner
Enthusiast
Enthusiast

Hello all

 

I am a reasonably green Vault administrator and am doing some head scratching. Inherited Vault setup from previous admin and have minimal training. Looking for some guidance from the more experienced of you if possible please?

 

I have what I assume is a pretty basic vault lifecycle setup. Excuse the poor graphic but configuration is per the attached image "Lifecycle". This lifecycle essentially controls which users can access the listed categories for any given state. No problems with this, all working as expected.

 

[ The subject line of this post has been edited to include the product name by @CGBenner ]

 

Again, excuse the basic graphic.... Our Vault folder structure is in the attached image "Folder Structure".

 

What I want to achieve:

We have an external contractor who will be granted access to the Vault via Vault Gateway (this is setup and ready to issue the URL, passwords etc. Intention is to manage them via their own user group, let's call this "Contractors" for the purposes of this query. Just need to find a way of restricting access to the majority of our Vault. I want to isolate their access to a specific Vault folder and make all other Vault folders invisible (see attachement called "Isolate". I have been considering achieving this by way of folder level security ACL but unsure of knock on consequences of this (for the record, I have watched some Autodesk University videos that cover combined security model etc. so now have at least a basic understanding of this). I have been told by our CAD reseller that there is no need to use folder level security and that this can be achieved via additional categories (specific to the folder in question) controlled within the lifecycle.

 

Even if I create additional categories with rules associated with the isolate folder, I can't for the life of me see how to grant access to some users but not others within the lifecycle configuration. I am either not understanding something fundamental or I need to switch the lifecycle security definition to combined and use folder level security in combination with it?

 

Any guidance greatly appreciated!!!

 

 

 

0 Likes
Accepted solutions (1)
2,701 Views
8 Replies
Replies (8)
Message 2 of 9

andrew_gardner
Enthusiast
Enthusiast
I should have said that I want the contractor to operate in an identical way to the internal users, using the same lifecycles etc. but within a restricted area. All internal users need to retain access to all Vault folders, inclusive of the restricted folder.
0 Likes
Message 3 of 9

ihayesjr
Community Manager
Community Manager

@andrew_gardner 

The contractor will need Read permission at the Primary folder level and the Sub Folder 4.

For the other Sub Folders, do not grant them Read permission. 

This will had all of the other Sub Folders from the contractor.

You will need Folder Level Security and a lifecycle on the Folders are not necessary.

On the Primary Folder

Everyone Group - All permissions Allow

 

On all Sub Folders except Sub Folder 4

Everyone Group - All Permissions - Allow

Contractors Group - Read - Deny




Irvin Hayes Jr
Principal Product Manager
Autodesk, Inc.

Vault - Under the Hood Blog
Message 4 of 9

Gabriel_Watson
Mentor
Mentor
Accepted solution

I have set two companies with something similar by now, and I find that in Vault it is much more elegant to set what users CAN do than what they canNOT.

My preferred way to deal with your specific situation would be to:
1- Create a group "CORP" (or "Internal", or "YourCompanyName") which should have overall visibility to all of Vault.
2- Set a folder-level security for all Sub Folders, except for #4, with full-access (Allow) to members of "CORP".

3- Include all internal users in the CORP group that is allowed to see those folders, and leave your contractors out of the same group.

 

Galaxybane_0-1666239461525.png

 

This makes it easier for us to set several tiers or groups with restrictions, without any lifecycle-type of restriction (folder or file). For example, if you had contractors from one region "NA", others from "EU", and some from "AP", and each should be kept from seeing the "CORP" folders above or each others' subfolders, you just need to set one restriction for each type of folder instead of denying all others.

Think of it as giving a pass-card for all the users that are allowed to see the intended folder(s), instead of checking a blacklist of rejected users to see if their name is on it.

Message 5 of 9

andrew_gardner
Enthusiast
Enthusiast

Both of the above have put me on the right track. Much appreciated!

 

This comment from @Gabriel_Watson was especially useful "I find that in Vault it is much more elegant to set what users CAN do than what they can NOT". This fundamentally changed the way I have approached this particular configuration and my understanding was much clearer using this basis. As you said, this has turned out to be a much cleaner and less problematic approach.

 

So the configuration is now set, and I am now satisfied. However, an associated issue has cropped up as a result of the above being configured, as follows...... 

 

The primary folder also contains files of various types. Therefore, the external users have visibility of these files as a result of access effectively being granted to them by the primary folder ACL. It's not a major issue as simply moving all of these files into one of the sub-folders will hide them from external users. However......

 

Question: In this particular scenario, are we to rely on discipline of internal users to ensure that no files are located in the primary folder? Or, is there a software feature that we can use to prevent files from being placed in this location?

Message 6 of 9

Gabriel_Watson
Mentor
Mentor

Glad to help!

I would recommend to stick with discipline and some saved search (use many as admin to correct mistakes) to police what comes through the door at that primary folder. However, if you absolutely need to restrict people, I believe you could set the top folder's security setting for the "Everyone" group to only be allowed to Read and Download. When you press OK you have to select "Do NOT propagate..." to keep this restriction only on this top folder.

Message 7 of 9

andrew_gardner
Enthusiast
Enthusiast

Ok, so I thought I was done with this thread as all seemed to be working as desired. However, I have just accidentally discovered that the contents of all of the hidden folders are searchable, the search results can then be opened/downloaded. What gives?

 

The user that is signed in has no roles assigned but is a member of a group that has roles assigned. If I remove him from the group, then switch the group name in the folder ACL to the user name, hidden folders are no longer searchable. The ACL security is set to "override" per below image. This is applicable to the parent folder and all sub-folders (propagated entirely).

 

andrewgardner_0-1666631899787.png

 

It seems like user permissions are not overridden by folder security settings? Could somebody please offer some further advice as I have been unable to identify the reason.

0 Likes
Message 8 of 9

ihayesjr
Community Manager
Community Manager

@andrew_gardner 

It still sounds like you don't have the permissions set correctly.

If the user has Read permissions at the Folder level but does not have Read permission in the lifecycle state of the file. The user cannot see the file. 

Your lifecycle definition must be set to the Combined Security model for this to work. If not, the lifecycle state security will rule the file. 




Irvin Hayes Jr
Principal Product Manager
Autodesk, Inc.

Vault - Under the Hood Blog
Message 9 of 9

andrew_gardner
Enthusiast
Enthusiast

Indeed, it turned out that lifecycle security was set to override as this was setup before the switch to combined security model in 2017. Switched the relevant lifecycles over to combined and now it is working as expected. 

 

Thanks to @ihayesjr , much appreciated.

0 Likes