Skip navigation

FileVault 2's FDE = Goodbye to remote boot & login?

1621 Views 6 Replies Latest reply: Nov 27, 2012 12:38 PM by Macrosheep RSS
TestBeforeSelling Level 1 Level 1 (0 points)
Currently Being Moderated
Apr 7, 2012 10:08 AM

Does enabling Lion's Full Disk Encryption (FDE) in FileVault 2 effectively rule out being able to remotely restart & then log in to the Mac?

 

So far, for me, yes it does    I walked straight into this hassle and could kick myself for not seeing it coming.

 

I can understand the fundamental problem here... booting from an FDE-enabled Mac drive first involves the Mac booting from the EFI firmware to perform the machine login.   Then, and only then, does it go on to boot from the startup disk and configure everything as normal.

 

Meaning of course, during that initial (firmware) login, with no OS loaded at that point, the Mac's networking is unconfigured and hence inactive, meaning in turn I can't remote to it to enter the login creds.  Catch 22!  Someone has to be there physically with the machine to do the login, ho ho.

 

Now, not being able to remotely restart a Mac and THEN log in to carry on working on it is a MAJOR hassle for me - I need to do that loads.  And I suspect can be just as awkward for many other business/educational Mac admins out there, especially where remote admin is more needed.  Fortunately,  some such admins can simply not bother using FDE on the boot drive for that very showstopping reason, lucky them!

 

But... what about those of us who now have to use FDE on their Macs, like me?  I support 20+ Macs and an XServe within a massive corporate enterprise.   The company's global policy makers are now insisting that ALL machines (whether PCs, Macs or whatever) that are used to handle or store company data must have full disk encryption running, and all data files placed on fixed & removeable media are encrypted.  I believe this strategy is an increasing trend across larger organizations especially, given ever more focus (and some paranoia!) on data security lately.

 

Sooooo.... on hearing about this unwelcome and sudden need for FDE, I reluctantly decided maybe it's time to consider upgrading all our Macs from SL to Lion, if only to get the FDE feature from Lion.  We must have FDE for the Macs, whether it's Apple's or a third party solution for that.  Naturally, I'd much prefer to go with the built-in Apple FDE - if I had that choice.

 

AFAIK there's no way round this roadblock (well, ok, short of elaborate measures like a remote-controlled robot to tap in the login creds!).  Maybe there's at least one third party FDE tool wouldn't have the same problem?  I don't know yet - I only got as far as trying out the Apple route.  Until I was stopped in my tracks.

 

Or, am I missing a trick?  Please, someone tell me what I can do about this situation?  But please don't suggest to try getting our policy makers to change their stance on this security rule - no way will that happen.  With 100s of 1000s of PCs yet only a handful of Macs in the company, I wouldn't even be heard!

 

I do about 95% of my Mac admin work remotely.  And most of that is done outside office hours, to avoid disruption to users.  I frequently schedule the Macs to power themselves on at nights so I can then do maintenance/repair work on them, often needing to do restarts along the way, hence my predicament now

 

As I write, the test Mac I was upgrading to Lion last night and enabled the FDE on is now sitting there miles away waiting for someone to log in.  I can't get anyone to do that for me until they return on Tues from the Easter break, and it's a long way for me to travel to do it myself.

 

Perhaps what's needed is some sort of change to the EFI firmware, to allow remotely sending the necessary login creds to the boot rom, via some LOM-type alternative connection into the ethernet i/f?  Or, get the EFI firmware to also include the config & enabling of the Ethernet and a skinny ARD client?  But what are the chances of Apple providing any such solution anyway? Just thinking out loud here...

 

When Apple announced the death of XServe I was wondering how business users can carry on using Macs for much longer.  This latest issue, with FDE, is another nail in the coffin, if not the final one.

 

Ideas/comments anyone please?

  • Topher Kessler Level 6 Level 6 (9,305 points)

    My recommendation here would be to avoid filevault on the boot volume, and instead put sensitive data into encrypted disk images or on secondary hard drives that are encrypted. Perhaps one could rewrite the EFI firmware to store the filevault password or encryption keys and automatically unlock the volume, but this would defeat the purpose of FileVault.

     

    As it stands, if you need to do remote work that requires rebooting then you should not enable FileVault on the boot volume.

  • Topher Kessler Level 6 Level 6 (9,305 points)

    One option is to get a KVM switch that has remote access capability, such as the following: http://www.rackmountmart.com/rmLCD/lcdK1039.htm

     

    From here you could reboot the system and provide the initial login credentials to unlock the drive via the switch, followed by directly accessing the system via SSH or VNC (or continuing to use th switch).

  • Macrosheep Calculating status...

    Hi TestBeforeSelling,

     

    In 10.8.2, Apple built in the ability to initiate an authorized pre-boot authentication bypass via CLI:

    sudo fdesetup authrestart

     

    This essentially allows you to provide credentials for the pre-boot authentication when you're initiating the restart action.

Actions

More Like This

  • Retrieving data ...

Bookmarked By (1)

Legend

  • This solved my question - 10 points
  • This helped me - 5 points
This site contains user submitted content, comments and opinions and is for informational purposes only. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Apple Support Communities Terms of Use.