Showing posts with label pointsec. Show all posts
Showing posts with label pointsec. Show all posts

Tuesday, November 30, 2010

An easier way for Full Disk Encryption Boot CD

Easily the most popular entry on this blog is how to create a boot CD that can read a hard drive that has been encrypted with Pointsec or FDE. Let me take a minute to refresh you of how that is done.

First, we install PE Builder on a working machine.
Then we grab the Pointsec Filter driver and put it into the plugin folder.
Next we have to stop some Pointsec services on a machine that is running Pointsec and working. From there we can grab a copy of a file call prot_2k.sys. Put that file into one of the plugin folders. Now you're ready to boot your CD. Then, you boot the non-working machine to the hard drive, rather than the CD and press CTRL+F10 at the logon screen to redirect into your boot disk. Congratulations, you've created a CD that will work with just that one version of Pointsec.

Thank goodness the bad old days are behind us. Several versions ago, Check Point released the Dynamic Mount Utility and now the process of making a boot CD couldn't be (much) easier. DMU is included with the installation media in the form of a zip file. The zip file contains two folders. So all you need to do is install Bart PE Builder, and copy those two folders into the plugin directory. Point Bart at your Windows XP disk and create your iso. That's it. Best of all, your new boot CD will work with any version of Pointsec or FDE (at the time of this writing). So you don't have to keep a CD for each version of the software that is floating around your organization.

Booting the CD also got quite a bit easier. Remember I said that you used to boot to the hard drive when you wanted to use a CD? Counter intuitive, right? Now you boot from the CD. When Bart comes up you can open the file management utility, but you'll notice that you can't read the C drive, you just know that it is there. But if you click on Go and look in programs, you'll find a new program for reading the Check Point encrypted drive. Run that program and authenticate with valid credentials. Now close that application and go back to the file management utility. Voila! You can now read the contents of the drive.

Here is a video of me making a boot CD using this method. I also wanted to make a video of me using it in the Bart environment, but alas the Bart disk doesn't have drivers that can see my virtual hard drive on my virtual machine. Anyone know what plugin to add? I'm using Virtualbox here if that helps.

http://screencast.com/t/CxasDOAW

Tuesday, October 27, 2009

Full Disk Encryption: Cannot install due to previous installation.

Well I finally got the licensing issues that I was having with Check Point worked out, and I finally got some of that "time" stuff that I hear other people have, so I got back to work on testing and configuring Check Point Full Disk Encryption R72. Sure enough, I didn't get too far into the process before I had some kind of problem, but I was able to figure out the solution and now I'm sharing it with you.

So first off, how did I create the problem? Well I installed the R72 software on my Windows 7 computer and everything loaded properly. After rebooting, I opened the Management Console created a set and installation profile so that I could get started on remote installation. Then I uninstalled the software from my computer and rebooted. The problem showed up when I tried to install the software a second time, this time using the installation profile. The Wizard came up and said that the installation was halted before the software could be installed. Then I looked around and found a log file named after the FQDN of my machine. The log file was located on the server where I was trying to install the software from. I looked in the log file and it told me that I cannot upgrade my machine from Pointsec version 4/5.

Well I know that I didn't have Pointsec for PC version 4 or 5 on my computer ever, so I thought this might be something buggy. The first thing I tried doing was modifying the precheck.txt file that is in the folder with the installation MSI. I changed line five so that it read IgnoreOldInstallation=Yes. I admit, this is not something I would feel comfortable with in production, but I thought I was just doing this to make my computer work. However, another crack at the installation got me the same error. I changed my precheck.txt back to the way it was and started looking for something else.

I thought there must be something in the registry that was not properly removed after I uninstalled Full Disk Encryption. So I searched the Registry for "Check Point" and "CheckPoint" but found nothing. Finally I looked in the tools folder that came with the FDE software and saw a program called CPClean.exe. In a nutshell, you use this program to forcibly remove all of the Pointsec/FDE components that are on your computer. This is suicidal if your disk is encrypted, but mine was not. I ran the program, rebooted and tried the installation again. It was successful this time.

So keep in mind that if you remove Full Disk Encryption from a machine where you might wish to reinstall later, you may have to use CPClean to completely remove components and have a successful 2nd installation.

Friday, September 4, 2009

Time to start getting ready for R72

Did you know that Microsoft is releasing a new operating system soon? In fact, many of us in the IT industry are already using the new operating system and it is a big improvement over Vista. I think the word will get out soon that Windows 7 is a big improvement over Vista and we will see a lot of older machines that have XP on them get traded in for shiny new Windows 7 machines.

