Security inheritance change from 2012 version

[criiser]

Upgraded from 2012 into 2015.

Imported the DB using the Upgrade from.....

Installed Patch 6.

Setup of the environment and DB works.

Have User Groups Administrators / External Consultants / Users.

On Root node Credentials I had assigned:

for Administrators and Users (FULL on both Private and Public)
for External Consultants (None on Public and FULL on PRIVATE) - To allow consultants to store passwords for their "private" accunts.

One Level down I have Folder "Standalone Machines" and under that I have 10 accounts.

In version 2012. The credentials saved that was under this Node the group External consultants had: (Standard Public Objects, READ) - That allowed them to actually SEE the Folder "Standalone Machines"

In version 2015 - NOT the case any more. Now I have to assign (Standard Public Objects, READ) on the Folder - Granting the External consultants FULL read on ALL credentials saved in this folder.

Bug or Feature? - Either way, not working as before. Not working as inheritance normally does in Windows.

And if kept like this, introduction of the "DENY" would be highly beneficial together with "Only Folder / Folder and Items IN folder"...

But TBH, preferably change to behave like 2012 version.

Br, Christian

[DevOma]

We have one migration issue fixed for Patch7 - will be published in the next days - the result should be the same as in version 2012... Do you want access to "Pre-Patch7" to test migration again? You could use this version until Patch7 will be released...

[criiser]

EH, I can't redo the migration. We are in production on 2015. So if I create new Folders and/or existing it would be great that it works as "before"...

Please..............

/C

[DevOma]

Creating new folders should be the same as it was in version 2012 - or do you have any differences after you set the permissions?

[criiser]

Truly sorry for delay in response on this. Set up an test environment to reproduce issue at hand.

How to reproduce:

Fresh DB Patch10 (now)

Activate Security groups.
AS the Administrator:
Create Group "Delegated Administrators"
Create Two Public Folders under Credentials. Credentials-Admins, Credential-Delegated.
Create one public entry in each folder. Admins-Credentials and Delegeated-Credential

Now, delegated admins should be able to read/use ONLY the delegated-credentials.

Step 1: ON the Object "Delegeated-Credential" - assign the group "Delegated Administrators" - Read

That works super. But the user cant actually read that. Since the user cant "browse/walk" to that path in the credentials tree..

This - WORKED - in 2012 version.

Workaround:

Step 2: Assign Read on the Folder containing the objects and grant the group read on that. This works if the folder is IN the ROOT of the Credentials Node.

Now, if we create one aditional folder inbetween the ROOT and the folder containing the object with the credentials. Inheretence gets complicated.

You need to grant read on the folder closest to the root now, and that grants the group READ on all subitems... NOT something you would want. IMHO.

This same behavior is ofc also present on connections node.

Expected would be that the user gets to browse/walk to the point where he has access. That way in an highly tree:d scenario you can assign rights for specific usergroups on credentials and connections that are present in an larger tree.

Does this explanation make sense?

Br, Christian

[DevOma]

