Is anyone using Credant (full disk encryption) on their Mac laptops?

We use PGPWDE with our Macs (and PC's). I push the installer PKG provided by the company and use at imaging time or using remote. I have an inventory extension collect status of the disk.

Everything runs through a tal server that keeps recovery keys etc...

We were using Filevault, but had too many issues. So we went with a Sparseimage of a Folder and put it in the user template. Created a launchd to a encrypted script to open it.

D. Trey Howell ACMT, ACHDS, CCA
trey.howell at austinisd.org
Desktop Engineering
twitter @aisdmacgeek


We are also using PGP here, I use the extention attributes for status, and I
have two others for version, and users who have enrolled(sometimes we have
more then one user on a laptop).

having issues install credant, on osx 10.8.4, credant suggest i edit the plist in which i did. Still won't work. Time to wait on the vendor to get back to me. Credant you cant push, because you need to setup the server info manually and authenicate to encrypt the machine. Having issues with certain machines not getting polices from the credant server.so much fun

I know this is an old thread, but the powers that be where I work have decided that we're going to begin encrypting our Macs with FV2 enabled through Credant (now known as Dell Data Protection Encryption) instead of through Casper.

We actually went from Pointsec (Check Point) to PGP WDE to FV2 through Casper and now to FV2 through Credant over the past 5 or 6 years.

I've done some testing with v8.1.3 which is apparently only officially supported on 10.9.3 and earlier, but appears to work on 10.9.5 and 10.10.1. The lack of updates or official word from Dell on whether e.g. Yosemite is supported or not doesn't sit too well with me.

One of the neat things is on 10.7.5, where it walks through an Automator style action of enabling FV2 for you through System Preferences, and captures the key which is escrowed on the DDPE server.

The not so nice thing is all recovery keys are wrapped as a "key bundle" which means you have to use the DDPE recovery tools to perform a recovery. Ugh. As far as I can tell, only PRKs are supported - I'm waiting to hear back from IT Security about this, but I don't think we have the ability to setup an institutional key for our organization.

I repackaged the installer using Composer and included the plist that configures the server address etc. I can post my plist if there's any interest in seeing that. You can push this pkg from Casper, but it still requires the user to authenticate before it begins encrypting. Since it's just using FV2 to encrypt, Casper reads the encryption status etc just fine.

Years ago (back in Lion), I did a write-up on Credant. It'd be interesting to see how much has changed:

http://derflounder.wordpress.com/2012/12/14/credant-enterprise-edition-for-mac-adds-filevault-2-support/

@wyip when I started this thread in 2010, we had a couple thousand Macs running 10.6 at a major movie company. Since Apple didn't provide FDE at the time, we vetted the available third party solutions until the only that was left was Credant.

Like most third party vendors trying to grab some of the Mac market share (cough), they made a lot of promises that were more sales driven marketing hype than anything - much like Microsoft and their "SCCM does Macs!" claims.

Luckily for us, the project fizzled and eventually died. Even though Credant looks capable of escrowing FV2 keys, their update release cycle is going to lag so far behind that your refresh cycles are going to take a hit.

Now that JAMF Software offers native support for FV2 keys, its hard to imagine using anything else. But, like anything else in enterprise, it's not enough a tool to be good at something, you have to sell it to the folks who matter. ;)

@rtrouton Nice writeup! Actually, it looks like not much has changed since you used Credant, besides the name/branding and a few other elements in the admin console. Also the recovery key bundle is no longer a CSV file, but the way you use it is the same. Very interesting that it is actually an Institutional Recovery Key being generated for each computer.

@donmontalvo No doubt, I am not a fan of this decision since we already have such a good system going with enable FV2 through Casper (which we've been using for a couple years). We'll see how good of a salesman I am :)

Anyone else using DDPE (Credant) still? We are going to push it to our Windows machines and the idea is to use DDPE key escrowing of FV2 to encrypt Macs. It looks like there is an additional step for El Capitan due to SIP. This requires physical access to each machine.

http://www.dell.com/support/Article/us/en/19/SLN299063

Going to see if I can sell using Casper to manage FV2 instead of DDPE.

@Vitamin-Z Yeah we're still using it for both Macs (FV2) and Windows (Dell encryption). The SIP thing is if you plan on using Dell's proprietary encryption on a Mac... you're probably going to want to use DDPE to manage FV2, so no need to disable SIP. BTW I already sent a note to our Dell/Credent Support team that telling customers to disable SIP is a terrible idea, and that they should update or remove that KB article.

The product itself actually seems to work well, and our Service Desk and IT Security people like it because it creates a single place for them to check for encryption status, keys, etc. Dell had El Capitan support 2 weeks after El Cap was released, which is better than some of the other third-party encryption vendors I've worked with. Dell/Credant customer support has been pretty good. Let me know if you have any other questions about it.

@Vitamin-Z wow. That link.

If your security software is telling your to disable a security feature of the OS... Time to move to another product.

I have been working with JAMF to see why we couldn't encrypt using FileVault2. Kept getting "FileVault is Off. Deferred enablement appears to be active for user 'aaaa'" in logs. After a couple of weeks and some escalation it ended up being an issue with the way El Capitan binds to AD. The issue was suppose to be resolved in 10.11.2 but we still see it. Hoping that it will be addressed in the next patch. As of right now we can't encrypt Macs (Casper or not) with FV2.

@wyip What was your process flow in implementing DDPE to your Mac environment?

@Vanegas I didn't do much on the server side but AFAIK the only real policy that is set on the DDPE server for Macs is to use FileVault 2 for encryption.

On the client side, I built a package in Composer that drops the DDPE plist in /Library/Preferences and the installer to /private/tmp, then runs the installer in a postinstall script. The installer reads your settings from the plist at the time of install, which includes things like the address and port to talk to your DDPE server on, what type of key to use (individual/institutional/both), AD/LDAP authentication settings, etc.

If a Mac is on 10.9+ and has FileVault 2 enabled (either through System Prefs or by Casper), DDPE will prompt you to enter the password for a FileVault 2 enabled user so that it can "take over management" of FileVault 2. It's really just generating a new recovery key and escrowing the new key on the DDPE server. The old key in Casper or whatever system you were using for escrow previously will stop working after you do this.

Our rollout project at the time involved upgrading any 10.7 and 10.8 Macs to 10.9, then we had a policy in Casper that would push out DDPE to all managed 10.9+ Macs. We did the roll out by building and had some field techs sweep through to do spot checks to make sure users were logging into DDPE to activate it, and that it was reporting in to the DDPE server properly with the updated recovery key.

Unencrypted Macs and anything new that gets imaged gets DDPE pushed at login, and DDPE pops up prompting you to login to start the FV2 encryption process. One thing to note is the DDPE client has a timeout set for this login prompt (which you can configure in the plist), but there's no way to keep it up in the foreground indefinitely, like setting timeout to 0 or something like that. I wrote a script that tells DDPE to keep prompting for login every 5 minutes until the user actually does login to DDPE which has been pretty effective because of how annoying it is. I had a feature request in with Dell to fix this but I'm not sure if they ever addressed it.

Hope this helps.

Sure, I'll kick the dead horse.

How do I get this blasted software off my Macs?? without decrypting.

There is a proprietary tool included with the installer. It seems to call a script named UninstallShield.sh but it seems to check if the disk is encrypted and returns a status of

"Managed FileVault disks exist."

I'm still an amateur at scripting so I'm not sure what I'm looking to modify. Or, if changing something will break something else or entirely.

comment>!/bin/sh comment>this script is used to install comment>common usages cd "dirname "$0"" scriptDirectory=dirname "$0" toolsDirectory="../tools" currentScript=basename "$0" me=whoami scriptDirectory=dirname "$0" currentScript=basename "$0" comment> synch EMS_FILESYSTEM_SIGNATURE with EMS_Controller.m: NSString const kEMSFileSystemLabel = @"EMS_FS"; EMS_FILESYSTEM_SIGNATURE='EMS_FS' FUSE_FILESYSTEM_SIGNATURE='fusefs' productName='Shield' kextName='DellDataProtection.kext' kextBundleID='com.credant.iomediafilter.CREDANTShield' serviceProductName='EMS Service' removeMacFuse=0 quiet=0 result=0 testOnly=0 removeFuseOption='' while [ $# -gt 0 ] && [ $result -eq 0 ] do if [ "$1" == '-f' ] then removeMacFuse=1 removeFuseOption='-f' elif [ "$1" == '-q' ] then quiet=1 elif [ "$1" == '-t' ] then testOnly=1 else echo 'Illegal parameter: '"$1" exit 10 fi shift done uninstallScriptPath="/Library/Extensions/${kextName}/Contents/Resources/Scripts/uninstall.sh" comment>test for service in use -- abort if it is emsInUse=mount | grep '^'"$EMS_FILESYSTEM_SIGNATURE"'@' | wc -l | awk '{ print $1 }' fuseInUse=lsvfs | grep "$FUSE_FILESYSTEM_SIGNATURE" | awk '{ print $2 }' if [ "$fuseInUse" == '' ] then fuseInUse=0 fi if [ $emsInUse -ne 0 ] then if [ $quiet -eq 0 ] then echo "Uninstall of ${productName} aborting" fi echo "${serviceProductName} is in use by the following media:" mount | grep '^'"$EMS_FILESYSTEM_SIGNATURE"'@' | sed 's(fuse4x.)$' | sed 's.@'"$FUSE_FILESYSTEM_SIGNATURE"'[0-9]{1,} on /' exit 101 fi if [ $fuseInUse -ne 0 ] && [ $removeMacFuse -ne 0 ] then if [ $quiet -eq 0 ] then echo "Uninstall of ${productName} aborting" fi echo 'Fuse4X in use' mount | grep '.@'"$FUSE_FILESYSTEM_SIGNATURE"'[0-9]{1,} on /' exit 102 fi kextLoaded=kextstat -l -b "${kextBundleID}" | wc -l | awk '{ print $1 }' if [ $kextLoaded -eq 1 ] then echo "${productName} is still in use. Please reboot and try to uninstall again." exit 104 fi comment>if the kext isn't loaded then any managed disks we get status for are FV2 disks disklistPath=mktemp "$HOME/library/disklist.XXXXX" "/Library/PreferencePanes/Dell Data Protection.prefPane/Contents/Helpers/client" -c -plist > "$disklistPath" if [ -e "$disklistPath" ] then fvEncrypted="${scriptDirectory}/ParsePList.pl" --value "$disklistPath" if [ $fvEncrypted -ne 0 ] then echo "Managed FileVault disks exist." exit 105 else echo "no FileVault disks exist" fi rm "$disklistPath" else echo "agent pid = $agentPID" > ~/uninstallError.txt exit 998 fi if [ -e "${uninstallScriptPath}" ] then echo "The shield is installed" else echo "${productName} not installed" exit 1 fi if [ $testOnly -ne 0 ] then exit 0 fi comment>echo "removeFuseOption = $removeFuseOption" comment>exit 1 if [ -e "${uninstallScriptPath}" ] then data=eval "${uninstallScriptPath}" "$removeFuseOption" result=$? if [ "$me" != 'root' ] then sudo -k fi echo "data = $data" if [ "$data" != '' ] then lines=echo "$data" | wc -l | awk '{ print $1 }' outLines=$(( $lines - 1 )) if [ $outLines -gt 0 ] then message=echo "$data" | head -n $outLines echo "$message" fi fi exit $result else echo "${productName} not installed" exit 1 fi exit 0

If anyone has had to do this before, I'm most interested in your workflow.

EDIT 1: It seems that the script wants to check existence of a particular kext: /Library/Extensions/DellDataProtection.kext/ and to call a script from within: /Contents/Resources/Scripts/uninstall.sh

The only problem is that I do not see the aforementioned kext in /Library/Extensions/ , however, do see it one of my other computers. So, it could be my test machine is compromised.

Update on my last post as I was working on this again today with an older laptop.

Since posting, had discovered removing DDPE from a computer is as simple as going into the DDPE console, de-activate the computer's policy, wait for computer to receive policy, and then uninstall. I am able to uninstall without waiting on the drive to de-crypt. Since a lot of these computers get wiped and re-installed OS, I don't wait.