Issues with Multiple AD Sites

[Zeheeba]

Hello all,

We have recently run into a problem in our environment by adding in a secondary AD Site. We have 3 domain controllers, of which the first 2 exist in the primary AD site, and the 3rd existing in a second AD site (The DR site).

The replication to the third domain controller is set to only occur every 3 hours due to bandwidth issues. All OSX machines that are bound to AD are located in the primary site/subnet. For some reason, when new machines are being bound, they are hitting the 3rd domain controller in the secondary site when AD should tell them to go to the first 2 domain controllers that exist in their site.

Does anyone have any experience working with bound OSX machines in a AD environment with multiple sites? If so have you run into this problem? I’m wondering if there is a way to specify a site when binding/authenticating the machine initially…

Summation: OSX Machines are not respecting the subnet declarations setup in the AD Sites/services config.

Any help would be appreicated.

Regards,
Z

[Zeheeba]

Thanks man, I’ll check it out.

Regards,
Z

[Zeheeba]

Hello again,

We have continued to have problems in our environment regarding OSX machines authneticating to a DC in a different AD site, and having authentication fail as Active Directory only replicates to this 3rd DC every 3 hours, instead of 5 minutes.

We have proof of this via TCP dumps being run before the initial Bind through the login to create a network user. When the osx machine is bound to the domain it actually contacts every domain contoller ( in our case dc1, dc2, and dc3), not just one, possible to create the machine account on all dcs. The problem is that the user account that is created manually on a domain controller in the same site as the client (dc1 or dc2) is not replicated to the DC in the different site (dc3) until the next 3 hour replication.

For some reason certain clients are hellbent on authenticating users against this 3rd domain controller, even though AD specifically says that the dc’s for the clients subnets are dc1 and dc2. This at least to me is showing that for authentication the AD plugin is not respecting sites and services.

A guess as to the source of this problem…
– Since the bind is contacting every domain controller, is it possible its putting the last DC it spoke to in a prefernce file as preferred domain controller for a certain period of time? This would explain the problems we are seeing as holding onto this 3rd DC instead of querying ad everytime as it should.

Any help would be appreciated. This is going to be a real problem for us. Thanks!

Regards,
Z

[chrisjasper]

You can specify which domain controller you can use in the administrative tab of the AD plugin.
If you specify the DC, and have the correct forest and domain then remove the tick from “Allow authentication from any domain in the forest” that should mitigate the problem.

Fingers crossed.

[Zeheeba]

Thanks for the reply Chris. If I understand correctly, this would solve the problem by telling the computer to always use on DC. My only concern with this is that it would disable any mac bound using this setting if the DC should go down, as it wouldn’t seek out any others. Although I could be wrong on this.

If you can specify a DC and have the machind query for the others if the primary is not available, than this would be at least a workaround for when the stated primary is up and operational.

Good Idea. Its not a real fix per say, but definitly a work around. : )

[chrisjasper]

No, Zeheeba, the seting is to prefer a DC, if the client is unable to find the preferred DC it will check DNS to find another.

Cant think of a way to ensure that it fnds the other local DC first though as I believe it queries DNS and takes the first apllicable record it receives so if the 3rd DC is named in a way as to place it higher in the list of entries it would probably get picked up first.

[Zeheeba]

[QUOTE BY= MacTroll] Is dc3 in the site for the clients? [/QUOTE]
No, DC3 is in a second site which is linked to a subnet that the client doesn’t lie in.

[QUOTE]The plugin should contact all of the site and test them to see if they actually are there.[/QUOTE]
This explains why our TCP Dumps are showing the client talking to all 3 domain controllers on Bind. After I viewed the dumps I was hoping this was a normal thing, this clarifies it, thanks.

[QUOTE]Also, I’d be curious as to what the _ldap._tcp. SRV records are returning, since those could be pointing to the third site also.[/QUOTE]
DNS INFO (I can’t get tabs so show up so its a bit crushed):

AD main portion:
“_ldap._tcp.dc._msdcs SRV 0 1 389 dc01
SRV 0 2 389 dc02
SRV 0 3 389 dc03″

