Blog: Mac

Like many new laptops, the new Apple MacBooks are too thin to have an onboard Ethernet adapter. After setting up a local account and connecting it to the internal wireless network (using WPA2 Enterprise), I was able to join the Macbook to the Active Directory domain without issues. However I quickly discovered that I couldn’t login to a domain account because by default wireless connections are not connected before login – remember, no Ethernet.
The immediate “fix” was to purchase a USB3 gigabit Ethernet adapter, but after some research later I discovered it's possible to enable WiFi before login. Here are the basic steps:

  • Install the Apple Configurator utility from the App Store. This app is designed to create deployment profiles for iOS devices but can also be used to create 802.1x profiles for OS X systems.
  • Run the Configurator and create a new profile. Update the WiFi section with the required connection information.
  • Save this profile locally.
  • Open the profile with a text editor and add XML text as outlined at This article is for an older version of OS X and refers to the discontinued iPhone Configuration Utility (which was replaced by the Apple Configurator), but the manual edits still apply to OS X 10.10 and 10.11.
  • Double-Click the edited profile to import into System Preferences. You can see the loaded profile by going to the 802.1x section of the Network->Advanced settings in System Preferences.
  • Logoff or reboot and you should be good to go.


Last week, one of our customers experienced a system wide outage due to a new MAC on the network. That’s right… it is typed correctly. During the setup of a MAC OS Lion 10.7 installation, one of the users had a home folder set in their Active Directory properties. When the MAC user logged in and the laptop attempted to map the user’s home folder, the EMC Celerra NS40 NAS that serves as the back-bone of the network serving CIFS shares and about a dozen iSCSI LUNs to Microsoft Exchange, SQL Server, and VMware hosts, experienced a kernel panic and crashed….very ungracefully I might add. The outage only lasted about 2-3 minutes while the datamover failed over to the standby. However, it took nearly two hours to clean up the carnage post-failure. Not to mention, two hours outside of business hours to fail the unit back to the primary datamover.

Specifics about the exact cause are not 100% clear, but two things are known. First of all, MAC OS 10.7 uses a different SAMBA client than previous versions. Formerly, MAC OS used a bundled open source SAMBA software for Windows file share and network directory services. With 10.7, they have rolled their own and replaced the open source code with their own flavor of SAMBA. According to EMC, the root cause of the issue is that MAC OS 10.7 passes a NULL value in one of the SAMBA message headers. Obviously, this is a problem for the Celerra. No word as to how gracefully Windows file server handle this issue.


When enabling whole disk encryption, be sure to save the recovery key externally from your laptop.  I recently upgraded to Mac OSX 10.7 (aka "Lion") and enabled the new whole disk encryption feature which is now part of FileVault.  Before encryption begins it provides the recovery key but it's up to you to save it offline (no USB flash drive option).  Thankfully I did this because when I rebooted it prompted me for local admin credentials which of course I changed and didn't remember.  Without the recovery key saved on my home network I would have been in big trouble.


I was recently helping a friend who was having trouble getting online with her Mac laptop.  After over an hour of talking to Apple they told her that her computer was self assigning the IP address, but did not tell her how to fix it. 

A little bit of forum scouring provided me with more than a few people who are having the same issues and a few ideas of how to fix this issue.  The idea that seems to have fixed the problem was resetting the PRAM.  Parameter RAM, or PRAM, is a small amount of RAM that stores the basic setup information about the computer.  This includes settings for the mouse, keyboard, startup, etc.  Warning, you may lose some of your customized settings.  However, you can use the Control Panels to restore them.  Here are the steps to reset your PRAM:  [more]

  1. Shut down the computer.
  2. Locate the following keys on the keyboard: Command, Option, P, and R. You will need to hold these keys down simultaneously in step 4.
  3. Turn on the computer.
  4. Press and hold the Command-Option-P-R keys. You must press this key combination before the gray screen appears.
  5. Hold the keys down until the computer restarts and you hear the startup sound for the second time.
  6. Release the keys.


In a prior post I outlined a method to set the time zone from the command line using a control panel applet.  I needed to do this to fix a problem with the Mac RDP client which doesn't work correctly with time zone redirection.  Using the control panel applet works great on XP and 2003 Server, but only launches the Date and Time applet on 2008 and Windows 7.  After a little bit of research, I found a utility called tzutil that's included with Windows Server 2008 and Windows 7.  This is the same utility Microsoft used to change time zones during the last daylight savings time calendar change. [more]

Syntax:   tzutil /s "Central Standard Time"


I had recently upgraded a Mac user to the v10 PGP client and registered them with the bank's PGP Universal Server.  Everything seemed to work fine, but the user later discovered that PGP would prevent them from shutting down their machine if their iPod was attached.  Other devices didn't seem to affect the shutdown process.  I did some research and found this was a known issue.  The fix was to simply update the client from v10.0.0 to v10.0.2.  Obtaining the v10.0.2 update proved to be trickier than expected, but with a coworker's help I was able to download the update and put it on my USB thumb drive.  With update in hand, I strolled over to the bank and quickly installed the update off my USB drive (ensuring the customer this simple procedure would fix their problem).  When the computer rebooted, I pulled my thumb drive out and waited for the PGP screen to come up.  When it did, I had the customer enter their PGP Wholedisk passphrase.  After a couple of failed tries, PGP accepted the password and began to load OSX.  Then, the OS crashed! 