This creates a problem for those of us in charge of putting disk encryption on these machines. The version of Pointsec that my brothers and sisters working for the State of Minnesota is using is not compatible with Windows 7. So we're probably going to be pushed towards using the 7.0 code line. The official name for the product is (as of right now) Check Point Endpoint Security Full Disk Encryption R72 (CPESFDER72). Holy crap even the acronym is too long!

R72 brings some interesting new features to the table that I'm really excited about trying out. I have been delayed in that because there were some problems with support getting renewed. Now I have the software and a semi-working license file and I want to get into it. I'll keep the blog posted on what I'm having to do that is different.

The most exicting new feature for me is that you can transfer log files, recovery files, update profiles over http or https now instead of requiring a connection to a file server. This is really big, especially for computers that leave campus for long periods of time and users that don't jump onto VPN very much. Now we can open up a rather safe firewall port and regain control over our remote machines. Sweet.

On the other hand, you also have to set up a license server. So far it doesn't seem very difficult, but it seems kind of crappy to have a whole server devoted to licensing for a single product. One irritant is that the licensing server doesn't seem to fit the needs of any of the other endpoint security proucts. The one I set up wouldn't accept my license for Media Encryption with Port Protection for example. But I'm just starting to play with this stuff so I might be wrong. I hope I'm wrong. I'll keep you posted.

Wednesday, July 22, 2009

Pointsec for PC: No waiting for recovery files

Here is a trick you might find useful once in a while: forcing the computer to write its recovery file now instead of later.

Every once in a while I get my hands on a computer that has Pointsec installed, but is not encrypted. The most common reason why a machine doesn't encrypt is that the recovery file hasn't been written. This usually happens on computers where the user is almost never on site or the user is not logging in with their regular user account. For whatever reason the computer might not have access to write the file.

Today I got in just such a machine. The user had too many failed logon attempts and the computer rebooted into the Pre-Boot Environment. I got the machine, but I didn't plug it into the network because both of my network ports were in use. So I authenticated in the Pre-Boot environment and clicked the enable WIL check box because I have set the 'Display Enable WIL' option in the system settings of my machine. Windows booted.

Remember that WIL doesn't actually get turned back on until someone logs into Windows. Since I had never logged into this computer before, and since I wasn't connected to our wired network, I logged on with a local administrator password. So now WIL was re-enabled, but I checked and the computer was 0% encrypted. I looked at the local event database and saw that the process of writing the recovery file had failed.

It had also failed just now when I logged in. I wasn't connected to any network. I wanted to get this computer fixed up quickly. I could connect to our wireless network, but then I would still have to wait for Pointsec to take another shot at writing the recovery file. Luckily for me there is a way to force Pointsec to write it now instead of waiting up to 30 minutes for it to happen on its own. Navigate to C:\Program Files\Pointsec\Pointsec PC and double click on CreRec.exe. You will see no output showing that anything happened, but the recovery file will be written. You can go to the network share and confirm that it is written. I have found that the encryption process will begin about five minutes after the recovery file has been written.

One thing that irritates me is that I don't see any new event written in the local event database. But the file was written and the encryption process did begin. So you can use this trick to jumpstart the process a bit. I always like to wait until I see the encryption process hit 1 or 2 percent before I shut down and deliver to the customer regardless of whether I use this trick, or just let it happen naturally.

Wednesday, July 1, 2009

New Attack on AES, is Pointsec broken?

Like many people in the security world, I keep a close eye on Bruce Schneier's blog. Today I was a little scared when I read about a new attack on AES that has theoretically broken the cipher. You can read Schneier's comments on it here: http://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html

The reason that this freaked me out at first is because the default encryption algorithm used by Check Point Full Disk Encryption (formerly known as Pointsec). Much of my personal data is protected by Check Point FDE and I don't want to see it exposed. The good news is that while this may fit the dictionary definition of a break, it is far from the end of the world.

The freakout comes from the difference between what a cryptologist calls a broken algorithm and what broken algorithm means to a typicaly person on the street. When you tell me that AES is broken, I think that it has been made completely worthless (or nearly worthless as is the case with DES). However, cryptologists have a much different definition. For them, a break means that someone found a way to get at the plaintext data in a more efficient way than simply trying all of the possible code combinations that exist. In this case, they found a way to reduce the number of possible code combinations from 2 to 119th power down to 2 to the 110th power.

So basically, AES is still very much alive and kicking. It is very unlikely that anyone is going to be able to exhaustively search through 2 to the 110th power code combinations and still derive value from your data. This is one of the points that I try to stress in my Full Disk Encryption classes, though. No encryption algorithm is perfect and able to remain eternally unbreakable. The power of encryption is to deny access to information for such a long period of time that the information is no longer valuable. For example it is worthless for the enemy to learn about tomorrows battle plan 35 years from now. The flip side of that coin is that if someone could theoretically gather enough computing resources to break your encryption in a short amount of time (say one week for example) the cost would exceed the value of the information. In other words, I would not spend tens of billions of dollars to break your encryption so that I could get your credit card number that has a limit of $5,000.