AD Sites protocol Portion:
“$ORIGIN _tcp.Co-Main._sites.company.com.
_ldap SRV 0 100 389 dc01.company.com.
SRV 0 100 389 dc02.company.com.
$ORIGIN _tcp.DR._sites.company.com.
_ldap SRV 0 100 389 dc03.company.com.”

This shows the 2 sites, Co-Main, and DR

AD TCP Portion:
“_ldap SRV 0 100 389 dc01.company.com.
SRV 0 100 389 dc02.company.com.
SRV 0 100 389 dc03.company.com.”

AD MSDCS Portion:
“$ORIGIN _tcp.Co-Main._sites.dc._msdcs.company.com.
_ldap SRV 0 100 389 dc01.company.com.
SRV 0 100 389 dc02.company.com.
$ORIGIN _sites.dc._msdcs.company.com.
$ORIGIN _tcp.DR._sites.dc._msdcs.company.com.
_ldap SRV 0 100 389 dc03.company.com.”

[QUOTE]Or… you can just cheat and pre-create the machine account and let it replicate out. Then bind after that.[/QUOTE]
The problem isn’t th at the machine account isn’t being created on all 3 DC’s, because it is on bind. The problem is that the persons account is created manually right before the bind, and that info doesn’t hit DC3 for until the next 3 hour replication schedule push occurs. We could create the account on DC3 as well, but who wants to do that? ; )

[QUOTE BY= chrisjasper]Cant think of a way to ensure that it fnds the other local DC first though as I believe it queries DNS and takes the first apllicable record it receives so if the 3rd DC is named in a way as to place it higher in the list of entries it would probably get picked up first.[/QUOTE]
You just hit the root of the problem. AD is supposed to be able to tell that the client is sitting in a subnet in site Co.Main and send it to the domain controllers for that Site/Subnet first, which are DC1 and DC2. I still think your idea of setting a preferred DC might be the correct workaround for this issue.

Thanks again guys, as always, any help is appreciated.

Regards,
Z

[Zeheeba]

Our situation is an interesting one. We had an existing domain that was basically messed up. After having it picked over it was decided it would be more productive to build a new domain and migrate over to it then try to repair/salvage the disaster that was in place. Since there are about 800 people and a support staff of about 7, the migration is happening over time. So the process goes like this…

The users account is setup on the new domain, mailbox created etc…
Their new computer is setup and bound to the network shortly after.
So yes, the bind is working and the computer account is being produced correctly. But the user account that was created on DC1 might not be on DC3 yet as its in a difference site and only is replicated to every 3 hours.

Now by the sites and services definitions, no client should ever try to hit DC3 due to its subnet, but for some reason the Macs are, which is causing login failures due to the account name not having been replicated to DC3 yet. If we were persay to always wait 3hours after creating the users account we wouldn’t have the authentication problem because the account would be on DC3. But the real problem is that the Macs are looking to DC3 at all, when they shouldnt be.

Life can never just be easy ya know? : )

[Zeheeba]

Thats a great idea, and will work on it first thing Monday. Thanks man!!

Z

Despite all the frustration this causes, I’m certainly learning a hell of a lot.

[Zeheeba]

