Well, since you offered....I'll take a large pan pepperoni and mushroom.
------------------------------------------------------------------------
*From:* [EMAIL PROTECTED] on behalf of Eric Fleischman
*Sent:* Sat 7/29/2006 11:22 AM
*To:* [email protected]
*Subject:* RE: [ActiveDir] Read-Only Domain Controller and Server Core
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
*Sent:* Friday, July 28, 2006 3:28 PM
*To:* [email protected]
*Subject:* Re: [ActiveDir] Read-Only Domain Controller and Server Core
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]
<mailto:[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]>
[mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>] *On Behalf Of *Al Mulnick
*Sent:* Friday, July 28, 2006 10:34 AM
*To:* [email protected] <mailto:[email protected]>
*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]
<mailto:[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]>
[mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>] *On Behalf Of *Dmitri
Gavrilov
*Sent:* Friday, July 28, 2006 9:48 AM
*To:* [email protected] <mailto:[email protected]>
*Subject:* RE: [ActiveDir] Read-Only Domain Controller and Server Core
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]>
[mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>] *On Behalf Of
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
*Sent:* Friday, July 28, 2006 8:22 AM
*To:* [email protected] <mailto:[email protected]>
*Subject:* RE: [ActiveDir] Read-Only Domain Controller and Server Core
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]> [mailto:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>] *On Behalf Of *Al Mulnick
*Sent:* 28 July 2006 16:08
*To:* [email protected] <mailto:[email protected]>
*Subject:* Re: [ActiveDir] Read-Only Domain Controller and Server Core
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] <mailto:[EMAIL PROTECTED]>> wrote:
FYI:
http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx
<http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx>
Read-Only Domain Controller and Server Core
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
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.