So if Check Point Full Disk Encryption broken? Well, maybe in a theoretical sense, but absolutely not in a practical sense.

Friday, June 5, 2009

Pointsec for PC: Failed to load osdgina.dll

I ran into a problem today that I hadn't seen yet and I'd like to share it with you.  I was asked to uninstall Pointsec from a laptop that had been encrypted when it wasn't supposed to be.  Obviously this is a rare occurrence, but it was proper so I went ahead and removed Pointsec.  After the reboot, I couldn't log into Windows.  Instead of the normal log in screen, I had an error message.

The logon user interface DLL osdgina.dll failed to load.
Contact your system administrator to replace the DLL
or restore the original dll.

OK, this was a new one for me.  I started by doing some digging on what osdgina.dll is.  As soon as I knew what osdgina.dll is, I knew what the problem was.  We use Microsoft System Center (formerly SMS) to image our workstations, and Pointsec is installed as part of the imaging process.  When a computer is being imaged by SCCM, the normal gina (msgina.dll) is replaced with osdgina.dll.  In this case, OSD stands for Operating System Deployment.  The osdgina.dll makes it so that the computer can boot up and finish the imaging tasks without having users on the system.  You could think of it like single user mode in UNIX.  When Pointsec installs, it first backs up the registry setting for the current GINA, which is normally msgina.dll, but since it is in the OSD environment, the value is osdgina.dll.  Then Pointsec installs and changes the active GINA to pssogina.dll.  

Everything works fine and life goes on.  But when I uninstalled Pointsec from this machine, the uninstaller removed pssogina.dll and replaced the registry entry that pointed to osdgina.dll (which is no longer present on the machine).  When the computer rebooted it looked for osdgina.dll and couldn't find it, thus the error message.

The Fix:
Now that I knew what the problem was, I knew how to fix it.  I took out my trusty BartPE disk and booted the computer using that.  Once I was in the Bart environment, I fired up regedit.exe.  When regedit comes up, you're looking at the registry for the Bart environment, not the registry on the hard drive.  To edit the hard drives registry, you have to import a hive and point it at the hard drives registry file.  The registry entry for the GINA is in HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon.  So in regedit, I selected the HKEY_USER folder and clicked File -> Load Hive.  Then I pointed regedit to the file c:\windows\system32\config\software.  That file is the HKLM\Software tree of the registry.  It asked me to give that a name, and of course I chose BlackFist.

So then I navigated to HKEY_User\BlackFist\Microsoft\Windows NT\CurrentVersion\Winlogon and sure enough, the value of the GinaDLL entry was osdgina.dll.  I changed this back to msgina.dll and rebooted.  

Success.  I hope this helps if there is anyone else out there that is using Microsoft System Center to image their computers and install Pointsec.  I know that I can't be the only one.

Wednesday, June 3, 2009

Pointsec Video Tutorial: Creating an installation profile

In today's video, I'll show you how to create an installation profile based on the local computer's settings.

Wednesday, May 20, 2009

Pointsec Video: Configuration Sets

It's been a while since I put up a Video Tutorial, so here I am to rectify that problem.  We're going to start getting into remote management of our Pointsec clients and before we can do any of that, we have to create a configuration set.  This video will get you started.  I'll be putting up another video in the next couple days to pick up with installation profiles.

Monday, April 20, 2009

Pointsec for PC: Watch out when creating installation profiles based on update profiles.

I got a call from someone the other day asking about a strange Pointsec problem he was having.  He had created an installation profile and put it in the installation folder with his installer MSI file.  But when he would run the installer, he would get a very generic error that just said "Profile Error."  He asked me if I could take a look at his installation profile and see if I could find anything out of the ordinary.


One thing that struck me as being out of the ordinary is that he had based the installation profile off an update profile.  Usually, I see installation profiles based off the local settings or another install profile.  I see update profile based off install profiles, but never before have I seen an install profile based off of an update profile.  


So I opened up his installation profile in my administration console and poked around for a bit.  I was making sure that administrator accounts were in there and that there was a valid path for updates and recovery files, etc.  Since it was based on an update profile, it is possible that some information was left out.  Then I clicked OK to exit the profile editor and see if any errors come up.  I was given the error message "Volume protection not defined."  This is different from the error message I usually get on an installation profile which reads "Volume protection not based on local."


