Mac OS X 10.6.8, Snow Leopard, and ".local" domains

Updated December 19, 2011

Apple has recently made a significant change in how the OS handles requests for ".local" name resolution that can adversely affect Active Directory authentication and DFS resolution.

We have determined that the issue is directly related to a change in the Mac OS X 10.6.8 update that only affects ".local" domains.  When processing a ".local" request, the Mac OS now sends a Multicast DNS (mDNS) or broadcast, then waits for that request to timeout before correctly sending the information to the DNS server.  The delay caused by this results in an authentication failure in most cases.

We have determined a possible workaround to the problem (only on Mac OS X 10.6.8, Snow Leopard) , but there will still be a delay when authenticating:

    Log in as a local admin
    Launch the Terminal
    Enter the following (followed by the 'return' key):

defaults write /Library/Preferences/com.thursby.CIFSPlugin "LDAP Connect Timeout" 30

    Reboot

This issue also affects Apple's built-in Active Directory.  Apple's only solution thus far is located here.

As soon as we have any newer information, this entry will be updated.

If you continue to experience a login failure, please contact our Support Specialists at support@thursby.com

The component of DAVE that allows Windows machines to access the Macintosh is DAVE Sharing. Verify that you've configured DAVE Sharing (turned it on and shared a volume). DAVE Sharing is found in System Preferences/DAVE Sharing.

Once DAVE Sharing is configured, you can verify that the Macintosh is advertising a share by issuing the command "nbtstat -A <MacIPaddress>" from a command prompt on Windows. This should return a list of names. One of those names should be followed by "<20>" signifying that sharing is enabled.

For example:

C:\>nbtstat -A 192.168.0.1

NetBIOS Remote Machine Name Table

Name Type Status
---------------------------------------------------------------------------
LAB MACINTOSH <03> UNIQUE Registered
WORKGROUP <00> GROUP Registered
LABMAC <03> UNIQUE Registered
LABMAC <00> UNIQUE Registered
LABMAC <20> UNIQUE Registered

MAC Address = 08-00-07-16-0A-07

If you still can't see the Macintosh, use Start/Find/Computer and enter the NetBIOS name for the Macintosh. If found, you can open the found computer to access the shared folders and printers.

Open System Preferences/Date and Time and verify that the time, date (including year) and time zone are correct.

If this information is incorrect, the evaluation key may expire prematurely.

If you use DAVE to access a Windows NT, 2000 or XP computer, the PC will request authentication. This authentication is similar to the Domain authentication required when using Microsoft's server line of products.

By default, the username is "Administrator", while the password and domain fields should be blank. Remember, these are default settings. If you have assigned a password to your Administrator's account you must provide that password. Likewise, if you have created additional user accounts, you may login using one of these accounts with its corresponding password. The domain field will always be left empty unless you actually have a Microsoft Domain server.

� Test TCP/IP
Ping the PC from the Macintosh. To ping, open the Macintosh Network Utility in your Utilities folder. Enter the TCP/IP address of the Windows computer in the box provided under the Ping tab, and click the Ping button. If any packets are 'received', ping was successful. If no packets are 'received', ping failed. If you can not ping you have no TCP/IP connectivity and DAVE will not work. If you could ping proceed to next test.

� Test NetBIOS over TCP/IP
Open the DAVE Network Utility in your Utilities folder. Under the 'NBT Status' tab enter the TCP/IP address of the Windows computer, and click Lookup. You should receive a name table for the remote computer. One of the names should be followed by <20> signifying that the remote computer is sharing files. If there is no <20> that PC is not sharing files. If there is no name table then that PC appears not to be using NetBIOS. If this test was successful proceed to the next test.

� Test name resolution
Open the DAVE Network Utility in your Utilities folder. Under the 'NBT Status' tab enter the NetBIOS name of the Windows computer, and click Lookup. You should receive a name table for the remote computer (this is the same table from the previous test). Again, one of the names should be followed by <20> signifying that the remote computer is sharing files. If this test failed you have no NetBIOS name resolution. The PC will not be browsable.

