locked
MIM ADMA and "permission-issue" when Deleting an Account RRS feed

  • Question

  • Hello all,

    Not sure where to start with this.  I suspect it's more of an AD issue than a MIM issue.  None of the posts I've read seem to address this issue specifically.

    My MIM ADMA is throwing a "permission-issue" message when trying to delete an account.  I've managed to mess around with it some and can make it work. But, I'm confused about a few things.

    The account MIM is trying to delete was created by  the ADMA, and owned by the account the ADMA is running under.  The ADMA account is granted full control rights to the parent OU, with inheritance set to this object and all child objects. (the account is actually four levels down).  If I check the security tab of the account, the ADMA account shows up with full control checked (and all the other checkboxes, includeing delete).  Seems pretty simple, to me.  I can't think of any more pertinent information to add.

    What I have done to make it work is: 1) remove the ADMA rights from the parent OU, 2) drill down to the account and assigned the ADMA account full control to the actual account.  After doing that, ADMA will delete the account.  Then, I'll set the ADMA account back to full control at the parent and enable inheritance.

    So, this leads me to believe there's something in the inheritance that's not getting set.  When setting file system rights, there is an option to replace all the child permissions when the changes are applied.  I don't see that option for user accounts.

    To throw another thing at this, I don't have the problem with all the accounts.  It actually seems to be quite rare that I run into this.

    I can't be certain about this final aspect.  I do have cases where there is an account I temporarily do not want MIM messing with. So, I'll break the inheritance on the one account and revoke the ADMA account rights.  When I'm comfortable that MIM isn't going to do something sinister to that account, I'll put the inheritance back.  It's rare that I do that, but in one case, this "permission-issue" has reared its head on an account I have done that to. 

    Is the a way to force the inheritance to propogate throughout the tree?  Is there something I'm missing?

    My "go to" work around has been to just go into AD and manually delete the account. That's quick and dirty and it keeps the ADMA from failing.  But, I'd like to know what's going on.

    Thanks,

    Greg

    Thursday, February 14, 2019 1:07 AM

Answers

  • Figured out the issue in my test domain.  The "Everyone" group had a deny set on the delete at the root of the domain, and at an OU two levels down. Not sure how that got set.  My guess is too many cooks in the kitchen.   But, clearing that solved my issue in my test domain.  That doesn't explain the erratic issues I run into from time to time at client sites, but at least I know where to look now.

    Thanks,

    Greg

    • Proposed as answer by Leo Erlandsson Wednesday, February 20, 2019 9:01 AM
    • Marked as answer by Greg Wilkerson Wednesday, February 20, 2019 1:01 PM
    Tuesday, February 19, 2019 2:12 AM

All replies

  • Hi,

    I see that you have checked the AD permissions.

    Could it be that the account has the adminCount=1 attribute set? This can cause a permission issue.

    This could still be an issue with AD inheritance, but it's worth a check.

    Br,

    Leo


    Did my post help? Please use "Vote As Helpful", "Mark as answer" or "Propose as answer". Thank you!


    Thursday, February 14, 2019 7:16 AM
  • Thanks for th reply, Leo.  I currently have 6 accounts with this issue. I'm tolerating the MIM errors, for now. But, the adminCount attribute is null for all cases.

    Greg

    Thursday, February 14, 2019 1:29 PM
  • Are all of the affected accounts in the same OU? Are the accounts without the issue in that OU? Was thinking there might be a deny on deletion being inherited somewhere.  Another thing to try would be to launch ADUC as your MIM ADMA service account and see if you can delete the account. If it fails, that would eliminate MIM as a suspect - even if it was unlikely as you said.

    Keith

    Thursday, February 14, 2019 1:42 PM
  • Keith,

    Interesting thought. I never thought about running ADUC under those credentials.  Tried it and I could delete an account MIM was having troubles with.  That makes me lean towards a MIM issue, but doesn't explain why I can explictly set the rights on the account and MIM will delete it. 

    To answer your OU question, the accounts are not in the same OU, but decend from an OU just below the root (think organization chart).  The permissions are applied at this top organization OU and inherited down.

    Greg

    Thursday, February 14, 2019 2:53 PM
  • Hello,

    The permission-issue error is due to permission problems on the target objects.  I have experienced one-off problems like this when someone in the past set special AD permissions on the target objects.  Assuming all the user objects in the OU should be treated the same and the OU permissions should be inherited by all objects in the OU, you can use a script like this to find and fix the problem target objects.

    See also, delegating the minimum set of permissions for user provisioning blog post.

    Best,

    Jeff Ingalls

    Monday, February 18, 2019 9:24 PM
  • Hi Jeff,

    Interesting script.  Didn't know how to get to those security settings.  Still a no go.  I ran it, as written, for a single identity.  Did nothing (no feedback, even). Tweaked the script a bit so it would tell me what it was doing, or not doing.  All objects come back with the inheritance enabled.  Tweaked it some more to "SetAccessRulesProtected" regardless of whether the script detected inheritance or not, still no joy.  Still messing with.  Added statement to dump the "ObjectSecurity" and it dumped much more info that I was ready for.  Going to have to delve into that massive list of SIDs/Classes/GUIDs and property settings.  That looks promising, provided I can get it into a manageable format. Investigating.....

    Tuesday, February 19, 2019 1:36 AM
  • Figured out the issue in my test domain.  The "Everyone" group had a deny set on the delete at the root of the domain, and at an OU two levels down. Not sure how that got set.  My guess is too many cooks in the kitchen.   But, clearing that solved my issue in my test domain.  That doesn't explain the erratic issues I run into from time to time at client sites, but at least I know where to look now.

    Thanks,

    Greg

    • Proposed as answer by Leo Erlandsson Wednesday, February 20, 2019 9:01 AM
    • Marked as answer by Greg Wilkerson Wednesday, February 20, 2019 1:01 PM
    Tuesday, February 19, 2019 2:12 AM
  • Thanks for letting us know.  Glad you solved your problem!

    Best,

    Jeff Ingalls

    Wednesday, February 20, 2019 5:12 PM