[midPoint] Problem creating new users with their role assignments
Ivan Noris
ivan.noris at evolveum.com
Sun Apr 10 22:26:54 CEST 2016
Hi Shawn,
On 04/08/2016 02:54 PM, Shawn McKinney wrote:
> 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?
>
Yes, that confusion is probably done by me. The role-meta-unix-group.xml
was already in the scenario when I started to deploy it on our our
machines. Then I realized it does not work properly and created
role-meta-unix-group2.xml. The latter is actually used in the story
tests (see TestUnix.java) and it is almost exact copy of what we are
using (the auxiliary object staff is 100% the same).
I need to refresh my memory of how the role-meta-unix-group.xml worked
or not. But the "2" works. I will eventually fix this mess.
If the posixAccount OC is defined in the (meta)role, it means that only
if user has assigned some role which has the unix (2) metarole assigned,
only then he/she will have the posixAccount auxiliary OC. So the
assigning/unassignin the role works like switching between unix/non-unix
enabled LDAP account. That's the magic. So you can have "normal" LDAP
accounts (inetOrgPerson), and by assigning the role which has the unix
(2) metarole assigned, you extend the "normal" LDAP account with the
posixAccount attributes.
Regards,
Ivan
>> 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
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
--
Ing. Ivan Noris
Senior Identity Management Engineer & IDM Architect
evolveum.com evolveum.com/blog/
___________________________________________________
"Semper ID(e)M Vix."
More information about the midPoint
mailing list