If the above tests were successful, you should be able to access the remote computer in DAVE Network 'Connect to Server' window.

An alternative method for connecting to remote servers (other than browsing) is to connect manually. To mount a shared folder manually:

1. Select Go/Connect to Server... (or Command+K).

2. In the Address field, enter the Server and Share Name using URL format. For example:

cifs://SERVER/SHARE   

These settings only appear if you select the option to join an Active Directory network. If your network is not Active Directory (when you join the computer to an NT domain network) those options are not available in the ADmitMac Directory Access Plugin properties.

If the software you are installing is not from a special VLA CD, you will get prompted for a license code. You will need to install the software from the CD, and install any updates afterwards.

These instructions are from Apple's support site. The original article can be found here:

http://www.info.apple.com/kbnum/n107952

1. Log in with an administrator account into Mac OS X.
2. Open Terminal (/Applications/Utilities).
3. To start the trace, you will type a command, followed by the Return key. The command you choose needs to match the way your computer connects to the Internet. You can also copy and paste the appropriate command into the terminal application to avoid typing mistakes.

For built-in Ethernet, type:
sudo tcpdump -i en0 -s 0 -w ~/Desktop/DumpFile.dmp

Note: Both "en0" and "-s 0" include a zero, not the letter O.

For AirPort, type:
sudo tcpdump -i en1 -s 0 -w ~/Desktop/DumpFile.dmp

Note: "-s 0" includes a zero, not the letter O.

For a VPN connection, type:
sudo tcpdump -i ppp0 -s 0 -w ~/Desktop/DumpFile.dmp

Note: "-s 0" includes a zero, not the letter O.

4. When prompted for a password, enter the one for your administrator account.
5. Now, perform the steps necessary to reproduce the problem so that the tcpdump can record the problem as it occurs (leaving the Terminal window open or minimized).
6. When you're ready to stop capturing packets, click the Terminal window to bring it to the foreground.
7. While holding down the Control key, press C (Control-C).

For each relevant computer shown in the trace, please send us along with the trace the following information:

The computer's role in the network activity.
The system type and operating system version.
The computer's IP address.
The computer's media access control (MAC) address, which is also known as the Ethernet address, hardware address, or AirPort ID.

NOTE: Apple's article does not mention that you can add the following to the end of the tcpdump command:

host [ip address]
(without "[ ]")

The [ip address] would be that of the machine the tcpdump trace needs to be of. This would be used if you perform the tcpdump from a different Macintosh. This other Macintosh must be connected to a hub that the problem Macintosh is connected to.

After installing Gimp-Print, make sure to reboot. It may take a reboot for the new drivers to start appearing in the Print Center.

Make sure that you have configured the printer with the appropriate driver.

1. Go to the Print Center (Mac OS X 10.2) or Printer Setup Utility (Mac OS X 10.3).

2. Highlight the printer you added, click on "Printers" on the menu bar at the top of the screen, and choose "Show Info".

3. This should bring up a Printer Info window with a drop down menu at the top.

4. Click on the drop down menu and choose "Printer Model".

This should display a second drop down menu, make sure it displays the correct printer model for your printer. If it does not, click on that drop down menu and find the manufacturer then the model thats appropriate for your printer and then try to print again

 It is possible you are connecting to a NAS (Network Attached Storage) device. Some NAS devices seem to only support using Kerberos in the extended security protocol and not NTLM extended security.

This means that unless the user has already gotten Kerberos credentials, either by
logging in with ADmitMac at the OSX login window, or using Apple's
Kerberos with ADmitMac/DAVE 5 for OSX, then the user will have to use the DAVE( OS9 or 10 ) or ADmitMac's 'Policy' configuration tool to drop the security level down to the lowest level( Send LM & NTLM responses ).

To rephrase, with DAVE5 or ADmitMac, you must have Kerberos credentials if you want to connect to Filer at a security level higher than the lowest setting.

