Friday, 4 March 2016

IKEv2 with iOS - issues and workarounds


Apple added support for IKEv2 VPN connections in iOS8 but only via mobileconfig profiles and added further support in iOS9 so you could define an IKEv2 profile in the GUI on the iOS device itself. (Apple also added IKEv2 support to OS X in El Capitan.)

Note: IKEv2 is considered much more modern and secure than previous older VPN standards such as IPSec, L2TP, and PPTP. Hence the fact Apple added support for IKEv2 and my using it.

While I have now successfully got an iPhone running iOS 9.2.1 to connect via IKEv2 to a matching IKEv2 VPN server I did come across a bug along the way which I have now reported to Apple. Obviously in getting it working I managed to get round these problems.

A common method for generating mobileconfig profiles for use with iOS devices is Apple Configurator. Apple Configurator 1.7.2 for Yosemite supports defining an IKEv2 profile but only for iOS clients, Apple Configurator 2.1 for El Capitan supports creating an IKEv2 profile for both iOS and Macs.

The issue I hit with Apple Configurator is that both the Yosemite version and the El Capitan version add an entry in the mobileconfig as standard which caused a conflict with my IKEv2 VPN server and prevented the iOS device from successfully connecting. The entry is in the IPv4 section and is a flag called OverridePrimary and AppleConfigurator sets this to be 'true' i.e. 1. This flag apparently tells the VPN client it must send all network traffic via the VPN connection including 'normal' traffic that needs to go to Internet connected sites, e.g. web browsing traffic. There is nothing wrong with wanting this to happen and in fact most corporates using IKEv2 would want that, however at least in my case this setting conflicts with settings in my IKEv2 VPN server which itself is already set to force all VPN clients to send all traffic via the VPN, this conflict causes the connection attempt to fail.

Note: I am using StrongSwan 5.1.2 on a Linux server as the VPN server.

To workaround this problem after identifying it I had to manually edit the mobileconfig file produced by Apple Configurator and delete the following section.

  1.      <key>IPv4</key>  
  2.      <dict>  
  3.           <key>OverridePrimary</key>  
  4.           <integer>1</integer>  
  5.      </dict>  

As my IKEv2 server is set to force all traffic via the VPN connection that still happens but this time with the above deleted from the mobileconfig the connection succeeds.

Unfortunately the Apple Configurator user interface does not list this option and hence does not itself allow disabling it if as in my case this turns out to be needed. Hence the need to manually edit the mobileconfig file. While investigating this issue I discovered that the old iPhone Configuration Utility which I had previously been using for Cisco IPSec configurations (being old it does not support IKEv2 configurations) does add the same OverridePrimary setting but sets it to 0 i.e. off and hence this is why I have not seen this problem before.

Note: Even though iPhone Configuration Utility set the setting to be 0 i.e. off because my StrongSwan5 setup has its own rule to force all traffic to go via the VPN connection this did indeed still as desired successfully force all traffic to go via the VPN connection. It should also be noted that the majority of example StrongSwan5 configurations include the same rule to force all traffic to go via the VPN connection which is to include the following in /etc/ipsec.conf

leftsubnet=0.0.0.0/0

This as should be obvious to anyone who has had to deal with configuring routers for a while means include every single IP address as the destination.


Now that I have got IKEv2 'working' on iOS I will move on to trying this in El Capitan and see how many bugs Apple have managed to include there. 

Wednesday, 17 February 2016

Automating the distribution of Apple Mail Stationery in a corporate environment

I recently had to find a solution to distribute Apple Mail Stationery files to all the Macs in a company. Stationery for use with Apple Mail is normally distributed either as an attachment to an email or as a file on a disk and either way would normally be installed in each users individual home directory. Not only would this result in potentially multiple copies of the same stationery file on a single Mac but the location in a users home directory is a rather complex one looking for example like this -

~/Library/Containers/com.apple.mail/Data/Library/Application Support/Mail/Stationery/Apple/Contents/Resources/Custom/

While hypothetically it might be possible to come up with a solution to both automate initial distribution of these files to each user and to distribute updates to these files to those users it seemed to me that the easiest solution was going to be to automate distributing them to each computer rather than each user especially as I was wanting to do this via Munki.

Note: This approach should equally work using similar tools like ARD, CasperSuite, etc.

