[midPoint] AD Groups, Getting Security Violation
Jason Everling
jeverling at bshp.edu
Sat Nov 29 17:30:51 CET 2014
Thanks for the information, I just wanted to make sure I was getting the
expected results. As long as I can make sure that no one is going into AD
and adding/removing users from these groups directly, all is good. They
need to do it all in the Midpoint GUI.
I really was not going to use this feature but after looking at it, I can
have midpoint automatically assign/remove users to these roles based on
attributes and other values, this can be very useful in a sense giving us
dynamic groups in AD that can automatically stay up to date, sort of like
exchange dynamic distribution lists.
JASON
On Sat, Nov 29, 2014 at 6:27 AM, Radovan Semancik <
radovan.semancik at evolveum.com> wrote:
> Hi Jason,
>
> This will not work automatically. The mappings that you use in the roles
> are *outbound* mapping. MidPoint mappings work only in one direction - by
> design. Otherwise it could get very complicated. However, your question
> gave me an idea that something actually could be done in this specific
> case. I have created a Jira issue for this:
>
> https://jira.evolveum.com/browse/MID-2103
>
> I have also realized that midPoint is currently quite weak when it comes
> to inbound synchronization of entitlement associations. Outbound
> synchronization can be done by the means of <construction> but there is no
> equivalent inbound mechanism. There is of course a "feedback" of
> association information to check whether it matches with definitions in
> <construction> blocks during reconciliation - which is kind of
> synchronization towards midPoint. But I guess this is not what you are
> looking for. Your case is actually the very first use of midPoint which is
> using the entitlement associations as a source therefore we have not
> realized that midPoint has this shortcoming. And I would like to thank you
> a lot for pointing that out by asking this question. I have also created a
> Jira issue for this:
>
> https://jira.evolveum.com/browse/MID-2104
>
> In the meantime I do not see any convenient mechanism to do what you want
> to do. But midPoint also has less convenient mechanisms how to do almost
> anything. The thing that you want can be achieved by using the scripting
> hooks:
> https://wiki.evolveum.com/display/midPoint/Scripting+Hooks
> In this case you need to write a custom code that will use the model
> context (https://wiki.evolveum.com/display/midPoint/Model+Context) to
> determine group associations and convert that to role assignments. It is
> definitely doable, however this goes quite deep into the midpoint core and
> it can be somehow complex. And you can always fork midPoint source code on
> github and hack in the solution that you need. In this case it actually
> won't even be a hack at all as midPoint is prepared for "hook" plug-ins so
> this can be done quite cleanly. E.g. this is how we have integrated
> workflow into midPoint. However, there is no convenient documentation about
> this yet therefore you would need to use the source code.
>
> Overall, you are raising an interesting question. Your ideas are good and
> we are definitely going to implement these two features. But right now I
> cannot say when exactly is that going to happen. MidPoint development is
> self-funded. Therefore we have to prioritize the requests from our
> customers/partners that are funding the development (by subscription or by
> other means). Even a nice-to-have request from a midPoint subscriber has a
> much higher priority than any other request from non-subscriber. Therefore
> unless one of the midPoint subscribers uses their influence in favour of
> these features I cannot promise they will get implemented very soon.
>
> --
>
> Radovan Semancik
> Software Architect
> evolveum.com
>
>
>
> On 11/28/2014 06:47 PM, Jason Everling wrote:
>
> So I tested, turns out it needs the 2nd order inducement.
>
> Using Midpoint Gui to add/remove users to roles also add/removes them
> from AD Group, tested, works.
>
> Using AD to add/remove users in Group, does not sync back to Midpoint,
> tested, does not sync, Should this work?
>
> JASON
>
> On Fri, Nov 28, 2014 at 11:28 AM, Jason Everling <jeverling at bshp.edu>
> wrote:
>
>> Meant to say I commented out the 2nd order inducement,
>>
>> JASON
>>
>> On Fri, Nov 28, 2014 at 11:27 AM, Jason Everling <jeverling at bshp.edu>
>> wrote:
>>
>>> Thanks for the followup, yes the groups to roles are created and
>>> vice-versa but users are not synced to roles or groups, I am using the
>>> domain administrator account so it shouldn't be an issue.
>>>
>>> One thing I changed from the original samples was the Metarole, these
>>> lines for the 2nd order incudment. WOuld this be the reason users are not
>>> synced to groups/roles? I had already had a role in midpoint that has the
>>> AD resource inducement so I figured it was not necessary unless I
>>> misinterpreted the comments.
>>>
>>> <!-- This inducement causes creation of AD account that is in AD group for any USER that possesses any role that possesses this metarole --> <!-- That's why this is called second-order inducement --> <inducement> <construction> <resourceRef oid="ef2bc95b-76e0-48e2-86d6-3d4f02d3eaef" type="c:ResourceType"/> <kind>account</kind> <intent>default</intent> <association> <ref>ri:group</ref> <outbound> <expression> <associationFromLink> <projectionDiscriminator> <kind>entitlement</kind> <intent>group</intent> </projectionDiscriminator> </associationFromLink> </expression> </outbound> </association> </construction> <order>2</order> </inducement>
>>>
>>>
>>> On Fri, Nov 28, 2014 at 3:49 AM, Ivan Noris <ivan.noris at evolveum.com>
>>> wrote:
>>>
>>>> Sorry for late responding - but you've already got your solution, it
>>>> was the right track indeed. Not using the samAccountName attribute will
>>>> cause AD to generate a random value (we were using this feature in one
>>>> deployment). This is the same also for Users (and sAMAccountName attribute).
>>>>
>>>> For the future you may also want to check the schema in the resource
>>>> object (Configuration - Repository objects - your AD resource) - you will
>>>> see all usable attributes if you are unsure of which are supported by the
>>>> connector. This works after the schema was fetched, which is the first
>>>> connection to your AD (e.g. the TEST connection for the resource).
>>>>
>>>> Of course this is usable for all other connectors as well.
>>>>
>>>> One more related thing to the permissions: to add/remove AD users to
>>>> the groups, your AD permissions must allow you to modify the *groups*.
>>>> (As the group membership is using the members attribute of the groups.)
>>>> I.e. permissions just to modify Users will be not enough.
>>>>
>>>> But as you are able to create groups, this should be ok now.
>>>>
>>>> Regards,
>>>> Ivan
>>>>
>>>>
>>>> On 11/27/2014 11:56 PM, Jason Everling wrote:
>>>>
>>>> Ah so I was on the right track, it works now, I had seen that
>>>> (samAccountName) in the group schema but thought maybe it was a typo so I
>>>> had changed it to sAMAccountName.
>>>>
>>>> Changed the name for a role and the attribute updated correctly now!
>>>>
>>>> JASON
>>>>
>>>> On Thu, Nov 27, 2014 at 4:50 PM, Pavol Mederly <mederly at evolveum.com>
>>>> wrote:
>>>>
>>>>> Ah, this is a stupidity in original AD connector that I've inherited.
>>>>> (And didn't have the courage to fix up to now.)
>>>>> Sorry for that.
>>>>>
>>>>> For groups, please use *samAccountName* (not sAMAccountName) as for
>>>>> users.
>>>>>
>>>>> Best regards,
>>>>> Pavol
>>>>>
>>>>> Spoke too soon, seems it errors when using sAMAccountName under the
>>>>> object type,
>>>>>
>>>>> Definition of attribute sAMAccountName not found in object class {
>>>>> http://midpoint.evolveum.com/xml/ns/public/resource/instance-3}CustomGroupObjectClass
>>>>>
>>>>>
>>>>> On Thu, Nov 27, 2014 at 4:40 PM, Jason Everling <jeverling at bshp.edu>
>>>>> wrote:
>>>>>
>>>>>> Hah, nevermind, I just needed create a attribute for sAMAccountName
>>>>>> under the objecttype using the +name+ outbound,
>>>>>>
>>>>>> JASON
>>>>>>
>>>>>> On Thu, Nov 27, 2014 at 4:36 PM, Jason Everling <jeverling at bshp.edu>
>>>>>> wrote:
>>>>>>
>>>>>>> Not sure why I didn't think about that after looking at it so many
>>>>>>> times, working now.
>>>>>>>
>>>>>>> One more question, the roles get created in AD as groups now but
>>>>>>> it does not update the sAMAccountName, so it created the
>>>>>>> cn=tester,ou=groups,dc=test,dc=local and common name is testers but the
>>>>>>> sAMAccountName or the Group Name (Pre Windows 2000) is a random value
>>>>>>> like $K61000-DN631FIPKSLL
>>>>>>>
>>>>>>> How can that be fixed?
>>>>>>>
>>>>>>> Thanks Again!
>>>>>>> JASON
>>>>>>>
>>>>>>> On Thu, Nov 27, 2014 at 4:18 PM, Pavol Mederly <mederly at evolveum.com
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> Hello Jason,
>>>>>>>>
>>>>>>>> as far as I know, in Active Directory CN is not updateable. It
>>>>>>>> suffices to create/update icfs:name attribute, and CN is updated
>>>>>>>> automatically.
>>>>>>>>
>>>>>>>> So, I would suggest to drop outbound mapping from CN attribute,
>>>>>>>> i.e. this one:
>>>>>>>>
>>>>>>>> <outbound>
>>>>>>>> <source>
>>>>>>>> <path>$focus/name</path>
>>>>>>>> </source>
>>>>>>>> </outbound>
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Pavol
>>>>>>>>
>>>>>>>>
>>>>>>>> On 27. 11. 2014 19:23, Jason Everling wrote:
>>>>>>>>
>>>>>>>> I cannot figure this one out, I followed the groups sync in the
>>>>>>>> wiki and from the github samples along with the metarole and role template.
>>>>>>>>
>>>>>>>> When creating a role in Midpoint it attempts to create the group
>>>>>>>> in AD but I get an error, look at the debug page it has the correct DN and
>>>>>>>> CN.
>>>>>>>>
>>>>>>>>
>>>>>>>> operation.com.evolveum.midpoint.model.impl.lens.ChangeExecutor.execute
>>>>>>>>
>>>>>>>> - Security violation during processing shadow shadow: null
>>>>>>>> (OID:null): Attempt to add shadow with non-createable attribute {
>>>>>>>> http://midpoint.evolveum.com/xml/ns/public/resource/instance-3}cn
>>>>>>>> - Security violation during processing shadow shadow: null
>>>>>>>> (OID:null): Attempt to add shadow with non-createable attribute {
>>>>>>>> http://midpoint.evolveum.com/xml/ns/public/resource/instance-3}cn
>>>>>>>>
>>>>>>>>
>>>>>>>> Activity Status Resource object (if applicable) Computing
>>>>>>>> projections of the focus object
>>>>>>>>
>>>>>>>> Entitlement (group) on Active Directory
>>>>>>>> Add:Fatal error -> cn=TESTER,ou=Groups,dc=test,dc=local
>>>>>>>>
>>>>>>>> I attached the AD Resource, Role Template, and MetaRole
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> CONFIDENTIALITY NOTICE:
>>>>>>>> This e-mail together with any attachments is proprietary and
>>>>>>>> confidential; intended for only the recipient(s) named above and may
>>>>>>>> contain information that is privileged. You should not retain, copy or use
>>>>>>>> this e-mail or any attachments for any purpose, or disclose all or any part
>>>>>>>> of the contents to any person. Any views or opinions expressed in this
>>>>>>>> e-mail are those of the author and do not represent those of the Baptist
>>>>>>>> School of Health Professions. If you have received this e-mail in error, or
>>>>>>>> are not the named recipient(s), you are hereby notified that any review,
>>>>>>>> dissemination, distribution or copying of this communication is prohibited
>>>>>>>> by the sender and to do so might constitute a violation of the Electronic
>>>>>>>> Communications Privacy Act, 18 U.S.C. section 2510-2521. Please immediately
>>>>>>>> notify the sender and delete this e-mail and any attachments from your
>>>>>>>> computer.
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> midPoint mailing list
>>>>>>>> midPoint at lists.evolveum.com
>>>>>>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> CONFIDENTIALITY NOTICE:
>>>>> This e-mail together with any attachments is proprietary and
>>>>> confidential; intended for only the recipient(s) named above and may
>>>>> contain information that is privileged. You should not retain, copy or use
>>>>> this e-mail or any attachments for any purpose, or disclose all or any part
>>>>> of the contents to any person. Any views or opinions expressed in this
>>>>> e-mail are those of the author and do not represent those of the Baptist
>>>>> School of Health Professions. If you have received this e-mail in error, or
>>>>> are not the named recipient(s), you are hereby notified that any review,
>>>>> dissemination, distribution or copying of this communication is prohibited
>>>>> by the sender and to do so might constitute a violation of the Electronic
>>>>> Communications Privacy Act, 18 U.S.C. section 2510-2521. Please immediately
>>>>> notify the sender and delete this e-mail and any attachments from your
>>>>> computer.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> midPoint mailing list
>>>>> midPoint at lists.evolveum.com
>>>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> CONFIDENTIALITY NOTICE:
>>>> This e-mail together with any attachments is proprietary and
>>>> confidential; intended for only the recipient(s) named above and may
>>>> contain information that is privileged. You should not retain, copy or use
>>>> this e-mail or any attachments for any purpose, or disclose all or any part
>>>> of the contents to any person. Any views or opinions expressed in this
>>>> e-mail are those of the author and do not represent those of the Baptist
>>>> School of Health Professions. If you have received this e-mail in error, or
>>>> are not the named recipient(s), you are hereby notified that any review,
>>>> dissemination, distribution or copying of this communication is prohibited
>>>> by the sender and to do so might constitute a violation of the Electronic
>>>> Communications Privacy Act, 18 U.S.C. section 2510-2521. Please immediately
>>>> notify the sender and delete this e-mail and any attachments from your
>>>> computer.
>>>>
>>>>
>>>> _______________________________________________
>>>> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>>>>
>>>>
>>>> --
>>>> Ing. Ivan Noris
>>>> Senior Identity Management Engineer
>>>> evolveum.com evolveum.com/blog/
>>>> _____________________________________________
>>>> "Semper Id(e)M Vix."
>>>>
>>>>
>>>> _______________________________________________
>>>> midPoint mailing list
>>>> midPoint at lists.evolveum.com
>>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>>
>>>>
>>>
>>
>
>
>
> CONFIDENTIALITY NOTICE:
> This e-mail together with any attachments is proprietary and confidential;
> intended for only the recipient(s) named above and may contain information
> that is privileged. You should not retain, copy or use this e-mail or any
> attachments for any purpose, or disclose all or any part of the contents to
> any person. Any views or opinions expressed in this e-mail are those of the
> author and do not represent those of the Baptist School of Health
> Professions. If you have received this e-mail in error, or are not the
> named recipient(s), you are hereby notified that any review, dissemination,
> distribution or copying of this communication is prohibited by the sender
> and to do so might constitute a violation of the Electronic Communications
> Privacy Act, 18 U.S.C. section 2510-2521. Please immediately notify the
> sender and delete this e-mail and any attachments from your computer.
>
>
> _______________________________________________
> midPoint mailing listmidPoint at lists.evolveum.comhttp://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
--
CONFIDENTIALITY NOTICE:
This e-mail together with any attachments is proprietary and confidential;
intended for only the recipient(s) named above and may contain information
that is privileged. You should not retain, copy or use this e-mail or any
attachments for any purpose, or disclose all or any part of the contents to
any person. Any views or opinions expressed in this e-mail are those of the
author and do not represent those of the Baptist School of Health
Professions. If you have received this e-mail in error, or are not the
named recipient(s), you are hereby notified that any review, dissemination,
distribution or copying of this communication is prohibited by the sender
and to do so might constitute a violation of the Electronic Communications
Privacy Act, 18 U.S.C. section 2510-2521. Please immediately notify the
sender and delete this e-mail and any attachments from your computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20141129/b778502e/attachment.htm>
More information about the midPoint
mailing list