Partager via

Recovering "Lost" ADAM Admin Access

  • Article

Consider the following scenario. You install ADAM/LDS as a particular user account. Lets assume its a normal domain user account with local administrative rights on a member server. So the install proceeds normally and you create the ADAM instance. Assume you use the same account to create other replicas of the configuration set.

Now assume you delete the user account used for the install some time later after you've populated the ADAM instance. Lets say the account is deleted and garbage collected too :) The point is we don't have access to that account (SID to be precise) and the password that goes along with it.

When an ADAM/LDS is installed using a certain account, that account is added to the ADAM/LDS configuration set's Administrators role. However, if no other Administrators are defined and the ADAM administrator account credentials are not available/usable, then you may find yourself with an ADAM install you "believe" you don't have full control for.

But fret not for there is a way to recover from this scenario. The procedure is documented by Lee Flight at

https://groups.google.co.uk/group/microsoft.public.active.directory.interfaces/browse_thread/thread/ade9cf248b0804b0

Essentially we end up following the following steps.

  1. Open a command prompt or logon as an account with "Take ownership of files and other objects" right. I.e. by default local administrators of the server with the ADAM instance will do.
  2. Take ownership of the #ConfigurationNamingContext NC itself.
  3. Write an inheritable ACE at the config NC root which grants full control (GA) to a user/group of your choice. This could be your own credentials. We will be removing this ACE soon.
  4. Modify the CN=Administrators,CN=Roles,CN=Configuration,CN=<GUID> group and add the user/group from the previous step as a member. Else make whatever changes to the membership as you see fit.
  5. Remove the inheritable ACE configured at step3.

From my experience I prefer to use adsiedit.msc to modify the membership of the groups. This is because it creates the Foreign Security Principal Objects (FSP) for me. If I use ldp or other tools I need to have the FSP ready.

I also prefer the ldp.exe in ADAM for doing granular permissions. However, configuring permissions like GA is much easier using dsacls. Please remember to type the path as \\server:port\CN=Configuration,CN={GUID} instead of simply the DN without the \\server:port part.

I've seen instances where customers that lost the credentials in someway or another have resorted to migrating from one ADAM instance to another or even sometimes rebuild. When the solution really is so easy.

I personally find the above example as a good way of explaining how local admin rights (or more precisely certain security rights) can be "exploited" on a server. This is why one must be careful in granting local administrative rights to a user/service/group.

HTH

M

Comments