OK, so how does this volume protection thing work?  When I typically build an installation profile I base it on my local machines settings.  And usually, my local machine has one hard drive and one partition.  So if the volume protection in my installation profile was based on local then every computer that installed using this profile would get protection on only one partition.  What if we run this on a computer with two partitions?  The second partition would get no protection.  So the default when you create an installation profile based on local settings is to set the volume protection to encrypt and protect all volumes on the machine, not just the ones that you have on your reference computer.  When you save your installation profile you are told that the volume protection was not based on the local machine, and I tell most people to ignore that message because it's actually a good thing.  But that isn't the message that we're getting here.  This machine is telling us that no volume protection has been set at all.


To understand why, you have to know about the limitations of update profiles.  An update profile can change ALMOST any setting on a Pointsec installation except for the encryption algorithm used to protect the volumes, and which volumes have been encrypted.  These settings cannot be changed after the installation and so they are not present in an update profile.  


Since those settings are not present in an update profile, any installation profile based on an update profile is going to be missing these settings as well.  I told him to go back to the installation profile, click on Systems Settings, Install, and double-click Select Volume Protection.  Then he can select the encryption algorithm he wants to use and specify which volumes he wants protected.  A day later I got an email telling me that making that change fixed the installation profile and he was able to use it to install Pointsec on client machines.

Monday, April 13, 2009

Pointsec for PC: Can't enable WIL, User Account not working.

The help desk brought me a strange Pointsec problem today. I'm not even sure how to describe it properly. They had a customer computer that had been locked out and was requiring authentication at the Pre-Boot Environment, but the password that I had provided for the help desk to use was not working. I also found that my personal password that I use for Pointsec was not working either. This was very concerning, but luckily I was able to log in with a third user account that I had built into the Installation profile used to install Pointsec on this machine.



I checked the Enable WIL checkbox in the preboot environment and booted into Windows like normal. Then I opened up the Management Console and I was able to log in with the accounts that were being denied in the Pre-Boot Environment. Weird! I also double checked that Windows Integrated Logon was turned back on and rebooted. I expected the machine would boot directly into Windows, but it stopped at the Pre-Boot Environment and challenged me for credentials again.



You may be aware that there are actually two places where you have to enable Windows Integrated Logon. If you already know this then skip this paragraph. There are two places where WIL has to be enabled. One place is in the Management Console in Windows which I just looked at. The other place is in the Pre-Boot Customization menu. If WIL isn't turned on in BOTH places, then you have to authenticate in the Pre-Boot Environment. To access the Pre-Boot Customization menu, hold down both shift keys when the computer is booting and says "Pointsec for PC" in the upper left of the screen.



But on this machine when I held down both shift keys during the boot process, nothing happened. I am not able to access the Pre-Boot Customization Menu! WTF! I feared that I was going to have to call Checkpoint Support before this poor soul could have his laptop back.

But instead, I decided to create a user account for him in Pointsec and set up single sign on for him. That way he could work on the time sensitive stuff he had to do and bring the computer back to us when he could stand to be without it for a while. I created the account, saved the settings, and rebooted. Surprise! Windows Integrated Logon worked this time.

My guess is that by creating another user account, Pointsec updated the authentication database and other settings for the Pre-Boot Environment which turned Windows Integrated Logon back on. So now he is able to work, but I am still not able to get into the Pre-Boot Customization Menu. I'll have him come back later and we'll probably just reimage this machine. I wanted to share this with all of you just in case you run into this problem so you'll have a dirty fix if you're in a jam. I looked at the Checkpoint Knowledge base and wasn't able to find any thing that looks similar to this.

Sunday, March 29, 2009

Pointsec Video: Single Sign on in the Pre Boot Environment

I just put the finishing touches on a new Pointsec video. This time we go through the process of setting up Single Sign on so that your users don't have to log on twice, but you can still enjoy the security of Pre Boot authentication. Enjoy.

Also, I have recorded this video in a higher resolution, but I'm not going to force it to display in that higher resolution. If you've got a wide bandwidth pipe and you want to be able to see more clearly, click on the HD button at the bottom right of the video.

Monday, March 23, 2009

FDE for Mac is giving me the blues....again

Back on March 4th I wrote up a post about the trouble I had installing Pointsec for Mac 3.1. After I got past all of that, I was able to function normally and I haven't had any trouble until today. My precious Mac wont boot. I cant even get to the Pre Boot Environment to log in. When I power up the machine, I get a black screen with this message:
Booting devicepath Acpi (PNP0A03,0)/Pci(1Fl2)/?/HD(Part3,Sig3EE4ECEF-7BED-CDC6-1B2D-E46AEB45FE67)/Pointsec\\ppbe_main_x86_64.efiChanged current root to: 3EE4ECEF-7BED-CDC6-1B2D-E46AEB45FE67
open file esp:ppc.log
LOG: 0 1 2009-03-23 13:10:37 EFI firmware spec: 1.10