If you are using ADmitMac, go to /Applications/Utilities and open the Directory Access utility. Under the "Services" tab, double click on ADmitMac. In the ADmitMac Directory Access plugin window that appears, click on the "Policies" tab. Change the LanMan Policy to the following option:

"Send LM & NTLM responses
Client will only use LM & NTLM authentication and never use NTLMv2 or Kerberos."

If you are using DAVE, go into the System Preferences and click on DAVE Network. In this preferences pane click on the "Policies" tab. Under "LAN Manager Authentication" choose the same option mentioned in the ADmitMac instructions above.

NOTE: Making this change will prevent the client from logging into the domain using Kerberos or NTLMv2

Pinging from Windows (all versions):

First you will need to get the TCP/IP address of the Macintosh. To find the TCP/IP address in Mac OS 8.6 - 9.2.2, go to the TCP/IP control panel. To find the TCP/IP address in Mac OS X, go into System Preferences and select the Network preference.

Click on "Start", then choose "Run". At the "Run" dialog box, enter the word "command" (without quotes) and click "Ok". A DOS window will appear. At the DOS prompt, type the following (without quotes):

"ping 192.168.0.1"

Then hit the 'Enter' key on your keyboard. Remember to replace the TCP/IP address above with the IP address of your Macintosh.

You should see something very similar to the following:

Pinging 192.168.0.1 with 32 bytes of data:

Reply from 192.168.0.1: bytes=32 time=2ms TTL=255
Reply from 192.168.0.1: bytes=32 time=2ms TTL=255
Reply from 192.168.0.1: bytes=32 time=1ms TTL=255
Reply from 192.168.0.1: bytes=32 time=1ms TTL=255

Ping statistics for 192.168.0.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milliseconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

If instead you receive something similar to this:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.0.1:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
Approximate round trip times in milliseconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

This means that either TCP/IP is configured incorrectly on one of the two computers involved or there is some type of network problem. The computers must be able to ping each other before you can install and use DAVE.

--------------------

Pinging from Mac OS 8.6 - 9.2.2

Using a utility such as OTTool, ping the TCP/IP address of the Windows. The utility is available for download from the following location:

ftp://ftp.neon.com/pub/goodies
(file name is OTTool121.sit.hqx)

To find the TCP/IP address of the Windows computer, you will need to go to the DOS prompt. To get to a DOS prompt, click on "Start", then choose "Run". At the "Run" dialog box, enter the word "command" (without quotes) and click "Ok". A DOS window will appear.

At the DOS prompt, type the following (without quotes):

"IPCONFIG"

Then hit the 'Enter' key on your keyboard. This will display TCP/IP information for your Windows computer.

To ping, open OTTool, enter the TCP/IP address of the Windows computer in the box provided, and click the Ping button. If any packets are 'received', ping was successful.

If no packets are 'received', ping failed. This means that either TCP/IP is configured incorrectly on one of the two computers involved or there is some type of network problem. The computers must be able to ping each other before you can install and use DAVE.

--------------------

Pinging from Mac OS X:

First you will need the TCP/IP address of the Windows computer (see instructions above to find this).

To ping the Windows computer from Mac OS X, use the "Network Utility" (location: /Applications/Utilities). Once you've opened the utility, click on the "Ping" tab. Enter the TCP/IP address of the Windows computer in the field specified and click on the "Ping" button.

You should see something very similar in the field below:

Ping has started ...

PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: icmp_seq=0 ttl=128 time=0.629 ms
64 bytes from 192.168.0.1: icmp_seq=1 ttl=128 time=0.622 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=128 time=0.605 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=128 time=0.587 ms

--- 192.168.0.1 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max = 0.587/0.61/0.629 ms

If instead you receive something similar to this:

PING 192.168.0.1 (192.168.0.1): 56 data bytes

--- 192.168.0.1 ping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss

This means that either TCP/IP is configured incorrectly on one of the two computers involved or there is some type of network problem. The computers must be able to ping each other before you can install and use DAVE.

