[Midpoint-dev] Active Directory Group Creation Issue

Dharmendra Parakh dharmendra at confluxsys.com
Thu Mar 5 16:28:07 CET 2015


Hi Ivan

I tried both the setups but no luck. Still the group is getting created in
AD but midpoint is not storing the shadow.


Thanks!

On Thu, Mar 5, 2015 at 6:39 PM, Ivan Noris <ivan.noris at evolveum.com> wrote:

>  Hi Dharmendra,
>
> can you please try with this:
>
> ...
> <connectorConfiguration>
> *                       <icfc:resultsHandlerConfiguration>*
> *
> <icfc:enableFilteredResultsHandler>false</icfc:enableFilteredResultsHandler>*
> *                        </icfc:resultsHandlerConfiguration>*
>
>             <!-- Configuration specific for the Active Directory connector
> -->
>                         <icfc:configurationProperties
> ...
>
> Alternatively:
>
>                         <icfc:resultsHandlerConfiguration>
>                                 <icfc:enableFilteredResultsHandler>*true*
> </icfc:enableFilteredResultsHandler>
>                                 <icfc:enableCaseInsensitiveFilter>*true*
> </icfc:enableCaseInsensitiveFilter>
>                         </icfc:resultsHandlerConfiguration>
>
> But please start with the *first* setup. The first config will switch off
> the result handler filtering in ICF; the second will let it turned on, but
> switch to case insensitive...
>
> Please let us know. Thanks you.
>
> Regards,
> Ivan
>
>
> On 03/05/2015 12:08 PM, Dharmendra Parakh wrote:
>
> Hi Ivan
>
>  I could not find the shadow in midpoint's repository page (xml). I think
> probably this is the problem that midpoint did not store the shadow somehow.
>
>  No attribute of this resource is dependent on user/role attributes, user
> is going to enter the value.
>
>  Thanks
>
> On Thu, Mar 5, 2015 at 3:53 PM, Ivan Noris <ivan.noris at evolveum.com>
> wrote:
>
>>  Hi Dharmendra,
>>
>> so far I can't see any reason for not working, especially if it works in
>> LDAP.
>>
>> Can you please check this:
>>
>> - open your user in midPoint's repository pages (XML)
>> - check the oid of the Shadow in linkRef
>> - open the shadow in midPoint's repository pages (XML)
>> - check the attributes attributes/icfs:name and attributes/icfs:uid -
>> they should be at the bottom of the object. Are this ok?
>>
>> midPoint seems to be unable to find the object - as this is AD, it should
>> be located by the GUID (icfs:uid).
>> I have a strange feeling that this is related to string case.
>>
>> BTW. I don't see any outbounds to generate icfs:name for that group; is
>> this done in the role(s)? Does the name somehow depend on user attributes?
>>
>> Regards,
>> Ivan
>>
>>
>> On 03/05/2015 10:38 AM, Dharmendra Parakh wrote:
>>
>> Hi Ivan
>>
>>  Thanks for all the information.
>>
>>  My requirement is just to create a AD group on the target and at this
>> point I do not want to assign this group to any user. So basically we want
>> to use this resource for group creation purpose only.
>>
>>  I am well aware of the way you have described for group creation as
>> entitlement (I have tried that and it works) but we want to avoid the
>> multiple steps involved in entitlement creation and also we want to create
>> this under a user/role as an assignment/account only because group
>> management becomes easy for us this way. As i have mentioned we are doing
>> the same in case of ldap resource and that is working for us. I cannot
>> think of any reason why midpoint will behave differently for ad and ldap.
>>
>>  AFAIK for connector group is just an object class like account so i
>> think it should work logically. I think i am missing something or i have
>> some issue in resource. I will appreciate any help on this.
>>
>>
>>  Thanks!
>>
>>
>>
>> On Thu, Mar 5, 2015 at 2:39 PM, Ivan Noris <ivan.noris at evolveum.com>
>> wrote:
>>
>>>  Hi Dharmendra,
>>>
>>> I'm not sure if I understand what you try to achieve.
>>>
>>> Do you want to create AD group for given user in midPoint? Or do you
>>> want to create the group through midPoint and then assign to user?
>>>
>>> I would definitely not change the default object class for "account" to
>>> CustomGroupObjectClass. Just use kinds and intents in schema handling.
>>>
>>> In my project I have the following setup: I want to create users in
>>> midPoint, accounts for them in AD. I also want to create groups (and other
>>> objects) in AD that belong to organizations in midPoint (part of org.
>>> structure replication). And I also want to put AD accounts to these groups.
>>> The simplified example follows:
>>>
>>> 1. in resource, I define new kind=entitlement and
>>> intent=group-municipality, e.g.:
>>>         <objectType>
>>>             <kind>*entitlement*</kind>
>>>             <intent>*group-municipality*</intent>
>>>             <displayName>Municipality groups</displayName>
>>>             <default>true</default>
>>>             <objectClass>ri:*CustomGroupObjectClass*</objectClass>
>>>             <attribute>
>>> . . .
>>>
>>> This means that I'm able to reference groups of this "type" (I have
>>> several different types of groups) as kind=entitlement and
>>> intent=group-municipality.
>>>
>>> 2. in resource, I define association for *accounts* with this kind of
>>> groups:
>>>                         <objectType>
>>>                         <kind>*account*</kind>
>>>                                 <intent>*default*</intent>
>>>                                 <displayName>Default Account -
>>> Municipality users</displayName>
>>>                                 <default>true</default>
>>>                                 <objectClass>ri:*AccountObjectClass*
>>> </objectClass>
>>> . . .
>>>             <association>
>>>                 <ref>ri:adGroups</ref>
>>>                 <tolerant>true</tolerant>
>>>                 <matchingRule>mr:stringIgnoreCase</matchingRule>
>>>                 <kind>*entitlement*</kind>
>>>                 <intent>*group-municipality*</intent>
>>>                 <direction>objectToSubject</direction>
>>>                 <associationAttribute>ri:member</associationAttribute>
>>>                 <valueAttribute>icfs:name</valueAttribute>
>>>
>>> <explicitReferentialIntegrity>false</explicitReferentialIntegrity>
>>>             </association>
>>>         </objectType>
>>>
>>> This means midPoint is able to associate AD accounts with this type of
>>> groups and will show the "Association" part in GUI when editing user - list
>>> of groups for that account.
>>>
>>> 3. to *assign AD account to any existing AD group* (EmailAllUsers in
>>> this example), I have a role in midPoint:
>>>
>>> <role xmlns="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
>>> <http://midpoint.evolveum.com/xml/ns/public/common/common-3>
>>>         xmlns:c=
>>> "http://midpoint.evolveum.com/xml/ns/public/common/common-3"
>>> <http://midpoint.evolveum.com/xml/ns/public/common/common-3>
>>>         xmlns:icfs=
>>> "http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3"
>>> <http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3>
>>>         xmlns:q="http://prism.evolveum.com/xml/ns/public/query-3"
>>> <http://prism.evolveum.com/xml/ns/public/query-3>
>>>         xmlns:ri=
>>> "http://midpoint.evolveum.com/xml/ns/public/resource/instance-3"
>>> <http://midpoint.evolveum.com/xml/ns/public/resource/instance-3>
>>>         oid="b4b5059a-5cdc-4a2c-a184-bb6e0c67e064">
>>>    <name>E-Mail</name>
>>>     <inducement>
>>>         <construction>
>>>                 <!-- The c: prefix in type must be there due to a JAXB
>>> bug -->
>>>                 <resourceRef oid="00000000-0000-0000-0001-100000000002"
>>> type="c:ResourceType"/>
>>>         <association>
>>>             <ref>ri:adGroups</ref>
>>>             <outbound>
>>> <strength>strong</strength>
>>>                 <expression>
>>>                     <associationTargetSearch>
>>>                         <filter>
>>>                             <q:equal>
>>>                                 <q:path>
>>>                                         declare namespace icfs=
>>> "http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3"
>>> <http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3>
>>> ;
>>>                                         declare namespace ri=
>>> "http://midpoint.evolveum.com/xml/ns/public/resource/instance-3"
>>> <http://midpoint.evolveum.com/xml/ns/public/resource/instance-3>;
>>>                                         attributes/ri:samAccountName
>>>                                 </q:path>
>>>                                 <expression>
>>>                                     <script>
>>>                                         <code>
>>> return '*EmailAllUsers*' <!-- group's sAMAccountName in AD -->
>>> </code>
>>>                                     </script>
>>>                                 </expression>
>>>                             </q:equal>
>>>                         </filter>
>>>                     <searchOnResource>true</searchOnResource>
>>>                     </associationTargetSearch>
>>>                 </expression>
>>>             </outbound>
>>>         </association>
>>> </construction>
>>> </inducement>
>>> </role>
>>>
>>> If this role is assigned to user in midPoint, it will create AD account
>>> (if it does not exist yet) it will search for a group named "EmailAllUsers"
>>> (by sAMAccountName) and add user to that group if such group exists.
>>>
>>> 4. if you want to *create groups* in AD from midPoint, they must be
>>> regarded as a projection of either User, Organization or Role in midPoint.
>>> In my scenario, for some Organization I create the type of groups I
>>> referred to above by assignin a role to an *organization*, e.g.:
>>>
>>> <role oid="00000000-0000-0000-0004-000000000010"
>>>         xmlns=
>>> "http://midpoint.evolveum.com/xml/ns/public/common/common-3"
>>> <http://midpoint.evolveum.com/xml/ns/public/common/common-3>
>>>         xmlns:c=
>>> "http://midpoint.evolveum.com/xml/ns/public/common/common-3"
>>> <http://midpoint.evolveum.com/xml/ns/public/common/common-3>
>>>         xmlns:t="http://prism.evolveum.com/xml/ns/public/types-3"
>>> <http://prism.evolveum.com/xml/ns/public/types-3>>
>>>     <name>Meta-role for organizational structure replication to AD</name>
>>>     <inducement>
>>>         <construction>
>>>                 <!-- AD resource -->
>>>                 <resourceRef oid="00000000-0000-0000-0001-100000000002"
>>> type="c:ResourceType"/>
>>>  *               <kind>entitlement</kind>*
>>> *                <intent>group-municipality</intent>*
>>>         </construction>
>>>     </inducement>
>>> ...
>>> </role>
>>>
>>> This means that midPoint will create a group of that type for the
>>> organization in midPoint. Of course, in schemaHandling for AD resource, in
>>> the kind=entitlement and intent=group-municipality part, you have to define
>>> proper outbound mappings (icfs:name = DN; sAMAccountName and possibly other
>>> attributes) to actually create the group.
>>>
>>> And that's all, so simple.
>>>
>>> Some examples can be also seen in our OrgSync scenario wiki page:
>>> https://wiki.evolveum.com/display/midPoint/OrgSync+Story+Test (it is
>>> different scenario as I've described in my example, but it's very usable
>>> for concept understanding).
>>>
>>> Hope this helps.
>>> Regards,
>>> Ivan
>>>
>>>
>>> On 03/05/2015 09:44 AM, Dharmendra Parakh wrote:
>>>
>>>  Hi
>>>
>>>  I have been playing around with AD Connector and i am facing an issue
>>> where i was trying to create an AD group using the AD Connector.
>>>
>>>  I have a resource configured where the default object class is my AD
>>> Group object class and kind is set to account.
>>> When i try to create the group by creating a account of this resource i
>>> see the* group is created on Active Directory* but same does not show
>>> up in the midpoint UI under User's accounts panel.
>>>
>>>  I can see the linkRef in user's xml but it is not getting loaded in UI
>>> and also when i open the user xml i see an error:
>>>
>>>   [RA({.../connector/icf-1/resource-schema-3}uid):[PPV(String:<guid=b611c389eb74224ba3cae9b9738ba1a6>)]],
>>> objectclass={.../resource/instance-3}CustomGroupObjectClass: Object
>>> identified by
>>> [RA({.../connector/icf-1/resource-schema-3}uid):[PPV(String:<guid=b611c389eb74224ba3cae9b9738ba1a6>)]]
>>> was not found by connector:1529887f-2adc-4a76-99fd-75d34c865332(ICF
>>> Org.IdentityConnectors.ActiveDirectory.ActiveDirectoryConnector
>>> v1.4.1.20257 @ConnectorServer27:22:8759)
>>>  com.evolveum.midpoint.util.exception.ObjectNotFoundException: Object
>>> not found.
>>> identifiers=[RA({.../connector/icf-1/resource-schema-3}uid):[PPV(String:<guid=b611c389eb74224ba3cae9b9738ba1a6>)]],
>>> objectclass={.../resource/instance-3}CustomGroupObjectClass: Object
>>> identified by
>>> [RA({.../connector/icf-1/resource-schema-3}uid):[PPV(String:<guid=b611c389eb74224ba3cae9b9738ba1a6>)]]
>>> was not found by connector:1529887f-2adc-4a76-99fd-75d34c865332(ICF
>>> Org.IdentityConnectors.ActiveDirectory.ActiveDirectoryConnector
>>> v1.4.1.20257 @ConnectorServer27:22:8759)
>>>   at
>>> com.evolveum.midpoint.provisioning.consistency.impl.ObjectNotFoundHandler.handleError(ObjectNotFoundHandler.java:268)
>>> ~[provisioning-impl-3.2-SNAPSHOT.jar:na]
>>>   at
>>> com.evolveum.midpoint.provisioning.impl.ShadowCache.handleError(ShadowCache.java:683)
>>> ~[provisioning-impl-3.2-SNAPSHOT.jar:na]
>>>
>>>
>>>
>>>  We have similar setup for ldap group provisioning and that works very
>>> fine.
>>>
>>>  I have attached my resource xml with the email, please have a look and
>>> let me know if i am doing anything wrong here.
>>>
>>>
>>>  Regards
>>> Dharmendra
>>>
>>>
>>>  _______________________________________________
>>> midPoint-dev mailing listmidPoint-dev at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint-dev
>>>
>>>
>>> --
>>>   Ing. Ivan Noris
>>>   Senior Identity Management Engineer & IDM Architect
>>>   evolveum.com                     evolveum.com/blog/
>>>   ___________________________________________________
>>>   "Semper Id(e)M Vix."
>>>
>>>
>>> _______________________________________________
>>> midPoint-dev mailing list
>>> midPoint-dev at lists.evolveum.com
>>> http://lists.evolveum.com/mailman/listinfo/midpoint-dev
>>>
>>>
>>
>> --
>>   Ing. Ivan Noris
>>   Senior Identity Management Engineer & IDM Architect
>>   evolveum.com                     evolveum.com/blog/
>>   ___________________________________________________
>>   "Semper Id(e)M Vix."
>>
>>
>
> --
>   Ing. Ivan Noris
>   Senior Identity Management Engineer & IDM Architect
>   evolveum.com                     evolveum.com/blog/
>   ___________________________________________________
>   "Semper Id(e)M Vix."
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.evolveum.com/pipermail/midpoint-dev/attachments/20150305/e2efe8b5/attachment-0001.html>


More information about the midPoint-dev mailing list