The set of passwords that *can* be sent down to the RODC
is controlled by password replication policy. The passwords are sent down by RODC’s
request, but the hub also checks whether the user (whose pwd is being requested)
actually attempted to authenticate at RODC (the hub can induce this info from
the traffic is sees). The pwd hash is sent down only if both are satisfied: pwd
policy allows it and the user actually attempted to logon there. Pwd policy is “empty” by default, i.e. nobody is in “allowed
to reveal” list. It is admin’s responsibility to populate this
list. We might have some UI that helps with this process. Once the hash is sent down, there’s no way to remove it
from RODC, basically because we do not trust that RODC will remove it, even if
instructed to do so. Therefore, the only way to “expire” the hash
is to change the password. We store the list of passwords that were sent down
to RODC in an attribute on the RODC computer object (the hub DC updates the
list when it sends a pwd). So, if the RODC is stolen, you can enumerate whose
passwords were down there, and make these users reset their passwords. There’s
a constructed attribute that returns only the users whose *current*
passwords appear to be on the RODC. WRT what data is sent down – currently, we send
everything, sans a handful of “secret” attributes, which are
controlled by pwd replication policy. There’s a DCR to be able to
configure the list of attributes that can go down to RODC (aka RODC PAS), but
it is not yet clear if we will get it done or not. Note that the client data
access story on RODC becomes quite convoluted because you don’t know if
you are seeing the whole object or only a subset of it. We do not normally
issue referrals due to “partial reads”. From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED] RODC stores password hashes only for a pre defined list of users
and they are not stored on a permanent basis. [I'm unclear how the latter is
achieved.] The goal is such that if the RODC were removed from the office then
no password secrets could be extracted from that machine. neil From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick The part that makes me wonder about the "story" is
if it stores no secrets is the server doing anything for me? Is there a
point to deploying the server in a remote office other than just being able to
point to it in the closet and say, "see, I do to earn my
paycheck!" I'm sure there's more, but I don't yet know which parts are
public information and which are NDA. Can you tell I'm concerned about the story being created? I
like stories; don't get me wrong. But I'm concerned that the story being
spun up might be missing the mark and lead a few people astray. Safe to note that there are some features that differentiate
the RODC from a NT4 BDC and that make it appealing in some cases. But if it actually does not store anything locally, ever,
then I'm not sure it's worth the time to deploy one now is it? Al
On 7/27/06, Susan Bradley, CPA aka
Ebitz - SBS Rocks [MVP] <[EMAIL PROTECTED]>
wrote: FYI: PLEASE
READ: The information contained in this email is confidential and intended
for the named recipient(s) only. If you are not an intended recipient
of this email please notify the sender immediately and delete your copy
from your system. You must not copy, distribute or take any further action
in reliance on it. Email is not a secure method of communication and Nomura
International plc ('NIplc') will not, to the extent permitted by law, accept
responsibility or liability for (a) the accuracy or completeness of, or
(b) the presence of any virus, worm or similar malicious or disabling code
in, this message or any attachment(s) to it. If verification of this email
is sought then please request a hard copy. Unless otherwise stated this
email: (1) is not, and should not be treated or relied upon as, investment
research; (2) contains views or opinions that are solely those of the
author and do not necessarily represent those of NIplc; (3) is intended for
informational purposes only and is not a recommendation, solicitation or offer
to buy or sell securities or related financial instruments. NIplc does
not provide investment services to private customers. Authorised and regulated
by the Financial Services Authority. Registered in England no.
1550505 VAT No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand, London,
EC1A 4NP. A member of the Nomura group of companies. |
- RE: [ActiveDir] Read-Only Domain Controller and Server... Dmitri Gavrilov
- RE: [ActiveDir] Read-Only Domain Controller and S... Eric Fleischman
- Re: [ActiveDir] Read-Only Domain Controller a... Al Mulnick
- RE: [ActiveDir] Read-Only Domain Controll... Eric Fleischman
- RE: [ActiveDir] Read-Only Domain Cont... Grillenmeier, Guido
- RE: [ActiveDir] Read-Only Domain... Grillenmeier, Guido
- Re: [ActiveDir] Read-Only Domain Controller and S... Al Mulnick
- RE: [ActiveDir] Read-Only Domain Controller and S... joe