[midPoint] AD Groups, Getting Security Violation
Jason Everling
jeverling at bshp.edu
Fri Nov 28 18:47:54 CET 2014
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20141128/6d0ff230/attachment.htm>
More information about the midPoint
mailing list