BTW, I wasn't trying to suggest that people should spend less money on
security, just that there are a lot of financial and technical
considerations that we don't have control over, so we have to target
our security proposals to a real world where companies do want to
lower their overall costs and the people saying "Cut your budget and I
don't care what the implications are" (while that's not necessarily
exactly they are saying, that's the gist of it).
Creating security models that, when the decision makers look at the
costs involved, are going to get denied is a waste of time (and time
is money) and will just end up with you having to come up with another
model that will meet the requirements, including the monetary
requirements. It's either that or we end up deceiving our client
(boss, whatever) on the actual cost of the security model that we're
implementing.
I think we'd all love to have a blank check for security
considerations, but we all know that's not going to happen now or any
time in the future.
On 8/1/06, * Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]*
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
>From the pentest listserve...
"If you spend more on coffee than on IT security, you will be hacked.
What's more, you deserve to be hacked.
-- former White House cybersecurity czar Richard Clarke "
Matt Hargraves wrote:
> You made a comment in the previous thread that I think is rather
> interesting:
>
> "Get your checkbook out and stop being stingy. :) "
>
> That's a nice thing to say when you're saying it to someone
else. But
> if they tell you that you have to spend hundreds of thousands of
> dollars or millions when they have metrics that require them to
reduce
> the costs or it's their job.
>
> I'm not trying to minimize the importance of security and least
> privileged access. Reality is though that we don't control what the
> rest of the company does, no matter how much 'for their good' it
might
> be. We don't own the data, we don't own the groups. We own the
> servers, the OS and the security model itself. We can simply
provide
> the tools and try and steer them down the right path, while
trying to
> make sure it's a path that they can walk down. The minute we
make a
> path that's too difficult to walk down, the path will get changed on
> us for a more managable model, with only a chance that we're
involved
> at all. More likely it will be someone who has no knowledge of the
> environment and is building a straight forward "MS says...."
> environment that could potentially be worse than what is already in
> place, but the people who are now making the decisions aren't very
> busy listening to us any more.
>
>
>
> On 8/1/06, *Matt Hargraves* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:
>
> Without going with an Access-Based Security (ABS) model,
there are
> few ways to make sure that all of the people who need access
to an
> object are the only ones who are getting access. Local server
> security groups (which are difficult to manage), a smallish
> environment, user-based ACLs on rights and objects, or a very
> strange environment, there is no other way to have a 100%
accurate
> security environment for resources.
>
> Access based security is nice because it is very granular,
but the
> problem with it is that it has a very high level of maintenance
> and has a lot of room for error and a lot of inherent cost in
> hardware. The larger the environment, the larger the number of
> points of failure in the security model. You have 100,000
shares
> in an environment (or more) and the number of people
required to
> manage that resource start getting restrictively high.
>
> Does John the Crankshaft mechanic need access to share
> "\\servername\share80385"? Probably not 95% of the time,
but that
> one or two times a year that he does need access, do you really
> want to make him wait between 2 hours and potentially as
high as 2
> days to gain that access just so that you an have 100 people
> controlling 1,000 shares and the ACLs each?
>
> I can't argue that RBS is the only way to go, but there's
nothing
> wrong with going with a hybrid. RBS base with an ABS
overlap ends
> up with a security model where you've got the potential for
> granularity, but a system where a resource has a team that may
> need access to an object, they can be granted that access
and if
> there are individuals who need access above and beyond what the
> RBS model would grant, the access can be granted. Users who
> change roles are automatically removed from the groups they
are no
> longer members of (via the HR software, SAP or whatever) and
when
> someone moves into a role where they now require access to a
> resource (or set of resources), they are automatically granted
> that access via the same mechanism.
>
> The alternative is a forest root with disjoined domain that
holds
> users, then a resource subdomain and an Exchange subdomain. 2-3
> times as many DCs, added cost that goes with that (power,
a/c, NOC
> space), added overhead of maintaining that somewhat complex
> environment... the alternative for larger environments is to buy
> 2-3 times as many Exchange servers due to large token
sizes. Not
> to mention the bloating of your DIT database causing reduced
> performance on your DCs.
>
> An exclusive RBS is a best-case scenario that almost never
> exists. But it should be the basis of a security model. The
> alternative is a bloated environment and a bloated management
> structure for that environment.
>
> An exclusive ABS is another best-case scenario that rarely
exists
> outside of smaller environments, where management of
resources is
> easier to control because the people who are controlling the
> resource know everyone who needs access to their resource.
>
> Considering how large the companies you commonly work with are,
> it's suprising to see you recommending a difficult to manage
> model. With hundreds of thousands of users and possibly a
nearly
> identical number of shares (or worse... more) and a large
number
> of applications, it's hard to see where an ABS is practical.
>
>
>
>
> On 7/31/06, *joe* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
>
> If I am fixing security bugs in my program is it ok to
get 80%
> of them and leave the remaining known 20%?
>
> Do you have a lot of faith in a firewall that stops 80%
of the
> bad traffic? Or an AV scanner that finds 80%?
>
> If I set up a shared folder to get files shared out to
> multiple folks, is it ok if only 80% of the people I give
> access to really need the access? What if in that shared
> folder are personal files about you or your wife or your
kids
> or maybe some compromising photos of you and your
mistress[1]? :)
>
> How about the flip side, if I set up a shared folder and
only
> 80% of the folks who need the access get it, is that good?
>
> Would you have a list of people in the DA group where
only 80%
> really needed the access? Or again on the flip side,
only 80%
> of the people who required it got it?
>
>
> Security should be very tightly controlled. Especially for
> access.
>
> Role based security fits squarely in this hole, IMO. It is
> probably more a problem with the implementation and the
> definition of the roles than anything because if you really
> got into defining really granular roles that you should, you
> are almost at the point of doing resource based security
> anyway which again, IMO, is by far the more secure way of
> handling resource security. It is rare that the data access
> requirements of everyone listed as a CrankShaft
Engineer, for
> example, are identical in a company. Sure, a good portion of
> the folks will all access the same things but it isn't
good to
> say well then, the Role Crankshaft engineers gets all of
these
> accesses. Those of you don't really need the access but
are in
> the role... don't look at that data... Pshaw. I just
said this
> the other day on another list but good fences make good
> neighbors. You don't trust people not to do bad things,
you do
> everything you can to prevent them from having the
opportunity
> to do the bad thing in the first place. With resource based
> access, you give the people who need the access to the
> resource the access. It is much easier overall to figure out
> who has the access and remove folks who don't need it.
>
> joe
>
>
>
> [1] Not sure why anyone would need to those photos but
if they
> were being shared, certainly the fewer the better and most
> certainly only the folks who are absolutely required.
>
>
> --
> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
>
>
>
>
------------------------------------------------------------------------
> *From:* [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
> [mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>] *On Behalf Of
> *Alex Alborzfard
> *Sent:* Monday, July 31, 2006 4:32 PM
> *To:* ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>
> <mailto:ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>>
> *Subject:* RE: [ActiveDir] Read-Only Domain Controller and
> Server Core
>
> Can you elaborate on why you think 80/20 concept in security
> is sloppy joe (no pun intended!)?
>
>
>
> Alex
>
>
------------------------------------------------------------------------
>
> *From:* [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> [mailto:
> [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>] *On Behalf Of *joe
> *Sent:* Monday, July 31, 2006 3:14 PM
> *To:* ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>
> <mailto: ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>>
> *Subject:* RE: [ActiveDir] Read-Only Domain Controller and
> Server Core
>
>
>
> It is a sensitive spot with me, I think 80/20 is a great
> concept, but in security it is a bit sloppy.
>
>
>
> --
>
> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
>
>
>
>
>
>
>
>
------------------------------------------------------------------------
>
> *From:* [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> [mailto:
> [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>] *On Behalf Of *Al
> Mulnick
> *Sent:* Monday, July 31, 2006 12:29 PM
> *To:* ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>
> <mailto:ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>>
> *Subject:* Re: [ActiveDir] Read-Only Domain Controller and
> Server Core
>
> Darned if you weren't the only one to pick up on it. :)
>
>
>
>
>
>
>
> On 7/30/06, *joe* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
>
> Argh there it is.... 80/20 in a security discussion. Oi!
>
>
>
> :)
>
>
>
> --
>
> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
<http://www.joeware.net/win/ad3e.htm>
>
>
>
>
>
>
>
>
------------------------------------------------------------------------
>
> *From:* [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> [mailto:
> [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>] *On Behalf Of *Al
> Mulnick
>
> *Sent:* Saturday, July 29, 2006 10:06 AM
>
>
> *To:* ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>
> <mailto:ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org> >
> *Subject: *Re: [ActiveDir] Read-Only Domain Controller and
> Server Core
>
>
>
>
> Agreed. Very useful.
>
>
>
> Guido, I'm curious. You mentioned this:
>
>
>
> "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…"
>
>
>
>
> How many of your customers do you see that travel between
> those sites and what would be the implications in your
scenario/s?
>
>
>
> This has been a problem that I have seen many times in the
> past. I'm just curious what you've seen and how it's been
> solved. In my case, I see everything from no technical
> resource on site (sometimes not even opposable thumbs
that we
> can count on) to a local administrator. Often this
depends on
> historical vs. business logic. To date, most designs I have
> been involved with have been the 80/20 of "yep, that'll take
> care of most of your issues, but there will be
exceptions and
> here's the plan for that". Some have also favored business
> unit logical lines. What I mean by that is a business
unit's
> computing resources are deployed as cookie cutter as
possible
> with the idea that almost the entire business unit will not
> need what a different business unit needs per se. Another
> factor is the geographical and co-location of business units
> and some shared resources that the units might have.
Typically
> a blend of the two approaches(base for *all* users anywhere,
> and business unit centric) has worked out since the
> co-location of business units makes sense for some
organizations.
>
>
>
> But I'm wondering if you've seen differently? If anyone else
> sees another way of solving the issue, I'm interested in
> hearing about it if you can share. I wonder about it
because
> trying to get them to fit into an OU by geography can be a
> tough approach with lots of touch times. They will
constantly
> move in and out of many different geo's during a given time
> period. The users move around a lot as well and some have
> high turnover.
>
>
>
> Interesting.
>
>
>
> Al
>
>
>
>
> On 7/29/06, *Grillenmeier, Guido* <
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
>
> But very useful idle chatter nonetheless ;-)
>
>
>
> /Guido
>
>
>
> *From:* [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>[mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>] *On Behalf Of
> *Eric Fleischman
> *Sent: *Saturday, July 29, 2006 8:35 AM
>
>
> *To:* ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>
> <mailto:ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org> >
> *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:* [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>[mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>] *On Behalf Of
> *Grillenmeier, Guido
> *Sent:* Friday, July 28, 2006 11:15 PM
> *To:* ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>
> <mailto:ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>>
> *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:* [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>[mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> >] *On Behalf Of
> *Eric Fleischman
> *Sent: *Friday, July 28, 2006 11:02 PM
> *To:* ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>
> <mailto: ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>>
> *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:* [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>[mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> >] *On Behalf Of
> *Grillenmeier, Guido
> *Sent:* Friday, July 28, 2006 1:33 PM
> *To:* ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>
> <mailto: ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>>
> *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:* [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>[mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>] *On Behalf Of
> *Eric Fleischman
> *Sent: *Friday, July 28, 2006 9:42 PM
> *To:* ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>
> <mailto:ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>>
> *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:* [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>[mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> >] *On Behalf Of *Al
> Mulnick
> *Sent:* Friday, July 28, 2006 10:34 AM
> *To:* ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>
> <mailto: ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>>
> *Subject:* Re: [ActiveDir] Read-Only Domain Controller and
> Server Core
>
>
>
> More clarity is always welcome.
>
>
>
> I suspect I'm trying to get my mind around the GPO providing
> that much value that I would want to put a DC in the local
> brach as part of the design vs. trying really hard to
use as
> little of the GPO as possible and making sure that the
changes
> are as infrequent as possible.
>
>
>
> Authentication and name resolution are my biggest uses
for a
> local DC in a branch. Outside of Exchange of course.
> Everything else I try to keep as compartmentalized as I can
> because if my WAN is a concern such that I can't use
> authentication across the wire (or can't trust it) then
I have
> some big concerns about the branch environment and how
> autonomous it is.
>
>
>
> Outside of "GP work" what else comes to mind that is
> off-loaded to the local site that you can think of?
>
>
>
> Perhaps I'm looking at this sideways?
>
>
>
> On 7/28/06, *Eric Fleischman*
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>> wrote:
>
> To add a bit more…
>
>
>
> > The part that makes me wonder about the "story" is if it
> stores no secrets is the server doing anything for me?
>
>
>
> The short answer is yes.
>
> The bulk of the work that a DC does, even in the auth code
> path, may not involve the secret. So even if the secret
> checking work is "outsourced" to a hub DC, there is a
lot more
> work that the local DC can perform for the user. For
example,
> if it is an interactive logon, consider all of the GP work
> alone that is done that is now local.
>
>
>
> At the end of the day, you have a knob….you can make real
> security trade-offs based upon what attack surface you can
> accept & mitigate, what administrative story you want, etc.
> You get to choose what secrets end up on the RODC. The
product
> is built such that you can turn these knobs as you see
fit but
> the default knob setting is "more secure".
>
>
>
> I hope between my response and Dmitri's you are clear
that the
> belief that it stores "nothing locally" is incorrect. If
more
> clarity is required please just holler.
>
>
>
> ~Eric
>
>
>
>
>
>
------------------------------------------------------------------------
>
> *From:* [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>[mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>] *On Behalf Of
> *Dmitri Gavrilov
> *Sent: *Friday, July 28, 2006 9:48 AM
>
>
> *To:* ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>
> <mailto:ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>>
> *Subject:* RE: [ActiveDir] Read-Only Domain Controller and
> Server Core
>
>
>
> The set of passwords that **can** be sent down to the
RODC is
> controlled by password replication policy. The passwords are
> sent down by RODC's request, but the hub also checks
whether
> the user (whose pwd is being requested) actually
attempted to
> authenticate at RODC (the hub can induce this info from the
> traffic is sees). The pwd hash is sent down only if both
are
> satisfied: pwd policy allows it and the user actually
> attempted to logon there.
>
>
>
> Pwd policy is "empty" by default, i.e. nobody is in
"allowed
> to reveal" list. It is admin's responsibility to
populate this
> list. We might have some UI that helps with this process.
>
>
>
> Once the hash is sent down, there's no way to remove it
from
> RODC, basically because we do not trust that RODC will
remove
> it, even if instructed to do so. Therefore, the only way to
> "expire" the hash is to change the password. We store
the list
> of passwords that were sent down to RODC in an attribute on
> the RODC computer object (the hub DC updates the list
when it
> sends a pwd). So, if the RODC is stolen, you can enumerate
> whose passwords were down there, and make these users reset
> their passwords. There's a constructed attribute that
returns
> only the users whose * *current** passwords appear to be on
> the RODC.
>
>
>
> WRT what data is sent down – currently, we send everything,
> sans a handful of "secret" attributes, which are
controlled by
> pwd replication policy. There's a DCR to be able to
configure
> the list of attributes that can go down to RODC (aka RODC
> PAS), but it is not yet clear if we will get it done or not.
> Note that the client data access story on RODC becomes
quite
> convoluted because you don't know if you are seeing the
whole
> object or only a subset of it. We do not normally issue
> referrals due to "partial reads".
>
>
>
> *From:* [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>[mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> >] *On Behalf Of
> [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
> *Sent:* Friday, July 28, 2006 8:22 AM
> *To:* ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>
> <mailto:ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>>
> *Subject:* RE: [ActiveDir] Read-Only Domain Controller and
> Server Core
>
>
>
> RODC stores password hashes only for a pre defined list of
> users and they are not stored on a permanent basis. [I'm
> unclear how the latter is achieved.]
>
>
>
> The goal is such that if the RODC were removed from the
office
> then no password secrets could be extracted from that
machine.
>
>
>
>
>
> neil
>
>
>
>
------------------------------------------------------------------------
>
> *From:* [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> [mailto:
> [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>] *On Behalf Of *Al
> Mulnick
> *Sent:* 28 July 2006 16:08
> *To:* ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>
> <mailto:ActiveDir@mail.activedir.org
<mailto:ActiveDir@mail.activedir.org>>
> *Subject: *Re: [ActiveDir] Read-Only Domain Controller and
> Server Core
>
> The part that makes me wonder about the "story" is if it
> stores no secrets is the server doing anything for me? Is
> there a point to deploying the server in a remote office
other
> than just being able to point to it in the closet and say,
> "see, I do to earn my paycheck!"
>
>
>
> I'm sure there's more, but I don't yet know which parts are
> public information and which are NDA.
>
>
>
> Can you tell I'm concerned about the story being created? I
> like stories; don't get me wrong. But I'm concerned
that the
> story being spun up might be missing the mark and lead a few
> people astray.
>
>
>
> Safe to note that there are some features that differentiate
> the RODC from a NT4 BDC and that make it appealing in
some cases.
>
> But if it actually does not store anything locally,
ever, then
> I'm not sure it's worth the time to deploy one now is it?
>
>
>
> Al
>
>
>
>
>
>
>
> On 7/27/06, *Susan Bradley, CPA aka Ebitz - SBS Rocks
[MVP]* <
> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:
>
> FYI:
>
>
http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx
<http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx>
>
<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
> <http://www.activedir.org/List.aspx
<http://www.activedir.org/List.aspx>>
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.activedir.org/ml/threads.aspx
<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
<http://www.activedir.org/ml/threads.aspx>