One cause for this symptom is if the domain account being used to login with is in multiple groups in the AD. One workaround for this problem would be to enter an OU into the groups OU field using Directory Access. Putting in an OU that doesn't have any groups will prevent ADmitMac 2.0 from returning any group info. Or, you may put in an OU that has one of groups the user is in, and ADmitMac will only return info about that one group.

Another cause we've found is to check to see if they have Etrust security software from Computer Associates installed (http://www.my-etrust.com/). If so, have them go into their Etrust software and have them deselect Network Drives in the Local Scanner and in the Realtime Monitor.

This is a refresh issue that is a known limitation with certain applications that were written using Apple's Carbon API, but not applications written using Apple's Cocoa API. The work around is to change the folder view in the "Open" dialogue window of the Application or to cancel out of the "File - Open" dialogue in the affected application and then go right back in and try to open the share again. The second time you attempt this, the links will not appear greyed out.

Instructions for getting a tcpdump remotely via ssh.

Mac1 = The Mac you will log into the domain and the one that has the problem

Mac2 = The Mac using SSH

Enable Remote Login on Mac1, to do this,
- Open System Preferences
- Select Sharing in the Internet & Network section
- Click the Remote Login box to enable this feature
- Quit System Preferences
- Logout

SSH login from Mac2 and start the tcpdump, to do this,
- Launch the Terminal application from the Applications/Utilities folder
- At the prompt, enter "ssh administrator@192.168.0.1". Replace
'administrator' with the name of a user on Mac1 that has local
administrative privileges, and replace '192.168.0.1' with the IP address of
Mac1.
- Enter the local administrator password for Mac1
- You should now have a prompt for Mac1
- At the new prompt type cd desktop and press the return key
- If the remote computer connects to the network via built-in Ethernet, then at the prompt type:

sudo tcpdump -s 0 -w admitmac.trc host IPaddress (the IP address of Mac1)

and press return. (Note: "-s 0" includes a zero, not the letter O.)
If the remote computer connects to the network via Airport, then at the prompt type:

sudo tcpdump -i en1 -s 0 -w admitmac.trc host IPaddress (the IP address of Mac1)

and press return ( Note: "-s 0" includes a zero, not the letter O.)
- Enter Mac1 admin password when prompted
- Login with domain credentials on Mac1
- Once the login is complete or the error has occurred, from the Mac2 terminal press control+c keys, this will stop the tcpdump
- At the prompt type exit and press the return key, this will end the SSH session
- Close the Terminal application on Mac2

From Mac1, login with local administrator account, you should have the admitmac.trc file on the desktop. Email this file to Thursby Software Systems.

In Mac OS X v10.6 (Snow Leopard) and v10.5 (Leopard), a default Finder option is to have mounted volumes not shown on the Desktop.

If you'd like to change this to match the way Tiger works, go to the Finder menu and choose Preferences (or use the Command and Comma keys while in Finder). On the "General" tab, check the box next to "Connected Servers".

In Mac OS X v10.5, Apple's Spotlight has been written to exclude all filesystem mounts except those that Apple's built-in networking uses. Because of this, ADmitMac or DAVE mounted volumes will not be indexed or searched.

Devon Technologies has a freeware utility named EasyFind from ( http://www.devon-technologies.com/products/freeware/index.html ) that is able to search volumes mounted with ADmitMac or DAVE.   

DFS shares and Finder "snap back"

In ADmitMac v5, we've changed the way we deal with DFS. When volume is mounted that contains a DFS link, the links will be shown as a folder icon with the Thursby "T" logo. This indicates a DFS link is recognized as such, but not yet resolved or mounted. When you open the folder with the Thursby "T" icon using the Finder, the link will be mounted. The link will be mounted when you use an application Open dialog and navigate to the link. Unix type processes will transparently cause the link to mount automatically if they look inside the link folder.

In Leopard and Snow Leopard, there is a Finder issue currently being referred to as "snap back". When opening a DFS link, the Finder may snap back a level to the containing folder when the DFS path is mounted, showing you the folder that you attempted to open. This is an Apple bug that we have been made to understand will be resolved in a future release or update to the Mac OS.