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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Mayes
Sent: Monday, July 31, 2006 1:39 AM
To: activedir@mail.activedir.org
Subject: 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" <[EMAIL PROTECTED]>
  • 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…

 

Reply via email to