RODC Referral Process

  • Thread starter Thread starter AJ
  • Start date Start date
A

AJ

Hi Guys

Can someone explain to me what process is used by a RODC to determine
where it should forward an authentication request if caching of
credentials on the RODC is not allowed? is it by using the DsGetDcName
API?

If there are multiple writeable DCs how does the RODC deal with
spreading the load accordingly, as opposed to returning the same
writeable DC for each request. In our situation this would overload a
single DC. I'm assuming here that DsGetDCName returns the domain
controller that responds the quickest and in that case an I/O bound DC
currently dealing with a lot of authentication requests should never
be selected?

Appreciate if someone could sanity check my thoughts on this.

TIA

AJ
 
Hello AJ,

As a RODC normally is in a remote site, it uses the replication partner in
AD sites and services where it has connectivity with.

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm
 
Her is a great blog I recently read up on from Microsoft. I think it will
answer all your questions.

http://blogs.technet.com/askds/arch...ad-only-domain-controller-authentication.aspx

--
Paul Bergson
MVP - Directory Services
MCTS, MCT, MCSE, MCSA, Security+, BS CSci
2008, 2003, 2000 (Early Achiever), NT4
Microsoft's Thrive IT Pro of the Month - June 2009

http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup This
posting is provided "AS IS" with no warranties, and confers no rights.
 
Hello AJ,

As a RODC normally is in a remote site, it uses the replication partner in
AD sites and services where it has connectivity with.

Best regards

Meinolf Weber
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.
** Please do NOT email, only reply to Newsgroups
** HELP us help YOU!!!http://www.blakjak.demon.co.uk/mul_crss.htm







- Show quoted text -
Click to expand...

Hi Meinolf/Paul

Thanks for your reply(s).

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.

I hope I am making sense here.

Thanks for your advice.
 
Hi Meinolf/Paul

Thanks for your reply(s).

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.

I hope I am making sense here.

Thanks for your advice.- Hide quoted text -

- Show quoted text -
Click to expand...

Maybe this is what I am after. Maybe this stuff just works and I
shouldn't worry about it!?

http://technet.microsoft.com/en-us/library/dd735927(WS.10).aspx

Will the RODC see all the writeable domain controllers as a valid
target for authentication and replication requests automatically? (Via
the connection objects)

TIA

AJ
 
Howdie!
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.
Click to expand...

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.
 
Howdie!
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.
Click to expand...

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.
Click to expand...

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
 
Howdie!
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
Click to expand...

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?
Click to expand...

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
 
Howdie!


You can assume that the DC the RODC has connection objects with is the
one that handles the 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
Click to expand...

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
 
Back
Top