The first step was therefore to locate where Apple's own included example mail stationery files were located which is…

/Library/Application Support/Apple/Mail/Stationery/Apple/Contents/Resources/

…with multiple sub-folders to organise the different categories of stationery Apple provide. An added complexity is that Apple also use the following file as an index defining the list of categories/sub-folders

/Library/Application Support/Apple/Mail/Stationery/Apple/Contents/Resources/TableOfContents.plist

I could have simply placed my files in one of the existing Apple folders but apart from this likely being confusing to users it may also be at risk of being wiped by Apple updates. I therefore wanted to create a sub-folder for my own files. I therefore needed to find a way to -

  1. Create the sub-folder
  2. Update Apple's TableOfContents if needed to include my sub-folder
  3. Copy my files in to it

I accomplished this by creating a standard Apple Installer package file with a payload of my mail stationery files, and a pre-install script in the Installer package to create the sub-folder and to update the TableOfContents index. While I have chosen to use a single Installer package to install multiple mail stationery files to the same folder this approach could easily be adapted to have individual installer package files one for each stationery file.

While the TableOfContents file is a plist file it is not of a format that makes it possible to use the standard 'defaults' command to modify it - defaults is particularly weak at handling arrays, it might have been possible to use PlistBuddy but I settled on using a perl script as part of a shell script to do this.

#!/bin/sh
/bin/mkdir -p "/Library/Application Support/Apple/Mail/Stationery/Apple/Contents/Resources/MyCompanyName/Contents/Resources/" && /bin/cp -R "/private/tmp/Mail Stationery/" "$_";
searchtableofcontents=`grep '<string>MyCompanyName</string>' "/Library/Application Support/Apple/Mail/Stationery/Apple/Contents/Resources/TableOfContents.plist"`
if [ "$searchtableofcontents" != " <string>MyCompanyName</string>" ]; then
perl -i -pe 'BEGIN{undef $/;} s/<\/array>.*<\/plist>/\t<dict>\n\t\t<key>Folder Name<\/key>\n\t\t<string>MyCompanyName<\/string>\n\t<\/dict>\n<\/array>\n<\/plist>/smg' "/Library/Application Support/Apple/Mail/Stationery/Apple/Contents/Resources/TableOfContents.plist";
fi
exit 0

I then added this installer package to my Munki repo to be automatically distributed to all the Macs. I can and have issued updated versions simply by creating a new updated installer package with a new version number and Munki picks this up and distributes it as an update.

Users can then see the mail stationery in Apple Mail as a separate folder in the standard list of stationery. Users do not have to be bothered by or confused by getting an email attachment and working out how to install it themselves. Furthermore this works even if a user uses more than one different Mac and even if the user leaves and someone else gets their Mac.

I can also automate uninstalling this and tidying things up by using the following matching Uninstall script in Munki.

#!/bin/sh
searchtableofcontents=`grep '<string>MyCompanyName</string>' "/Library/Application Support/Apple/Mail/Stationery/Apple/Contents/Resources/TableOfContents.plist"`
if [ "$searchtableofcontents" == " <string>MyCompanyName</string>" ]; then
perl -i -pe 'BEGIN{undef $/;} s/\n\t<dict>\n\t\t<key>Folder Name<\/key>\n\t\t<string>MyCompanyName<\/string>\n\t<\/dict>//smg' "/Library/Application Support/Apple/Mail/Stationery/Apple/Contents/Resources/TableOfContents.plist";
fi
exit 0

Note: The above script's If statement has exactly the number of spaces needed in it so be careful when copying it.

Note: Munki uses the package receipts list to delete i.e. uninstall the actual mail stationery files, the above script simply removes the sub-folder entry from the Apple TableOfContents file.

Saturday, 13 February 2016

Munki and Microsoft Office licenses

Many Mac using organisations will use a free open-source tool called Munki to deploy applications and updates for those applications including of course Microsoft Office for Mac. If you have a Microsoft volume license this is extremely easy as all you have to do is download the ISO and add the contents to your Munki repo. If you however still have individual aka. ‘boxed’ license numbers for Office then matters are a bit more complicated.

