[Midpoint-dev] Active Directory Group Creation Issue

Ivan Noris ivan.noris at evolveum.com
Thu Mar 5 13:58:23 CET 2015


Hi Dharmendra,

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.
>

And the resource (AD) group still exists...?

I.

> 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/432dbe93/attachment-0001.html>


More information about the midPoint-dev mailing list