Only if your sister’s name is Cindy ;-) From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Crawford, Scott Well, since you offered....I'll take a large pan pepperoni and
mushroom. From: [EMAIL PROTECTED] on
behalf of Eric Fleischman 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 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 D... Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
- RE: [ActiveDir] Read-O... Brian Desmond
- Re: [ActiveDir] Re... Al Mulnick
- Re: [ActiveDir... Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
- Re: [ActiveDir... Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
- RE: [ActiveDir] Read-O... Grillenmeier, Guido
- RE: [ActiveDir] Re... Crawford, Scott
- RE: [ActiveDir] Read-O... joe
- Re: [ActiveDir] Re... Al Mulnick