Add Windows Security Principal as ADAM Admin via LDIFDE?

[jeff henrichs]

What we are trying to do:
Backup a production ADAM instance (NTBackup) and restore into a lab
environment for troubleshooting.

Issue #1:
Lab environment has no trusts to production, so Windows security
principal ADAM administrators are unavailable.

Issue #2:
ADAM security principals with admin rights (we have the hotfix and
AllowADAMUsersInConfigPartition [sic] = 1) cannot be used to access the
directory using ADAM ADSI Edit, our preferred tool. We need a Windows
account for this (see issue #1).

Proposed Solution:
Create ADAM security principle in config partition, make it an ADAM
admin. Restore directory backup to lab. Access directory via LDIFDE
with -a switch specifying ADAM user credentials (DN, password). Use
LDIFDE in import mode to add a well-known group (local admins,
Everyone, etc) to the Administrators role on the config partition.
Connect in ADAM ADSI Edit using credentials matching this well-known
Windows group.

Current Problem:
In ADAM ADSI Edit when I add a Windows account to the Administrators
member attribute, ADAM automatically creates a foreignSecurityPrinciple
object for the account in CN=ForeignSecurityPrinciple container, and
adds the corresponding DN to the member attribute. To do this via
LDIFDE, I first need the foreignSecurityPrinciple object to be created
(adding its DN to the member attribute is trivial). However, when I
try to create a foreignSecurityPrinciple object via LDIFDE, I get
complaints about require attribute missing. Looking at the schema,
this seems to be the objectSid attribute. If I try to specify the
well-known SID with the appropriate encoding (taken from an LDIFDE
export of another instance), I get a security error. I understand this
is because the system is supposed to create this automatically... which
it does in ADAM ADSI Edit (which we cannot access)... all of which begs
my question:

Is there a way to use an ADAM admin account that is an ADAM security
principle, and use that to add a Windows account as an ADAM
Administrator (presumably through a tool like LDIFDE)? I rarely use
LDP.exe, so maybe there is something there I have missed...

Many thanks for any help or suggestions.

[Lee Flight]

Hi

how about adding a portable group like

Builtin Administrators group (SID S-1-5-32-544)

to the Administrators role on your production ADAM instance
and then taking the backup and then restoring the backup to
your test environment? You could then remove the builtin group
from the production instance again once you have taken the backup.
The test environment will then not be an exact match for production
but I cannot think for any significant difference this approach would
entail.

Lee Flight

"jeff henrichs" <jeffhe...@gmail.com> wrote in message
news:1138251220.6...@o13g2000cwo.googlegroups.com...

[Joe Kaplan (MVP - ADSI)]

Also, if you add the member to the group with LDIFDE using the SID binding
string for the group (which must be base64 encoded), the FSP should be
created by the directory on the fly. Isn't this what you get, Lee?

But yeah, just having built-in adminstrators as an Admin on the instance to
begin with seems reasonable.

Joe K.

"Lee Flight" <l...@le.ac.uk-nospam> wrote in message
news:uiO5BZmI...@TK2MSFTNGP15.phx.gbl...

[Lee Flight]

Hi

yes the FSP should be created. I think the problem may be a that
an ADAM principal as Administrator may not have the correct
security context to add a Windows SID. I would have to try a repro.
to check.

Lee Flight

"Joe Kaplan (MVP - ADSI)" <joseph....@removethis.accenture.com> wrote
in message news:uXv0Q1qI...@TK2MSFTNGP15.phx.gbl...

[jeff henrichs]

Thanks guys. I've suggested exactly that (adding the local Admins
group to the backup image) where we have an opportunity to do so. The
concern is more that we take nightly backups automatically, and our
local admins are not granted ADAM admin rights, so it's considered a
security exposure to automatically add them in and take them out. Put
more directly, our backup images won't have any well-known SIDs in them
by default.

Re: Joe's comment, the only way I know to add the Windows account to
the ADAM admins role is to do:

dn: CN=Administrators,CN=Roles,CN=Configuration,CN={GUID}
changetype: modify
add: member
member: DN_of_the_FSP

using this approach, I'm not sure how the objectSID gets in... that's
why I tried to manually create the FSP object (which blew up).

Am I missing a SID-based step/attribute in trying to add the windows
account to the Admin group's member attribute? I'm not sure I
understand "the SID binding string".

Thanks again,
Jeff

[Dmitri Gavrilov [MSFT]]

Local admins on a box running ADAM have full control over the instance. They
can start/stop the service. They can restore the DIT. They can debug the
process. Finally, they have take_ownership privilege, which allows them to
change any ACL in ADAM to whatever they want.

To add an FSP, you must use the following syntax:

dn: CN=Administrators,CN=Roles,CN=Configuration,CN={GUID}
changetype: modify
add: member

# member: <SID=S-1-5-XXX-XXX-XXX>
member:: base64-encoded-value-above
-

--
Dmitri Gavrilov
SDE, DS Admin eXperience

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"jeff henrichs" <jeffhe...@gmail.com> wrote in message

news:1138403171.4...@g47g2000cwa.googlegroups.com...