[Midpoint-dev] Active Directory Group Creation Issue
Pavol Mederly
pavol.mederly at gmail.com
Fri Mar 6 14:30:37 CET 2015
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
ofCN=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 <mailto: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 <mailto: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 <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 <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
> http://lists.evolveum.com/mailman/listinfo/midpoint-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.evolveum.com/pipermail/midpoint-dev/attachments/20150306/0eb311fb/attachment-0001.html>
More information about the midPoint-dev
mailing list