Hi Willoh,

Groups from the AD are only retrieved and validated when a user logs in, so it would not be possible to do this exactly in the way you describe. There is an extra step that needs to be included for this kind of validation. 

AD groups can be linked to users’ access rights if SSO is configured for your organisation in Keycloak, but via Roles and Groups configured in Ataccama itself.

The following sections of the documentation explain this in more detail:

https://docs.ataccama.com/one/latest/third-party-software/keycloak-active-directory-integration.html
https://docs.ataccama.com/one/latest/user-access-management/introduction.html

I hope that helps,

Brian.

Hi again,

Re-reading your question, was I right that you want to control access using the AD Group you’ve included, or is it that you need to validate that the group is valid and exists in your organisation's directory?

Thanks,

Brian.

Hi Brian!

Thank you for the reply! I appreciate the explanation. You are correct in the understanding that I would like to control access via AD groups. A bit more context on the intention/our circumstances:
 

• We are on-prem, so I am referring to standard AD, not Azure, when I say AD groups.
• We are intending to pull in the desired AD groups through Identity Provider Mappings, as we use Secure Auth to authenticate sign-ons and cannot seems to bind to multiple sources/also form an LDAP connection. 
• Because AD groups are used to manage access within our connected applications (currently SQL Server, dremio, and Power BI) on several levels, we would like to maintain this concept within Ataccama. In an ideal world, these controls would be automatically inherited, but for now we are simple interested in replicating them within Ataccama. 
• We would like to maintain the groups section of Ataccama to maintain the set-up described in the documentation- outlining our business’ functional business groups. This provides an avenue for the logical assignment and upkeep of stewardship. 
• Our AD Groups somewhat mirror our functional business groups, but not exactly. We have a fair amount of data that is strictly meant to be kept from certain groups (Sales). They are also often broken down at an application level. A person will belong to many groups. 

I am of the understanding that to use AD groups as our governing control, it is necessary that in addition to the functional business groups hierarchy, we create and map identity providers to ‘Groups’ within ONE, and then we are able to share entities, or collections thereof through the use of locations, by sharing access with it. If I am incorrect in this understanding, please feel free to let me know. I am also looking for more clarification on how identity providers work in conjunction with users within the functional business groups. Is a user able to be mapped to multiple groups that aren’t in the same branch? How can this be done autonomously by importing AD groups? We have thousands of potential users, and the groups are changing often, so it is not viable to manually associate users with different groups. 

In lieu of all of this, I am hoping to update the Metadata Model such that I can remove the intermediary “Groups” within Ataccama and shared directly with an Identity Provider Role mapping within the Ataccama application (we have Secure Auth authentication happen at an app entry level successfully). Any solutions anyone can provide are greatly appreciated! Would love to know how others have managed this concept.

Thank you!!
Willoh