[Midpoint-dev] Active Directory Group Creation Issue
Ivan Noris
ivan.noris at evolveum.com
Thu Mar 5 14:09:37 CET 2015
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
> <mailto: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 <mailto: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 list
>>> midPoint-dev at lists.evolveum.com <mailto: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 <http://evolveum.com> evolveum.com/blog/ <http://evolveum.com/blog/>
>> ___________________________________________________
>> "Semper Id(e)M Vix."
>>
>>
>> _______________________________________________
>> midPoint-dev mailing list
>> midPoint-dev at lists.evolveum.com
>> <mailto: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 <http://evolveum.com> evolveum.com/blog/ <http://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/432672ce/attachment-0001.html>
More information about the midPoint-dev
mailing list