Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Log in to Grouper using SSO

  2. Search for the DS folder

  3. When creating a group

    1. use the prefix grp_ds_denodo

    2. description should refer to a data steward

      1. members should all be run by the data steward before addition

    3. Add grp_ds_denodo-admin to the group with ADMIN privileges. This gives Denodo admins the ability to administer the group.

    4. Create separate -dev and -read groups

      1. Add the dev group to the read group so all dev group members are synced with the read group automatically. This will ensure read access for devs will exist beyond dev, since only the read group should be promoted outside of dev.

    5. If developers need scheduler access, create a -scheduler group and associated associate that group with a scheduler project after importing into Denodo.

      image-20250203-203429.pngImage Added
    6. If the developers need solution manager access, add the -dev group as a member of grp_ds_denodo-solution-manager-deploy.

    7. If a service account is going to be used, create -service group and give it the appropriate permissions after importing. Do not assign it the tts-facstaff role as this will create view clutter in applications like DBeaver and Tableau.

  4. Add members to groups

    1. Only add members that have been approved by the data steward

  5. Import groups into denodo. Note: You may need to wait up to 30 minutes for grouper changes to get synced to AD before importing.

    Code Block
    Role base: DC=tufts,DC=ad,DC=tufts,DC=edu
    Attribute with role name: sAMAccountName
    Attribute with description: description
    Role search pattern: (&(cn=*denodo*)(objectcategory=group))

     

  6. Assign roles and permissions as necessary. Add tts-facstaff to give metadata access to all views.

...

https://denodo-prod.it.tufts.edu:9443/denodo-data-catalog/#/view/training/abs_denodo_course_completion

See who has access to views or columns (and their dependents)

The view admin.execute_permission_view has been created to help audit who has execute access to to a view and/or their dependents.

For example, to see who has execute access to views with columns containing visa or citizen that isn’t a Denodo admin, you can run the following query:

Code Block
SELECT 
    epa.parent_database_name, 
    epa.parent_view_name AS view_name, 
    epa.parent_column_name AS column_name, 
    epa.parent_column_distinct_query AS distinct_query, 
    epa.parent_datasources AS datasources, 
    epa.child_database_name AS child_vdb, 
    epa.child_view_name AS child_view_name, 
    epa.child_column_name AS child_column_name, 
    epa.child_column_distinct_query AS child_distinct_query, 
    group_concat(DISTINCT epa.access_role) AS access_role_concat, 
    group_concat(DISTINCT epa.user_name) AS user_name_concat 
FROM admin.execute_permission_audit epa
WHERE
    (
        epa.parent_column_name like '%citizen%' 
        OR epa.parent_column_name like '%visa%'
    ) 
    AND epa.user_name is not null  
    AND epa.user_name not in (
        SELECT user_name FROM admin.f_ad_user_groups WHERE group_name in ('grp_ds_denodo-admin', 'denodo-admin')
    ) 
GROUP BY 1,2,3,4,5,6,7,8,9;

Example result:

...

This view has been deployed in all environments, and be access in either Design Studio or Data Catalog

https://denodo-dev.it.tufts.edu:9443/denodo-data-catalog/#/view/admin/execute_permission_audit

User Guide
Anchor
denodo-user-guide
denodo-user-guide

...