| Author | Messages | |
bdesmond
Posts:366
 | | 07/29/2006 9:05 AM |
| IMHO it would be hard to ship an appliance for an application which
requires designing the hardware around the scenario...
Thanks,
Brian Desmond
brian@xxxxxxxxxxxxxxxx
c - 312.731.3132
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-
> owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Susan Bradley, CPA aka Ebitz -
> SBS Rocks [MVP]
> Sent: Saturday, July 29, 2006 2:50 PM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core
>
> Ah see but I don't like mushrooms.
>
> Stupid question alert?
>
> What's the specs on this? We've always joked that in SBSland with our
> everything including the kitchen sink on our DCs if there was a way to
> make the DC services like on a linksys sized box that attached to the
> file/printer/email/kitchen sink box that would remove a lot of
> "OHMYGOSHYOUDOWHATTOYOURDC!" that we get from the enterprise crowd.
>
> Are there any embedded OS like plans for this server core RODC?
>
> Crawford, Scott wrote:
> > Well, since you offered....I'll take a large pan pepperoni and
> mushroom.
> >
> >
---------------------------------------------------------------------
> -
> > --
> > *From:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx on behalf of Eric
> > Fleischman
> > *Sent:* Sat 7/29/2006 11:22 AM
> > *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
> > *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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] *On Behalf Of *Al
Mulnick
> > *Sent:* Friday, July 28, 2006 3:28 PM
> > *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
> > *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* > > 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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> >
> > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > ] *On Behalf Of *Al
> Mulnick
> > *Sent:* Friday, July 28, 2006 10:34 AM
> >
> >
> > *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
> >
> >
> > *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* > > 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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> >
> > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > ] *On Behalf Of *Dmitri
> > Gavrilov
> > *Sent:* Friday, July 28, 2006 9:48 AM
> >
> >
> > *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
> >
> > *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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> >
> > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > ] *On Behalf Of
> > *neil.ruston@xxxxxxxxxxxxx
> > *Sent:* Friday, July 28, 2006 8:22 AM
> > *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
> >
> > *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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > [mailto:
> > ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > ] *On Behalf Of *Al
> Mulnick
> > *Sent:* 28 July 2006 16:08
> > *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
> >
> > *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]* > sbradcpa@xxxxxxxxxxx > wrote:
> >
> > FYI:
> >
> > 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.
> >
> 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
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 | | | |
| GuidoG
Posts:58
| | 07/29/2006 9:48 AM |
| But very useful idle chatter nonetheless ;-)
/Guido
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Eric Fleischman
Sent: Saturday, July 29, 2006 8:35 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
You basically articulated my point for me. J
> And once tools exist to automate this knowledge whether by
populating groups or attributes (such as office or address)
> or leveraging an OU structure, it really doesn™t matter
which mechanism is used to configure the RODC policies.
Yup. My contention is that in many cases, I think this will be
non-trivial for customers. They will have trouble knowing where security
principals are¦.especially computers. So we need to spend engineering
effort here (the Auth2 list should help with this though).
> However, many companies have organized their AD with a
geographic OU structure, which doesn™t necessarily match
> 100% to their site structure, but certainly gets pretty close
Yes, and because it is not 100%, they™ll either need to move
users around across their OUs (which has other implications, like on
delegation) or use groups to work around it. ;)
My contention is not that OUs are a bad idea for this sort of
policy. Only that:
-
For many customers they will not work. Groups will work for all
customers, even the ones that are already organized by OU¦.simply
provision a group with the OU membership and you have it.
-
If I ran the world and got to choose ever engineering dollar that
we spend, I would want to solve as many problems as I can. Far more customers
will have trouble figuring out what security principals are where than there
are customers that have a 100% site to OU mapping.
My $0.02. Since I don™t make this call, maybe this is idle
chatter. ;)
~Eric
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Grillenmeier, Guido
Sent: Friday, July 28, 2006 11:15 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
Ofcourse OUs don™t fix the underlying challenge of knowing
which user belongs to which site. And once tools exist to automate this
knowledge whether by populating groups or attributes (such as office or
address) or leveraging an OU structure, it really doesn™t matter which mechanism
is used to configure the RODC policies.
However, many companies have organized their AD with a geographic
OU structure, which doesn™t necessarily match 100% to their site
structure, but certainly gets pretty close. And since the delegation
model is often configured such that local admins manage particular aspects of
the users and computers in their site, it is a common practice to move a user
account from one OU to another when the user is relocated to a different
location within the company. As such the OU structure is often a good starting
base to build policies for which credentials to replicate to which RODC¦
I do agree that a lot of the same customers tend to have a security
group that matches the OU a user is located in, simply because an OU is not a
security principal and thus you can™t use it for permissioning (another
long missed feature from Netware). The problem is that without automation tools
(and there are still plenty of customers without these), the OU-specific
users group won™t necessarily be updated as consistently when a
User account is moved from one OU to another.
I am sure that at some point it is a performance thing “ not
sure how this password replication mechanism actually works in the background,
but I think an RODC needs to make decisions at the time of logon of a user:
during the logon process the RODC must determine if it should cache (and then
continue to replicate) the user™s credentials or not. And I guess a
user™s group-membership is analyzed faster than figuring out the OU that
a user belongs to.
Naturally, query based security groups wouldn™t help to
improve performance, but if you could add some nice processes from MIIS to AD
that periodically and dynamically populate AD groups based on LDAP queries
(without the need to support another database), this would certainly
help. And the I would be all for using groups instead of OUs ;-)
/Guido
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Eric Fleischman
Sent: Friday, July 28, 2006 11:02 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
> And currently this is all based on group memberships. I hope
to see an option coming up to use OU™s instead.
To be clear, OUs are a Guido likes the way this looks
feature, not a this helps the problem feature.
The crux of the problem is figuring out who to cache on a given
RODC. If you know this¦by OU membership or something
else¦constructing a group with said membership is trivial. However, if
you don™t know this, OU based policy is not going to help.
With that, I™ll state in public that my vote is not to build
OU based policy. Why? Because it doesn™t fix the problem. Instead, I want
to spend our engineering dollars building tools to help users find who should
be cached where¦ie, tackling the problem itself head on. Whether you then
organize by OU or just populate groups is the easy part.
~Eric
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Grillenmeier, Guido
Sent: Friday, July 28, 2006 1:33 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
Could be worth to note that an RODC can also be a DNS server for
the respective BO. As it is designed for one-way replication from a writeable
DC, it does not allow direct dynamic updates of DNS records that are requested
to be updated by clients that use the RODC as a DNS server (same is true for
password changes) => these are basically forwarded to the next writeable DC
and then replicated back to the RODC. Sounds complicated, but makes sense as
the RODC should be regarded as an untrusted DC.
I am certainly a friend of combining RODC with Server Core for BO
environments. Combine this with the Admin Separation features of RODC and you
have a great BO story. Admin Separation means that you can make a non-domain
admin a member of the local admin group on an RODC, without granting him/her
admin rights in AD. Server Core will obviously not only be useful for BOs
“ they can also host writeable DCs in a company™s datacenters.
Biggest challenge I see is configuring the policies for storing
credentials on RODCs “ it™s the typical challenge of matching
mobile objects (users and notebooks) to non-mobile devices (an RODC in a site).
And currently this is all based on group memberships. I hope to see an option
coming up to use OU™s instead.
I do agree with Al, that the original blog entry that started this
discussion was a little misleading and didn™t do the features of RODC
justice.
/Guido
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Eric Fleischman
Sent: Friday, July 28, 2006 9:42 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
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:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Al Mulnick
Sent: Friday, July 28, 2006 10:34 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Dmitri Gavrilov
Sent: Friday, July 28, 2006 9:48 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of neil.ruston@xxxxxxxxxxxxx
Sent: Friday, July 28, 2006 8:22 AM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al Mulnick
Sent: 28 July 2006 16:08
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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] sbradcpa@xxxxxxxxxxx>
wrote:
FYI:
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. | | | |
| amulnick
Posts:138
| | 07/30/2006 1:55 AM |
| Think about it: You don't have to think about what software to buy with SBS. The most common features are already there. Now you have to consider the hardware. Yuck. Why? Why isn't that pre-packaged? Why isn't it pre-optimized for most of what I do? ISA? Is that something you spread on a bagel to avoid the high-cholesterol spreads? What about this Exchange stuff? It needs what? Anti-something or other?
To have somebody truly take into account 80% of the usage scenarios and optimize a low-cost machine to install this on seems like a natural extension of the product line.
To take that a step further, I have no issues around the appliance concept for AD domain controllers in medium to large businesses (as defined by Microsoft sales, not necessarily what you're thinking of as medium to large.) Think about it for a second: how many of your AD DC's have performance problems? How many people knew it had performance problems? How long do you spend figuring out the configuration for remote office deployments? Or small site deployments? Doesn't have to be a big deal, but in some shops it could be extra time figuring out what you'll need, justifying it, deploying it, adjusting it, upgrading it, etcΏ]. Putting that in a form factor that is already rated at a particular performance benchmark takes a lot of that out of the picture. It simplifies a lot of the configuration information. Can anyway. I can see some shops finding benefit from that.
Ώ] I found myself slipping into the latest 'ism and was going to say "blah blah blah". I slapped my hand and I'm moving on now. :)
On 7/30/06, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] wrote:
I was.(but typically I'm thinking SBSized)Brian Desmond wrote:>> *I wasn't thinking of SBS. SBS could totally be an appliance. I
> thought she meant AD in general. *>> * *>> *Thanks,*>> *Brian Desmond*>> *brian@xxxxxxxxxxxxxxxx*>> * *>> *c - 312.731.3132*
>> * *>> *From:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx
] *On Behalf Of *Al Mulnick> *Sent:* Saturday, July 29, 2006 9:48 PM> *To:* ActiveDir@xxxxxxxxxxxxxxxxxx> *Subject:* Re: [ActiveDir] Read-Only Domain Controller and Server Core
>>>> I have to admit, when I first read that my initial thought was, "why?"> My second thought was, "well, why not?" But in the end my first> instinct won out and I again ask, "why?" I mean, SBS comes on an
> appliance (or am I confusing that with open source version?) But to> dedicate a DC to an appliance AND have an SBS box seems to defeat the> purpose to me.>>>> Virtualization would be a better bet to me.
>>>> RODC on Server Core would be the type of thing that could easily end> up in appliance format. Heck, that's half the time spent - figuring> out hardware to meet the demands. One shortcoming is that an
> appliance is harder to support in this scenario because the settings,> performance, etc are all tied to the greater fabric. Could be a bit> of a support nightmare I'm sure.>>>
> To create an appliance with SBS on it would be of interest. To create> one for a DC doesn't hold a lot of appeal over virtualization to me.>>>> Am I just missing something Susan?
>>>> On 7/29/06, *Brian Desmond* > wrote:
>> IMHO it would be hard to ship an appliance for an application which> requires designing the hardware around the scenario...>> Thanks,> Brian Desmond>
brian@xxxxxxxxxxxxxxxx >> c - 312.731.3132>> > -----Original Message-----> > From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx> [mailto:ActiveDir-> > > owner@xxxxxxxxxxxxxxxxxx ] On
> Behalf Of Susan Bradley, CPA aka Ebitz -> > SBS Rocks [MVP]> > Sent: Saturday, July 29, 2006 2:50 PM> > To: ActiveDir@xxxxxxxxxxxxxxxxxx
> > Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core> >> > Ah see but I don't like mushrooms.
> >> > Stupid question alert?> >> > What's the specs on this? We've always joked that in SBSland with our> > everything including the kitchen sink on our DCs if there was a way to
> > make the DC services like on a linksys sized box that attached to the> > file/printer/email/kitchen sink box that would remove a lot of> > "OHMYGOSHYOUDOWHATTOYOURDC!" that we get from the enterprise crowd.
> >> > Are there any embedded OS like plans for this server core RODC?> >> > Crawford, Scott wrote:> > > Well, since you offered....I'll take a large pan pepperoni and
> > mushroom.> > >> > >> ---------------------------------------------------------------------> > -> > > --> > > *From:*
ActiveDir-owner@xxxxxxxxxxxxxxxxxx> on behalf of Eric> > > Fleischman> > > *Sent:* Sat 7/29/2006 11:22 AM
> > > *To:* ActiveDir@xxxxxxxxxxxxxxxxxx> > > > *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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx> > > > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx> ] *On Behalf Of *Al> Mulnick> > > *Sent:* Friday, July 28, 2006 3:28 PM> > > *To:* ActiveDir@xxxxxxxxxxxxxxxxxx> > > > *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* > > > >> 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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx> > > > >> > > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx> > > > >] *On Behalf Of *Al> > Mulnick> > > *Sent:* Friday, July 28, 2006 10:34 AM> > >> > >> > > *To:*
ActiveDir@xxxxxxxxxxxxxxxxxx> > > > >> > >> > > *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* > > > >> 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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx> > > > >> > > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx> > > > >] *On Behalf Of *Dmitri> > > Gavrilov> > > *Sent:* Friday, July 28, 2006 9:48 AM> > >> > >> > > *To:*
ActiveDir@xxxxxxxxxxxxxxxxxx> > > > >> > > *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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx> > > > >> > > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx> > > > >] *On Behalf Of> > > *neil.ruston@xxxxxxxxxxxxx > >> > > *Sent:* Friday, July 28, 2006 8:22 AM
> > > *To:* ActiveDir@xxxxxxxxxxxxxxxxxx> > > > >> > > *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:*
ActiveDir-owner@xxxxxxxxxxxxxxxxxx> > > > > [mailto:
> > > ActiveDir-owner@xxxxxxxxxxxxxxxxxx>
> > > >] *On Behalf Of *Al> > Mulnick> > > *Sent:* 28 July 2006 16:08> > > *To:* ActiveDir@xxxxxxxxxxxxxxxxxx> > > > >> > > *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]* > >
sbradcpa@xxxxxxxxxxx > >> wrote:> > >> > > FYI:> > >> > > 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.
> > >> > 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> 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
> >>>List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx | | | |
| amulnick
Posts:138
| | 07/30/2006 2:47 AM |
| Virtualization would be a better bet to me.
RODC on Server Core would be the type of thing that could easily end up in appliance format. Heck, that's half the time spent - figuring out hardware to meet the demands. One shortcoming is that an appliance is harder to support in this scenario because the settings, performance, etc are all tied to the greater fabric. Could be a bit of a support nightmare I'm sure.
To create an appliance with SBS on it would be of interest. To create one for a DC doesn't hold a lot of appeal over virtualization to me.
Am I just missing something Susan?
On 7/29/06, Brian Desmond wrote:
IMHO it would be hard to ship an appliance for an application whichrequires designing the hardware around the scenario...
Thanks,Brian Desmondbrian@xxxxxxxxxxxxxxxxc - 312.731.3132> -----Original Message-----> From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-> owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Susan Bradley, CPA aka Ebitz -> SBS Rocks [MVP]
> Sent: Saturday, July 29, 2006 2:50 PM> To: ActiveDir@xxxxxxxxxxxxxxxxxx> Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core>
> Ah see but I don't like mushrooms.>> Stupid question alert?>> What's the specs on this? We've always joked that in SBSland with our> everything including the kitchen sink on our DCs if there was a way to
> make the DC services like on a linksys sized box that attached to the> file/printer/email/kitchen sink box that would remove a lot of> "OHMYGOSHYOUDOWHATTOYOURDC!" that we get from the enterprise crowd.
>> Are there any embedded OS like plans for this server core RODC?>> Crawford, Scott wrote:> > Well, since you offered....I'll take a large pan pepperoni and> mushroom.> >
> >---------------------------------------------------------------------> -> > --> > *From:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
on behalf of Eric> > Fleischman> > *Sent:* Sat 7/29/2006 11:22 AM> > *To:* ActiveDir@xxxxxxxxxxxxxxxxxx> > *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 turningthe> > 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 inwhich> > to ship the product.> >> > This is like ordering pizza for every admin in every forest on the
> planet.> >> > ~Eric> >> >---------------------------------------------------------------------> -> > --> >> > *From:*
ActiveDir-owner@xxxxxxxxxxxxxxxxxx> > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] *On Behalf Of *AlMulnick> > *Sent:* Friday, July 28, 2006 3:28 PM
> > *To:* ActiveDir@xxxxxxxxxxxxxxxxxx> > *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 thetraffic> > and rethink the view on the RODC concept. Like you said, it mayprove> > 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* > > 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 suspectyou> > 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 inAD> > 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 tobe> > 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.... Treatyour> > 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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx> > > > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx> > ] *On Behalf Of *Al> Mulnick> > *Sent:* Friday, July 28, 2006 10:34 AM> >> >> > *To:*
ActiveDir@xxxxxxxxxxxxxxxxxx> > > >> > *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 aspossible> > 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* > > 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 interactivelogon,> > 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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx> > > > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx> > ] *On Behalf Of *Dmitri> > Gavrilov> > *Sent:* Friday, July 28, 2006 9:48 AM> >> >> > *To:*
ActiveDir@xxxxxxxxxxxxxxxxxx> > > > *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 weresent> > 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 theRODC.> >> > 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 listof> > attributes that can go down to RODC (aka RODC PAS), but it is notyet> > 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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx> > > > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx> > ] *On Behalf Of> > *neil.ruston@xxxxxxxxxxxxx > > *Sent:* Friday, July 28, 2006 8:22 AM
> > *To:* ActiveDir@xxxxxxxxxxxxxxxxxx> > > > *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 thelatter> > 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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > [mailto:> > ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > ] *On Behalf Of *Al> Mulnick> > *Sent:* 28 July 2006 16:08> > *To:*
ActiveDir@xxxxxxxxxxxxxxxxxx> > > > *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 theRODC> > 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]* > sbradcpa@xxxxxxxxxxx > wrote:> >> > FYI:> >> >
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.> >> List info : http://www.activedir.org/List.aspx> List FAQ :
http://www.activedir.org/ListFAQ.aspx> List archive: http://www.activedir.org/ml/threads.aspxList info :
http://www.activedir.org/List.aspxList FAQ : http://www.activedir.org/ListFAQ.aspxList archive: http://www.activedir.org/ml/threads.aspx | | | |
| sbradcpa
Posts:317
| | 07/30/2006 3:06 AM |
| SBS doesn't come on an appliance....
remember SBS is now
Windows
Exchange
Sharepoint
ISA (yes we have our firewall on it)
Also running DHCP/DNS/AD
Kitchen Sink
And in the R2 era WSUS
SQL server 2k5 workgroup
But it's not on an appliance... sucky hardware at times yes, but not
appliance.
But virtualization is prob the better way to go... I'm just thinking
also the Centro OS that will be splitting off roles but keeping the
wizardish stuff.
I think you are thinking of Nitix which has an appliance version.
Al Mulnick wrote:
I have to admit, when I first read that my initial thought was, "why?"
My second thought was, "well, why not?" But in the end my first
instinct won out and I again ask, "why?" I mean, SBS comes on an
appliance (or am I confusing that with open source version?) But to
dedicate a DC to an appliance AND have an SBS box seems to defeat the
purpose to me.
Virtualization would be a better bet to me.
RODC on Server Core would be the type of thing that could easily end
up in appliance format. Heck, that's half the time spent - figuring
out hardware to meet the demands. One shortcoming is that an
appliance is harder to support in this scenario because the settings,
performance, etc are all tied to the greater fabric. Could be a bit
of a support nightmare I'm sure.
To create an appliance with SBS on it would be of interest. To create
one for a DC doesn't hold a lot of appeal over virtualization to me.
Am I just missing something Susan?
On 7/29/06, *Brian Desmond* > wrote:
IMHO it would be hard to ship an appliance for an application which
requires designing the hardware around the scenario...
Thanks,
Brian Desmond
brian@xxxxxxxxxxxxxxxx
c - 312.731.3132
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-
> owner@xxxxxxxxxxxxxxxxxx ] On
Behalf Of Susan Bradley, CPA aka Ebitz -
> SBS Rocks [MVP]
> Sent: Saturday, July 29, 2006 2:50 PM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core
>
> Ah see but I don't like mushrooms.
>
> Stupid question alert?
>
> What's the specs on this? We've always joked that in SBSland
with our
> everything including the kitchen sink on our DCs if there was a
way to
> make the DC services like on a linksys sized box that attached
to the
> file/printer/email/kitchen sink box that would remove a lot of
> "OHMYGOSHYOUDOWHATTOYOURDC!" that we get from the enterprise crowd.
>
> Are there any embedded OS like plans for this server core RODC?
>
> Crawford, Scott wrote:
> > Well, since you offered....I'll take a large pan pepperoni and
> mushroom.
> >
> >
---------------------------------------------------------------------
> -
> > --
> > *From:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
on behalf of Eric
> > Fleischman
> > *Sent:* Sat 7/29/2006 11:22 AM
> > *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
> > *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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx
] *On Behalf Of *Al
Mulnick
> > *Sent:* Friday, July 28, 2006 3:28 PM
> > *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
> > *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*
> > >> 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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > >
> > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > >] *On Behalf Of *Al
> Mulnick
> > *Sent:* Friday, July 28, 2006 10:34 AM
> >
> >
> > *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
> > >
> >
> > *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*
> > >> 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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > >
> > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > >] *On Behalf Of *Dmitri
> > Gavrilov
> > *Sent:* Friday, July 28, 2006 9:48 AM
> >
> >
> > *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
> > >
> > *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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > >
> > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > >] *On Behalf Of
> > *neil.ruston@xxxxxxxxxxxxx
>
> > *Sent:* Friday, July 28, 2006 8:22 AM
> > *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
> > >
> > *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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > > [mailto:
> > ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > >] *On Behalf Of *Al
> Mulnick
> > *Sent:* 28 July 2006 16:08
> > *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
> > >
> > *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]* > sbradcpa@xxxxxxxxxxx
>> wrote:
> >
> > FYI:
> >
> > 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.
> >
> 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
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
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 | | | |
| bdesmond
Posts:366
| | 07/30/2006 3:30 AM |
| I wasn™t thinking of SBS. SBS could totally be an appliance. I
thought she meant AD in general.
Thanks,
Brian Desmond
brian@xxxxxxxxxxxxxxxx
c - 312.731.3132
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Al Mulnick
Sent: Saturday, July 29, 2006 9:48 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core
I have to admit, when I first read that my initial thought
was, "why?" My second thought was, "well, why not?"
But in the end my first instinct won out and I again ask,
"why?" I mean, SBS comes on an appliance (or am I confusing
that with open source version?) But to dedicate a DC to an appliance AND
have an SBS box seems to defeat the purpose to me.
Virtualization would be a better bet to me.
RODC on Server Core would be the type of thing that could
easily end up in appliance format. Heck, that's half the time spent - figuring
out hardware to meet the demands. One shortcoming is that an appliance is
harder to support in this scenario because the settings, performance, etc are
all tied to the greater fabric. Could be a bit of a support nightmare I'm
sure.
To create an appliance with SBS on it would be of
interest. To create one for a DC doesn't hold a lot of appeal over
virtualization to me.
Am I just missing something Susan?
On 7/29/06, Brian Desmond brian@xxxxxxxxxxxxxxxx> wrote:
IMHO it would be hard to ship an appliance for an
application which
requires designing the hardware around the scenario...
Thanks,
Brian Desmond
brian@xxxxxxxxxxxxxxxx
c - 312.731.3132
> -----Original Message-----
> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-
> owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Susan Bradley, CPA aka Ebitz -
> SBS Rocks [MVP]
> Sent: Saturday, July 29, 2006 2:50 PM
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> Subject: Re: [ActiveDir] Read-Only Domain Controller and Server Core
>
> Ah see but I don't like mushrooms.
>
> Stupid question alert?
>
> What's the specs on this? We've always joked that in SBSland with our
> everything including the kitchen sink on our DCs if there was a way to
> make the DC services like on a linksys sized box that attached to the
> file/printer/email/kitchen sink box that would remove a lot of
> "OHMYGOSHYOUDOWHATTOYOURDC!" that we get from the enterprise
crowd.
>
> Are there any embedded OS like plans for this server core RODC?
>
> Crawford, Scott wrote:
> > Well, since you offered....I'll take a large pan pepperoni and
> mushroom.
> >
> >
---------------------------------------------------------------------
> -
> > --
> > *From:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
on behalf of Eric
> > Fleischman
> > *Sent:* Sat 7/29/2006 11:22 AM
> > *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
> > *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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
*On Behalf Of *Al
Mulnick
> > *Sent:* Friday, July 28, 2006 3:28 PM
> > *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
> > *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* efleis@xxxxxxxxxxxxxxxxxxxxx
> > > 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:* ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> >
> > [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> > ] *On Behalf Of *Al
> Mulnick
> > *Sent:* Friday, July 28, 2006 10:34 AM
> >
> >
> > *To:* ActiveDir@xxxxxxxxxxxxxxxxxx
> >
> >
> > *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* efleis@xxxxxxxxxxxxxxxxxxxxx
> > >
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.
> |
|
|