LOG: 0 1 2009-03-23 13:10:37 EFI firmware vendor: Apple

LOG: 0 1 2009-03-23 13:10:37 EFI firmware revision 0x1000a

LOG: 0 1 2009-03-23 13:10:37 failed to open file uninstall.dat - Not Found
LOG: 0 1 2009-03-23 13:10:37 failed to open file recovery.dat - Not Found
LOG: 0 1 2009-03-23 13:10:37 found raw file ppc.db (262144, 2000000)

LOG: 0 1 2009-03-23 13:10:37 found raw file ppc.db (262144, 2000000)

LOG: 0 1 2009-03-23 13:10:37 Couldn't initialize container subsystem from raw:ppc.db
FATAL ERROR: Look above for possible cause!

* Hit any key to continue *


I'm working with Checkpoint support to see if I can get my machine working again without having to do a full reinstall. Now pay attention, noobs! Unlike most of you that write to me asking how to get back into your encrypted machines, my recovery file was saved onto a network share and I have recent backups of all my data. So I will not be out in the cold if I have to do a complete reinstall. However, I'm not looking forward to going through all the work of reinstalling all of my apps and tuning them the way I had them, etc. I'll keep you posted on how things go.

Update 1: After talking to support, I looks like I'm going to need to create my recovery media and decrypt the drive. The problem is that I need to convince someone else to let me use their Mac to install Pointsec so that I can create the recovery drive. Given the rather public nature of my problems with FDE for Mac, that may be a tough sell. It would be nice if there was a standalone utility that was distributed with FDE that could be used to create a recovery file. That would be particuarly helpful if I was a small business that only owned one computer...namely the broken Mac.

Update 2: I have found a guinea pig and installed FDE on his Mac. I have not experienced the problems that I had on my own machine. One possibility that comes to mind is that since this machine has never had an older version of FDE installed, it wasn't as cranky. The recovery USB device has been created, but I can't seem to get the Mac to boot to it.

Update 3: I haven't been able to get the USB drive to boot. I found out that my first problem was that I didn't format it properly. The drive needs to be formatted with Mac OS Extended (Case-Sensitive, Journaled). Then I was able to boot to it by holding down the option key while booting. However, I ran into a new Pointsec error so I am no closer to decrypting my drive.

LOG: 0 1 2009-03-23 18:50:56 open file recovery.dat
LOG: 0 1 2009-03-23 18:50:56 Booting from recovery media
LOG: 0 1 2009-03-23 18:50:56 open file ppc.db
LOG: 0 1 2009-03-23 18:50:56 open file ppc.db
LOG: 0 1 2009-03-23 18:50:56 New container file : ppc.db
LOG: 0 1 2009-03-23 18:50:56 Doing user-acquisition, skipping directly to boot.
LOG: 0 1 2009-03-23 18:50:56 Got roodguid: 0C79D3EA-32AE-4AC5-BD7B-2F2BED73BCD9
LOG: 0 1 2009-03-23 18:50:56 raw file not found 0C79D3EA-32AE-4AC5-BD7B-2F2BED73BCD9
LOG: 0 1 2009-03-23 18:50:56 PPBE uuid = 3EE4ECEF-7BED-CDC6-1B2D-E46AEB45FE67
LOG: 0 1 2009-03-23 18:50:56 Found root-device in DB, installing block-encryption on BlockIO
LOG: 0 1 2009-03-23 18:50:56 Changed current root to: 670E55E1-E341-43A7-A517-07841C49ADF3
LOG: 0 1 2009-03-23 18:50:56 Booting devicepath Acpi(PNP0A03,0)/Pci(1Fl2)/?/HD(Part2,Sig0C79D3EA-32AE-4AC5-BD7B-2F2BED73BCD9)/\System\Library\CoreServices\boot.efi
Error: Not Found while loading
LOG: 0 1 2009-03-23 18:50:56 Couldn't boot into user-aquisiton mode!
FATAL ERROR: Look above for possible Cause!

* Hit any key to continue *

Checkpoint support said my hard drive must be going bad, so I'm going to have to completely reinstall my OS and restore from backups. Poop.

Wednesday, March 11, 2009

Pointsec for PC: Creating an update profile based on an installation profile

One thing that really annoys my users is having their computers lock after a period of inactivity. They really don't like having to put a password in and would prefer if they could leave themselves logged in forever (and probably forget their password in the process). But when we install Pointsec on a computer it sets the screensaver to lock, and we don't turn that feature off. Usually I tell users how important that security feature is until they get tired of talking to me and go away, but the other day someone presented a valid reason why his inactivity time needs to be longer. I decided to make that change to his computer, but I'm not going to do it to everyone. His valid reason isn't something that applies across the board. Here is how I'm doing it.

