I agree 100%, secure by default, make the admins learn how
to make it less secure. This has been one of the core security issues Microsoft
has had forever. It is good that this has turned around and while it pisses off
the lesser quality admins, it is good for Windows and the computing
community as a whole. If your admins need their hands held, you need new
admins. Get your checkbook out and stop being stingy. :)
I'll take ham, pepperoni, capsicum, black olives,
onions, mushrooms, extra sauce, and garlic butter crust please.
:)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Saturday, July 29, 2006 12:23 PM To: ActiveDir@mail.activedir.org 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 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] Read-O... Al Mulnick
- RE: [ActiveDir] Re... joe
- RE: [ActiveDir... Brian Puhl
- RE: [Activ... Grillenmeier, Guido
- RE: [Activ... joe
- RE: [ActiveDir] Read-Only D... joe
- RE: [ActiveDir] Read-Only D... Paul Mayes
- RE: [ActiveDir] Read-O... Grillenmeier, Guido
- Re: [ActiveDir] Re... Al Mulnick
- RE: [ActiveDir] Re... joe
- Re: [ActiveDir] Read-Only D... Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]
- RE: [ActiveDir] Read-Only D... Grillenmeier, Guido
- RE: [ActiveDir] Read-O... Eric Fleischman