Protected default still allows edits/posting

[SamSzotkowski]

We are using Enterprise 11.1, and ArcGIS Pro 3.1.2.  This issue seems to come and go, but it's reared its head again.

When creating an enterprise geodatabase (SQL Server), we are using branch versioning, and set the default access level to "protected".  Despite this, portal user roles without the "Manage All" capability are allowed to edit the default directly and post to it.  @EvaTTA mentioned this fairly recently, and in that post it was said to be linked to bugs BUG-000135099 and BUG-000150561, but I cannot find any information on these.

I'll note something especially strange, that "protected" was working as expected last time I checked on Oct 3, but today on the same dataset I dusted off my test account that is not a "Version Administrator", and that account was able to edit the protected default directly.  I think the only thing that's changed since then schema-wise is adding a couple of values to one of the domains.

Has anybody encountered this?  I'm stumped because as far as I can tell I'm doing everything by the book with respect to creating the enterprise geodatabases, managing portal users, and publishing the feature services.

[MarceloMarques]

@SamSzotkowski "Branch versioned data must not be owned by the SDE or DBO users." 

This means the data, e.g. featureclasses, tables, feature datasets, geodatabase domains, etc. must not be owned by the sde user which is the arcsde repository owner nor by DBO.

In SQL Server there are 2 options to create the ArcSDE repository, 1) dbo owned or 2) sde user owned.

Create a geodatabase in SQL Server—ArcGIS Pro | Documentation

I tell all my customers to not use DBO, it does not provide the level of security for your data that is necessary, and instead always use the ArcSDE Repository with the sde user owner.

Now, that you created the ArcSDE Repository with the sde user owner, next you shall not use the sde user to load the data, the sde user is the geodatabase repository owner and must be used only for geodatabase administration tasks, then you must create a data owner users to load the data.

Example:

SQL Server Geodatabase Name: waterdb

ArcSDE Geodatabase Repository Owner: sde

Data Owner User Water Data Model: water

For more best practices please visit my community.esri.com blog below. There you will find the ArcGIS Pro database guide books for SQL Server, and you can also download my database template scripts for SQL Server to assist to setup the SQL Server Geodatabase. You can use the Production Mapping database guidebooks, the best practices can be applied to any industry. 

Mapping and Charting Solutions (MCS) Enterprise Databases Best Practices

I hope this helps.

[SamSzotkowski · Accepted solution]

Hello, I tried following the suggestions of @MarceloMarques, essentially having a separate database user with minimal privileges to create the feature classes, and publishing from that connection.  I'm not sure how well these translate from SQL Server to postgres, but the privileges I granted this "publisher" user were Connect, Create procedure, Create table, Create view, Delete, Execute, Insert, Select, and Update.

In any case, the issue still persisted.  Turns out that what was causing our problem has to do with Portal privileges: it appears any user with Administrative privileges > Content > Update enabled will be able to do anything that a version administrator can do.

Either this is a bug in which case please fix it Esri, or this documentation is inaccurate -- it does not list the apparently crucial "Update" privilege under the definition of users who act as a "Version administrator."

[MarceloMarques]

@SamSzotkowski - please open a ticket with Esri Technical Support to log a new bug. Thanks.

[MarlonAmaya]

@SamSzotkowski 

I am able to confirm that a custom role (set with existing Publisher role)  + the addition of 'view all' in admin category allows for editing in Portal Map viewer. The same user however is not allowed to to edit from ArcGIS Pro. In your scenario, where you able to edit default using ArcGIS Pro?

Marlon

[SamSzotkowski]

Custom role same as publisher + Admin>Content>Update privilege is what caused user to be able to edit default in Pro, I have not messed with the View All privilege.

[SamSzotkowski]

Ok I did some more digging and there's clearly some funny logic going on here.  The three privileges I'm testing are these, and I'll refer to them by their numbers later on:

1. Admin > Members > View All
2. Admin > Content > View All
3. Admin > Content > Update

When you enable 3 in the UI, 1 and 2 toggle on automatically.  When you enable 2, it enables 1 automatically.

• 1+2+3, or 1+3 enabled: Can edit in both Pro and Map Viewer
• 1, 2, 3, 1+2, or 2+3 enabled: Can edit in Map Viewer, not in Pro
• None of these three enabled: Can neither edit in Map Viewer nor in Pro (desired behavior)

I have a case open currently so I'll bring up these additional details.

[MarlonAmaya]

@SamSzotkowski 

Thank you for the further testing. Found your support case and have communicated my findings to the analyst. Something is up for sure. 

Marlon

[CBD]

We were able to solve our issue with the help of ESRI support. It turned out we were using custom roles in Portal an in the publisher role we allowed for one Admin Privilege to "View All" under groups. This allowed my non version admin to reconcile/post to the protected default. 

It was logged as 

• BUG-000165159 - Branch version editing using a custom portal role that contains at least one administrative privilege allows for editing a Protected Default version.