All rights granted to "Public" role are allowing any GSS user for example delete ANY computers from database directly
Article ID: 224521
Updated On:
Products
Issue/Introduction
After installing a brand new instance of GSS, regular users are unable to access the console properly because the tables in the eXpress database are not proper even after granting appropriate permissions.
GSS users that do not have admin rights in the database are not able to manage computers in the console. For those users that do not have admin rights in the database, The customer's current workaround involve creating a database role, adding permissions that enable that role to access the Computers, NIC Interface and Location tables, and adding security groups to that role. It is thought that this was previously performed automatically by a middle man service.
Steps to duplicate:
This issue will not repro if the AD user you are applying Console permissions to has sysadmin rights to SQL or any additional rights that allows insert/update/delete permissions to the tables in question.
Please ensure the AD User has ONLY SQL "public" role permissions. It would be advantageous to add your Admin account as a SQL sysadmin and remove the BUILTIN\Administrators group from SQL Permissions all together. The AD User should be added in SQL security with only public role permissions and the public role should not have any additional rights/permissions other than the default.
A simple way to verify would be to try and insert a record into the computer table using the AD User credentials. If you can successfully insert/update/delete a record in the computer table then the AD User has improper SQL permissions.
Environment
GSS 3.3 RU4 and later
Cause
This use case was reported in the past as a security concern. For the customer was not acceptable that all rights granted to "Public" role allowing any GSS user, for example, delete ANY computers from database directly.
Changes done:
1. 'public' only users now have only 'SELECT' permission for 116 tables & 'Select, Update, Insert', Delete' permissions for 7 tables below
sysprep_tz_index
sysprep_os_keys
sysprep_answers
return_codes
dns_suffix
config_static_route_set
config_static_route_item
2. If customer will create a new user with only 'public' role and assign it to GSS database (upgraded or clean installed database), then this user will also has correct permissions set for GSS tables like in #1 above.
Also checked that before upgrade, when internal GSS users were created with/without Administrators role from GSS Console and have only some separate permissions enabled, all these settings are successfully preserved and working for them once GSS is upgraded to 3.3 RU4 (3088) build.
Resolution
This is by design. We made changes in GSS 3.3. RU4 release to disallow users with "public" role to run SQL operations except SELECT. This was changed to address some security concerns (Database Security - all rights granted to "Public" role allowing any GSS user for example delete ANY computers from database directly). It is expected by current design. This also was mentioned in the GSS 3.3 RU4 Release Notes:
Feedback
