Posted on 01-12-2015 03:05 AM
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!
Solved! Go to Solution.
Posted on 01-12-2015 07:31 PM
@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:
Posted on 01-12-2015 04:01 AM
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.
Posted on 01-12-2015 07:29 AM
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.
Posted on 01-12-2015 07:31 PM
@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:
Posted on 01-13-2015 01:37 AM
Thanks @calumhunter, I've always had it the other way round in my head! Not sure how, the man page is pretty clear!
Posted on 01-13-2015 02:04 AM
Thanks everyone!
Great help! Very cool ldapsearches !
So my learning is to set
-preferred "DC"
besides my "usual" settings:
-alldomains disable
-passwordinterval 0
Posted on 01-13-2015 03:11 AM
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)
Posted on 01-13-2015 03:19 AM
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....
Posted on 01-13-2015 03:33 AM
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
Posted on 01-13-2015 03:41 AM
Thanx! I owe you! ..luckily our configuration is not affected!