To start, I opened up my Management Console and went to Profiles. Right-click on profiles and select New Profile -> Update. The New Profile Wizard appears. Click Next to begin. First you will be asked to give the profile a name. I'm going to call mine 60-min-screensaver. You also have to provide a profile protection password.

Remember, in most cases your profiles are kept on a simple file server and you probably aren't limiting read access to these profiles to a single account. It is possible, but not commonly done. In order to prevent people from downloading your profile and examining them for weaknesses or creating rogue update profiles, you have to specify a profile protection password. You cannot continue until you provide that password.

Now you will be asked if you want to base this profile on an existing profile or the machines local settings. I'm going to check this box and continue. On the next page I will have the option to search for the profile that I want to use as my template, or I can use the local machines settings. In this case, I'm going to use my installation profile rather than my local settings. To be honest, I don't remember if I've made changes to my own machine while playing around with stuff. I know that the installation profile is pristine. So I'm going to select that, and I'm going to make sure that I have not checked "Base on local settings." I'm also going to uncheck "Base on Groups" which will automaticall uncheck "User Accounts."

Was that last step really necessary? Probably not. I have all the same users and groups on the machines that are out there, so including the group and user configuration in this update profile shouldn't hurt anything. The reason I unchecked it has to do with the difference between "shouldn't cause a problem" and "wont cause a problem." If I don't include any group or user information in this update profile, then I know that I wont make any changes to the user and group settings on my computer. Generally speaking, you want to limit your update profile as much as possible to only cover things that you're going to change. You don't have a ton of granularity in limiting the scope of your update profile, but you should exercise the power that you have in that area. Click Next to continue, and Finish to open up the profile editor.

This is a pretty simple change to make. I'm just going to click on the Windows Integrated Logon folder on the left and find the setting called "Set WIL User Screen Saver Timeout." Double-click and change it to 60. Then click OK to quit the profile editor. I'm going to get two warnings. One is a warning that I have Windows Integrated Logon enabled. That's fine, I don't want to turn WIL off so I can ignore that warning. The other message is that "No user has a group authority level high enough to change system settings." We're getting this message because we stripped all the user and group informaton out of this update profile. You couldn't have an installation profile that looked like that, but this update is only going to change that one setting and leave the current users and groups that are on the machine in place. So even though this profile doesn't have any admin users, the end users computer will because they already have them. We can safely ignore this message as well.

Now in my Management Console I see a profile called 60-min-screensaver. If I wanted to push this out to everyone on the network, then I could right-click and select publish. But that's not what I want to do. Instead I'm going to go over to the file server itself and find my profile storage folder. In there I'll find the actual profile file. I'm going to email it to the user the file with instructions on how to apply it to his own machine. Another course of action would be to put the file in the update folder for his particular machine and wait. This guy isn't on our network right now so I'm just going to use the email route.

How do you apply the update profile to a single users machine without putting it in the update folder? The answer is shockingly simple...you put it in their work folder. When a Pointsec machine checks for updates, it really just goes out to the file server and copies the update profiles down to the local hard drive in a folder called work. The path is C:\Program Files\Pointsec\Pointsec for PC\Work. Once the profile is in that folder, it is checked to make sure the Update Validation Password is correct and then the settings are applied. If you manually copy the update file into that folder, you will be doing the same thing. Somewhere between 5 and 15 seconds after the file is copied, it will disappear, and the settings will be applied.

Wednesday, March 4, 2009

New Version of Checkpoint FDE for Macs

Last night I got a chance to try out the latest version of Checkpoint Full Disk Encryption for Mac, version 3.1.0 build 171. The software is just over a month old and looking at the release notes has a few interesting features like Single Sign On and User Account Acquisition. With SSO, a user only has to log in once to get into their machine, and they don't have to use the workaround that I was using (OS X account auto-login). User Account Acquisition makes it easy to add user accounts to the Pre-Boot Environment without having to manually create an account on each workstation. The user logs in once as normal, and their credentials are sucked into the Pre-Boot Environment. From then on the user can use those credentials in the Pre-Boot Environment. Unfortunately, the whole thing didn't go as smoothly as I would have liked. Here is the harrowing tale of my installation nightmare from last night.

I downloaded the software from Checkpoint User center. I opened up the DMG and ran the .pkg file inside. I went through the usual stuff about license agreements and an overview of the installation process.

After agreeing to the license agreement, I was asked to select the drive that I want to install this on. I only have one drive on my macbook, so it was an easy choice. Once I selected the drive, I clicked continue and the installation began. Software was installed and then I was asked to provide my license file.

Next comes the familiar process of creating two user accounts. These screens will seem familiar if you've installed Pointsec on a Windows machine. If not, then just know that you need to create two administrator accounts. This time around I didn't create an account corresponding to my OS X username because I want to try out the user acquisition feature.