Did you activate "Show root items for all users" in Permission settings? Else you have to grant your users also on the root object level (and of course then you need to assign new permissions on all sub folders that they don't have access)...

[criiser]

Yes sir! Show root Items for all users is activated. But the main issue is around the actual objects.

Root
|
----- Folder1
|
-------- Folder2
|
------Object #1

Set rights on Object one does not grant read to the above structure. Set read on Folder 2 - still cant see the folder
Set rigths on Folder 1 - Group can read ALL inside Folder1 and Folder2..

Br, Christian

Edit: Gah - Spacing not working as expected... Obj#1 is Inside Folder 2. Folder2 is inside Folder 1. Get it?

[DevOma]

I know what you mean - but it is the same as in was in version 2012 - you can't specify READ on any object in 3rd folder level and it is automatically shown - you need to configure it top down

[criiser]

I know what you mean - but it is the same as in was in version 2012 - you can't specify READ on any object in 3rd folder level and it is automatically shown - you need to configure it top down

The 2012 version had Permissions "Standard - Folder" aswell - and an inherit checkbox. Those two in combination made this work..

On the root node Allow Read acess on the folders. That opens the tree structure. And on special entries you can add read to the actual credentials. Then they will show under the actual proper folder.

2015 is missing the folder rights...

Br, Christian

[DevOma]

In version 2015 it looks different but it has the same functionallity (and more).

On the top of the properties dialog you have "Default", "Inherited Values" and in some cases "Personal Values" - for permissions only Standard and Inherited.

If you specify permissions on any folder the sub items (folders, connections, creds...) will have "Inherited values" checked as default - if you want to customize you have to select "Default values" - if you use Inherited the values from parent object will be used - if you use Default you have to specify new values for that object...


That's now working for all categories in "Properties" dialog - it's the same as it was in 2012 - just a new UI and available for all properties.

So I don't think that there is missing something - a lot of customers are using Permissions

[criiser]

SO where do I add read to JUST the folders and not the Public Objects inside the folders?

[DevOma]

FolderAll
-->FolderPublic1
------->Connection11
-->FolderPublic2
------->Connection21

Set "Read" for "FolderAll" for all security groups and everybody can see this folder
Inherit will be the default for all subitems - so all users have read access to all sub objects...

Now goto PublicFolder1 - switch from "Inherited" to "Default Values" and customize the assigned security groups - e.g. only Admins
From now - Admins will see all folders, other users will see FolderAll, FolderPublic2 and all sub items...

[criiser]

FolderAll
-->FolderPublic1
------->Connection11
-->FolderPublic2
------->Connection21

Set "Read" for "FolderAll" for all security groups and everybody can see this folder
Inherit will be the default for all subitems - so all users have read access to all sub objects...

Now goto PublicFolder1 - switch from "Inherited" to "Default Values" and customize the assigned security groups - e.g. only Admins
From now - Admins will see all folders, other users will see FolderAll, FolderPublic2 and all sub items...

I follow - now if:

FolderAll
-->FolderPublic1
------->Connection11
-->FolderPublic2
------->Connection21
-->Connection31

Assigning Read on FolderALL will grant the user right to read Connection31. Not just the folder..
and that is what i feel has changed. In 2012 you could set right on JUST the folder. Now its restricted to just the objects.

Example (Small but serves as example of LARGER solution):

Root
-->PublicCustomers
-------->Customer1
-------------->ConnectionC1_1
-------------->ConnectionC1_2
-------------->ConnectionC1_3
--------->Customer2
-------------->ConnectionC2_1
-------------->ConnectionC2_2
-------------->ConnectionC2_3
--->ManagementConnection_1
--->ManagementConnection_2
--->ManagementConnection_3
--->ManagementConnection_4

My consultant should service Customer1. He then needs READ on PublicCustomers Folder. That grants him read ASWELL on all the ManagementConnection_1-4. Not quite desirable. So Then all managementCOnnections needs to be modified with an default value. If more than 10 - that becomes an tiresome event...

Attaching snip from 2012 ASG vs 2015 to highlight the differences.

Br, Christian

[DevOma]

OK i see the screens - that is really a special case where you use folders and connections on one level with different security.

Yes you are right - in this case you had to configure all connections - not the best way.

Let me think about it - nobody else complaint about that :-) As "work-around" you should think about using another folder for your objects that are directly under the folder - like ManagementConnection_1

I will add to the feature list - but it will take some time to implement again...

[criiser]

OK i see the screens - that is really a special case where you use folders and connections on one level with different security.

Yes you are right - in this case you had to configure all connections - not the best way.

Let me think about it - nobody else complaint about that :-) As "work-around" you should think about using another folder for your objects that are directly under the folder - like ManagementConnection_1

I will add to the feature list - but it will take some time to implement again...

We used this EXTENSIVELY - and since upgrade to 2015 suffered.. Now - ALL is administrators is the current workaround.

I could ofc use the workaround. But this applies both to Password/Creds AND connections... That means, redo the entire environment.. MAYBE not something I really want to do Quite some amount of connections. But then again, everything is relative

Br, C

[DevOma]

Perhaps MultiEdit can help - use MultiEdit and Set connection security

But sorry again - we overlooked this!

[DevOma]

Sorry, but I have looked into version 2012 again - and the different security types for folder, private and public creds are only available for Creds - not in Connections tree. So the difference between 2012 and 2015 is not really as much as I thought...

[criiser]

Right you are sir!

We allowed our admins to see the connections but not logon using the stored credentials.

But, having the same rights system on all nodes - would make sense....

/C