QUESTION: How to force a Mac to bind to specific DC within the AD forest?

[cainehorr]

We have an unusual problem...

Any thoughts on how to force a system to bind to a specific DC within the AD forest?

For example, let's say we have domain "mydomain.com" and AD1 and AD2 are located in the same office that our Mac resides. Normally, binding to AD will force the Mac to bind to the closest DC... In this scenario, AD1 or AD2.

Now let's assume that we have a special scenario... we obviously want to bind to mydomain.com but we want to force the local machine to utilize a different DC known as AD4 that just happens to be in another physical geographical location.

You might be asking, why would we want to do such a thing in the first place?

Well, AD4 just happens to be our certificate server and AD propagation starts at AD1 and goes to AD2 (5 min TTL) then it goes to AD-Off-Site (5 Min TTL) then it goes to AD4 (5 min TTL) and then finally, it goes to AD4 (5 min TTL). We now have a 20-minute propagation time thanks to AD's automatic self-configuration).

PS - No, we can not add a manual route to create a mesh topology because IT Director says, "NO!" So there's that.

So why do we want to do this?

We use JAMF to deploy a MobileConfig + AD Cert. JAMF is set to a 15-minute check-in cycle.

In some cases, if the user gets bound to AD at "just the right moment", everything works as we would like. But that's rare.

Usually, the user's system get's bound to AD1, but the cert server's (AD4) record hasn't been updated yet, so while binding to AD1 is a success, the MobileConfig fails because we're still waiting for propagation to take place. And because it's a 20-minute propagation time, assuming the JSS client is in sync with the AD clock, the JSS client will check in 5 minutes before the AD prop finished. This means the JSS client will actually take 30 minutes after binding before it would be able to successfully receive the MobileConfig.

However, the MobileConfig is in a failed state within the JSS and JAMF doesn't keep trying with failed Computer Profiles like it does with Computer Policies based on smart groups, therefore It becomes a manual task of canceling the failure at the right time and on a per-device basis.

So, anyone have any brilliant ideas?

I thought perhaps pointing the device to be bound to the AD4 server in this particular scenario would be a great idea considering the AD4 server is both the AD and Cert Server.

But, based on my tests with dsconfigad, is seems that the -preferred flag only tells the system which DC is its authoritative source AFTER the binding process has been completed.

And I can't put my cert server in AD1 or AD2 because we need to be able to bind and push certs to machines sitting on other offices around the globe.

So I'm wondering if anyone else has tackled this scenario (or something similar) before.

Thanks!

[cainehorr]

PS - I thought @rtrouton post https://derflounder.wordpress.com/2012/03/29/diagnosing-ad-binding-problems-from-the-command-line/ might be helpful, but didn't tell me anything I didn't already know.

[dfeulner]

We're currently in exactly the same situation as you, and I'm investigating a solution. Surprisingly, the "Preferred Domain Controller" option does not seem to apply to the actual binding. Please let me know if you came across any solutions.

[40540057]

from /etc rename krb5.keytab to krb5.keytab.old
rename krb5.conf to krb5.conf.old *this file may not exist

and retry - only this worked for us