[midPoint] AD groups reconciliation

Pavol Mederly mederly at evolveum.com
Wed Jun 25 12:53:00 CEST 2014


Hello Roman,

I've tried to prepare a minimalistic sample to demonstrate 
synchronization of groups between AD and midPoint.

I'll describe it in two steps:

_*Step 1: Basic synchronization of users and groups*__- see 
__*samples/resources/ad/ad-resource-groups-basic.xml*__._

What it does:

*1) **AD->midPoint*

It synchronizes AD accounts and groups from AD to midPoint - i.e. when a 
new account is created in AD, it appears in midPoint as a corresponding 
account shadow and a user. When new group is created, it appears in 
midPoint as a new entitlement shadow and a role.

You can try it to see if it works.

*2) midPoint->AD*

a) It is able to provision users from midPoint to AD: you just have to 
add or assign a user the corresponding resource account.
b) It is able to provision groups from midPoint to AD.

The second point is a bit more complicated: at minimum, you have to tell 
the midPoint that the role should be provisioned to AD.

It is done by adding the following assignment to the role:

    <assignment>
       <construction>
          <resourceRef oid="11111111-2222-3333-4444-000000000000" 
type="ResourceType"/>
          <kind>entitlement</kind>
          <intent>group</intent>
       </construction>
    </assignment>

Just like a user can have assigned an account on a resource, a role can 
have assigned an "account" (a group, in this case) on a resource.

---

What is missing in both cases (a + b), is a rule that would say "any 
user having this role has to have an account on AD with corresponding 
group assigned". For this, an inducement is used. By using inducements, 
you can prescribe not only that an account on a particular resource 
should exist, but you can also set its attributes and/or assignments -- 
and exactly that is what we are interested in: assigning an entitlement 
(a group) that corresponds to this role. You can use 
assignmentTargetSearch, or a less flexible, but perhaps more 
straightforward way that uses a simple object reference:

    <inducement>
       <construction>
          <resourceRef oid="11111111-2222-3333-4444-000000000000" 
type="ResourceType"/>
          <kind>account</kind>
          <association>
             <ref>ri:group</ref>
             <outbound>
                <expression>
                   <value>
                      <shadowRef 
oid="88c95eb4-f2a3-4b63-b269-18696e52c03f"/>
                   </value>
                </expression>
             </outbound>
          </association>
       </construction>
    </inducement>

(note that oid="88c95eb4-f2a3-4b63-b269-18696e52c03f" points to a shadow 
of this role -> i.e. the group we are talking about)

Now, when you assign this role to a user, an account for him will be 
created on a resource, and it will be a member of the given group.

---

MidPoint allows you to avoid all these nuances by using its 
sophisticated mechanisms, namely:
- object templates
- roles with higher-order inducements (meta roles)

An object template is used to automatically assign a meta role to any 
role created.
Meta role is used to create all the necessary assignments/inducements to 
that role.

This leads us to the second step:

_*Step 2: Synchronizing group membership*__- __see 
__*samples/resources/ad/ad-resource-groups-advanced.xml*__._

_*Do not*_ import ad-resource-groups-advanced.xml at this moment, as we 
will import things in it stepwise.

First of all, we create a meta role that will do exactly the thing we 
did manually in the above step:
1) creates an assignment to an AD group on our resource
2) creates an inducement prescribing creation of user accounts with AD 
group on the resource

Note that for the metarole, item #1 is an inducement (as it creates 
assignments for any role that possesses this metarole) and item #2 is an 
second-order inducement (as it creates first-order inducements for any 
role that possesses this metarole).

     <role oid="11111111-2222-3333-4444-200000000001"
xmlns="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
xmlns:c="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
xmlns:t="http://prism.evolveum.com/xml/ns/public/types-3"
xmlns:ri="http://midpoint.evolveum.com/xml/ns/public/resource/instance-3">
         <name>Metarole for groups</name>

         <!-- This inducement causes creation of AD group for any role 
that possesses this metarole -->
         <inducement>
             <construction>
                 <resourceRef oid="11111111-2222-3333-4444-000000000000" 
type="c:ResourceType"/>
                 <kind>entitlement</kind>
                 <intent>group</intent>
             </construction>
         </inducement>

         <!-- This inducement causes creation of AD account that is in 
AD group for any USER that possesses any role that possesses this 
metarole -->
         <!-- That's why this is called second-order inducement -->
         <inducement>
             <construction>
                 <resourceRef oid="11111111-2222-3333-4444-000000000000" 
