Installing pfSense on a Compact Flash card

I purchased a Netgate ALIX.2d3 to use for a pfSense Firewall.  It runs pfSense off of a Compact Flash (CF) card.  The trick is getting pfSense installed onto the CF card.  Once I got the process figured out, it was really quite simple.  I used a Windows 7 computer to accomplish this.

To Load it up…

1. Download pfSense from one of the mirrors here. You’ll need the nanobsd version (depending upon the size of your CF card, you can choose to download the most appropriate nanobsd img.gz file.  Store it in an folder easily accessed from a command line like c:\pfsense.  I also renamed my download to something simple like pfsense-2.0.img.gz.
2. Download physdiskwrite, unzip it, and place the physdiskwrite.exe in your c:\pfsense directory.
3. Gather a CF card reader and plug it into your computer.
4. Format your CF card.  This is necessary for physdiskwrite.exe to work correctly.
   • Open up a command prompt as Administrator and type “diskpart”, then hit “Enter”
   • Type “list disk” and hit enter
   • Type “select disk x” (where x = the disk number of your CF card from the last step)
   • Type “clean” and hit enter
   • Type “exit” when diskpart has finished cleaning the disk. Type “exit” to quit diskpart.
5. In your command prompt navigate to your c:\pfsense directory and type “physdiskwrite -u pfsense-2.0.img.gz” and hit enter (be sure to use the name of your pfSense image at the end of that statement).
6. You’ll see a listing of drives.  Make note of which drive number is you CF card and then enter that number after the question “Which disk do you want to write?” and hit enter.  (For example: PhysicalDrive1 = disk 1 so enter 1 and hit enter)
7. If your CF card is larger than 2 GB you will be prompted with a “Proceed?” question.  Type “y” and hit enter.  (By the way the “-u” switch in the command line in step 4 allows you to write to a CF card larger than 2 GB.)
8. You will now see the bytes begin to copy over to the CF card.  Once completed, eject the card from the reader and plug it into your Alix board.  Connect a null serial cable to the board.  Plug in the power.  Pull up a Serial Client like Hyperterminal or Putty and connect to the  Alix.  You may proceed from there to configure pfSense as your firewall.

By no means am I an expert at this.  It’s my first attempt!  Please feel free to share any pointers you may have come across if you have done or are doing something similar!

Syncing Active Directory Users with Postini Message Security

There are two options to sync your Active Directory with Postini, you can host the sync on your server or on Postini’s servers.  You can find information here.

I chose to use the local server tool so that Postini isn’t poking through my firewall and accessing my LDAP.  I’m pushing the information to them.

Go ahead and download the tool here and then install it.  If you’ve ever installed an app, I’m sure that you can do this without detailed instructions.

This whole process is very similar to installing the Google Apps Directory Sync tool.  As a matter of fact – the interface is pretty much the same.  You can see how I set that up here.

Here is how to setup the Google Apps Directory Sync for Email Security.  NOTE: this will only sync users – NOT PASSWORDS.

1. After installing the Google Apps Directory Sync for Email Security tool, go ahead and open the application.  The first screen you’ll need to configure is the Authentication screen which is highlighted in orange along the left side of the picture below.  At 1. you’ll enter the Admin Email and Password of your Postini account.  This is the account that has the FULL Admin rights for your whole Postini Account.
2. Select Authentication at #2.  I chose Password since I didn’t go through setting up the Xauth in my Postini account.
3. I checked the box at #3.  This will send any new users a welcome message from Postini.
4. If you are using an SSL Proxy or an HTTP Proxy you’ll enter that information here.  I don’t use either on my network so I left them blank.
   

   Steps 1-4

5. Here is where you will select which Organization you will sync with.  This is the organization that is setup within your Postini account.  You can sync with more than one Postini Organization if you choose to do so but they must be in the same Postini account.  I only have one Postini organization, therefore I chose the first option.
   

   Step 5

6. The Directory Sync tool will remove any users from Postini that are not on in your Active Directory.  It is here that you would enter rules to exclude those users from being deleted.  The 2 rules you see below are in the Sync Tool by default.  I left those rules in place and did not enter any others.  You may choose to do differently.
   

   Step 6

7. Here you will enter the information to allow the Sync Tool to pull the data from your Active Directory server.  Connection Type for Microsoft’s Active Directory will be “Standard LDAP”.  Host name can be either the fully qualified domain name or IP address of your Active Directory Domain Controller.  Port # should be 389.  Finally, the Base DN is where you store your user information in Active Directory.  I have an OU called GFC_Staff, hence the data input in this field.  If you have your users spread over multiple OU’s, you’ll need to create a container OU and then relocate your User OU’s into the container OU.  The Container OU will then become the OU that is entered in the Base DN field.
8. Authentication type for Microsoft Active Directory is Simple.  The Authorized User and Password will be a username that has Admin Rights to your Active Directory.  Notice the format of the Authorized User field:  domain\username.  That format is important – you will not authenticate unless you enter the information in this format.
9. By clicking on the “Test Connection” button you will then test your connection to your Active Directory Domain Controller.  If you have configured everything correctly up to this point, your test should succeed.
   

   Steps 7-9

10. This is where you tell the Sync Tool what user attributes to push up to Postini.  Server Type will be MS Active Directory.  Email Address Attribute will be mail (the attributes are Case Sensitive).  If you have an Exchange Server and have email Alias’ that you would like to upload to Postini, you’ll add the proxyAddress attribute in the Alias Address Attributes field.  Since we don’t have an Exchange Server, I cannot access this field in my Active Directory to add email alias’.  I’ll have to add those manually to Postini.
11. This is where you’ll tell Postini to upload any mailing lists you may have such as an All-Staff list.  The attribute you’ll enter here is called mail. (again – case sensitive)
    

    Steps 10 - 11

12. This is where we are going to tell the Sync Tool which users to push up to Postini.  To make a rule for that, you’ll click on the “Add Rule” button.
13. Here you are telling the Sync Tool in which Organization you would like to place your users.  Be sure to type this EXACTLY as your Organization is named within Postini.
14. Now you need to give the Sync Tool direction as to which users to pull over.  I used the rule (objectclass=user) to bring push ALL USERS within the Base DN specified in step 7 up to Postini.
    

    Steps 12 - 14

15. If you want to exclude any users from being pushed to Postini, you may do so here by adding rules to exclude them.  I am not excluding any users, thus I have no rules here.
    

    Step 15

16. Mailing Lists – I am not using any right now, therefore I have left his area blank and not added any rules.
    

    Step 16

17. Enter an address you would like Sync Tool notifications to come from.
18. Enter any email addresses you would like to have notifications sent to.
19. Complete the necessary credentials to authenticate to your SMTP Email Relay Host.  You may also test this connection by clicking on the “Test Notification” button at the bottom of the page.
    

    Steps 17 - 19

20. THIS IS A MUST!!! It exists to protect you from deleting your whole organization from Postini at one time.  The default is set to delete no more than 5% of your users at one time.  If more than 5% of your users are to be deleted during a sync – the sync will fail.  THIS IS A GOOD THING!  Choose your settings here according to the amount of risk you are willing to assume.
    

    Step 20

21. Set where you would like your log files to be stored, the Level of the log, and the Size of the log.  Again this is your choice and your preference.  Set it as you’d like.
    

    Step 21

22. The Sync Tool allows you to simulate a sync or test it before actually syncing.  This is a good thing.  Click on “Simulate Sync” to see of your sync would be successful.  You’ll get a full readout of what happens during your sync.
23. Now – click on File, Save.  Make note of where you save the xml file.  You’ll need to know the location of this file in ordre to make changes in the future, and also to run the REAL sync.
24. To run the real sync, I wrote a batch file that is attached to a Schedule Task on my Domain Controller.  The syntax of the Batch file is as follows:
    cd “c:\Program Files (x86)\Postini Directory Sync”
    Start sync-cmd.exe -a -c c:\PostiniDirSync.xml

Now, anytime I add a user to the Active Directory I will run the Scheduled Task to push the new user up to Postini.  I’ve also scheduled that task to run automatically, once a week.

I hope this helps.  If you see any errors or would like to make suggestions for improvement, let me know!

Migrating Calendars and Contacts between Google Apps Instances

I’m in the middle of a Google Apps migration project, moving users from one instance of Google Apps to a completely different instance of Google Apps.  I haven’t found a great free method to migrate Calendars and Contacts so I documented the process to move them manually.  Here you go…

Migrating Calendars

Since there isn’t a tool to migrate calendars from one Google Apps instance to another, this is a manual process done user by user.  The good thing is that it’s pretty straight forward and your users should be able to do this themselves.  Here we go:

1. View your Calendars within the OLD instance of Google Apps.
2. Click on Settings in the upper right corner of your screen and select Calendar Settings.
3. Click on Calendars and then click on Export Calendars. This will download a .zip file to your  computer.  (Pay attention to the location that this file downloads to.  Mine downloaded to my “Downloads” folder.  Yours MAY download to a different location.
4. Find the file you just downloaded and open it.  This will reveal your exported calendars.  Pay attention to the loaction of these files.
5. Open your Calendars in the NEW instance of Google Apps.
6. Repeat step 2 to open your Calendar Settings.
7. You will now need to re-create your calendars so that you can import to them.  Click on Create New Calendar. Repeat for each calendar that you exported.
8. After creating your new calendars, it’s time to import the old calendars to the new ones.  Click on Import Calendars.  Click on Browse.  Navigate to the calendar files from Step 4 above.  Select one.  Select the Calendar you would like to import to. Click Enter.
9. Repeat this process for each calendar you would like to import.
10. Done!

Migrating Contacts

1. The user should login to their OLD Google Apps Email and click on contacts in the left-hand column. 
2. Click Export in the upper right corner of the Contacts screen.
3. Compare your settings to the following Screen Shot.  I recommend only Exporting “My Contacts”.  Also be sure to select Google CSV format.  Click Export.  (“All Contacts” is EVERYONE you have ever emailed, whether you have entered them into your contacts or not.  The email addresses imported on this setting may not have a name associated with it.)
4. Clicking Export will download a file to your computer called google.csv.  Make note of its location.
5. Open the email of the NEW Google Apps instance and click Contacts as you did in step 1 above.
6. Click on Import in the upper right corner of your screen (same area as Export from Step 2).
7. Navigate to and select your google.csv file that you exported in Step 4.  After selecting the file, click Import.
8. Done!

Google Apps and Grace Family Church

As the I.T. Director for Grace Family Church, I am charged with determining the best path for us with regards to which technology best suits the needs of our vision, users, congregation, and budget.  Keeping that in mind, I began to look at our current email solution: Microsoft Exchange 2003.

Knowing that Microsoft recently released the 2010 version, immediately I saw we were behind in the technology.  In researching the new version, I saw that the only option to run Exchange 2010 was on a 64-bit capable server. Hmmm… I didn’t have one of those, nor did I have a VT capable server on which I could run Exchange 2010 in a virtual server.  That meant I would need to purchase a new server.  I also would need to purchase all new licensing for Exchange 2010, including new Client Access Licenses.  I know for a non-profit that the cost of the licensing is relatively nothing compared to the public sector, but it is a cost none the less.

Doing a little more research I found that Google gives the Education Edition of their Google Apps product FREE to non profits.  Ok – that got my attention.  What I also liked about Google Apps is that it runs in the “Cloud”.  In other words, it is hosted on Google’s servers, not mine, and therefore reduces some of my day to day overhead.  Since we already run our Church Management System, Fellowship One, in the Cloud, this seemed like a logical step to at least test Google Apps for Grace Family Church.

I am also a part of an close knit organization called The Church IT Roundtable (CITRT).  This organization is made up of Church IT Professionals and volunteers who make up the IT Staff for their respective churches.  On their Wiki Site is a page dedicated strictly to the discussion of Google Apps and it’s pros and cons.  Check it out! By the way,  if you do Church IT in any capacity, YOU NEED to be a part of this group – It’s a FREE and invaluable resource of friendship, advice, and professionalism!  Check out the main page here.

Moving on, the decision was made to move forward with Google Apps.  The setup process is extremely simple and Google even gives you a step by step tutorial within the management interface on how to set it up and get it working properly.  I have been able to do ALL of the setup myself.  Google provides excellent tools to assist you with the migration from Exchange to Google Apps.  I am  also using the Google Apps Migration Tool which makes moving users a piece of cake.  The Google Apps Directory Sync Tool also makes it simple to keep your users sync’d between your Microsoft Active Directory and Google Apps.  This blog post of mine explains how I use it and also how I was able to get user passwords to sync too.

What made this move good for us is that we were NOT using all of the features of Microsoft Exchange.  Let me be clear also – Google Apps is not a Microsoft Exchange equivalent.  While I can see this happening in the future (Google is continually improving Google Apps), it’s just not a full replacement yet.  For us the move made sense.  For your church it may not.

What do I like so far?  These are just few things I like.

1. Google Talk – This is Google’s Instant Messaging (IM) platform which allows for text, video, and voice chats.  All of our users are now on the same IM platform.
2. Google Sites – This allows you to create simple websites that can be used for Intranet purposes or even Internet purposes.  I was able to quickly create a Google Apps Tutorial website for my users where they can quickly learn the ins and outs of using Google Apps.
3. The Web Interface – While it may not be the prettiest screen to look at, the interface is extremely functional.  I LOVE the conversation view of email messages.  I am using the keyboard shortcuts to compose new messages, reply, and add labels to messages.
4. Labels – This is Google Apps version of Folders in Microsoft Exchange email.  The best part here is that you can easily apply multiple labels to an email message to make it easier to find later.
5. Calendar – I’m finding the ability to overlay multiple calendars from different places over the top of my calendar extremely helpful.  Calendars are also easily shared between users in order to make overlaying calendars possible.

Also – Google Apps might be a good solution for you if you need to provide email addresses to your volunteers but not give them access to your exchange server.  You can setup your domain on Google apps but not “activate” it for email, docs, talk, etc.  You then add a subdomain to your Google Apps installation where you would create user accounts for your volunteers at an address like stevew@volunteer.church.org.  Just an idea…

Enough of my rambling – I hope you find some of this information helpful or at least somewhat informative.  If you have questions, leave a comment – I’ll do my best to answer you through the comments (smart remarks are welcome too).  Or if you’d like to converse in more depth over the phone, let me know!

Google Apps Directory Sync and AD Passwords

I’ve been working on our Google Apps deployment today and thought I’d share some of what I’ve learned along the way.

Google Apps Directory Sync

The Google Apps Directory Sync tool allows you to sync all of your Users, Groups, Profiles, and Contacts in your LDAP with Google Apps.  The latest revision of this tool also says it will do sync passwords from Microsoft Active Directory.  That’s true  – kinda.  Stay tuned for that…

The Google Apps Directory Sync tool is pretty self explanatory in it’s setup.  It is helpful to know a little bit about LDAP and Active Directory but with a little sleuthing, I was able to figure everything out.  Following are 10 screenshots of my setup in the tool.  The Yellow Highlighted text at the left of each screen shot shows where I am in the configuration and if a screen is skipped, the fields there have been left blank.

Password Sync

Active Directory doesn’t actually keep the user passwords in the LDAP, therefore when trying to sync the passwords – they don’t sync.  You have to get the passwords into an attribute field within Active Directory for this to work.  I found this link that helped explain why the passwords would not sync.  Near the end of the thread, you’ll see a tool referenced.  The tool can be found here.

This tool is basically a dll file that catches the password before it is hidden away, puts it in SHA1 hash format, and then inserts it into the “division” attribute field in Active Directory.  After following the installation directions and then changing my password, I saw the SHA1 hash of my password populate into the “division” LDAP attribute field.  In order to get this field to populate, YOU MUST initiate a password change for the user.  I plan on doing that as I migrate my users over the next few weeks.

Updates

So now, how does Google Apps stay synchronized with Active Directory?  Setup a Scheduled Task on your server to launch at whatever frequency you feel is necessary.  If you need to update in a more timely manor, just manually launch that scheduled task. On the Run line in the Scheduled Task I have the following:

“c:\Program Files\Google Apps Directory Sync\sync-cmd.exe -a -c c:\Documents and Settings\Administrator\My Documents\GAppsDirSync.xml”

I created an old fashioned MS-DOS batch file to launch the Google Apps Directory Sync from the command line.  This batch file is then attached to a Scheduled Task.  In the Batch file my commands are as follows:

cd “c:\Program Files\Google Apps Directory Sync”

Start sync-cmd.exe -a -c c:\GAppsDirSync.xml

Hopefully this helps you get started on syncing your Microsoft Active Directory with Google Apps.  If you see items that need to be clarified, please let me know so that I can make this easier for everyone!