|
I want to make one other thing clear….the
other reason to ship the product in this state is secure by default. Out of the box, we have no idea what
secrets you will want on the RODC. We don’t know your enterprise or your threat
model. As such, there’s really no good choice….we too would be implicitly
turning the knob for “better out of the box admin experience” vs “more secure
out of the box.” No good choices. So, even if you assume that this state is
good for no one (a contention I’ll disagree with, there are some enterprises
that will do this, but that’s not the point), it is still the right state in
which to ship the product. This is like ordering pizza for every admin
in every forest on the planet. ~Eric From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Al Mulnick That's the ~Eric we've come to know :) Thanks for that view. I'll take your advice and check for the
traffic and rethink the view on the RODC concept. Like you said, it may prove
uninteresting, but after that amount of information from you, Dmitri and Guido,
I'd hate to leave that stone unturned. I'll ping back if I get lost watching the traces. I appreciate the
offer and you guys taking the time to discuss this. Al On 7/28/06, Eric
Fleischman <[EMAIL PROTECTED]>
wrote: Hi Al, Take your workstation and take a sniff of a logon. All
traffic you throw at the DC will work against the RODC. The only WAN traffic in
that scenario would be the auth itself, a tiny amt of work. (assuming GC and
all that is satisfied locally) So, the statement that authentication is your biggest use is
true, kinda…you need to more carefully define the operation. I suspect you
don't mean auth in the Kerberos sense, you mean "user logon" really.
Unless your branch has a bunch of apps that do Kerb work and no clients….then
you can correct me and we have a totally different conversation on our hands.
:) Answering some questions of yours, from this and other forks
of the thread….. > What conditions would make it so that the
password policy would be configured such that the password replication > was
not allowed? There is a policy (not group policy, administrative one
defined in AD itself) which defines what can be cached there and what can not.
The statement made (I think first by Dmitri, but I then commented on it
further) was that by default, this policy allows almost nothing to be cached.
You could tweak this in your enterprise and change what is cached, anything
from the near-nothing default to almost every secret in the domain. You can
choose. > Would that just be that the RODC is no
longer trusted (i.e. it was abducted or otherwise compromised?) Well, we never know if an RODC was compromised. Rather, RODC
was built such that you the admin can assume they are compromised, and fully
understand the scope of compromise in your enterprise should it happen one day,
and respond to said event. So, I say you should look at this problem the other way….
Treat your RODCs as if they were
about to get compromised, then make real decisions around how much work the
recovery from said compromise would be vs. actually having an environment that
is useful, reliable, easy to manage, etc. That's what I was talking about re:
the knobs….you can turn said knobs and make decisions that work for you. And
we'll have documentation that will help you do this. > Or
is that something that some admin can configure and hurt themselves? Better
yet, if that were true, is there any value left in the > RODC
that can't get a password hash? I think I answered this but please holler if it is still
unclear. > Outside of "GP work" what else
comes to mind that is off-loaded to the local site that you can think of? Take a network sniff of your clients talking to your DCs for
a day. Almost all of that stuff. J You could have apps, you have logon itself, etc. > Perhaps I'm looking at this sideways? Every environment is different. It is entirely possible that
a secret-less RODC is totally uninteresting in your enterprise. That said, I
would argue that you probably haven't done enough investigation yet to really
know if that's true or not…it's not personal, why would you? This has likely
never been relevant. Almost no one does this sort of analysis unless they
absolutely have to. Take some data, please report back to us. I'd love to look at
said data with you if you're unclear as to what would fall in what bucket. Hope this helps. Please holler back with questions. ~Eric From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of Al Mulnick Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core More
clarity is always welcome. I suspect
I'm trying to get my mind around the GPO providing that much value that I would
want to put a DC in the local brach as part of the design vs. trying really
hard to use as little of the GPO as possible and making sure that the changes
are as infrequent as possible. Authentication
and name resolution are my biggest uses for a local DC in a branch.
Outside of Exchange of course. Everything else I try to keep as
compartmentalized as I can because if my WAN is a concern such that I can't use
authentication across the wire (or can't trust it) then I have some big
concerns about the branch environment and how autonomous it is. Outside
of "GP work" what else comes to mind that is off-loaded to the local
site that you can think of? Perhaps
I'm looking at this sideways? On
7/28/06, Eric Fleischman <
[EMAIL PROTECTED]> wrote: 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 |
- Re: [ActiveDir... Al Mulnick
- RE: [ActiveDir] Read-Only D... Eric Fleischman
- RE: [ActiveDir] Read-O... Crawford, Scott
- Re: [ActiveDir] Re... Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
- RE: [ActiveDir... Brian Desmond
- Re: [Activ... Al Mulnick
- RE: [ActiveDir] Re... Grillenmeier, Guido
- RE: [ActiveDir... Crawford, Scott
- RE: [ActiveDir] Read-O... joe
- RE: [ActiveDir] Read-Only D... Paul Mayes