type="c:ResourceType"/>
                 <kind>account</kind>
                 <intent>default</intent>
                 <association>
                     <ref>ri:group</ref>
                     <outbound>
                         <expression>
                             <associationFromLink>
                                 <projectionDiscriminator>
<kind>entitlement</kind>
<intent>group</intent>
                                 </projectionDiscriminator>
                             </associationFromLink>
                         </expression>
                     </outbound>
                 </association>
             </construction>
             <order>2</order>
         </inducement>

     </role>

Now, if you import this metarole and create a role (e.g. "r1") having 
this metarole assigned, you'll see that on AD a group r1 has been 
created, and a midPoint shadow for it has been created as well, and 
linked to group r1.

Moreover, if you now create a new midPoint user, and assign him role r1, 
his account on AD will be created and it will be a member of r1 AD group.

---

Now, what is missing?

If you create a role in midPoint, you have to manually assign it our 
metarole.
In a similar way, if a group is created in AD, the corresponding role in 
midPoint is again without the metarole.

Here, an object template is going to help us.

     <objectTemplate oid="11111111-2222-3333-4444-300000000001"
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xmlns='http://midpoint.evolveum.com/xml/ns/public/common/common-3'
xmlns:c='http://midpoint.evolveum.com/xml/ns/public/common/common-3'
xmlns:q="http://prism.evolveum.com/xml/ns/public/query-3">
         <name>Role Template</name>

         <mapping>
             <name>Metarole assignment</name>
             <authoritative>true</authoritative>
             <expression>
                 <assignmentTargetSearch>
<targetType>c:RoleType</targetType>
<oid>11111111-2222-3333-4444-200000000001</oid> <!-- our meta role -->
                 </assignmentTargetSearch>
             </expression>
             <target>
                 <path>assignment</path>
             </target>
         </mapping>

     </objectTemplate>

Besides creating the template, we have to tell midPoint to use it for roles.
We have to include the following to the system configuration:

<objectTemplate>
     <type>c:RoleType</type>
     <objectTemplateRef oid="11111111-2222-3333-4444-300000000001"/>
</objectTemplate>