Firstly a bit of a rant about Microsoft and their ‘Volume’ licenses. To most people volume implies a volume discount as anyone who has to do the weekly supermarket shopping run will be familiar with. This also applies to most software companies but not Microsoft. Instead volume when associated with Microsoft probably refers to how loud their customers will scream when they see how much they are being ripped off by Microsoft. You will be staggered to learn that a Microsoft volume license for Office 2016 costs almost exactly double the price of the same number of ‘boxed’ Office 2016 copies. Yes you read that correctly double!

Now this is on top of the long standing practice by not only Microsoft but most software companies of not allowing you to convert individual boxed licenses to be part of a volume license and therefore requiring you to pay full price for a new volume license. This is as I said a longstanding practice and while arguably unfair and arguably counter-productive in that it can discourage customers moving to a volume license which even ignoring costs would be in the long-term interest of Microsoft as well.

Historically small organisations would start off by buying boxed licenses and then grow to a size that the simpler administration provided by a volume license becomes important, most companies at some point would hit this problem. (These days companies might start off with Office 365 and then move to a volume license.)

Note: The fact that the volume license for Office costs double the price of the same number of boxed copies applies to both Mac and Windows versions. At least one can say unusually that Microsoft are treating both Mac and Windows customers equally bad.

The main purpose of this post is therefore to describe how to continue to use boxed Microsoft licenses on Macs via Munki and to still keep much of the benefit of simplicity provided otherwise by a volume license.

The steps to do this are simple to do and only require a modest amount of initial work.
  1. Add as normal the (boxed) Office installer to your Munki repo
  2. Use Munki to deploy Office to a new Mac
  3. On the new Mac launch Office and manually activate its license as normal
  4. This will create the license file on that Mac, this now needs to be copied to your Munki server, I create an additional sub-folder in the Munki repo called licenses for this purpose, and then in the licenses folder create another folder called office2008 or office2011 or office2016 as appropriate, then create in that a folder named with the serial number of the Mac e.g. CK123456789Z and finally put the office license file in that
For Office2008 the license file is located at
/Applications/Microsoft Office 2008/Office/OfficePID.plist
For Office2011 the license file is located at
/Library/Preferences/com.microsoft.office.licensing.plist
For Office2016 the license file is located at
/Library/Preferences/com.microsoft.office.licensingv2.plist

So on your Munki repo you will have something like this
./licenses/office2008/CK123456789Z/OfficePID.plist or
./licenses/office2011/CK123456789Z/com.microsoft.office.licensing.plist or
./licenses/office2016/CK123456789Z/com.microsoft.office.licensingv2.plist

This now makes it possible to have Munki automatically install the license file the next time the same Mac needs Office reinstalling, perhaps after replacing a fault hard disk or fitting a bigger hard disk or wiping and reinstalling the entire Mac. As the license file is linked to the same Mac all that is required is to copy the license file back to the same location. To do this I use the following post-install script in Munki for the Office install.

Note: This example script is for Office 2011 it should be very obvious what changes are needed for other versions of Office based on the above information.

#!/bin/sh
officeversion=”office2011”
location=”/Library/Preferences”
filename=”com.microsoft.office.licensing.plist”
serialnumber=$(/usr/sbin/system_profiler SPHardwareDataType | /usr/bin/grep 'Serial Number (system)' | /usr/bin/awk '{print $NF}')
/usr/bin/curl https://munki.domain.com/repo/licenses/$officeversion/$serialnumber/$filename –o $location/$filename
exit

Note: If you run the Munki install of Office before a license file has been 
created and added to the relevant sub-folder of the licenses folder this is not 
a problem as Office will still be installed successfully and you simply have to 
license it manually, thereafter assuming you remember to copy the license file 
to the relevant folder in your Munki repo this will be copied automatically 
after the install of Office.

Friday, 20 November 2015

Apple HomeKit, the 'Internet of Things' and security

Apparently some manufacturers are criticising Apple for the 'excessive' security required in order to gain HomeKit certification. Some of them and some pundits may be thinking this is another fiendish scheme by Apple to achieve lock-in to yet another Apple only eco-system.

They are wrong.

Apple have shown themselves to be very much concerned about security and gone to great lengths for example to provide excellent security for iOS devices including end-to-end encryption in iMessage - so much so that the FBI is pretty unhappy.

Funnily enough on the topic of the FBI, some of you may have seen a new TV series called CSI: Cyber which about a cybercrime fighting division in the FBI, the first episode in the series was about a baby monitor being hacked over the Internet. This is actually based on true events, baby monitors have and are being hacked over the Internet. See http://www.bbc.co.uk/news/technology-34138480

