Introduction
This plugin is used in coordination with the plugins of storage technologies connected to LDAP to provision the groups that represent the DSAs, and it also manages the memberships that represent the acceptance of the DSAs by users.
Services available in the plugin
-
Create groups: Allows creating groups with users.
-
Assign/unassign users: Used to add or remove users in the groups created by the plugin.
-
Delete groups: Delete previously created groups.
Integration model
Active governance of access permissions
In general, the DSAs (Data Sharing Agreements) of Anjana Data Platform are represented in AD/LDAP as groups, and the signing users of each agreement are managed as members of those groups. In this way, group membership materializes effective access to the data governed by the DSA.
Anjana Data Platform automatically creates, updates and deletes these groups, including or excluding users based on the adherence and de-adherence processes defined in the platform.
The groups created by Anjana Data Platform follow this naming convention:
<configurable prefix>_<DSA logical name>_v<DSA version number>
Where:
-
<configurable prefix>: prefix defined by the organization to identify the groups managed by Anjana Data Platform. Configurable in the plugin's YAML. -
<DSA logical name>: functional name of the agreement as it appears in Anjana. -
v<DSA version number>: version number of the DSA, which allows distinguishing between active and historical versions.
Anjana Data Platform interacts with the corporate identity manager via the LDAP protocol, through which it executes the operations described for group provisioning and membership management.
Required credentials
The plugin requires a credential with the following permissions:
-
Creation, modification and deletion of groups (
groupOfNames or groups) within the selected OU -
Modification of group members
If used as a complementary plugin instance for another instance of a different plugin, keep in mind that each technology is different, so the configuration of each one may vary.
Limitations
-
The name of the DSA used to create the group must not exceed 60 characters, although the limitations of the specific AD implementation in place should be reviewed in case they vary.
-
In the path of the branch generated with the base + baseUser configuration, there must not be users with the same username value, even if they are in different sub-branches.
-
The name of the class used to create groups by default is groupOfNames. As explained further below, this class type does not allow creating groups without users, so if, due to the configuration, there are no users assigned as owners in the DSA, the creation of the group in LDAP will fail.
However, there are other class types that do allow creating the group in LDAP without including users, such as the group type.
TLS
Configuration availability, if required, under an ldaps:// connection
Windows AD
When working with Windows AD, it will be mandatory to include the sAMAccountName and groupParam.instanceType properties (see the example configuration) so that servers such as SQLServer can understand the AD group names.
Ranger plugin
If the Tot LDAP plugin is used together with Ranger and Active Directory, keep in mind that a mechanism is needed to synchronize the changes made in Active Directory groups and the groups used by HDFS, for example SSSD.
For cases where the group identifier (the common name) needs to be available in more than one place (for example the sAMAccountName, because the mechanism that synchronizes the changes made in Active Directory groups and the groups used by HDFS reads that attribute for synchronization) the extraGroupCn can be used, as detailed in the example configuration above.
That is, if user X has adhered to a DSA D, the result observed in Active Directory will be the creation of a group D with one member, X.
Similarly, in Ranger a policy will be created with the group D, and in HDFS, when running for example “hdfs groups X”, the group D should appear.