Here are some details on how to make sure your non-primary AD authentication servers are available to macs running snow leopard …
This comes from the MACENTERPRISE list which always provides a wealth of information for people who support Macs …
======================================
Subject: Re: Mac Login issue
From: Tim Perfitt
Reply-To: Mac OS X enterprise deployment project
Date: Wed, 23 Feb 2011 20:14:28 -0600
Content-Type: text/plain
Parts/Attachments:
text/plain (64 lines)
There is no way to manually enter in the DCs, as this information is based on site. The important thing to check is that the SRV records for the DCs that are in your site are advertised at the top level of AD DNS as well. You can see which DCs are available by turning on verbose DS logging and looking at the logs:
sudo defaults write /Library/Preferences/DirectoryService/DirectoryServiceDebug “Debug Logging Priority Level” -integer 7
sudo touch /Library/Preferences/DirectoryService/.DSLogDebugAtStart
sudo killall DirectoryService
open Console and filter on “tory:” for this log: /Library/Logs/DirectoryService/DirectoryService.debug.log
You should see some lines like these:
2011-02-23 19:26:38 CST – T[0x0000000101981000] – Active Directory: Processing Site Search with found IP
2011-02-23 19:26:47 CST – T[0x0000000101981000] – Active Directory: Site found of – Default-First-Site-Name
2011-02-23 19:26:47 CST – T[0x0000000101981000] – Active Directory: Adding Server –
In order for a DC to be used, it must :
1. Have ldap and kerberos service records in the site specific DNS service records (_ldap._tcp.sitename._sites.dc._msdcs.domain.name and _kerberos._tcp.sitename._sites.dc._msdcs.domain.name)
2. Have its kpassword service records in the top level dns records (_kpasswd._tcp.domain.name)
If a DC fails either of those tests, it is not used. If you see “Adding Server – “, you know that it passed those tests and would be used in case of a failure and for load balancing.
The rules for GC are a bit different, since it doesn’t care about _kerberos or _kpassword (GCs aren’t used to to authenticate users or change passwords). The important thing for GCs is that the _ldap records are in the site specific DNS entries (_ldap._tcp.sitename._sites.gc._msdcs.domain.name). Again, if you see “Adding Server” in the GC section:
2011-02-23 19:26:51 CST – T[0x0000000101C10000] – Active Directory: Global Catalogs – Start checking servers for site “Default-First-Site-Name”
then you know it passed that test.
HTH,
tim
On Feb 23, 2011, at 11:15 AM, Logston, Alan wrote:
> When I came into work this morning and got a call that an entire Mac instructional lab would not allow domain/Student logins. Soon I got three more calls complaining of the dame situation all over campus. There was a very small handful of Macs able to authenticate and all the PCs were still logging in just fine.
>
> I dug into the problem and discovered that the Domain controller DC-1 was down. The PCs were falling back to other servers to authenticate but the Macs were only trying to authenticate to DC-1
>
> In the “Directory Utility” I have “Prefer this domain server” Blank. I thought this would make it so the Mac would auto discover the other authentication servers like the PCs.
>
>
> Is there any way I can manually enter these severs so this problem will not happen again?
>
>
>
> Thanks,
>
>
> Alan
> ITS
>
>