One thing that is unique about installing FDE on a Mac is that it asks you if you want to encrypt your entire disk or if you want to select volumes for encryption. This differs from the Windows side where Pointsec automatically selects all of your partitions for encryption and then asks you if you want to change that setup. I selected Encrypt entire hard disk, and chose AES for my encryption algorithm. At this time it looks like AES is the only encryption option. However they must be planning to change that at some point otherwise they wouldn't have a screen asking me which algorithm I want to use.

Finally I was asked to provide a path for the recovery file. I gave it a path and clicked finish. A very quick installation later, I was able to reboot the computer. That is when things got a little weird for me.

After the reboot I authenticated in the Pre-Boot Environment with one of the admin accounts I created. The computer appeared to boot as normal. Something had changed though because I was brought to the login screen. My computer had been set up to auto-login with my account. It was my way of getting a single sign on environment with the previous version of FDE. Oh well, FDE must have set it back for security reasons. So I logged in and nothing happened. I sat and looked at a blue screen for about 10 minutes. Finally I had to power down the machine to reboot it. This went on for several tries. I was really worried that I was going to have to reload my machine from scratch. In a last ditch effort, I booted into single user mode and followed the directions to mount the root file system. I was looking for an application extension bundle, but I wasn't able to find anything. I rebooted the computer. After logging in at the Pre-Boot Environment and logging in at the OS X log in screen, I got my desktop. OK, cool. I'm not sure why that happened because the only thing I did in single user mode was run fsck and then mount the root file system. Either way, I'm back looking at my desktop. OK fine, I'm going into the Management Console to poke around.

It doesn't look much different from the previous version, except that there is a new folder for User Account Acquisition. The weird thing I'm noticing is that I can't seem to change any of the settings. I can't make adjustments to the password policy and I can't turn on User Account Acquisition. So I called up support to ask them about it. While I was on hold, I kept poking around and it looks like you need to create another group before you can turn on User Account Acquisition. That makes sense to me because you don't want to automatically create users in the System group. So I created a group called users and made changes to the password settings there. Once that group was created, I went back and I was able to turn on User Account Acquisition. I also made sure to enable Single Sign on for the Users group. Alas, when I clicked OK to save the changes I was told that I need to set an acquisition group. Hmmm. I tried renaming my Users group to Acquisition, but that didn't do it for me. Then I noticed that User Account Acquisition has a subfolder called Select Group. I went in there and found options for selecting the group where my Users will be created. However, I wasn't able to select my users group. I suspected that maybe because I hadn't saved my changes yet, that group wasn't available to me. So I turned off User Account Acquisition and clicked OK to save my changes. I exited the Management console and went back in. Now I was able to select my Users group for Acquisition. Around this time the support person came back on the line and I told her what happened. She said that I should have been able to change settings right away and that adding a user group shouldn't have made a difference.

Once I had set up User Account Acquisition, I rebooted the computer. As expected, I was not asked to authenticate in the Pre-Boot Environment and was instead taken to the OS X login screen. I selected my account and logged in. Then I rebooted again. This time I was taken the Pre-Boot Authentication screen and I was able to log in with my OS X credentials. Sweet.

Unfortunately I was back in the blue screen of forever hell. I was able to get into my desktop by booting into safe mode though. After booting into safe mode I rebooted again into regular mode. Is this sounding ridiculous yet? But now, finally, I am able to achieve single sign on and have a reasonable boot time.

I'll be honest with you, I need to do some more testing. I'd like to know if the problems I witnessed were specific to my machine or if this would happen on any computer. I can't imagine that Checkpoint saw problems like this during Quality Assurance testing and still released the product. On the other hand, I haven't done anything unusual with my machine (no Boot Camp or FileVault stuff) and it is only about 9 months old. So if I had these problems I would worry that another use would have the same problems. And I am not about to put my users through this level of hell to get their disk encrypted.

Update: After the encryption process was complete, I rebooted my machine and found myself dealing with the blue screen of forever again. I was able to boot into safe mode again though. A reboot after safe mode worked properly. Then I did a full shutdown. The machine worked properly when it was powered back on too. So it seems that when the encrypting process changes state I have to go through the safe boot hoops, but once it stabalizes I don't need to worry about it.

Tuesday, March 3, 2009

Pointsec for PC: Copying your management settings

I had an embarassing moment today while I was in a conference call. An easy question came in from someone and I wasn't able to answer it right off the top of my head. I was also frustrated that my computer locked up on me and thwarted my attempts to find the solution for her. Anyway, here is the question and the answer.

Let's say you have a workstation that has Pointsec for PC installed on it. The previous Pointsec administrator used that machine to create his sets and profiles. Now whenever you want to manage your Pointsec installation you have to go to that machine to get things done. Is there a way to transfer the settings from that machine to your own?

