Macintosh gotchas

Question

Up until now, I've only managed networks with Windows users and the occasional *nix server. Soon, a few users with Macs will get added to our network. What are some "gotchas" to look out for when adding Macs to the network? Key concerns here: compatibility with Active Directory and security

Answer 1

You might want to invest in a utility that disables the creation of .DS_Store files on network volumes. Otherwise you'll find these little files popping up all over your network volumes as the Mac users use them.

I use an app called Cocktail for this.

Answer 2

If you have enough Macs, I'd suggest adding a Mac server - to create the so called "Holy Trinity". You don't even need to buy an Xserve - OSX server runs on a Mac Mini!

The Macs use AD for all the normal access/permissions and the Mac server for Mac specific task such as updates (you'll find a Mac version of WSUS called Software Update Server). You could also use the Mac server deployment options (NetInstall) for installs.

Answer 3

If your internal domain is .local, you will have a problem resolving names via DNS. There is an old article on Mac OS X Hints which describes a solution:

I created a company.local file in /etc/resolver, and populated this file with the nameservers for the company.local AD domain. This allows Mac OS X to use standard DNS to resolve company.local (or subdomain.company.local), while still allowing Rendezvous to operate as expected.

The only drawback I've seen to this approach is that the nameservers in this company.local file don't update via DHCP, so I have to update them manually.

Here is a more official support document from Apple which will parse your existing /etc/resolv.conf to populate the file in /etc/resolvers.

Answer 4

Updates ... although OS X can authenticate to AD there is nothing that requires them to update their computers. Make sure you talk to them about installing the updates as they come out. There really isn't any way to force them to do it though.

Answer 5

Some versions of OSX crash a lot when connected to a windows 2003 server that has active directory enabled. They seem to have fixed it at some point but I couldn't tell you when. So keep up to date.

Depending on who gets the machine, you may or may not want to enable network logon. While you can restrict user access (using parental controls) you might just want to make the user not an administrator and leave it at that as many apps self update and spawn other apps, so restricting them can lead to trouble. I've always giving my mac users full aministrative access and never saw any of the problems crop up that I've seen my windows users get into when they have full admin access to their boxes. There's basically no spyware or virus's for the mac, it makes it a lot easier to maintain.

You should also note that every mac has "internet sharing" capability that comes with a DHCP server which can cause trouble.

Also enable imap in exchange and let them use apple's "Mail". It's worlds better then entourage. Also the address book has ldap support built in. There's nothing else special to the mac that comes to mind.

Answer 6

Here's a good trick, don't bother trying to get OSX itself to connect to your AD - it can be done but I believe it's not that easy and can take a fair bit of support. Buy something called 'AdmitMac' from http://www.thursby.com/ - it takes all the pain away and is of course supported by them directly. Oh and don't let your macs use any protocols that you're not happy with, they're very flexible but they should work around you not the other way around.

Answer 7

I know of a few end-user support issues you might encounter:

• Renaming a user's home directory can result in "missing files"
• While this has since been fixed, earlier versions of OS X had some AD integration issues at times.
• Replacing a folder with a folder of the same name can have semantical differences from what you're used to.
• It is possible to blow away a directory (under certain circumstances) by writing out a file with the same name.

Answer 8

One thing it took me a while to figure out: if you set an "inherit" ACL on a folder, it will only affect newly created files - the "gotcha" being that if a user "drags and drops" a file into the folder in question, the permissions for the folder won't change in any way (unless it's dragged from a different volume, where it will, in essence, be copied and pasted). For the files to assume the inherited ACL you set, they will have to "copy and paste", or manually set the permissions... maybe (since ACL behavior should in theory be the same) this happens on Windows too, I don't know, but it's worth repeating.