[midPoint] Active Directory + associations - different behavior between Midpoint 4.8 and Midpoint 4.1

Lubomir Marton lmarton at evolveum.com
Mon Apr 29 10:59:20 CEST 2024


Hi Carlos, 

We recommend turning off explicitReferentialIntegrity for associations with groups. Please see related documentation [ https://docs.evolveum.com/connectors/resources/active-directory/group-synchronization-howto/ | https://docs.evolveum.com/connectors/resources/active-directory/group-synchronization-howto/ ] and [ https://docs.evolveum.com/connectors/resources/active-directory/active-directory-ldap/ | https://docs.evolveum.com/connectors/resources/active-directory/active-directory-ldap/ ] . 

Best regards 

Lubomir Marton 


From: "midPoint General Discussion" <midpoint at lists.evolveum.com> 
To: "midPoint General Discussion" <midpoint at lists.evolveum.com> 
Cc: "Carlos Ferreira" <carlos18619 at gmail.com> 
Sent: Thursday, April 25, 2024 6:33:11 PM 
Subject: [midPoint] Active Directory + associations - different behavior between Midpoint 4.8 and Midpoint 4.1 

Hi everyone, 


Here is a snippet of a resource that connects with Active Directory and deals with associations: 

<association id="2800"> 
<ref>ldapGroups</ref> 
<displayName>Group Membership</displayName> 
<inbound id="2809"> 
<strength>strong</strength> 
<expression> 
<assignmentTargetSearch> 
<targetType>RoleType</targetType> 
<filter> 
<q:equal> 
<q:path>name</q:path> 
<expression> 
<script> 
<code> 
basic.getAttributeValue(entitlement, 'cn') 
</code> 
</script> 
</expression> 
</q:equal> 
</filter> 

</assignmentTargetSearch> 
</expression> 
<target> 
<path>assignment</path> 
</target> 
</inbound> 
<kind>entitlement</kind> 
<intent>ListaAD</intent> 
<intent>GrupoAD</intent> 
<direction>objectToSubject</direction> 
<associationAttribute>ri:member</associationAttribute> 
<valueAttribute>dn</valueAttribute> 
<shortcutAssociationAttribute>ri:memberOf</shortcutAssociationAttribute> 
<shortcutValueAttribute>ri:dn</shortcutValueAttribute> 
<explicitReferentialIntegrity>true</explicitReferentialIntegrity> 
</association> 

And here is the specific configuration in a metarole that sums up with the previous one to populate groups in Active Directory: 

<inducement id="2"> 
<construction> 
<resourceRef oid="746ecf5e-3e8c-11e6-b2f9-3c970e44b9e3" relation="org:default" type="c:ResourceType"> 
<!-- Active Directory 10.x.x.x - --> 
</resourceRef> 
<kind>account</kind> 
<intent>default</intent> 
<association id="3"> 
<ref>ri:ldapGroups</ref> 
<outbound> 
<strength>strong</strength> 
<expression> 
<associationFromLink> 
<projectionDiscriminator xsi:type="c:ShadowDiscriminatorType"> 
<kind>entitlement</kind> 
<intent>GrupoAD</intent> 
</projectionDiscriminator> 
</associationFromLink> 
</expression> 
</outbound> 
</association> 
</construction> 
<order>2</order> 
<focusType>c:UserType</focusType> 
</inducement> 

Scenarios (for a specific user): 

a) Assignment of a role 
1. Select the user; 
2. Click "assignment->role->"Just a test role"; 
3. Click the "save" button; 

-> result: 
Midpoint 4.1:the role is assigned to the user and the association is correctly created on AD. 
Midpoint 4.8:the role is assigned to the user and the association is correctly created on AD. 

b) Unassignment of a role 
1. Select the user; 
2. Click "assignment->role->"Just a test role"; 
3. Click on the "-" icon; 
4. Click the "save" button; 

-> result: 
Midpoint 4.1:the role is unassigned from the user and the association is correctly removed from AD. <- expected behavior 
Midpoint 4.8:the role is NOT unassigned from the user BUT the association is correctly removed from AD. <- unexpected behavior 

Is there any configuration (in Midpoint 4.8) missing on the resource or metarole? 

Thks. 

_______________________________________________ 
midPoint mailing list 
midPoint at lists.evolveum.com 
https://lists.evolveum.com/mailman/listinfo/midpoint 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20240429/823dbd6c/attachment.htm>


More information about the midPoint mailing list