|
To add a bit more… > The part that makes me
wonder about the "story" is if it stores no secrets is the server
doing anything for me? The short answer is yes. The bulk of the work that a DC does, even
in the auth code path, may not involve the secret. So even if the secret
checking work is “outsourced” to a hub DC, there is a lot more work
that the local DC can perform for the user. For example, if it is an
interactive logon, consider all of the GP work alone that is done that is now
local. At the end of the day, you have a knob….you
can make real security trade-offs based upon what attack surface you can accept
& mitigate, what administrative story you want, etc. You get to choose what
secrets end up on the RODC. The product is built such that you can turn these
knobs as you see fit but the default knob setting is “more secure”. I hope between my response and Dmitri’s
you are clear that the belief that it stores “nothing locally” is
incorrect. If more clarity is required please just holler. ~Eric From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Dmitri Gavrilov 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
no. 1550505 VAT No. 447 2492 35. Registered Office: 1 |
- [ActiveDir] Read-Only Domai... Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
- Re: [ActiveDir] Read-O... Al Mulnick
- [ActiveDir] RE: [A... Tim Vander Kooi
- Re: [ActiveDir... Al Mulnick
- RE: [Activ... joe
- RE: [ActiveDir] Read-O... neil.ruston
- RE: [ActiveDir] Re... Dmitri Gavrilov
- RE: [ActiveDir... Eric Fleischman
- Re: [Activ... Al Mulnick
- Re: [ActiveDir... Al Mulnick
- RE: [ActiveDir... joe
- Re: [Activ... Al Mulnick