Now, when you create a role (let's say r2), it will get automatically 
assigned the metarole, what causes creation of AD group and automatic 
assignment of this group to any user that has this "r2" role.
In a similar way, when you create a group (let's say r3) in AD, a role 
r3 will be created in midPoint and it will be assigned this metarole.

For more information:

  * https://wiki.evolveum.com/display/midPoint/Entitlements
  * https://wiki.evolveum.com/display/midPoint/Assignment+Configuration
    (namely section "Entitlements Association")
  * https://wiki.evolveum.com/display/midPoint/OrgSync+Story+Test
    (namely section about Responsibility synchronizing - what is
    presented here is basically a simplification of the responsibility
    synchronization of this story test)

Hope this helps. If you would have any questions, just let me know.

Best regards,
Pavol


On 23. 6. 2014 21:24, Roman Pudil - AMI Praha a.s. wrote:
> Hello Pavol,
>
> how about the reconciliation groups sample in Active Directory? Have 
> You any simple example?
>
> Thanks!
> Regards
> Roman
>
> Roman Pudil
> solution architect
>
> gsm: [+420] 775 663 666
> e-mail: roman.pudil at ami.cz <mailto:roman.pudil at ami.cz>
>
> 			
>
> AMI Praha a.s.
> Plánic(kova 11
> 162 00 Praha 6
> tel./fax: [+420] 274 783 239
> web: www.ami.cz <http://www.ami.cz>
>
> 			
>
> AMI Praha a.s.
>
>
> <http://www.ami.cz/reseni-a-sluzby/bezpecnost-dat/identity-management>
>
> Textem tohoto e-mailu podepisující neslibuje uzavr(ít ani neuzavírá za 
> spolec(nost AMI Praha a.s.
> jakoukoliv smlouvu. Kaz(dá smlouva, pokud bude uzavr(ena, musí mít 
> výhradne( písemnou formu.
>
> Dne 12.6.2014 23:35, Pavol Mederly napsal(a):
>> Hello Roman,
>>
>> both Ivan and me are planning to prepare such a sample for group 
>> synchronization in next few days.
>>
>> Unfortunately, both of us have some critical tasks to be done 
>> immediately, so it could take maybe
>> a week until we'll be able to prepare the sample.
>>
>> Best regards,
>> Pavol Mederly
>>
>>> Hi Radovan,
>>> thanks for inspiration.
>>> I tried 3 days to find right combination of AD group schema 
>>> definition, schema handling etc. - with no success.
>>> Somebody tried it with success?
>>>
>>> Thanks!
>>> Roman Pudil
>>>
>>> Roman Pudil
>>> solution architect
>>>
>>> gsm: [+420] 775 663 666
>>> e-mail: roman.pudil at ami.cz <mailto:roman.pudil at ami.cz>
>>>
>>> 			
>>>
>>> AMI Praha a.s.
>>> Plánic(kova 11
>>> 162 00 Praha 6
>>> tel./fax: [+420] 274 783 239
>>> web: www.ami.cz <http://www.ami.cz>
>>>
>>> 			
>>>
>>> AMI Praha a.s.
>>>
>>>
>>> <http://www.ami.cz/reseni-a-sluzby/bezpecnost-dat/identity-management>
>>>
>>> Textem tohoto e-mailu podepisující neslibuje uzavr(ít ani neuzavírá 
>>> za spolec(nost AMI Praha a.s.
>>> jakoukoliv smlouvu. Kaz(dá smlouva, pokud bude uzavr(ena, musí mít 
>>> výhradne( písemnou formu.
>>>
>>> Dne 9.6.2014 18:08, Radovan Semancik napsal(a):
>>>> Hi Roman,
>>>>
>>>> We haven't tried group synchronization in AD yet. But we have done 
>>>> it is LDAP and the principle is the same. Perhaps the best place 
>>>> for inspiration is our "OrgSync" story test. This test synchronized 
>>>> orgunits and groups in the LDAP server. The configuration files are 
>>>> here:
>>>>
>>>> https://github.com/Evolveum/midpoint/tree/master/testing/story/src/test/resources/orgsync
>>>>
>>>> -- 
>>>>
>>>>                                             Radovan Semancik
>>>>                                            Software Architect
>>>>                                               evolveum.com
>>>>
>>>>
>>>> On 06/05/2014 01:03 PM, Roman Pudil - AMI Praha a.s. wrote:
>>>>> Hi,
>>>>> I need synchronize/reconcile AD Groups into midPoint as 
>>>>> Entitlements (Roles). Any simple example about this?
>>>>> Importing groups over midpoint webservices is also acceptable 
>>>>> solution, but when I tried Your example in 
>>>>> \samples\model-client-sample\ it getting error in 3.0 version.
>>>>>
>>>>> Thanks!
>>>>> R. Pudil
>>>>> -- 
>>>>>
>>>>> Roman Pudil
>>>>> solution architect
>>>>>
>>>>> gsm: [+420] 775 663 666
>>>>> e-mail: roman.pudil at ami.cz <mailto:roman.pudil at ami.cz>
>>>>>
>>>>> 			
>>>>>
>>>>> AMI Praha a.s.
>>>>> Plánic(kova 11
>>>>> 162 00 Praha 6
>>>>> tel./fax: [+420] 274 783 239
>>>>> web: www.ami.cz <http://www.ami.cz>
>>>>>
>>>>> 			
>>>>>
>>>>> AMI Praha a.s.
>>>>>
>>>>>
>>>>> <http://www.ami.cz/reseni-a-sluzby/bezpecnost-dat/identity-management> 
>>>>>
>>>>>
>>>>> Textem tohoto e-mailu podepisující neslibuje uzavr(ít ani 
>>>>> neuzavírá za spolec(nost AMI Praha a.s.
>>>>> jakoukoliv smlouvu. Kaz(dá smlouva, pokud bude uzavr(ena, musí mít 
>>>>> výhradne( písemnou formu.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> midPoint mailing list
>>>>> midPoint at lists.evolveum.com
>>>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> midPoint mailing list
>>>> midPoint at lists.evolveum.com
>>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>
>>>
>>>
>>> _______________________________________________
>>> midPoint mailing list
>>> midPoint at lists.evolveum.com
>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20140625/5244e0a1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 2895 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20140625/5244e0a1/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 21628 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20140625/5244e0a1/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 2895 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20140625/5244e0a1/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 21628 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20140625/5244e0a1/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 2895 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20140625/5244e0a1/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 21628 bytes
Desc: not available
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20140625/5244e0a1/attachment-0002.png>


More information about the midPoint mailing list