So Apple is being well ahead of the field in building in extremely robust security in to HomeKit ready for when the 'Internet of Things' really takes off, it is after all far easier to do this at the beginning rather than trying to figure out how to fix things afterwards.

Monday, 22 June 2015

Apple Lossless music files and Windows, an update

As per my previous article here - Using Apple Lossless (aka. ALAC) in Windows the situation is unchanged for Windows 7, 8, or 8.1 however if you are currently testing Windows 10 or plan to upgrade to it when it is released then there is significant news for you.

Microsoft with Windows 10 have added official built-in support for a number of additional music and video formats and this includes Apple Lossless. This is provided in the form of a brand new MediaFoundation codec, both 32-bit and 64-bit versions are included. In fact there seem to be both decoding for playback and encoding versions provided although at this point I have not found any way to utilise the encoding versions. Playback is of course via Windows Media Player.

Furthermore with a subsequent update to Windows 10 preview Microsoft have also fixed the deliberate crippling of Apple Lossless files which previously resulted in such files being moved to the 'other' section of the Windows Media Player library. Apple Lossless files now correctly end up in the 'music' section at least in Windows 10. The previous workaround using WMPTagPlus is still needed for Windows 7, 8, and 8.1.

As a result of these two changes it is no longer necessary to install any additional software at all in Windows 10 and you can now straight away fully utilise Apple Lossless files. As before Windows Media Player still is able itself to read the meta-tags in these files including any embedded album artwork.

One of the supposed benefits of using a MediaFoundation codec over a DirectShow equivalent is that MediaFoundation codecs are supposed to support the ability to use the 'play-to' feature in Windows Media Player so that you can stream the music to a compatible DNLA client device. With DNLA being in my opinion a poorly designed and implemented system and with very few DNLA clients supporting Apple Lossless I have not yet been able to confirm whether this works for Apple Lossless files. If anyone else has had success please post a comment detailing what DNLA client you successfully tested an Apple Lossless file with.

Tuesday, 22 July 2014

Running Crypt Server on a Mac via Server.app

(Revised for new Django 1.5 version of Crypt Server)
Crypt is software written by Graham Gilbert of pebble.it to provide a FileVault2 escrow solution. That is to provide a secure centralised store for FileVault2 recovery passwords. With this (or similar FileVault2 Escrow solution) the user or authorised administrator can generate the recovery key to get back into a FileVault2 protected machine should the user forget their original code or leave the company. See http://grahamgilbert.com/blog/2013/01/18/crypt-a-filevault-2-escrow-solution/

Crypt consists of two parts, a client part which firstly enforces the use of FileVault2 encryption on the computer and secondly stores the details for the recovery key in the matching Crypt Server. There are other similar solutions available but Crypt has the advantages of being free and not using any external hosted systems.

Whilst (obviously) the client part of Crypt is native Mac software designed to run on Macs, currently the only official documentation for the Crypt Server is aimed at running Crypt Server on a Ubuntu Linux Server. It is certainly possible to run the Crypt Server on an Ubuntu Server with Mac clients by following those instructions and you can even host the Ubuntu Server in a Virtual Machine running on a Mac, e.g. in VirtualBox. However some people might prefer to run Crypt Server natively on an existing OS X Server and this article therefore describes how to achieve this.

Firstly we need to look at the requirements for running Crypt Server -
Apache
Python
VirtualEnv
Django
mod_wsgi
Of these Apache is included on all Macs as is Python, Django can be easily installed but mod_wsgi is only included if you have Server.app installed on top of Lion or Mountain Lion. This article is only aimed at how to get Crypt Server working with Server.app. As Server.app is very cheap if your unwilling to pay even that modest sum then your on your own and perhaps should stick to using the free Ubuntu Server approach. So in terms of this article the full requirements will be -

OS X Lion or OS X Mountain Lion
Server.app
Apache
Python
VirtualEnv
Django
mod_wsgi

I will be differing from the normal Crypt Server install instructions so as to be able to integrate with Apple's Server.app approach. I will be including download links for the configuration files I had to create to achieve this.