The answer is yes, and it is very easy to do. What you need to do is located a file called PCMC.cfg and copy it to your workstation. Remember, the configuration set itself is not stored on your machine, it is on the server that you were using. Also remember that a set isn't really anything but a list of locations where you're keeping stuff. Same goes for the profiles. They are all up on the server. The Pointsec Management Console provides a convenient view of them, but they are not stored on the machine that the previous administrator was using. So here is what you need to do:

Go to the machine that the previous administrator was using and make sure that you don't have the Pointsec management console open. Now find a file called PCMC.CFG. On Windows XP systems the file will be located in c:\Documents and Settings\All Users\Application Data\Pointsec\Pointsec for PC\. On Vista machines the file is located in C:\ProgramData\Pointsec\Pointsec for PC. Some of these folders will be hidden from you.

Now go back to your workstation. Again make sure that you have the Pointsec Management Console closed. Copy that file to the corresponding location on your machine based on the Operating System that you use. Now open the Management Console and voila! You should have all of the set and profile information available to you now.

There are a couple things that can trip you up in this process. The most common one I see is people doing this without shutting down the management console. When you close the management console, Pointsec saves it's current state to the PCMC.CFG file. So if you copy that file over while the management console is running, and if there are no sets configured in the management console, then when you close out it will save the nothing configuration and write over the file you just copied. Then you call me up and ask "Why isn't this working?" The other thing you might have a problem with is permissions. If your user account cannot view the folders on the server then you wont see your profiles in the management console. This isn't something that you need to work out with Pointsec, you need to work it out with whomever manages that file server. Pointsec is accessing the server with your user credentials.

Hope that helps someone out.

Friday, February 27, 2009

Pointsec Video: Windows Integrated Login

Here is the latest Pointsec instructional video from Black Fist. Today we're going to cover Windows Integrated Logon; how to set it up and what it looks like for your users. It's a short video because it's really easy to do. Enjoy.



Errata: After I finished making this video I realised that I left something out. It doesn't change the process of enabling Windows Integrated Logon though, so I decided not to record the whole video over again. Anyway, I talked about setting Max Failed Windows Logon in the video. I said that when you set that number and a user has that many failed logon attempts then the computer will reboot and force authentication in the Pre-Boot Environment. What I failed to mention is that this functionality is not workin in Vista right now. So if you're testing this out on Vista you might beat your head agains a wall for a while.

Wednesday, February 25, 2009

Pointsec certificate expiring - may cause upgrade problems

This morning Checkpoint released a bulletin about a problem affecting Pointsec for PC version 6.2.0 (with HFA1 or HFA2) and 6.3.0. The certificate that the software uses to validate recovery files and log files has expired. As a result, recovery files and log files are not being updated anymore, and new installations of these software versions will fail.

It is also possible that you're going to see some error messages such as "The installed license number is no longer valid" or "-1"

The good news is that your data is still secure. I talked to Checkpoint support and they assured me that you are still able to create recovery media based on the recovery files that have already been written. You can also use the crerec.exe (located in c:\program files\pointsec\pointsec for pc) to force creation of a new recovery file. Checkpoint has hotfixes available if for some reason you're not able to upgrade, but this certificate expiration problem will not prevent you from upgrading if you choose to go that route.
Notice from Checkpoint

Thursday, February 12, 2009

First Pointsec Video Tutorial

So I took some time to put together a video tutorial on a Pointsec topic. In this case, how to do a simple, manual installation of Pointsec for PC. Please let me know what you think of the video. If it is well received, then I will probably make more in the future on more difficult topics.


Sunday, February 8, 2009

Upcoming Pointsec class in Minnesota

Hey, if you're a State of Minnesota employee then you might be able to register for the next Pointsec class that I'm going to be teaching. The class is scheduled for February 20th in St. Paul. Check out the link: http://www.strategicit.org/encryptiontraining.shtml#top

On the Pointsec side of things, I'm going to be focusing on data recovery. So there is going to be a lab on creating a BartPE disk to boot an encrypted device, and there is going to be a lab on setting up a hard drive as a slave so you can get at your information from a working Pointsec machine. I'm also putting in a lab on Network Location Awareness, temporary user accounts, and customizing the Pre-Boot Environment for your organization.

We're also going to be talking about Pointsec protector, which is also available to State of Minnesota Agencies. Protector has a lot of neat features and is a big step up from Pointsec Media Encryption in terms of ease of use. I'm still not certain if it is easier to deploy however.

Anyway, there are still some seats left so if you are a State of Minnesota employee and you still have some budget available for travel, sign up and come see Black Fist. I'll be available for autographs throughout the day.