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.

On "Personal Technology" and the "Next Big Thing"

I have the fortune (or misfortune) of getting Information Week delivered to my door. This year has seen a lot of articles about iOS, Android, Personal Technology, and custom application development. Of course, the executive team at work gets Information Week as well - from the CIO down to the department managers. We have been fairly forward-looking for a while - when Apple released the iPhone 3Gs we were able to support deploying those on a corporate level, and allowed users to bring them into the environment (on a personal level) if they were configured with a profile as detailed in the Apple iOS Enterprise support documentation.

Sadly, we were unable to support droids for a while, since they didn't even conform to ActiveSync security policy (this has changed, fortunately). This has been going on for a couple years, and for a business that is very concerned with privacy (we are a hospital, after all) it was very forward looking. The hospital did not choose to go the route than many others are on - hiring a team to develop custom applications for iOS or Android connectivity to our various data silos, but that wasn't a problem.

This year, however, has been the year of "personal technology" in the trade rags. And as the hospital desperately wants to be at the forefront of technology, they are pushing for support of personal technology at every level.

I am a fan of supporting personal technology. It helps your employees feel attached to your business. It makes them believe that you care about them, and their wishes. But sometimes, you have to balance that with security, business needs, and legal concerns. A strong leader in IS doesn't just give in to the employees, no matter how important they are, if what they want to do compromises the security of your business, and even more important if it compromises state or federal law. I thought we had a strong leadership team in our IS department. Turns out I couldn't be further from the truth.

Leadership knows one word when it comes to "I want" from the VIP/high-profile users: "Sure!"

Can I bring my personal device to the hospital, put explicitly restricted patient information on it, without any oversight or data security managed by the IS security group?

"Sure!"

Can I buy hardware that is blatantly incompatible with our environment, and connect to the internal network with it, so that I look important at conferences and meetings?

"Sure!"

But when we (as the IS team on the ground with the technology) attempt to raise red flags, or warnings to the leadership team that we need to have some sort of structure around these things, and they have to work (function) within the legal and moral scope of our business, we are ignored, or (worse) chastised for even considering such things.

Personal Technology is the "Next Big Thing" in IS - it makes sense because it can save money, it invests your employees in the business on a personal level, and it can improve the effectiveness of your employees - when your environment is able to support it. Before you take the time to let every smartphone, tablet, and personal device into your environment, you need to evaluate the devices, develop a plan, and implement it in a measured way with continued review to determine if what you are doing works for your employees and your business.

SMB issues with Lion Mac OS X 10.7

This is more of a rant than anything. So be prepared.

As you may (or may not) know, my day job is in IS at a fairly large regional hospital group. I was brought on a couple years ago because of my experience with Mac OS X, and their desire to evaluate and deploy Mac systems in a limited fashion. I put in the effort and legwork to get Macs integrated as much as I could, with what support I had from the leadership. For around 2 years it worked OK. Then came the Lion.

Mac OS X 10.7 has issues here. I'm not sure if it has issues everywhere, I guess it depends on how your environment is built, and whether your users are actually using the environment and not just the computer. The first (and biggest) problem is that when Mac OS X 17.0, 10.7.1, and 10.7.2 connects to an SMB share, it doesn't actually mount the share you requested. What Lion does, is parse the share path, and actually mounts the directory containing the share you want to mount. That seems to be confusing (at least to AppleCare), so allow me to explain.

If you want to mount the share myhomedirectory from your SMB server, you enter the path:
smb://mycompanyserver/homedirectories/myhomedirectory
In Mac OS X 10.4, 10.5 and 10.6, the following things happened when you authenticated to that share:
1. SMB mounted the device /Volumes/myhomedirectory
2. The sidebar shows mycompanyserver under shared devices
3. Finder opens a folder of myhomedirectory
4. Mac OS X display the share myhomedirectory on the desktop (if this item is visible).

In Mac OS X 10.7 the following things happen:
1. SMB mounted the device /Volumes/homedirectories
2. The sidebar shows mycompanyserver under shared devices
3. Finder opens a folder of myhomedirectory
4. Mac OS X display the share homedirectories on the desktop (if this item is visible).

OK, now read through those again. When I was on the phone with Apple, they explained that they had changed the behavior of SMB to mount the root share. Except that's not what they are doing. They are mounting the directory one level above the share point you attempt to access.

This introduces all sorts of problems which may be security issues, or just user-friendliness, depending on your environment. In my environment, no-one has any access to homedirectories - so the links on the desktop, in volumes, and in the sidebar are all useless. The only thing useful is the Finder window that opened, but only if you leave it in List, Cover Flow or Icon view, because if you change to Columns it breaks and you can't see your directory contents anymore. If for any reason you close that Finder window, you have to use Go -> Go to Folder... to reopen it.

Of course I opened a ticket with Apple, and got it escalated, but I'm not holding my breath. In the meantime, we get the following issues in our environment:

• When a user logs into a Lion system, they are presented a dialog listing all the share points in the directory where their network home folder resides. They have to navigate to the network home folder, select it and then continue before the system will log in.
• If a user connects to a network share, they have to be very careful about the application they attempt to use, because most applications won't be able to parse the path if the entire directory tree isn't at least readable by all.

So Lion is effectively broken in my environment. Which, by the by, has about 15,000 PC systems and about 50 Macs. Which leads to tomorrow's post: On "Personal Technology" and the "Next Big Thing".

It's the interface, stupid...

So I just spent 20 minutes on the phone with a potential iPad user, and I realized something during that conversation. The "amazing and magical" hype about the iPad isn't the device itself, it's about the interface. HP has a device quite similar to the iPad (at least in initial visible review) coming called the Slate, but it runs Windows. That will be the actual downfall of the device - because a desktop OS isn't a true touch-tablet interface. I've used the HP all-in-one desktop touchscreen - it's a novelty but you really need a keyboard to use Windows effectively. That's what iPad has going for it, along with the other iPhone OS devices, as well as the Android OS devices - the UI is a unique experience focused on a touch-based interface, not a mouse and keyboard.

If you've never really used a touch-tablet interface like the iPad, or a Surface device, you can't understand - even if you use one of the tablet based PCs out there like the Lenovo X200. The interface and the way you interact with the device is what makes or breaks it - so although I am optimistic about the Slate for those Windows-only environments (like the hospital I work in today), I'm afraid that it will fall flat, with a mouse/keyboard UI that fails on a touch based device. Only time will tell, however, if HP and Microsoft "get it" with touch interface PCs beyond the shiny nature of a Surface....

Scripting smb fun

I'm not a UNIX geek by nature. I'm a Mac guy, but any Mac tech worth their salt isn't afraid of the shell. I've spent more and more time in the shell, knowing that my goal (ACSA) will require a lot of hard-core shell work to get. So when I try to script a silent install of Check Point Full Disk Encryption, it's not the walk in the park it might be for others.

In the end, the answer was simple:

mount -o noowners -v- t smbfs //domain;user:pass@sharename mountpoint

will mount the smb share for all users, bypassing the sudo the script runs under, and enabling access to the share by the FDE Installation package.

However, this foray into shell scripting is getting deeper and deeper as I try to automate my Mac setup more and more. My current favorite utility? Bwana - a great utility for viewing man pages in Safari.

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