Step 1.
Ensure you have Server.app installed and have run it at least once so it can configure itself. As is best practice your server should have a static IP address. The only service in Server.app we will require is the webserver service. We will configure this later. You can if you wish run other services and even other websites on the server you will be using. In order to be able to run multiple websites on the standard port 80, you need to have at least one extra DNS name pointing to this server. So if its main DNS name (A record) is server.example.com you would add an alias (CNAME) and pick a new name for that for example cryptserver.example.com this will allow using a website name of cryptserver.example.com for the website we will be using.

Note: I see no benefit to running Crypt Server on a (web) server accessible from the Internet. In fact I would suggest from a security point of view you should only run it on an internal private server. This does mean client machines will need to be setup either on the internal private network or via a VPN connection to the private internal network.

Step 2.
We will be installing various Django and other python modules. The standard Ubuntu instructions describe using apt-get and pip to install these modules. Neither of these commands is as standard part of OS X however we can install pip very easily by using the built-in 'easy_install' command. So the first command will be

sudo easy_install pip

We now have the pip command installed so we can now use it to install the other modules as follows. First we will install VirtualEnv which allocates the modules to an environment private for the use of Crypt to prevent conflicts with any other python based software which might use different versions of these modules.
(You can check to see if virtualenv is already installed by typing the command virtualenv -–version if it is already installed then you can skip this step.)
sudo pip install virtualenv
We will then create the environment for Crypt.
cd /usr/local
bash
(virtualenv prefers using the bash shell rather than the standard sh shell)
sudo virtualenv crypt_env
cd crypt_env
sudo source bin/activate
sudo pip install django==1.5.3
(The current version of Crypt Server is now written specifically for Django 1.5 and has not been tested with Django 1.6, the above command ensures that Django 1.5.3 is used.)
sudo pip install south
sudo pip install django-bootstrap_toolkit
Step 3.
We will now download the Crypt Server software. This is available here https://github.com/grahamgilbert/Crypt-Server this can in theory be downloaded using a GIT client however I chose to download the ZIP archive listed on the right-hand side and save having to install GIT on my server.

In order to have file paths matching (as much as possible) the original Ubuntu instructions and also to match the settings files I am providing you then need to expand the zip file and move/copy the resulting folder of files as follows. The zip file contains at the top a single folder called crypt-server-master and in that various subfolders. The folder crypt-server-master needs to be renamed crypt and moved into /usr/local/crypt_env/ therefore the path to crypt will become /usr/local/crypt_env/crypt/ I did this in Terminal.app.
Step 4.
We now need to create a wsgi file, the author provides an example one but strangely does not include it in the zip file, so here is one I prepared earlier crypt.wsgi :)

Note: Oops! Just discovered on 22nd July 2014 that the link above to the example crypt.wsgi was pointing to an old incorrect version, I have updated the link to point to a corrected version.

You need to download that file and copy it to /usr/local/crypt_env/crypt/crypt.wsgi
Note: Apple's Server.app will not process python webapps unless they use the file extension .wsgi if you try using the file extension .py they will not work.
Step 5.
We now need to create and configure the settings file for Crypt Server, first we copy the example file.
sudo cd /usr/local/crypt_env/crypt/fvserver/
sudo cp example_settings.py settings.py

We now need to edit settings.py pick your favourite commandline editor, e.g. nano, pico or vi.

You need to set the Administrator email details and the TimeZone for your server. This step is the same as the original Ubuntu instructions. You can therefore look at section 27 here http://derflounder.wordpress.com/2012/12/31/first-look-at-crypt/
Step 6.
We now need to generate the database that Crypt Server will use to store the accounts and FileVault2 recovery keys. To do this we use the following commands.
sudo cd /usr/local/crypt_env/crypt/
sudo python manage.py syncdb

These steps are again the same as the original Ubuntu instructions so you can look at section 28 here http://derflounder.wordpress.com/2012/12/31/first-look-at-crypt/

Note: The user account being created here is only used internally in the database it is not linked in anyway to Open Directory or any other OS X user account. It is used when you login to Crypt Server via a web-browser.

Then we do

sudo python manage.py migrate
sudo python manage.py collectstatic

Again this is the same as the standard Ubuntu instructions so see sections 29 and 30 here http://derflounder.wordpress.com/2012/12/31/first-look-at-crypt/

