Active Directory and OS X client issues and workarounds

So I'm perusing my email today, when I get this tidbit:

And I think to myself, yeah, that's a pretty good title.

We utilize Casper at my place of work. We also have Active Directory. They both provide different things to Mac clients, but are separate silos of service. So here's a quick couple things about Active Directory with OS X clients I've experienced over the last 8 years in an enterprise environment.

Recently we've been experiencing an issue with our Mac clients failing to renew their client keys with Active Directory. Basically, we bind a client, then at some point when they request their client key update, AD fails to recognize the key presented by the Mac, and within 24 hours the Mac will no longer receive any data response from Active Directory. It still *looks* bound with the basic tests, but it isn't actually reading any data from AD. How can you tell quickly and easily? ID a user in Active Directory via Terminal. A local user account will have something like this as a response:

macosclient:~ admin$ id admin
uid=499(admin) gid=20(staff) groups=20(staff),12)everyone),61(local accounts),80(admin),33(_appstore),90(_lpadmin),100(_lpoperator),204(_developer),,398(com.appleaccess_screensharing),399(com.apple.access_ssh)

An Active Directory domain account will have a very different response:

macosclient:~ admin$ id itadmin
uid=191571970(itsupport) gid=951704675(MYDOMAIN\Domain Users) groups=951704675(MYDOMAIN\Domain Users),191535401(MYDOMAIN\Everyone - GAL access),1700667532(MYDOMAIN\Exchange Admin),12(everyone),62(netaccounts),1163998572(MYDOMAIN\AD Delegation),461668394(MYDOMAIN\Citrix-OfficeDemo),675762013(MYDOMAIN\Techserv),1066250157(MYDOMAIN\DesktopAdmins)

So if you enter a known Active Directory account and get a local account response (or no response) you know that the computer isn't actually getting a data feed from Active Directory even though it appears to be a bound AD client. You will need to unbind and rebind the Mac to resolve this issue, ideally removing the Active Directory computer object manually (because a broken bind prevents the AD plugin from cleaning up on it's own). In addition, after some troubleshooting (that wasn't as helpful as I hoped), we ended up changing the client password/key interval to never request a refresh:

sudo dsconfigad -passinterval 0

Although opening a bit of a security hole (because our Mac clients will never request a refresh from AD), this has resolved the more business-impacting issue of AD users unable to log into Macs with current credentials. Which leads me to the second piece of this AD discussion.

When naming an AD client computer, think old-school DOS naming rules, and stick to them. Active Directory won't prevent you from leaving a Mac name like "John Smith's iMac" when binding to AD, but you will get an actual device name like "john-smiths-imac$" which isn't the same client name. Much like any system in a traditional network, you should change the name to be something friendly to DNS, so 13 characters or less and no funny business. We've found that seems to improve AD communication stability of Mac clients when bound to our domain.

In addition, recent versions of OS X Active Directory plugin do a great job of communicating and registering Dynamic DNS client IDs. Unfortunately, if you are using any iteration of a Mac Pro, you have the possibility of using two separate network ports for two separate connections, and having two duplicate DDNS ids. This can cause issues when using StorNext or Xsan with a separate metadata subnet on the secondary ethernet port. This one is also easily resolved with the AD plugin:

sudo dsconfigad -restrictDDNS "en1"

This command will restrict dynamic DNS updates to the second ethernet port only. There are some details I've left out (like determining which port to restrict to) but I'll leave that as an exercise to the reader.

Those are some small tidbits of managing Active Directory features in OS X. There are a whole slew of other things you can do with the AD plugin, which you can learn about in depth with the man pages available for dsconfigad.

Next time, I'll talk about how to integrate Active Directory binding into Casper Imaging sequences.

Being a Mac in a Windows world

So you hear this all the time. "I'm a Mac user - I don't want to use Windows. I don't like it/It sucks/It gets viruses..."

Whatever. The Mac is far from perfect.

I"m a Mac user too. For the last 3 years I've been struggling to bring the Mac on par with Windows in the "Real World" of business. I had it easy the first couple of years. I worked in a cable broadcast environment, where the Mac already had a presence in motion graphics and marketing. It was also commonly used in associated companies in other broadcast production services, so there it wasn't a matter of bringing the Mac in from scratch, it was a matter of integration and trying to bring parity to the Mac platform. Parity was a challenge of mindset - the IT group there was so entrenched in "The Windows Way" that the Mac was still Mac OS 7/8/9 - pretty, for making pictures, but not a real computer. During my career there, all the easy work was done, and some of the hard work as well. When I left, all the Mac systems were bound to a "Magic Triangle Cylinder of Destiny" environment with AD/OD management, SSO login processes, and IT viewed them as another piece of the environment, no longer just a pretty picture-making box. I may write more about my experiences there, but this is about my current experience, mostly to keep me sane.

Here, at my new job, I really am a lone Mac in a Windows world. I've moved into IT support for a large regional hospital/medical group. I was brought in to plan and develop an integration plan for Macs in the environment, as the entire IT group here is (again) living in Microsoft land. I was here for almost 3 weeks before they took one of the 8 (yes 8!) Macs they had and let me get started with this project. In the next few articles I'll describe the process I've gone through, mostly for my own sake but also for those who might accidentally stumble across this and either have additional information or need to do something I've already done. Stay tuned...