I have deleted some user objects from the FIM portal but get "access denied" errors when I want to "export" those deletions to AD. Creating & modifying user objects from FIM to AD has no issues.

Checked the FIM ADMA account but that appears to have the right permissions to delete objects from that particular OU and downwards. What am i missing.

Thanks,

JD

Hi,

if the user account have administrative permissions in AD then AdminSGHolder could be the reason.

or maybe permission are not inherited correctly to some objects.

/Peter

Thanks Peter. Had a look on 1 of the OUs from which FIM is trying to delete a user object. Did an "effective access" assesment for the FIM ADMA account and it has (amongst other permissions):

• Delete
• Delete all child objects
• Delete contact objects
• Delete account objects

Not sure what you mean with AdminSGHolder might be causing issues.

Update: deprovisioning of groups works fine.

JD

• Edited by JOTdude 21 minutes ago

Thanks Peter. Had a look on 1 of the OUs from which FIM is trying to delete a user object. Did an "effective access" assesment for the FIM ADMA account and it has (amongst other permissions):

• Delete
• Delete all child objects
• Delete contact objects
• Delete account objects

Not sure what you mean with AdminSGHolder might be causing issues.

Update: deprovisioning of groups works fine.

JD

• Edited by JOTdude Thursday, May 21, 2015 7:05 AM

Thanks Peter. Had a look on 1 of the OUs from which FIM is trying to delete a user object. Did an "effective access" assesment for the FIM ADMA account and it has (amongst other permissions):

• Delete
• Delete all child objects
• Delete contact objects
• Delete account objects

Not sure what you mean with AdminSGHolder might be causing issues.

Update: deprovisioning of groups works fine.

JD

• Edited by JOTdude Thursday, May 21, 2015 7:05 AM

Thanks Peter. Had a look on 1 of the OUs from which FIM is trying to delete a user object. Did an "effective access" assesment for the FIM ADMA account and it has (amongst other permissions):

• Delete
• Delete all child objects
• Delete contact objects
• Delete account objects

Not sure what you mean with AdminSGHolder might be causing issues.

Update: deprovisioning of groups works fine.

JD

• Edited by JOTdude Thursday, May 21, 2015 7:05 AM

Thanks Peter. Had a look on 1 of the OUs from which FIM is trying to delete a user object. Did an "effective access" assesment for the FIM ADMA account and it has (amongst other permissions):

• Delete
• Delete all child objects
• Delete contact objects
• Delete account objects

Not sure what you mean with AdminSGHolder might be causing issues.

Update: deprovisioning of groups works fine.

JD

• Edited by JOTdude Thursday, May 21, 2015 7:05 AM

+1 for Peter's suggestion. I think he may have misspelled, it is called AdminSDHolder. Have a look here - https://technet.microsoft.com/en-us/magazine/2009.09.sdadminholder.aspx

You can also have at the user that it is trying to delete - to see if it has a property set called 'adminCount' and/or has Inherit permission unticked under the Security pane.

Have you checked to see if the object you're trying to delete has "protect this object from accidental deletion" set?  There is a checkbox put on OUs now when they are created via ADUC by default now, and I am thinking that there may be a similar idea for user objects too - if I recall correctly.