Thursday, February 16, 2012

adminCount is a killer

Once again, I bumped into the problem described here ( when scheduling export runs for the Active Directory Management Agent.

I decided once and for all to create a one-liner PowerShell command to help me with this problem with missing inherited permissions, adminCount and protected groups (read more about it in blog article referenced above). The right solution would of course be to create administrative account for the user that have this problem, but often times I'm unable to implement this organizational change as part of the project because it occurs extra task, such as new delegations in Active Directory and such.

So often the remedy is to reset the adminCount (through ADSI) and re-enable the inherited permissions using DSACLS for the objects (users) in question. So here is the PowerShell command to do just that -

([ADSISearcher] "adminCount=*").FindAll() | foreach {$User = [ADSI] $_.Path; $User.adminCount.Clear(); $User.SetInfo(); dsacls $User.distinguishedName /p:n}

At one customer, I've put this in the Run Profiles (or MARunScheduler pre-processing job) scheduled task to make sure that necessary permission are present before export from FIM is run against the Active Directory.

Hope this solves some frustration for some FIM admins out there.


Tomek said...

So ... if any of FIM admin will decide to make little modification to this script and to delete all accounts in AD ... uppps ... we're cooked. This is what he will be able to say :). Am I wrong? BTW - what permissions this script is running with?? :) DA? :)?

Søren Granfeldt said...

@Tomek: As I write - "The right solution would of course be to create administrative account for the users that have this problem" and maybe keeping the admin accounts out-of-scope from. However, I do have a few customers who both wanna have their candy and eat it too - and in those cases, this is one way to go.

No matter how, as a FIM admin, you have a very big responsibility.

Tomek said...

Sure ... but responsibility and running a script on DA privileges are not two meanings I would put together in my dictionary :).

Søren Granfeldt said...

Seems like a "hot topic" - I don't disagree with; I usually do this through delegation and NOT Domain Admin permissions which you should only give where necessary.

Matthew McDonald said...

**Take CAUTION running this command**

This command finds and resets all AD objects that have adminCount set, including the default protected AD groups, e.g. Domain Admins.

Running this command essentially removes the SDProp/AdminSDHolder functionality that is there to help protect your domain.

This command should be edited to only reset USERS.