Mac Login Slow – Windows Active Directory

[piperspace]

The school I support uses Windows Active Directory (AD) for user accounts. We have a mix of Macs and Windows for students and teachers. There is a single Domain Controller (DC) at our building which is connected to district headquarters over a WAN link. This link is often congested. At headquarters there are several other Domain Controllers which back up our DC.

Our problem is that Mac logins are often very slow. This is intermittent. Frequently, a student who is unable to login to a given Mac will try on another machine close by and the login will work.

I suspect this may have to do with our Macs randomly attempting to obtain login service from one of the off-site domain controllers rather than the local DC.

The only relevant documentation I can find from Apple is in this white paper:

http://images.apple.com/business/solutions/it/docs/Best_Practices_Active_Directory.pdf
——————————————————-

Site awareness

Apple’s AD plug-in is AD site aware. It queries
the global catalog for site information
and polls the site’s domain controllers. From those
that respond, the plug-in chooses two and
uses them until a network change occurs
or until one of the domain controllers stops
responding.
———————————————————–
Does anyone know precisely how to interpret the above in our context? Is it accurate that the client always picks two domain controllers and uses both?

We would like to restrict our Macs to use just our dedicated on-site domain controller and never try to contact the off-site DCs. Does anyone know of a way to do that?

Thanks!

[Patrick Gallagher]

Your Macs will use the information, not provide it. Does your AD infrastructure use sites? Check with your AD admin.

[piperspace]

Yes, the infrastructure does have sites. When I last checked them they looked OK. I will check them again.

Your statement implies that if the infrastructure accurately reflects that we only have one DC at our site then the Macs will only go off-site for logins if that DC is unresponsive. Please confirm that is what you meant and thank you very much for your response.

[Patrick Gallagher]

Yes, if your DNS srv records are correct, it should only try to use the DC’s in their site.

You can troubleshoot with some info from [url]http://support.microsoft.com/kb/247811[/url].
Any reference you see to something like _ldap._tcp.DnsDomainName, use a command in this format:

[code]dig -t srv _ldap._tcp.yourDNSdomain[/code]

You want to determine that machines in your building(s) are getting the correct DC’s from DNS and that they are part of the site you think they should be. If your infrastucture is purely AD (authentication and DNS), then you’re probably in better shape than those of us that have AD + non-AD DNS.

Also see: http://blog.macadmincorner.com/leopard-ad-integration-headaches/ for a bit of my experiences.

[piperspace]

I do not see anything wrong with DNS or with the site/subnet records in our Domain.

Our Apple S.E. opines we should be using the “preferred” AD plugin parameter. Pointing our Macs at the on-site Domain Controller. He says that if we use that the client will avoid going off-site unless the preferred DC is unresponsive. I plan to give that a try and run a packet trace to confirm it works as advertised.

If anyone reading this has experience using “preferred” please post. I do not understand why Macs need this kind of manual help in order to find a fast DC. Windows XP login works fine without it.

Cheers

[piperspace]

Wireshark packet trace shows that the Mac OS X 10.5.8 AD Plugin [b]does not[/b] honor “Prefer this domain server”.

Contrary to Apple’s documentation this parameter has no effect either on the bind process or on subsequent signons. During bind the trace shows the Mac choosing a Domain Controller seemingly at random where it creates/updates a computer account. In our case this is usually an unreliable, slow off-site DC. We often get “Unkown error” failures when attempting bind. After it does complete successfully we are unable to signon using our on-site DC for an unpredictable period of time while waiting for inter-site DC replication to occur.

After bind finally completes and the client Mac has been rebooted a couple of times the trace shows it usually settles down and mostly uses the fast on-site DC for signon. But again this is true whether or not “Prefer” is set.

We did find some relief by disabling the plugin parameter “Allow authentication from any domain in the forest”. On our network this eliminates unnecessary off-site DC look-ups during each signon.

[Tom H]

Have you seen the following articles :

