[Midpoint-dev] Active Directory Group Creation Issue
Dharmendra Parakh
dharmendra at confluxsys.com
Fri Mar 6 11:58:13 CET 2015
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."
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.evolveum.com/pipermail/midpoint-dev/attachments/20150306/f8f06b8d/attachment-0001.html>
More information about the midPoint-dev
mailing list