[midPoint] AD Groups, Getting Security Violation
Radovan Semancik
radovan.semancik at evolveum.com
Sat Nov 29 13:27:21 CET 2014
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
> <mailto: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 <mailto: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 <mailto: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 <mailto: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
>>> <http://midpoint.evolveum.com/xml/ns/public/resource/instance-3%7DCustomGroupObjectClass>
>>>
>>>
>>> On Thu, Nov 27, 2014 at 4:40 PM, Jason Everling
>>> <jeverling at bshp.edu <mailto: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 <mailto: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
>>> <mailto: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
>>>> <http://midpoint.evolveum.com/xml/ns/public/resource/instance-3%7Dcn>
>>>> * 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
>>>> <http://midpoint.evolveum.com/xml/ns/public/resource/instance-3%7Dcn>
>>>>
>>>>
>>>> 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 list
>>>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>>
>>>
>>> _______________________________________________
>>> midPoint mailing list
>>> midPoint at lists.evolveum.com
>>> <mailto: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 list
>>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> <mailto: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 list
>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>
> --
> Ing. Ivan Noris
> Senior Identity Management Engineer
> evolveum.com <http://evolveum.com> evolveum.com/blog/ <http://evolveum.com/blog/>
> _____________________________________________
> "Semper Id(e)M Vix."
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> <mailto: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 list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20141129/cda8ad9f/attachment.htm>
More information about the midPoint
mailing list