[midPoint] Problem creating new users with their role assignments

[Shawn McKinney]

Hello Ivan, thank you for the detailed response.  The breakdown of configs with descriptions was most helpful.

> On Apr 7, 2016, at 9:25 AM, Ivan Noris <ivan.noris at evolveum.com> wrote:
> 
> Well this is strange, I had a problem and it dissapeared during
> testing... ;-)
> The only thing I had to do was create the
> ou=unixgroups,dc=example,dc=com container.
> 
> Anyway. I used the (adapted for OpenLDAP) resource, and imported also
> the sequences and then role-unix.xml and role-meta-unix-group2.xml.
> 
> I wanted to specifically test if the role-meta-unix-group2.xml metarole
> works, because the object in test scenario is from our real deployment
> where it works.
> 
> So, I tested it and it worked. Then I tried to use Unix User role
> instead and it also worked.
> 
> I tried various combinations starting with creating user, where the
> following attributes were filled:
> - name
> - givenName
> - familyName
> - fullName
> - password
> And assigned the roles Unix User and two previously created LDAP roles
> shawnrole1-331 and shawnrole2-331. Then I saved the user.
> 
> LDAP account was created and put to groups cn=shawnrole1-331,... and
> cn=shawnrole2-331,... and also posixAccount attributes were set (from
> Unix User role). Everything worked.
> 
> After that I tried to unassign some of the roles and everything worked.
> 
> Also I tried to utilize LDAP Unix Group Metarole 2 instead of Unix USer
> role. I created two roles in midPoint (shawnunix1-331 and
> shawnunix2-331) and assigned LDAP Unix Group Metarole 2 to them. The
> Unix (posixGroup) groups were created in ou=unixgroups,dc=example,dc=com.
> 
> Then I assigned the shawnunix1-331/shawnunix2-331 roles to the user
> with/without the normal LDAP roles and user was correctly put to
> standard groups as well as the posixGroups.
> 

Still trying to understand the nuances of the two approaches.  What is the difference between the config in role-meta-group.xml and role-meta-unix-group2.xml?  I am using the former.  I can see the group2 has the posixAccount attributes defined there rather than in the resource.xml.  What is the rationale of one approach over the other?

> 
> On Apr 7, 2016, at 9:25 AM, Ivan Noris <ivan.noris at evolveum.com> wrote:
> 
> 
> So, the only real changes in OpenDJ -> OpenLDAP resource except
> connection parameters were:
> 
> 1) I removed all inbound mappings
> 2) <association> was changed as below:
>             <association>
>                <ref>ri:ldapGroup</ref>
> +                <matchingRule>mr:stringIgnoreCase</matchingRule>
>                <displayName>LDAP Group Membership</displayName>
>                <kind>entitlement</kind>
>                <intent>ldapGroup</intent>
>                <direction>objectToSubject</direction>
>                <associationAttribute>ri:uniqueMember</associationAttribute>
>                <valueAttribute>ri:dn</valueAttribute>
> +<!--
> 
> <shortcutAssociationAttribute>ri:isMemberOf</shortcutAssociationAttribute>
>                <shortcutValueAttribute>ri:dn</shortcutValueAttribute>
> +-->
> 
> <explicitReferentialIntegrity>true</explicitReferentialIntegrity>
>             </association>
> 
>             <association>
>                <ref>ri:unixGroup</ref>
> +                <matchingRule>mr:stringIgnoreCase</matchingRule>
>                <displayName>UNIX Group Membership</displayName>
> 
> <auxiliaryObjectClass>posixAccount</auxiliaryObjectClass> <!-- Strictly
> speaking should be ri:posixAccount. but it also should work without
> namespace prefix. -->
>                <kind>entitlement</kind>
>                <intent>unixGroup</intent>
>                <direction>objectToSubject</direction>
>                <associationAttribute>ri:memberUid</associationAttribute>
> -               <valueAttribute>ri:uidNumber</valueAttribute>
> +               <valueAttribute>ri:uid</valueAttribute>
> +<!--                    <valueAttribute>ri:uidNumber</valueAttribute>-->
> 
> <explicitReferentialIntegrity>true</explicitReferentialIntegrity>
>             </association>
> 
> 3) I removed <activation> mapping.
> 4) I added attribute ri:uniqueMember mapping for ldapGroups:
> +                <ref>ri:uniqueMember</ref>
> +                              
> <matchingRule>mr:distinguishedName</matchingRule>
> +                <outbound>
> +                       <strength>strong</strength>
> +                       <expression>
> +                               <value>cn=dummy,dc=example,dc=com</value>
> +                       </expression>
> +                </outbound>
> +            </attribute>
> 

At this point, after applying the changes you state above, the unassignment op began working correctly (this was reported on another thread), which means that problem is now resolved.  :-)


> 
> On Apr 7, 2016, at 9:25 AM, Ivan Noris <ivan.noris at evolveum.com> wrote:
> 
> 4) maybe the most important change: entitlement/unixGroup must have
> objectClass as follows:
>      <objectType>
>                        <kind>entitlement</kind>
>                        <intent>unixGroup</intent>
>                        <displayName>UNIX Group</displayName>
> 
>                        <objectClass>ri:posixGroup</objectClass>
> 
> So overall, after those changes the scenarios work just fine in the
> upcoming 3.3.1 release. (git-v3.3support-72-g760e30a)

I did this as well and see no change in behavior (error in console on save).  Again I can create a new user with ldap projection.  And then add unix and ldap roles and it works.  This problem only appears when I try to do all 4 (at same time) before hitting ’save’ button on UI.

Seems that I should redeploy with 3.3.1 release and go from there.

Thanks

Shawn