Clarifications on Enterprise database: dataset permissions and owner vs admnistrator

1044
6
Jump to solution
10-16-2018 03:25 AM
AlessandroValra
Occasional Contributor III

Coming from a File GDB world, I am having difficulties understanding how Enterprsie (Workgroup in my case, with SQL Express) GDB permissions work. Specifically, this is what confuses me:

  • I have two users ("A" and "B"), which connect to my SQL EXPRESS instance with Windows auth
  • "A" is the SQL Server administrator
  • "A" creates a new geodatabase (named "test") and assigns "B" read/write premissions (with the ArcCatalog tools)
  • "B" creates a new feature dataset (named"test_FD") in this GDB and it gets the name "test."A".test_FD"
  • "A" from the Catalog window cannot see this feature dataset

So, a few questions:

  1. why can't "A" see the FD created by B? I thought A, being the SQL Server admin (and therefore, the GDB admin by inheritance) would have control over anything.
  2. why can "A" create a new FD with the same name "test_FD"? I know the two FD come from different users, but still this is surprising to my eyes.
  3. Is there a way to assign a user provileges to create new datasets leaving the control on these same datasets to the admin/s only?
  4. In the official documentation it reads:

Privileges on datasets in geodatabases should be granted or revoked using ArcGIS clients and must be done by the dataset owner.

   , so I guess the admin in this case won't have control over these user created datasets, is it correct?

I have just a simple setup with only the DEFAULT version.

0 Kudos
1 Solution

Accepted Solutions
Asrujit_SenGupta
MVP Regular Contributor

What you highlight, has been existing since the very beginning. Only the user, who created a Feature Dataset can create Feature Dataset, or other objects for that matter inside it and also manage these.

If you don't want a user to create any kind of data, simply don't give them the Permissions to do so.

View solution in original post

0 Kudos
6 Replies
Asrujit_SenGupta
MVP Regular Contributor

Permissions on the Workgroup gdb are handled a bit differently than the Enterprise gdb. Check these links:

Add logins to a database server—Help | ArcGIS Desktop 

Alter permissions—Help | ArcGIS Desktop 

AlessandroValra
Occasional Contributor III

Asrujit SenGupta‌ Thanks.

I am quite aware of how to add users and alter their permissions.

However, the questions I asked still remain unsolved even after reading the documentation you linked to.

So maybe some screenshots can be of help to clarify my point.

This is the situation:

USER A: SERVER ADMIN

1. creates new geodatabase (test)

2. assigns read/write permission to other user at GDB level

USER B: READ/WRITE

3. creates new feature dataset (test_FD) thus becoming its owner

4. looking at the Feature Dataset Manage -> Provileges window, I see:

, which is weird, given that this user is the creator of the same Feature Dataset. Moreover, I cannot see any other users here...

USER A: SERVER ADMIN (again)

5. from the Catalog Window and a new ArcMap session, I reconnect to the SQL EXPRESS DB, and searches for the just created Feature Dataset, but cannot find it

6. creates another Feature Dataset (called "test_FD", again):

7. Look in the same Feature Dataset Manage -> Provileges window, I see with this user I see:

, meaning that the other user ("B", or "minorau") has inherited provileges to read/write in this Feature Dataset from the GDB level, which is what I expected.

Still, user B or minorau cannot see this server admin-created FD, but only its one (point 3).

Can anybody please shed a light on this? My setup is untouched (I kept the default settings of the Esri installation and just added new windows users from the Catalog Window by right clicking the SQL Express Server connection and then Permissions).

0 Kudos
AlessandroValra
Occasional Contributor III

I might have done some improvements in understanding this.

With user A I just created a Feature Class inside its previously created feature dataset and now I with the other user B I can see both this feature dataset and the feature class, AND its other feature dataset.

This makes sense, and I guess that probably a feature dataset is not really a table, rather an abstraction object to contain and manage real tables like feature classes.

Still, what suprises me is that:

  1. other NON admin users (e.g. user B) can create content and being the owner and only real "admin" of this content (see Change ownership of SDE feature class , and Grant and revoke dataset privileges—ArcGIS Help | ArcGIS Desktop)
  2. there can be two feature dataset with the same name in the same geodatabase (due to the "[database].[domain].[user].[featuredataset]" nomenclature).

How can a server or geodatabase admin avoid point 1 which is probably a situation nobody would like to have in his organization?

Also, WHAAAAAAAAT??? (Creating a feature dataset—Help | ArcGIS Desktop )

0 Kudos
Asrujit_SenGupta
MVP Regular Contributor

What you highlight, has been existing since the very beginning. Only the user, who created a Feature Dataset can create Feature Dataset, or other objects for that matter inside it and also manage these.

If you don't want a user to create any kind of data, simply don't give them the Permissions to do so.

0 Kudos
AlessandroValra
Occasional Contributor III

Asrujit SenGupta‌ Ok, I acknowledge this is the situation and I have to adapt to it. Thanks for clarifying.

0 Kudos
AlessandroValra
Occasional Contributor III

Just to add my last test with some customers.

Assigning to different windows users the privilege to administer the entire server db is probably not the best, but has the great (for me and them) advantage to make all them being the "DBO" user, so that everytime one of them creates something, no matter who they are, they are seen by the application as the same user. This way I solved the problem of (e.g.) not being able to Register a dataset with another user, or adding feature classes to a feature dataset created by another user.

I hope this could be of help for anybody.

0 Kudos