http://support.apple.com/kb/HT3393

http://support.apple.com/kb/HT3394

Should give you a insight into whats required

[piperspace]

I had not seen HT3393 before. Thanks very much for that.

Unfortunately, as far as I can tell… it is [b]wrong[/b].

In the trace:

1) I do see the DNS queries come back listing our on-site server for _ldap, _kerberos and _kpasswd.

2) Average ping response for the on-site DC is 0.2ms. For off site servers it ranges from 1-9ms. No firewall issues that I know of. Certainly the on-site DC is not behind a firewall.

3) I confirmed that the on-site DC is designated as a Global Catalog, the Site/subnet settings are good and I can see the client querying the Site info in the trace.

In a lab environment I also looked at whether “Prefer this domain server” was honored for signon when choosing between two DC’s on the same subnet. It had no effect.

[piperspace]

I would also like to point out that…even if all the criteria for honoring “prefer” are somehow not being met…what the AD Plugin is doing is just plain dumb.

Its default behavior for bind processing IMHO is seriously lame.

[Tom H]

Have you checked that AD is returning a list of sites to the mac ?

Try

[code]ldapsearch -x -h “dc1.adomain.co.uk” -b “CN=Sites,CN=Configuration,dc=adomain,dc=co,dc=uk” -D “[email protected]” -W siteList | grep siteList[/code]

and

[code]ldapsearch -x -h “dc1.adomain.co.uk” -b “CN=Sites,CN=Configuration,dc=adomain,dc=co,dc=uk” -D “[email protected]” -W siteList[/code]

Tom

[piperspace]

I will try that and post results here.

Thanks for your comments ❗

[piperspace]

So, I ran the queries Tom kindly provided.

They spit out the Sites, subnets, and server configurations I would have expected based on examining the AD console.

Also, I ran two queries (results follow) provided by Kyle at this link: http://patternbuffer.wordpress.com/category/active-directory/

Kyle’s queries confirm that the subnet is correct and that our server can be looked up via the subnet info.

The only faintly suspicious thing I can see in these results is the presence of a server named 559-wdcpe01 at our site. This server has been decommissioned and so, technically, it should no longer appear in the Sites database. But it [b]has[/b] been removed from DNS and my traces [b]never[/b] show the client attempting to contact it.

Due ti the fragmentary and conflicting nature of Apple’s documentation, what I see in my traces and these results I see no alternative but to conclude this is a bug.

[b]Many thanks to those who have posted here[/b] and please let me know if you spot a flaw in my analysis.

Cheers

ldapsearch -x -h “559-wdcpe02.sf.k12.internal” -b “CN=Subnets,CN=Sites,CN=Configuration,dc=k12,dc=internal” -D “[email protected]” -W “(cn=10.63.0.0/20)” siteObject

# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter: (cn=10.63.0.0/20)
# requesting: siteObject
#

# 10.63.0.0/20, Subnets, Sites, Configuration, k12.internal
dn: CN=10.63.0.0/20,CN=Subnets,CN=Sites,CN=Configuration,DC=k12,DC=internal
siteObject: CN=Galileo,CN=Sites,CN=Configuration,DC=k12,DC=internal

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

ldapsearch -x -h “559-wdcpe02.sf.k12.internal” -b “CN=Servers,CN=Galileo,CN=Sites,CN=Configuration,dc=k12,dc=internal” -D “[email protected]” -W dNSHostName | grep dNSHostName

# requesting: dNSHostName
dNSHostName: 559-wdcpe01.sf.k12.internal
dNSHostName: 559-wdcpe02.sf.k12.internal

[Macly]

Perhaps you could post your packet trace or an excerpt of the Mac’s not respecting this?

[piperspace]

No can do, sorry.

The school district IT people are kinda sensitive about posting such detail on a public forum.

[Tom H]

Drop me a email to Tom AT jigsaw24.com I have one last thing that may be worth you trying 🙂

[Author]

Posts