[piperspace]

The fix was to migrate our Snow Leopard clients to Lion. Windows DC is now functioning normally.

[piperspace]

If you are getting the message:

“Your are unable to log in to the user account at this time.”

Its a bug.

The period of time during which login is denied can be reduced by editing the file /etc/autofs.conf on the Mac and reducing the value of AUTOMOUNT_TIMEOUT.

[piperspace]

No can do, sorry.

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

[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

[piperspace]

I will try that and post results here.

Thanks for your comments ❗

[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.

[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]

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.

[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]

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.

[Author]

Posts