We have now in theory finished installing and setting up Crypt Server, the remaining steps will be integrating it into Apple's Server.app

Step 7.
Launch Server.app and go to the webserver service. Create a new website using the hostname you chose in step 1. Leave it using the standard port 80 and all IP addresses settings. Click on the Edit button next to Aliases and add a rule to map from a path of /static/ to a folder (any folder) we will be manually editing this later because Server.app does not let you browse to /usr/local where we need it to point to.

You should now quit Server.app for now, do not start the webservice yet. Next we want to manually edit the apache conf file corresponding to the website you have just created. This will be located in /Library/Server/Web/Config/apache2/sites/ it will have a name something like 0000_any_80_cryptserver.example.com.conf the exact name will depend on the host name you are using. You need to edit this in Terminal.app using your favourite editor. You want to set the line beginning with DocumentRoot (the fourth line typically) to the following

DocumentRoot "/usr/local/crypt_env/crypt"

You also want to set the line beginning with <Directory similarly as follows

<Directory "/usr/local/crypt_env/crypt">
Finally we want to edit the line beginning Alias /static/ it will be need the bottom of this file, change it to the following
Alias /static/ "/usr/local/crypt_env/crypt/static/"
We have to do this manually because the files for Crypt Server are not in the normal websites folder location, and because in Server.app you cannot browse and set the location to somewhere in /usr/local/ as this is 'hidden' from view.

Note: Fortunately my experience is that once this change is made manually, Server.app respects it and does not later overwrite it.

The standard Ubuntu instructions tell you to run the website with an additional user account setup specifically for it and that you need to add an additional command to the apache conf file you have just edited above. I could not get those instructions to work with Server.app but fortunately it is not necessary to do so. If you follow the instructions here the website will run successfully with the standard _www account. You do need however to set the ownership of the Crypt Server files to _www so that the standard account can access and modify the Crypt Server database. To do this issue the following command

sudo chown -R _www /usr/local/crypt_env

Step 8.
We now need to setup the extra config files to make the Crypt Server django webapp available as a webapp that will be listed in Server.app and this will allow us to have this webapp run when someone accesses this website. In this article I will merely tell you what to put where and how to then turn it on, but for more details on how you setup webapps in general with Server.app see my other article about this topic available here http://jelockwood.blogspot.co.uk/2013/06/running-django-webapps-with-os-x.html

You need to first place a file called com.crypt.webapp.wsgi.plist in /Library/Server/Web/Config/apache2/webapps/ here is a copy of com.crypt.webapp.wsgi.plist I have made for you. You also need to place a file called httpd_crypt.conf in /Library/Server/Web/Config/apache2/ here is a copy of httpd_crypt.conf for you to use.

You can now open Server.app again. Go to the webserver service and select the website you previously added in step 7 above. Edit the website by clicking on the pencil button, scroll down and click on the 'Edit Advanced Settings...' button. You should now see a list of available webapps, the one you want to enable (tick) is the 'FileVault Escrow Server'. This corresponds to the webapp that the two files you have just installed has defined and this will run the Crypt Server webapp when you access this website. Then click OK and then click Done. You can now start the websites service.


All being well you should now be able to access the Crypt Server in a web-browser at a URL like http://cryptserver.example.com/ depending on what hostname you are using.

Thursday, 27 March 2014

DHCP Option Code Utility 1.1

I finally updated my DHCP Option Code Utility to make it compatible with Mountain Lion. This gets round a change Apple introduced (it had worked fine with Tiger, Leopard, Snow Leopard and Lion).

DHCP Option Code Utility makes it easy for mere mortals to generate the encoded values needed to define DHCP Option Codes for use with Apple's DHCP server. The most common uses of DHCP Option Codes are to define extra fields of information to advertise things like a VoIP phone system or a PXE Boot Server.

I also took the opportunity to add the ability to define 'null-terminate strings' as well as normal strings.

More details along with a download link can be found here.

http://jelockwood.blogspot.co.uk/2013/06/dhcp-server-on-os-x-server.html

[As a belated update to this post - I did sometime ago confirm that version 1.1 also works fine running in Mavericks, and that the DHCP server in Mavericks Server.app still accepts the same encoded values. Version 1.1 can therefore run on 10.4 all the way up to (currently) 10.9.2 and the values work with 10.5 Server through to Mavericks Server.app]