RODC Referral Process
in [Active Directory]
|
From: Florian Frommherz [MVP] on 9 Feb 2010 15:02 Howdie! AJ schrieb: > To 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.
From: AJ on 9 Feb 2010 16:18 On 9 Feb, 20:02, "Florian Frommherz [MVP]" <flor...(a)frickelsoft.DELETETHIS.net> wrote: > Howdie! > > AJ schrieb: > > > To 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
From: Florian Frommherz [MVP] on 10 Feb 2010 02:56 Howdie! AJ wrote: > 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 You can assume that the DC the RODC has connection objects with is the one that handles the authentication requests. > question is what mechanism is used to make sure the writeable domain > controllers dont get overloaded with authentication requests? If a DC doesn't respond to a request in a certain time, another DC is picked. That should apply to RODCs in a similar manner. If you are concerned about the writable DCs, I'd probably think about caching domain information on the RODCs as they'd then be able to handle auth themselves. If it is that much of user data, I'd probably think about a seperate forest and domain for the DMZ and create a forest trust with selective auth and let only those accounts really needed into the corp forest. I don't wanna say you didn't evaluate the situation right, I just want to point out options. Cheers, Florian
From: AJ on 10 Feb 2010 04:33 On 10 Feb, 07:56, "Florian Frommherz [MVP]" <flor...(a)frickelsoft.net> wrote: > Howdie! > > AJ wrote: > > 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 > > You can assume that the DC the RODC has connection objects with is the > one that handles the authentication requests. > > > question is what mechanism is used to make sure the writeable domain > > controllers dont get overloaded with authentication requests? > > If a DC doesn't respond to a request in a certain time, another DC is > picked. That should apply to RODCs in a similar manner. If you are > concerned about the writable DCs, I'd probably think about caching > domain information on the RODCs as they'd then be able to handle auth > themselves. If it is that much of user data, I'd probably think about a > seperate forest and domain for the DMZ and create a forest trust with > selective auth and let only those accounts really needed into the corp > forest. I don't wanna say you didn't evaluate the situation right, I > just want to point out options. > > Cheers, > Florian OK thanks for this and this is what I stated in my orginal question. Actually the setup is a seperate forest (Forest trust model). The reason we decided not to cache accounts on the RODC is because of the issues with more than one RODC in a site and the potential issues that might occur if one of the RODC has a new password replicated to it before the others. As you know the RODCs cannot rep with each other and therefore there would be a time lag before the other RODCs have up to date password information (as I undersatand it) which would cause authentication issues. Nothing will be allowed into the corp forest, the corp forest will be trusted by the perimiter forest only. In addition there will be a firewall between the RODC and writeable domain controllers, in seperare sites and lots of IPSEC going on. Thanks very much for your response and if you have any further comments to make, please do so. TIA AJ
First
|
Prev
|
Pages: 1 2 Prev: win 2000 / 2003 ad problem Next: Windows 2000 single label domain problem |