The user told me that happens sometimes after he misses his PGP password, so he simply restarted and tried again, this time putting the password in correctly the first time.  It ended the same way however.  At this point, the room became very hot and I started to sweat profusely.  I was sure I had just trashed this guys' machine by applying this simple update.  I'm sure he was starting to think the same thing too.  I sat down at his machine, wondering what in the world my next step was going to be, and then it hit me.  "I wonder if PGP needs something off the installation media (my USB drive) to update the boot process?"  I shut down the machine, plugged my USB drive back in and powered it back on.  I logged in to the PGP screen, the OS started to load...loading....loading....loading... OSX login screen!  Suddenly, the temperature in the room dropped drastically.  I had the user log in, I removed my USB drive and rebooted again.  Everything came up perfectly.... much to my relief. [more]

One other note about PGP and OSX upgrades...
In some cases, PGP will modify the system partition table enough that OSX upgrades (in my case, Leopard to Snow Leopard) won't be able to identify the currently installed OS.  This makes doing an in-place upgrade impossible.  The fix is to simply open Disk Utility, select the system disk, select the Partition tab, resize the system partition by dragging the bottom right corner up, then right back down (this should enable the "Apply" button), click Apply (confirming the change), exit Disk Utility.  The OSX upgrade should be able to correctly identify the currently installed OS after this.


Back several months ago I tried to update my laptop to Snow Leopard (OSX 10.6).  Most things worked great, but at the end of the week when I started doing some of my reports, I noticed lots of file system problems.  The Word documents I was editing would become read-only after I saved them once.  New documents I created would be read-only.  As I got to digging, I found that any files I created on the file server were being created with empty permissions (as viewed from my laptop), and read-only permissions (via the checkbox) as viewed from the Windows side.  I found lots of people having the same problem with no real workaround.  I noticed the permissions would fix when I viewed them from the Finder, or when I did an ‘ls –l’ from the command line.  I restored my system back to Leopard from my backup (which was nice to have available) and waited for a fix.  Well, the fix came in the recent release of Snow Leopard 10.6.3.  I’ve updated again and everything works great.


I think we all know better than to download executable programs (.exe's) from untrusted sources and run them.  Opening a Word document from an untrusted source could be dangerous.  Now, even opening a PDF file on a fully patched Windows machine with excellent, up-to-date anti-virus and malware software could cause your machine to get owned.

Didier Stevens, who has written some great PDF analysis tools, published a disturbing blog post the other day.  He demonstrates how to use an existing feature in PDF to execute a program on someone's computer when they open the document.  Adobe Acrobat Reader displays a message first, but the message can be changed to social engineer someone into clicking the Open button on the message.  And my favorite PDF reader, Foxit, does not even display this message.  Disabling javascript does not help. [more]

Here is the link to his article:

I downloaded his extremely simple example and in a few seconds changed it run a batch script instead of cmd.exe.  It looks it would be trivial to make it run any sequence of commands desired.  Depending on the PDF viewer used on other operating systems such as Linux or Mac OS X, this same technique will work there.

When using Google, one might consider clicking on Quick View or View as HTML instead of viewing the actual the PDF file.

UPDATE:  Adobe finally responded to this, explaining simply how to disable this feature.  This sounds like a good thing to do for most users.


I’ve been using the Microsoft RDP client for the Mac to login to one of our terminal servers.  Unfortunately this client has an annoying bug where the time zone is not set correctly if time zone redirection is set through group policy.  After manually changing the time zone a few days in a row I decided to look for more automated solution.  I found that you can invoke the Date and Time control panel applet from a command line and pass the desired time zone.  The command is: [more]

control.exe timedate.cpl,,/Z Central Standard Time

The time zone has to match the one key values saved in the registry at HKLM\Software\Microsoft\Windows NT\CurrentVersion\Time Zones.  I put this in a command file and added it to my startup group on the server.


I had several issues getting my PGP Desktop software to correctly talk to the PGP management server.  First, I went through the default install without any problems.  I configured my private/public keys and encrypted my disk.  I got word from Chris Brewer later, however, that I wasn’t showing up in the PGP server.  We both tried several things to get me in.  I tried importing my private key to the server, but it failed and the log was saying I wasn’t part of the managed domain.  We eventually called PGP support and got my PGP Desktop software reconfigured to use my domain credentials and register with the server.  Turns out I should have done a custom install and targeted our PGP management server… rather than the default stand-alone install.  I was now showing on the server, but I was showing to be decrypted.  My disk, however, was encrypted.  I decided to decrypt and re-encrypt now that I was talking to the server.  This was about a 24-hr process.  After re-encryption and multiple reboots… I still was showing to be “unencrypted” on the server.  The PGP support guy had mentioned the Mac client had some issues reporting properly to the management server and he had  a special build he could let us try.  Once we got it, I installed it and rebooted and everything was fixed.