On 9 Feb, 20:02, "Florian Frommherz [MVP]"
Post by Florian Frommherz [MVP]Howdie!
Post by AJTo add to this, we will likely have 6 RODC's maybe more in a permiter
network and the same amount of Writeable domain controllers on the
internal network. My concern here is to make sure that neither one of
the RODCs or the Writeables get overloaded with authentication
requests as we are talking a large number of users. The authentication
requests will come from a thid party application via LDAP and be
serviced intially by the RODC which will then refer to a writeable DC
(No caching of creds). How would it be best to acheive this, should I
manually configure the connection objects so that each RODC has a
secure channel with its own writeable DC so a one to one mapping? I am
more concerned about the referall traffic overload as opposed to the
initial authenctication request from the application to the RODC as
this will be handled by the application itself.
Six RODCs in the perimeter? I would assume you're trying to serve a heck
load of users out there. I'm interested in what kind of metrics you're
identifying that you'll need six RODCs. I'd run some perf tests on this,
just to be sure :-)
The RODCs will manually create a replication topology - they have some
mechanism involving the NTDS objects of DCs in the directory (ntds-DSA
vs. ntds-DSA-RO) and they're checking the DC's behaviorVersion attribute
that differs between 2008/2003. Let's just say they know what they're
doing and the KCC on both Full-DCs and RODCs form a rep topology so that
only 2008 DCs replicate to RODCs.
As far as multiple RODCs are concerned in a single site, you'd need to
watch. There are a couple of caveats. You may not be hit by many of them
but having different PRPs for the RODCs there may result in fancy
results. Also, RODC<->RODC rep won't occur so all of those six RODCs are
going to build rep connections to the hub site.
Cheers,
Florian
--
Microsoft MVP - Group Policy
eMail: prename [at] frickelsoft [dot] net.
blog:http://www.frickelsoft.net/blog.
ANY advice you get on the Newsgroups should be tested thoroughly in your
lab.
Hi Florian
Thanks for your response, I appreciate your input
The number of DCs is not an issue for us at the moment as it hasn't
been decided upon yet so no concrete decisions. It is expected to be
somewhere around that mark though maybe more (>100K users)
We are already aware of the issues you mention, we have read so many
blogs and whitepapers on the subject but nothing answers our core
question. Based on a response from Meinolf it stated that the
writeable domain controller that the RODC is partnered with (As seen
via sites and service as a inbound NTDS connection object) is the
domain controller that will handle authentication requests on behalf
of the RODC (as well as being the source of replication traffic). My
question is what mechanism is used to make sure the writeable domain
controllers dont get overloaded with authentication requests?
How will each RODC determine which writeable domain controller to
partner with when it is joined to the domain and what if each RODC
gets partnered with the same writeable DC, surely this will cause an
overloaded DC. My suggestions was to manually configure the connection
objects as opposed to letting the ISTG perform this function.
Can anyone throw some light on this and answer my question?
TIA
AJ