| Author | Messages | |
amulnick
Posts:138
 | | 07/31/2006 4:50 AM |
| Might still save some performance in the sense that they can logon and pull GPO etc. And I still need a chance to see the rest of the traffic to test ~Eric's information. (not really test, but rather come up to speed with it).
That's why I'm curious how you envision figuring who logs on where and how you'd map that in a way that makes sense. By "you" I'm referring to anyone who'd like to comment.
Al
On 7/31/06, Grillenmeier, Guido wrote:
RODCs do NOT replicate a subset of objects => right now they basically replicate everything a normal DC has (i.e. the full domain NC, config and schema), less the password hashes of any users.
The OU vs. group discussion was solely around configuring the so called "Password Replication Policy" (bad name) for an RODC “ and after discussing this here and offline, doing various tests and elaborating about possible usage scenarios, I agree that configuring this policy by OU doesn't really give you enough flexibility. I would actually love to configure it by an LDAP query leveraging any appropriate attributes “ but this is simply to resource intensive during the authentication. Leveraging groups gives us the option to automatically provision the memberships appropriately though. Don't forget, you'll have to do this for users and computers.
Why is "Password Replication Policy" a bad name? Because that's not what it does “ calling it "Password Caching Policy" would be more appropriate, as an RODC would never store a users pwd-hash unless he has logged onto that RODC. Once the pwd is changed, an RODC will NOT update the hash “ it will only be updated the next time a user uses that same RODC. I don't mind this mechanism “ it provides an automatic "cleanup" mechanism and thus lowers the attack surface if a policy allowed many RODCs to cache a users PWD. But the name "Replication Policy" suggests that an RODC would actually replicate the new password when it is changed on a WDC (writeable DC), which is confusing.
Replicating only parts of a tree (i.e. only specific OUs) would be a totally different story, which I also hope to see in the future (but won't be part of this version of RODC). However, RODCs will also be able to replicate the GC partitions (making them an ROGC) “ but from what I understand this will only be sufficient for authenticating, but not to be used as a GC for Exchange (I guess since Exchange simply needs that writeable domain partition). So placing an ROGC in a remote site will not be sufficient if you also have an Exchange server in that site.
Exchange 2007 edge servers is yet another different story “ not sure if they can benefit from RODCs.
/Guido
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Paul MayesSent:
Monday, July 31, 2006 1:39 AMTo: activedir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Read-Only Domain Controller and Server Core
Apologies as I'm reading in digest. But I just wanted to chip something into this surrounding OU's versus groups as it was something that I've been thinking about on my mind-numbing commute.
I understood that RODC's could be configured to be a read only subset of objects (users) from the writeable AD, or that you could set them to cache which would also be useful to catch user population at a given site if this was unknown. I remember there being a long discussion at the back of DEC about people wanting the subset replication to be based around OU's rather than groups, and lots of people being quite passionate about it. The thing that struck me was how would you then deal with group membership where the group was sat in a totally different part of the tree? Somehow you've got to get that closed set to work with, which is very loosely linked to migration strategies. (Blimey I must have paid attention on that migration course all of those years ago.). And then you've got constraints on OU structures for if they are now partitions for replication in some capacity.
How wrong is this understanding?
If it's kind of right, then at some point in the future are we going to see multiple domain partitions hosted on DC's? 'Cos that would be nice as well as the ability to replicate subsets as read only. Where a GC could hold writeable copies of domain partitions that weren't from it's particular domain in the forest¦.. etc¦ mmm DC consolidation, the possibilities!
Then going more OT. There were also rumblings about ROGC's so that didn't contain sensitive info and could be used purely for email purposes without the baggage of a full fat DC. Is this correct and how does this relate to Exchange 2007 and it's Edge servers, which from what I can gather are looking to suck bits of the AD into an ADAM for kind of the same purpose as an ROGC would perform? I may be totally babbling now.
RE: [ActiveDir] Read-Only Domain Controller and Server Core
From: "Grillenmeier, Guido"
Al, that's basically getting back at what Eric said and the more I think about it, the more I have to agree: there is only a certain percentage of companies that are able to setup an OU structure by geography and certainly no single OU structure will fit for all companies. I have myself worked with quite a lot of customers, where OUs by location made sense “ but also some that had a mix of location-OUs for computers and business units-OUs for users. And others simply adjust it to their helpdesk model “ depending on who needs to manage which part of the world.
Thinking more about the travel bit, it will be easy to understand that this doesn't make the password caching story any easier. If you want full coverage for WAN outages (which is the main reason that you want to cache the passwords in the first place), then you may need to match those traveling users (and computers) to multiple sites “ this is where the fun begins with figuring out how to handle the password replication policies for RODCs. Granted, OUs suddenly make less sense, since a user and a computer can only be in a single OU, but they can belong to multiple groups¦ | | | |
| efleis1
Posts:0
| | 07/31/2006 5:51 AM |
| Commenting further on one other item in
this list¦.
> We currently have info available to tell us where people are
authenticating, it just isn't the easiest to get the reports because the
> info isn't centralized. If we could
work in the direction of getting that info centralized it could make it more
useful as the
> mechanism to help make the decisions.
To be clear, we thought of this already. This
is what auth2 does.
~Eric
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of joe
Sent: Sunday, July 30, 2006 4:00
PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] Read-Only
Domain Controller and Server Core
Hmm I would say in larger orgs where
provisioning has come into play, the process of putting users into site or
building based OUs is being turned on its head and users are being moved back
to a centralized OU structure that more closely mimics the way administration
is being done. And I personally think that is great. As I have stated a couple
of times I am more and more ofthe opinion that direct delegation of users is
not the way to manage AD. The last of the controls on what people can do means
it is probably dangerous to do, especially with more and more apps following
the "Exchange way". As much as hate to admit it, I completely agree
with Eric that I would rather not see the money put into trying to figure out
how to manage that way because in the customer base and the AD base that I am
most familiar with it would have extremely limited use.
In the end we need some cool tools to
identify which users should be turned on for the policy. While it is generally
easier to do it in fell swoops with OUs or Groups, it very likely won't be
the most accurate mechanism. Just because someone reports to a given office as
their primary office doesn't mean that is where they log on. I am a great
example of that, my primary office that I am supposed to go to is in City X yet
I have been in 4 other cities more often than I have been in City X. Actually
now that I think about it, I haven't been to my primary office in over a year.
This could be very unusual but is just one point about OUs and groups being an
80/20 mechanism and hopefully we can find something better. It reminds me of
role based group management which pretty much really sucks when you get down to
it for tight security controls, resource based management is much stricter and
tighter when implemented properly.
We currently have info available to tell
us where people are authenticating, it just isn't the easiest to get the
reports because the info isn't centralized. If we could work in the direction
of getting that info centralized it could make it more useful as the mechanism
to help make the decisions.
Certainly though, I think having group
based mechanisms on top of it all is valid, I just don't want it to be my
own mechanism and not just because the whole security group thing is breaking
down due to kerberos and token limitations. Say I want to specify that an RODC
should never cache the password of a user who is in the administrators
group (directly or nested) or in account operators or in my XYZ-Important group
that isn't built into the product. That should be doable. The handling of
nested groups makes it all fun but hey, we didn't come up with this group
system, MSFT did, good that they get to have fun dealing with it like we do. :)
I think that when this feature comes out
it will be like Global Group Craching and everyone will stand around looking at
everyone else and how they are going to use it. It will then either be heavily
used or ignored. If it looks like the use is going to be heavy, if the MSFT
tools suck, then third parties will come up with management tools. I
personally love the ideas of RODC and Server Core and will certainly be looking
at holes that I think can be filled in the tool lineup. Unfortunately I don't
actually do any real work anymore so I will be looking closely at what the
people doing real work are complaining about when trying to admin their
environments.
joe
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Grillenmeier, Guido
Sent: Saturday, July 29, 2006 2:15
AM
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] 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. | | | |
| listmail
Posts:454
| | 07/31/2006 6:42 AM |
| Actually I was looking at it from the reverse end that you
just described. I assumed that you already knew where you wanted users to have
their passwords cached and had set the policy and the tool simply looked at that
policy and forced the password population so in case the user gets there on a
day when the WAN has a stomach ache the user could still log on.
But a tool that looks at the available sources of info on
where a user/computer has been logging on and then setting the policy from that
is just as doable. At least I believe so, I would have to look to make sure
nothing in my core assumptions have changed, I admit to not having enough time
to play with RODCs yet.
Anyway it could range from just allowing all but admin
passwords to be cached everywhere and then when someone logs on at one of
those DCs the password hash gets replicated down to an application that watches
the auth being done and dynamically updates the policy based on defined business
rules that the utility knows (i.e. if their are >3 auths at an RODC in a
month period add them to that policy or if they haven't logged on in a month to
remove them from the policy or if the moon is full on the days the user logs on
then cache the hash or what not...). I don't expect MSFT to do the latter, at
least not for a while. MSFT tends to shy away from useful tools like that. That
is what I am here for... ;o)
joe
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Eric
FleischmanSent: Sunday, July 30, 2006 7:59 PMTo:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Read-Only Domain
Controller and Server Core
Such a tool is entirely
possible. Of course, you just need the knowledge of where a user should be
authenticated. For users, this is not horrible¦.for computers, it is tougher in
many enterprises (though certainly not all).
I suspect, but don™t
know, that a great many customers will end up looking at the computer problem
reactively¦.either they will just allow most computers (other than known admin
ones) to get cached on RODCs and track what ends up there, or they will manage
via the Auth2 list and move to the allow list after. But hey, that™s just me
guessing. Maybe this new feature will inspire a new push to understand the
usercomputer relationship in enterprises. We™ll find out in 2010 or
so.
~Eric
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of joeSent: Sunday, July 30, 2006 4:05
PMTo:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Read-Only Domain
Controller and Server Core
> I could then
configure all RODCs (maybe per region) to allow caching the credentials
> of these users “
and remember they will only start caching the pwds for users that
> have actually
authenticated at least once to the respective
RODC¦.
Yeah, when I first
heard about how that was going to work some time ago (years now I think, amazing
how long this stuff has been getting talked about without actually having it in
production) I visualized a tool that would look at the policy for where a
user should be authenticated and then would auth that user on all of those
machines up front just to force the initial caching or if you prefer seeding...
--
O'Reilly Active
Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Grillenmeier,
GuidoSent: Saturday, July 29,
2006 12:15 PMTo:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Read-Only Domain
Controller and Server Core
Al, that™s basically
getting back at what Eric said and the more I think about it, the more I have to
agree: there is only a certain percentage of companies that are able to setup an
OU structure by geography and certainly no single OU structure will fit for all
companies. I have myself worked with quite a lot of customers, where OUs by
location made sense “ but also some that had a mix of location-OUs for computers
and business units-OUs for users. And others simply adjust it to their
helpdesk model “ depending on who needs to manage which part of the
world.
Thinking more about
the travel bit, it will be easy to understand that this doesn™t make the
password caching story any easier. If you want full coverage for WAN outages
(which is the main reason that you want to cache the passwords in the first
place), then you may need to match those traveling users (and computers) to
multiple sites “ this is where the fun begins with figuring out how to handle
the password replication policies for RODCs. Granted, OUs suddenly make less
sense, since a user and a computer can only be in a single OU, but they can
belong to multiple groups¦
But at some point you
have to weigh the configuration efforts against the benefits and the probability
of WAN outages for your network. I would argue that 95% of the users in most
companies have a main location that they work in most of the time. Even though
they may have 20% to 30% of traveling users, most of these users won™t travel to
different offices all the time (of course there are companies where this
exception would be the rule).
So in an RODC
scenario, for 95% of the user base, I would probably plan on creating of a
password replication policy that only allows the RODC in their main location
to cache their passwords “ besides some additional performance benefits for the
local authentication, they can also successfully authenticate when the WAN is
down (which won™t help too much either, if all other services are centralized,
but that™s a different story).
I would then try to
figure out who those 5% of always-on-the-road-in-different-offices users are
and add them to a special group. I could then configure all RODCs (maybe per
region) to allow caching the credentials of these users “ and remember they will
only start caching the pwds for users that have actually authenticated at least
once to the respective RODC¦.
/Guido
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Al
MulnickSent: Saturday, July
29, 2006 4:06 PMTo:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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 guido.grillenmeier@xxxxxx>
wrote:
But very useful idle chatter nonetheless
;-)
/Guido
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Eric FleischmanSent: Saturday, July 29, 2006 8:35
AM
To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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,
GuidoSent: Friday, July 28,
2006 11:15 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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 FleischmanSent: Friday, July 28, 2006 11:02
PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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,
GuidoSent: Friday, July 28,
2006 1:33 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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 FleischmanSent: Friday, July 28, 2006 9:42
PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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 MulnickSent: Friday, July 28, 2006 10:34
AMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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.
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 GavrilovSent: 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@xxxxxxxxxxxxxSent: Friday, July 28, 2006 8:22
AMTo: 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 MulnickSent: 28 July 2006 16:08To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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] wrote:
FYI:http://blogs.msdn.com/jolson/archive/2006/07/27/679801.aspx
Read-Only
Domain Controller and Server CoreList info : http://www.activedir.org/List.aspx List
FAQ : http://www.activedir.org/ListFAQ.aspxList 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. | | | |
| listmail
Posts:454
| | 07/31/2006 6:53 AM |
| Hey Brian, good to see your name on the
list...
I got pinged offline on the basis behind this
functionality. I admit to being a little shocked that someone was tossing
password type info into other attributes especially with AD being so generally
open to viewing, especially when using the Pre-W2K Compat group with
auth'ed users allowed to see all attributes by default which most domains
still seem to be in due to fears in what will break if it is turned off. If this
is purely based on security concerns, I would be more apt to tell people to
install ADAM on the DCs and put the data there. At least you know that is
severely locked down by default and not having to be worried what side direction
someone might come in and pop you from.
From the standpoint of less crap being sent down to WAN DCs
I like the idea. I realize I can't have branch level replication but at least
being able to weed out all of the non-essential attributes would be a nice start
for tiny branches with 10 users in domains with tens of thousands of users. I
actually recently had to say it didn't make any sense to move from Novell to AD
for a customer because of that very issue. You can't imagine how much that
pained me to say. In cases like that if there is no real strategic reason to
move to AD, it is better to stay on Novell because of the replication
model.
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Brian
PuhlSent: Monday, July 31, 2006 4:05 AMTo:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Read-Only Domain
Controller and Server Core
You™re right Joe “ that
the RODC PAS would complicate things for the developers. The easy
solution would be for developers to use the writeable flag when connecting to a
DC, then they™d be guaranteed to not get an RODC¦but even that isn™t a great
solution, and if we get the RODC GC it only becomes more
complex.
For general background
though, the justification for the RODC PAS DCR is actually that there are
numerous attributes which contain password hash, or password-like data.
Because these attributes aren™t part of the pre-defined list of secrets, they
are replicated normally rather than on-demand via the PRP. It wouldn™t
do me much good to prevent replication of 5 password attributes, when a
6th one which also includes a hash gets pushed down through normal
replication. There needs to be a way for an administrator to define where
these secrets live and protect them accordingly.
I™ve broached the topic
of using this method to protect PII data a couple of times in relation to some
RODC work we™re doing internally, and the response is always that it™s firmly in
the realm of unsupported followed with a that™d be a bad idea and some
serious head shaking “ simply because of the way applications
behave.
Brian
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of joeSent: Sunday, July 30, 2006 5:08
PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Read-Only Domain
Controller and Server Core
I am not sure if I
understand where you are going but let me explain where I am coming
from.
First, the passwords
being there or not being there is not important for this talk, that is already
built in and will be there, now the discussion is around everything versus an
RODC PAS.
Everything is already
there as well but is an important option because it will be the most used
option. Actually I expect to see a ton of RODCs deployed that are configured as
replicate everything including passwords so that people get the RO part of the
benefit and they don't have to worry about replicating bad stuff back into the
"real directory" and not have to worry about password caching management, if
someone logs on somewhere, the password is cached there, bob's your uncle have a
nice day.
So now we get down to
replicating a portion of the normal attribute set. Why would you want to do
this? Because you want to minimize the traffic to WAN sites and/or reduced info
in some locations in case of compromise. For instance, if the email addresses of
everyone in the company isn't on a DC in a WAN site and someone steals that DC
hoping to get those email addresses, they are SOL; they missed. However, now
think about this from a application developer standpoint and it is the same
issue that exists with GCs only worse because it is DCs. If an app developer
wants to find something, they need to understand what they can actually find in
the GC in terms of what attributes are populated. Maybe they (a) put in a
requirement and hope people follow it, maybe they (b) actually try to verify it,
maybe they (c) say screw that and query a DC instead because they know all of
the data is there for a full query. From what I have seen the likely cases for
an app that can handle any query is C, A, and in the absolute blue moon case B.
Usually the app will just fail to find what it needs if you specify an attribute
that isn't in the GC. How does Exchange do it??? So there are hybrids like where
certain things that people KNOW will always be in GC PAS and they will set it up
so that queries using those things will use a GC and everything else will go to
a DC. We already know that the same override that exists for the GC PAS would
have to exist for an RODC PAS so why not just make that the other option and be
done with it? I don't really see the majority of developers doing this any
better with RODCs than they do with GCs and so it seems like a lot of make work
to allow for the flexible handling of that if you just say these are the
options.
Again also the password
thing isn't even worried about at the app level since apps can play with those
anyway.
joe
--
O'Reilly Active
Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Al
MulnickSent: Sunday, July 30,
2006 6:57 PMTo:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: Re: [ActiveDir] Read-Only Domain
Controller and Server Core
Um, why? What value at this point?
Last I checked it supports limited applications that
might want that information. And if you follow ~Eric's logic, they want to be
secure out of the box. That would indicate that they want it to be as
minimal as possible until and unless told otherwise.
To put that information in there by default might be
counter to that.
Now, if you had some templates or something so that we
didn't have to work on the carpal tunnel, that would be
something....:)
On 7/30/06, joe listmail@xxxxxxxxxxx>
wrote:
RE: RODC
PAS....
Oi, that will add some
nice complexity to all of this... :)
If I was looking to
implement that I think I would look at doing it in four levels so people don't
shoot themselves... Everything, everything but password info, core NOS info
required for auth/authz with passwords, core NOS w/o passwords.
--
O'Reilly Active
Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On
Behalf Of Dmitri
GavrilovSent:
Friday, July 28, 2006 12:48 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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@xxxxxxxxxxxxxSent: Friday, July 28, 2006 8:22
AMTo: 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 MulnickSent: 28 July 2006 16:08To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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 CoreList info : http://www.activedir.org/List.aspx List
FAQ : http://www.activedir.org/ListFAQ.aspxList 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. | | | |
| listmail
Posts:454
| | 07/31/2006 7:04 AM |
| For Exchange, there has been a lot around Exchange. At no
point though have I heard that they were even going to start consider supporting
Exchange with RODCs. I have hear a lot of absolutely we will not support
Exchange that way. If Exchange were supported, not to be a pain, but I can't
imagine what a horrible mess that would turn into to support. It isn't my
opinion that the Exchange team has been wonderfully good at writing code to
utilize AD as it is already and it is currently relatively
simple.
I agree on the naming with Guido. Though straw poll now for
the folks who plan on using RODCs, who plans to just tell them to cache all
passwords as necessary (excluding admin accounts of course)? Or to put it
another way, who plans to use RODCs and then actively try to manage where
passwords can be cached? I would not be surprised to hear that RODCs are going
out the door with the dial all the way to the right (or left if you prefer) and
everything but admin passwords are being cached. It still gives a ton of
benefit, i.e. someone screws with it and that can't (allegedly) get back to the
"real" directory and not all password hashes would be on all RODCs, it would be
based on who actually auth'ed at the local DC.
If I could do it dynamically, I would like to do something
like, if the user/computer has attempted to log into RODC(x) more than y times
in the last z days, then cache the password locally. If the user/computer hasn't
authed there in v times in the last w days, then remove them from the
policy for that RODC again.
My theory is that unless this management is extremely
simple and mostly automated, most folks won't use it because the security
concerns probably aren't all that high since most users won't be authenticating
(and therefore caching) their passwords on most RODCs.
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Grillenmeier,
GuidoSent: Monday, July 31, 2006 4:06 AMTo:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Read-Only Domain
Controller and Server Core
RODCs
do NOT replicate a subset of objects => right now they basically replicate
everything a normal DC has (i.e. the full domain NC, config and schema), less
the password hashes of any users.
The OU
vs. group discussion was solely around configuring the so called Password
Replication Policy (bad name) for an RODC “ and after discussing this here and
offline, doing various tests and elaborating about possible usage scenarios, I
agree that configuring this policy by OU doesn™t really give you enough
flexibility. I would actually love to configure it by an LDAP query
leveraging any appropriate attributes “ but this is simply to resource intensive
during the authentication. Leveraging groups gives us the option to
automatically provision the memberships appropriately though. Don™t forget,
you™ll have to do this for users and computers.
Why is
Password Replication Policy a bad name? Because that™s not what it does “
calling it Password Caching Policy would be more appropriate, as an RODC would
never store a users pwd-hash unless he has logged onto that RODC. Once the
pwd is changed, an RODC will NOT update the hash “ it will only be updated the
next time a user uses that same RODC. I don™t mind this mechanism “ it
provides an automatic cleanup mechanism and thus lowers the attack surface if
a policy allowed many RODCs to cache a users PWD. But the name Replication
Policy suggests that an RODC would actually replicate the new password when it
is changed on a WDC (writeable DC), which is confusing.
Replicating
only parts of a tree (i.e. only specific OUs) would be a totally different
story, which I also hope to see in the future (but won™t be part of this version
of RODC). However, RODCs will also be able to replicate the GC partitions
(making them an ROGC) “ but from what I understand this will only be sufficient
for authenticating, but not to be used as a GC for Exchange (I guess since
Exchange simply needs that writeable domain partition). So placing an ROGC in a
remote site will not be sufficient if you also have an Exchange server in that
site.
Exchange
2007 edge servers is yet another different story “ not sure if they can benefit
from RODCs.
/Guido
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Paul MayesSent: Monday, July 31, 2006 1:39
AMTo: activedir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir]
Read-Only Domain Controller and Server Core
Apologies
as I™m reading in digest. But I just wanted to chip something into this
surrounding OU™s versus groups as it was something that I™ve been thinking about
on my mind-numbing commute.
I
understood that RODC™s could be configured to be a read only subset of objects
(users) from the writeable AD, or that you could set them to cache which would
also be useful to catch user population at a given site if this was unknown. I
remember there being a long discussion at the back of DEC about people wanting
the subset replication to be based around OU™s rather than groups, and lots of
people being quite passionate about it. The thing that struck me was how would
you then deal with group membership where the group was sat in a totally
different part of the tree? Somehow you™ve got to get that closed set to work
with, which is very loosely linked to migration strategies. (Blimey I must have
paid attention on that migration course all of those years ago.). And then
you™ve got constraints on OU structures for if they are now partitions for
replication in some capacity.
How
wrong is this understanding?
If
it™s kind of right, then at some point in the future are we going to see
multiple domain partitions hosted on DC™s? ˜Cos that would be nice as well as
the ability to replicate subsets as read only. Where a GC could hold writeable
copies of domain partitions that weren™t from it™s particular domain in the
forest¦.. etc¦ mmm DC consolidation, the possibilities!
Then
going more OT. There were also rumblings about ROGC™s so that didn™t contain
sensitive info and could be used purely for email purposes without the baggage
of a full fat DC. Is this correct and how does this relate to Exchange 2007 and
it™s Edge servers, which from what I can gather are looking to suck bits of the
AD into an ADAM for kind of the same purpose as an ROGC would perform? I may be
totally babbling now.
RE: [ActiveDir] Read-Only Domain Controller and Server
Core
From: "Grillenmeier, Guido" guido.grillenmeier@xxxxxx>
Date: Sat, 29 Jul 2006 17:14:51
+0100
Al,
that™s basically getting back at what Eric said and the more I think about
it, the more I have to agree: there is only a certain percentage of
companies that are able to setup an OU structure by geography and
certainly no single OU structure will fit for all companies. I have myself
worked with quite a lot of customers, where OUs by location made sense “
but also some that had a mix of location-OUs for computers and business
units-OUs for users. And others simply adjust it to their helpdesk
model “ depending on who needs to manage which part of the
world.
Thinking
more about the travel bit, it will be easy to understand that this doesn™t
make the password caching story any easier. If you want full coverage for
WAN outages (which is the main reason that you want to cache the passwords
in the first place), then you may need to match those traveling users (and
computers) to multiple sites “ this is where the fun begins with figuring
out how to handle the password replication policies for RODCs. Granted,
OUs suddenly make less sense, since a user and a computer can only be in a
single OU, but they can belong to multiple
groups¦ | | | |
| listmail
Posts:454
| | 07/31/2006 7:09 AM |
| > there are enough companies out
there that are NOT yet automating group and user provisioning
My
experience is that this comes down to MOST companies aren't. It seems the ones
that are doing it had someone come in from the outside and say, what are you
insane??? or the company was already doing it even under NT4. Obviously there
are many that don't fit either of those but there are A LOT of companies running
AD now and most that I encounter fit those items or aren't doing
provisioning.
As
someone who deals a lot with trying to get Exchange off the ground in a company,
I love coming in and seeing provisioning, you just give a list of attributes and
say here are things that people really shouldn't be touching, thanks. If you
walk in and someone has given all of their site admins FC over the users in
their site based OUs or even worse have local site admins creating the users,
Exchange is a completely utter mess to deploy. If you have an environment where
your local site admins have FC and you have Exchange out there that is supported
centrally and you don't understand what I mean... just wait, you will get a foot
in a sensitive place at some point and you will be like..... oh.
joe
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Grillenmeier,
GuidoSent: Monday, July 31, 2006 4:27 AMTo:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Read-Only Domain
Controller and Server Core
That
discussion was basically done if you™d not re-activate it ;-) I™d say it™s
pretty clear by now that OUs are too inflexible and I had actually never said
not to do it with groups, but also to allow setting the policies it with
OUs. In the meantime, I think it™s a moot point and groups are fine.
The
thing that worries me is that there are enough companies out there that are NOT
yet automating group and user provisioning “ so it would be good to get some
basic functionality into the product, without the need to deploy another DB.
Think of a minimal IIFP service built just for AD without the need for an SQL DB
“ for example simply to query AD once a day and populate groups as
required¦
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of joeSent: Monday, July 31, 2006 1:02
AMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir]
Read-Only Domain Controller and Server Core
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:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx]
On Behalf Of Al MulnickSent: Saturday, July 29, 2006 10:06
AMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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
wrote:
But very useful idle chatter
nonetheless ;-)
/Guido
From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Eric
FleischmanSent: Saturday, July 29, 2006 8:35
AM
To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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, GuidoSent: Friday, July 28, 2006 11:15
PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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
FleischmanSent: Friday, July 28, 2006 11:02 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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, GuidoSent: Friday, July 28, 2006 1:33
PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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
FleischmanSent: Friday, July 28, 2006 9:42 PMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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
MulnickSent: Friday, July 28, 2006 10:34 AMTo: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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.
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
GavrilovSent: 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@xxxxxxxxxxxxxSent: Friday, July 28,
2006 8:22 AMTo: 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
MulnickSent: 28 July 2006 16:08To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject: 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 CoreList info : http://www.activedir.org/List.aspx List
FAQ : http://www.activedir.org/ListFAQ.aspxList 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 |
|
|