Macs do a lot of things well: user friendliness, works well with high-end graphics, out-of-the-box simplicity. But, when it comes to accessing network shares in a Windows environment, it can mean disaster: conflicting authentication, slow log on times and sometimes, no access.
Apple has had, for a long time, AD integration built into the Mac OS. Windows uses Kerberos as the default authentication protocol, and Apple has gone along with that. There is even a SSO (Single Sign On) solution in the Mac OS documentation. If setup correctly, a Mac user can sign on to the local machine and have the credentials passed to the Windows domain for network resource access seamlessly. Getting this to work properly depends on many factors.
Joining the Mac to the domain isn’t difficult. The AD plug-in is in Mac OS X 10.3 and later. Navigating to Applications–>Utilities–>Directory Access and entering the Windows Active Directory Server and credentials and initiating the Bind should do it. Centrify is a free utility to also join Macs to Windows domains.
The first problem Windows administrators will come across is the .local domain conflict. It is best practice to avoid naming your internal domain the same as your external. If I use wificastle.com as my internal domain name and it is also registered on the internet (external domain), a split-brain DNS server will be needed to differentiate what is inside the local network and what is on the internet so internal users can access both. Wanting to avoid that, most Windows domain suffixes are .local instead of .com. Microsoft takes it a step further in that it defaults to a .local domain suffix when setting up Small Business Server 2011.
Apple has its own network resource protocol: Bonjour. Bonjour will scan the network for other Macs broadcasting shared resources and present what it has found to the user in the Shared list. Here’s the problem: Every Mac machine considers itself a separate .local domain. So, if a Mac is a member of a Windows domain with a .local suffix, Bonjour will take priority over DNS. This will significantly delay the ability to see Windows Shares. It will also delay connecting to shares via a SMB Network connection via Go–>Network.
One way to fix this problem is to yield to the Mac and use other internal domain suffixes besides .local for your Windows AD Severs. Obviously, this would be a preparatory step knowing you may have Macs in your Windows environment sometime soon. A fix is provided here for existing .local domains: Changing the Search Policies in Mac OS X
The usernames conflict is another annoyance exacerbated by the .local domains. If a Mac user has a machine username that is identical to their Windows domain username, bad things happen. The user will be unable to log on or experience long delays before gaining access. This occurs because Bonjour forces the Mac to use its local credentials. The same thing can happen with identical usernames and passwords, most likely because there are no domain differentiators. The easiest fix here is to make sure the Windows usernames and passwords are different than the Mac machine credentials.
Using third-party tools to help Mac users access Windows shares is an option that I have used. ExtremeZ-IP is a utility that wraps SMB (Server Message Block- Windows file sharing protocol) shares in the Mac friendly AFP (Apple Filing Protocol). The Windows shares are presented in the Shared folder as if they belong to a Mac. Logging in with Windows credentials is required, but once added to the keychain, log on should be automatic. It’s a bit pricey, but ExtremeZ-IP sped up the access to Windows shares quite a bit.
In summary, we all have to plan ahead for integrating Macs into Windows networks. Not using a .local domain suffix will probably fix most of the authentication problems. In existing .local networks though, the workarounds above will make life much easier.
Categories: IT Pros