Alrighty, its update time. I have been doing a lot of logging and research into this. Here is the standard important stuff on a bind that comes out in the DS debug log:

 ADPlugin:    Doing CheckServerRecords......
 ADPlugin:       company.com - Start checking servers for site "any"
 ADPlugin:          Total Servers "any" LDAP - 3, Kerberos - 3, kPasswd - 3
 ADPlugin:             Server #1 picked - "dc02.company.com"
 ADPlugin:             Server #2 picked - "dc03.company.com"
 ADPlugin:       Got rootDSE for server dc03.company.com to determine forest
 ADPlugin:       Determined Forest of company.com from Domain Controller dc03.company.com
 ADPlugin:       Found Default Domain company.com
 ADPlugin:       Global Catalogs - Start checking servers for site "any"
 ADPlugin:          Total Servers "any" LDAP - 2, Kerberos - 3, kPasswd - 3
 ADPlugin:             Server #1 picked - "dc03.company.com"
 ADPlugin:             Server #2 picked - "dc01.company.com"
 ADPlugin:       Found Forest Domain GC company.com
 ADPlugin:    Something wrong, unable to determine domain information from Config container......
 ADPlugin:    Finished CheckServerRecords......
 ADPlugin:       Created KerberosClient record Generation ID 158597214
 ADPlugin:    Rebuilt Kerberos File
 ADPlugin: Calling CloseDirNode
 ADPlugin: Calling OpenDirNode
 ADPlugin: Calling CustomCall
 ADPlugin:    Doing CheckServerRecords......
 ADPlugin:          Good credentials for [email protected]
 ADPlugin:          No existing connection in connection mgr for user@[email protected]:389
 ADPlugin:          Secure BIND Session with server dc02.company.com:389
 ADPlugin:          Read Context information from server for configurationNamingContext of CN=Configuration,DC=company,DC=com
 ADPlugin:      Processing Site Search with found IP
 ADPlugin:         Site found of - Main-site
 ADPlugin:          Returning connection to pool for domain company.com with dsStatus 0.
 ADPlugin:       company.com - Start checking servers for site "Main-site"
 ADPlugin:          Total Servers "Main-site" LDAP - 3, Kerberos - 3, kPasswd - 3
 ADPlugin:             Server #1 picked - "dc02.company.com"
 ADPlugin:             Server #2 picked - "dc01.company.com"
 ADPlugin:       Got rootDSE for server dc01.company.com to determine forest
 ADPlugin:       Determined Forest of company.com from Domain Controller dc01.company.com
 ADPlugin:       Found Default Domain company.com
 ADPlugin:       Global Catalogs - Start checking servers for site "Main-site"
 ADPlugin:          Total Servers "Main-site" LDAP - 2, Kerberos - 3, kPasswd - 3
 ADPlugin:             Server #1 picked - "dc01.company.com"
 ADPlugin:             Server #2 picked - "dc03.company.com"
 ADPlugin:       Found Forest Domain GC company.com
 ADPlugin:          Good credentials for [email protected]
 ADPlugin:          Retrieved existing connection from connection mgr [email protected]@company.com:389
 ADPlugin:          Read Context information from server for configurationNamingContext of CN=Configuration,DC=company,DC=com
 ADPlugin:          Returning connection to pool for domain company.com with dsStatus 0.
 ADPlugin:    Finished CheckServerRecords......

You can see during this binding portion that it looks for the defined servers for the “any” site and the “Main-site” site. The selected servers for the “any” domain have dc03 included a lot, but the “Main-site” shows the correct servers with dc03 only included as a GC. We are assuming this is happening becasue the plugin is looking for 2 GC’s, and there are only 2 available, one of them being dc03.

These results change often for the “any” section when repeating the bind process, but remain reliable for the “Main-site” section. This would mean to me that the ADPlugin indeed can read the information on sites and interpret it correctly.

Since the server information for the “Main-site” site is correct but logins are still failing randomly beecasue the server is looking at dc03 would at least make it appear that when it comes time for authentication, the sites are not being respected.

There is the one issue of the line that reads “Something wrong, unable to determine domain information from Config container……”. I have no idea what this error means. Any idea MacTroll?

I will let you know if I come up with anything else.

PS- Is there a way to keep DirectoryService Debug on through restart?

[pixelgrunt]

Give a little, take (well, ask) a little…

[quote]To enable debug logging at startup, run the following:

[code]$ sudo touch /Library/Preferences/DirectoryService/.DSLogDebugAtStart[/code]
[url]http://www.jaharmi.com/2008/07/21/start_directory_service_debug_logging_automatically_after_the_next_restart_on_mac_os_x[/url]

I’m left hanging. I’m also seeing the following in my DirectoryService.debug log:

[code] ADPlugin: Something wrong, unable to determine domain information from Config container……[/code]
My client macs are OS X 10.4.11 attempting to bind to a 2003 AD environment. Can anyone shed some light on this particular error?

I’m also seeing “Computer Container specified does not exist,” when attempting to bind. This shows whether I create the machine
account in AD or not. I even tried a CN beside Computers to see if that helped. It didn’t.

Anyone?

[Author]

Posts