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] *On Behalf Of *Alex Alborzfard
*Sent:* Monday, July 31, 2006 4:32 PM
*To:* 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] *On Behalf Of *joe
*Sent:* Monday, July 31, 2006 3:14 PM
*To:* 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] *On Behalf Of *Al Mulnick
*Sent:* Monday, July 31, 2006 12:29 PM
*To:* 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]> 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
------------------------------
*From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
*On Behalf Of *Al Mulnick
*Sent:* Saturday, July 29, 2006 10:06 AM
*To:* 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] > wrote:
But very useful idle chatter nonetheless ;-)
/Guido
*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *Eric Fleischman
*Sent: *Saturday, July 29, 2006 8:35 AM
*To:* 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] *On Behalf Of *Grillenmeier, Guido
*Sent:* Friday, July 28, 2006 11:15 PM
*To:* 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] *On Behalf Of *Eric Fleischman
*Sent: *Friday, July 28, 2006 11:02 PM
*To:* 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] *On Behalf Of *Grillenmeier, Guido
*Sent:* Friday, July 28, 2006 1:33 PM
*To:* 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] *On Behalf Of *Eric Fleischman
*Sent: *Friday, July 28, 2006 9:42 PM
*To:* 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] *On Behalf Of *Al Mulnick
*Sent:* Friday, July 28, 2006 10:34 AM
*To:* 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]> wrote:
To add a bit more?
The part that makes me wonder about the "story" is if it stores no
secrets is the server doing anything for me?
The short answer is yes.
The bulk of the work that a DC does, even in the auth code path, may not
involve the secret. So even if the secret checking work is "outsourced" to a
hub DC, there is a lot more work that the local DC can perform for the user.
For example, if it is an interactive logon, consider all of the GP work
alone that is done that is now local.
At the end of the day, you have a knob?.you can make real security
trade-offs based upon what attack surface you can accept & mitigate, what
administrative story you want, etc. You get to choose what secrets end up on
the RODC. The product is built such that you can turn these knobs as you see
fit but the default knob setting is "more secure".
I hope between my response and Dmitri's you are clear that the belief that
it stores "nothing locally" is incorrect. If more clarity is required please
just holler.
~Eric
------------------------------
*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *Dmitri Gavrilov
*Sent: *Friday, July 28, 2006 9:48 AM
*To:* 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] *On Behalf Of *
[EMAIL PROTECTED]
*Sent:* Friday, July 28, 2006 8:22 AM
*To:* 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]
*On Behalf Of *Al Mulnick
*Sent:* 28 July 2006 16:08
*To:* 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]>
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.
