[Midpoint-dev] Active Directory Group Creation Issue

Dharmendra Parakh dharmendra at confluxsys.com
Sat Mar 7 11:52:49 CET 2015


Hi Pavol,


Thanks for your reply, I tried it doing on other midpoint server which is
connected to different AD server and it worked for me. I am not sure what
is wrong with my setup but i am going to look into this and update you with
my findings.

Thanks a lot for the time you invested in this. I really appreciate your
help.

Regards
Dharmendra

On Fri, Mar 6, 2015 at 7:00 PM, Pavol Mederly <pavol.mederly at gmail.com>
wrote:

>  Hello Dharmendra,
>
> I've tried to replicate the problem in my midPoint. However, in my case,
> everything works as expected.
>
> What I use:
>
> - AD connector 1.4.1.20283 (however, I know of no changes with respect to
> your version that could cause different behavior)
> - midPoint version v3.2devel-188-g409d5e1 (last commit
> 409d5e117c7ddd9e35ce5c2bc4ec6c3ff51bfb8d)
> - your resource configuration, with changes:
>
> <gen70:Container>OU=ConnectorTest,DC=test,DC=***,DC=local</gen70:Container>
> <gen70:DomainName>test.***.local</gen70:DomainName>
>
> (I removed <schema> section)
>
> - then I created a user named "testgroup", filled in some common
> attributes, selected ADD ACCOUNT, entered a value of
> CN=abc,OU=ConnectorTest,DC=test,DC=***,DC=local for the name attribute
>
> The group was created on the resource, the shadow was created in midPoint,
> and when I open the user, I see the "account" created for it.
>
> Back to your situation:
> - are there any errors in ConnectorServer.log (on windows side)?
> - are there any errors in midpoint log?
> - could you enable TRACE debug level for model and provisioning and retry
> the operation? Then could you send me the log? I can have a look on that.
>
> Best regards,
> Pavol
>
>  Hi
>
>  Any other suggestions?
>
>  Thanks!
>
> On Thu, Mar 5, 2015 at 8:58 PM, Dharmendra Parakh <
> dharmendra at confluxsys.com> wrote:
>
>> 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."
>>>
>>>
>>
>
>
> _______________________________________________
> midPoint-dev mailing listmidPoint-dev at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint-dev
>
>
>
> _______________________________________________
> midPoint-dev mailing list
> midPoint-dev at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.evolveum.com/pipermail/midpoint-dev/attachments/20150307/cd169468/attachment-0001.html>


More information about the midPoint-dev mailing list