DNS Site-Awareness: How to check Active Directory AD plug-in settings for MS DNS Server site-aware-ness

michaelhusar
Contributor II

We are using the OSX (10.10) AD plug-in for our clients. So far dsconfig -preferred is set to nopreferred which should lead to dynamic server discovery.
We are using MS DNS Servers with defined _sites to set the "right" Domain Controller.

I wanted to check if it works correctly since it seems the clients do not use the right DC

I can query the _sites with
dig -t SRV _ldap._tcp."site-name"._sites."domain.com"
The Answer-Section is correct.

How can I check whether the client "knows" the right "site-name"
Can anyone help me with the respective dig command?

Any other remarks? Do you use the _sites or are you setting the dsconfig -preferred manually ?
Thanks!

1 ACCEPTED SOLUTION

calumhunter
Valued Contributor

@davidacland actually the reverse.
the preferred option is used for auth/contact information after the initial bind, there is no method to set a preferred DC to use when binding with the ad plug in.
from dsconfigad man page

-preferred server
              Use the specified server for all Directory lookups and authentications.  If the server is no longer available, it will fail-over to other servers.

The ad plug in will use the service records contained in the DNS server provided to the mac client.
So do your service record look ups on the dns service the mac has to confirm.

AD determines site based upon subnet range i think the attribute is siteobject or siteobjectBL which is an attribute of a site record in AD something like (cn=10.147.147.0/21)

There is an issue with 10.9.0 through to 10.10.1 where if your site dc is a RODC (read only domain controller), and your srv records only give you that RODC to use, the AD plugin will fail to bind with an error 1001. 10.8 would actually look outside of the site to locate DC's it could write to and then bind.

I have some ldapsearch queries i have used in here https://github.com/hunty1/strapper that might be useful to get site code and stuff like that

I also found this site pretty useful as well:

https://patternbuffer.wordpress.com/2007/12/13/finding-your-active-directory-site-and-domain-control...

View solution in original post

9 REPLIES 9

davidacland
Honored Contributor II

Slightly related but the -preferred option only applies for the initial bind and get ignored for any subsequent connections AFAIK.

Not sure on the dig command I'm afraid, I only usually go as far as host -t SRV _ldap._tcp.domain to get domain controller names.

alexjdale
Valued Contributor III

Someone on one of our teams created a web service that you hit which returns your site code based on your IP and AD Sites and Services info (which is what really matters most). I've requested some sort of AD Sites and Services integration from Apple for years now.

calumhunter
Valued Contributor

@davidacland actually the reverse.
the preferred option is used for auth/contact information after the initial bind, there is no method to set a preferred DC to use when binding with the ad plug in.
from dsconfigad man page

-preferred server
              Use the specified server for all Directory lookups and authentications.  If the server is no longer available, it will fail-over to other servers.

The ad plug in will use the service records contained in the DNS server provided to the mac client.
So do your service record look ups on the dns service the mac has to confirm.

AD determines site based upon subnet range i think the attribute is siteobject or siteobjectBL which is an attribute of a site record in AD something like (cn=10.147.147.0/21)

There is an issue with 10.9.0 through to 10.10.1 where if your site dc is a RODC (read only domain controller), and your srv records only give you that RODC to use, the AD plugin will fail to bind with an error 1001. 10.8 would actually look outside of the site to locate DC's it could write to and then bind.

I have some ldapsearch queries i have used in here https://github.com/hunty1/strapper that might be useful to get site code and stuff like that

I also found this site pretty useful as well:

https://patternbuffer.wordpress.com/2007/12/13/finding-your-active-directory-site-and-domain-control...

davidacland
Honored Contributor II

Thanks @calumhunter, I've always had it the other way round in my head! Not sure how, the man page is pretty clear!

michaelhusar
Contributor II

Thanks everyone! Great help! Very cool ldapsearches !
So my learning is to set

-preferred "DC"

besides my "usual" settings:
-alldomains disable
-passwordinterval 0

calumhunter
Valued Contributor

Sounds good.

I would just double check with your AD admin that they do not have some kind of policy that removes machines that have not updated their password in x amount of days.

I had a client where their mac's were losing their binding after 14 days, turns out because I had set -passinterval to 0 the machine was being removed from AD by a policy on the AD side.

They had a something like a 30 day policy where if the machine has not updated its password in 30 days it was considered "rogue" and was removed from AD. Something to be aware of as it was a bit of a head scratcher

Assuming that the AD sites and servers is all set up correctly, I probably wouldn't even bother to set the preferred DC to use for authentication and contact lookups

if AD sites and servers are configured correctly, the mac should only hit the DC's in that site. I know in the places ive worked, I often don't hear about DC's being decommissioned or removed until way after its happened, if you hardcode in a preferred DC here, you may create unnecessary slow downs on the machines while they try to contact a DC that no longer exists before it fails over.

Oh and if you don't know already. 10.10 has some pretty nasty issues with AD.... And Wi-Fi (802.1x)

michaelhusar
Contributor II

Thanx again for the very valuable input!!!

naive question: 10.10.1 also has the nasty WiFi-AD issue? Please say that it is fixed...
We have certificates on the client and use EAP-TLS....

calumhunter
Valued Contributor

I'm not seeing it personally we don't have that setup, but i have seen LOTS of reports of it being broken. i think @bentoms was looking in to it.
I also think PEAP might have been the problem and switching to EAP-TLS might have been a fix.
In any case test thoroughly! also check this
https://jamfnation.jamfsoftware.com/discussion.html?id=12589#responseChild76100

michaelhusar
Contributor II

Thanx! I owe you! ..luckily our configuration is not affected!