admin adventure

the ongoing struggle: man vs machine

WPA2 Enterprise EAP-TLS Authentication with Apple IOS Devices without iPhone Configuration Utility



The recommended way to configure an enterprise wireless network is with certificates rather than a shared passphrase. This allows you to issue a certificate to each wireless device, and should a device be lost, revoking the certificate is all that is required to prevent access.

Searching the internet reveals that many guides focus on using the iPhone Configuration Utility to install a certificate and wireless profile on IOS devices as, or using MDM, as the only possible ways to enable apple devices to participate in this network. What I seek to outline is a 3rd way that relies on neither of these methods.

The reason for this guide is that the iPhone Configuration Utility is end of life, and will not work with IOS 8 and above. It has been replaced by Apple Configurator, which is an app only available on MacOS. Purchasing a Mac just to configure iPads is not an option for me.

I will details all steps to get a non-domain joined device (weather it be a PC, Tablet or Phone) to join the wireless network.

This guide assumes that you already have a functional WPA2-Enterprise EAP-TLS Wi-Fi network, NAP server and Certificate Authority. This network should already be functional with domain-joined PCs.


Create A Certificate Template

Stage 1 of this process is to create an appropriate certificate template, and enable the template on our Certification Authority.

  1. On your certificate server, open a blank MMC console, and add the certificate templates, and certification authority snap-ins.
  2. Under the Certificate Templates Node, Right Click the “Computer” template and click “Duplicate Template”
  3. Select “Windows Server 2003 Enterprise” As the template version, and click OK.
  4. On the General Tab, give the template a display name, template name, and set a validity period
  5. On the Request Handling tab, Set the Purpose to Signature and Encryption, set a minimum key size of 2048, and tick on the “Allow private key to be exported” checkbox
  6. (CRITICAL) On the Subject Name tab, check the option to “Supply in the request”, as shown below.
  7. On the Issuance Requirements tab, check the checkbox for “CA certificate manager approval”. This ensures that an administrator is involved in approving the issue of a certificate to non-domain (i.e. non-trusted) devices.
  8. Finally, on the Security tab, ensure an appropriate administrative user has rights to read, write and enroll certificates based on this template. Click Ok.
  9. Now we need to enable the certificate template on our Certificate Authority. Navigate to Certification Authority>Certificate Templates. Right click the node, and select New>Certificate Template to Issue.
  10. Select the template you created in previous steps and click ok.


Create Certificate Request

Stage two of this process is to request a certificate. I am doing this from my own domain-joined Windows 7 PC, however it may be better practice to have a workstation dedicated to this task. (Note that I have certificate auto-enrolment enabled for my domain, so my PC will automatically enrol certificates issued to it).

  1. Open up a blank MMC console as administrator (This should be the administrator you defined earlier on your certificate template). Add the Certificates (local computer) snap-in.
  2. Expand Certificates>Personal
  3. Right-Click “Personal”>All Tasks>Request New Certificate
  4. Click Next until you arrive at the Request Certificates Screen
  5. Check the mobile device template, and click properties.
  6. On the Subject Tab, fill out the certificate details. Common Name is required by the system, whilst other fields are optional, however I recommend you fill in at least these fields.
    Common Name
    (e.g. username_IOSPhone1 for BYOD or asset number for corporate owned devices)
    Note, the common name cannot be longer than a NetBIOS name (20 characters)
    Organisational Unit (I.e. department)
    Given Name

    Note that the common name is the easiest way to identify the certificate in the future, so make sure it is as descriptive of the device and user as possible.

  7. Click Ok, then enrol.
  8. The final screen shows that enrolment is pending. This is because on the template, we selected that approval was required before issuance. Click Finish.


Approve Certificate

On your Certification Authority Server, open up the Certification Authority Console (as administrator) and navigate to “Pending Requests”. Issue the certificate from the right click menu (Ensure that you have the correct certificate request).


Export Certificates with Key and Without Key

  1. Return to the certificates console on your local computer. Right-click on the Certificates>Local Computer root node, and choose “All tasks>Automatically enrol and retrieve certificates. Complete the wizard. (This works because certificate auto-enrolment is enabled in my domain).
  2. Navigate to Personal>Certificates. You will see your newly issued certificate.
  3. Right-click the new certificate, and select All Tasks>Export.
  4. Follow the wizard, choosing to export the private key, and include all certificates in the certification path. You will need to set a password for the certificates.
  5. Export a second copy of the certificate, this time with no key.


Map Certificate to an Account

Note: The normal authentication process involves the computer presenting the certificate (Common Name) to the Network Policy Server (NPS), which in turn will check if the computer account is enabled in AD DS, and that the certificate is valid. Because we are issuing computer certificates, logic would follow that we need to map the computer certificate to a computer account in active directory.

Devices such as iPads behave differently, where they treat all certificates installed as a user certificate, hence when passing the subject name to the NPS server, NPS will look for a user object in AD DS rather than a computer object, causing the authentication request to fail. When this occurs, you will see logs in the NPS server security event log. Keep in mind that devices from different vendors may behave differently, so watch out for this issue.

  1. Open up Active Directory and create a dummy user account. This account must have a username that matches the common name on the certificate. Passwords and other options do not matter for this purpose.
  2. If your NPS server has a group which contains authorised clients, add this account to that group.
  3. Select the new account, and choose Action>Name Mappings
  4. Add the certificate you exported without the key, and click ok.


Configure the IOS Device

Note: These instructions have only been tested on an IPAD 3 running IOS 9.0.1. Your mileage may vary.

Now to the heart of the issue. The previous steps are only an overview of the process to prepare a certificate for a non-domain joined device, and should be acceptable for most devices for WPA2-Enterprise EAP-TLS authentication. What follows are the steps to perform on the iPad (or iPhone) to enrol the certificate on the device, and use the certificate as the credentials to join the wireless network.


  1. Transmit the certificate that was exported (the version with the key) in any way possible to the device. Methods can include cloud storage, email etc. It’s entirely up to you. Just be cautious, as this file has the private key included. This needs to be protected, even though the key is protected by a password you set when you exported the certificate.
  2. Open the certificate file on the device. IOS will recognise the file as a certificate file, and begin the import process. Tap install.
  3. Tap install again.
  4. Tap install again.
  5. Enter the password to unlock the private key.
  6. Click Done. Your Certificate has now been imported into an IOS identity profile, without the aid of external tools.
  7. Finally, lets join the wireless network, with some minor changes to the usual process on IOS. Tap Wi-Fi, and tap on the network you want to join (being your EAP-TLS network, not some other passphrase based network).
  8. Notice that you are prompted for a username and password. Change the mode to EAP-TLS (Why does automatic not work…….?)
  9. The prompt has changed to username and identity. Username is optional, and we will leave it blank. Tap “Identity
  10. A list of installed identities is provided (I only have one). Tap the identity to use for the connection, which places a blue tick next to it.
  11. Tap “Enter Password” to return to the main Wi-Fi screen, then tap “Done”.
  12. You will now be asked if you trust the NPS server Certificate. Tap “Trust”.
  13. You are now connected.


A Quick Note about Revocation


Depending on how your Certificate Authority is configured, and the cache timeouts for Certificate Revocation List checking, there are two ways that can be used to prevent a device from connecting to the wireless network.

1. Revoke the certificate. – This is the most reliable method, as it ensures the certificate cannot be used again. The downside is that this can take a long time to take effect, as the various cache timeouts and CRL updates can take a long time.

2. Disable or delete the computer or user account that the certificate is mapped to – This takes effect immediately, however the certificate is still valid, and if used for other purposes, can still authenticate.

I recommend you perform both of these steps, just to be sure. Neither of these steps will kick an active Wi-Fi connection off the network, but they prevent a re-connection attempt.


I hope you find this helpful.




Connecting iPads to an Enterprise Wireless 802.1x Network Using Certificates and Network Device Enrollment Services (NDES) –

Certificates and Exporting Private Key –


Firefox ESR 31 Deployment via Group Policy and Powershell

If you have found this blog through searching for tips on how to deploy Firefox in the enterprise, you are likely in one of two camps.

  1. Your luck was high today and this was the first link you clicked on in the search results.
  2. Your a generally lucky person, but today your Google-foo search skills seem to be lacking. You are encountering numerous websites that make it seem like deploying Firefox and customising some simple settings is a very difficult process.

I myself have been in the second scenario, and eventually realised that everyone was overcomplicating this issue. I suspect that most people have some very simple requirements when deploying Firefox. What follows is a the process I used to install Firefox ESR 31.2 in my Windows 7/Windows Server 2008 environment, using nothing but native windows tools, and the Firefox install bundle.


  • Install Firefox using Group Policy to my Fleet of Windows 7 PCs.
  • Customise the homepage URL.
  • Disable the “Know your rights” website that can display on first run.
  • Configure several internal domain names to be trusted for NTLM authentication purposes. This enables things like SharePoint to automatically login with the current windows user account.
  • Updates will be handled via the in-built Firefox updating mechanism. This is performed by the Mozilla Maintenance Service, which is installed alongside Firefox. Firefox will be automatically updated when a new ESR version is released, without the user requiring administrative rights over their local PC.

Task 1 – Install Firefox

This seems to be the area where many people come unstuck. Mozilla do not provide an .msi installer for Firefox, despite this being requested for several years. Fortunately Firefox can be silently installed from the command line with some switches. We can utilise Powershell to execute the install on startup, after performing some initial checks to make sure that Firefox is not already installed.

  1. Download the appropriate version of Firefox ESR from
  2. Create a deployment share on a server that has read permissions to the everyone group. This will be your deployment share.
  3. Copy the Firefox installer to a folder within the deployment share.
  4. Open up the Powershell ISE. It is likely in your windows 7 start menu.
  5. Now we need to get started on the script. Note that the complete script is available for download at the end of this blog entry. Here I will work through the script in parts so that you are able to customise it for your requirements. Due to how various web browsers will display this script, download the copy in the zip file rather than copy and paste from the script boxes.
  6. Firstly, we need to define some variables that we will reference later. We will create the config files later. For the moment just add them to the script with their intended file names.

$InstalledFilePath = “C:\Program Files (x86)\Mozilla Firefox\Firefox.exe”

$ConfigFile1Source = “\\servername\sharename\Firefox\v31\autoconfig.js
$ConfigFile2Source = “\\servername\sharename\Firefox\v31\Firefox.cfg”

$ConfigFile1Destination = “C:\Program Files (x86)\Mozilla Firefox\defaults\pref”
$ConfigFile2Destination = “C:\Program Files (x86)\Mozilla Firefox”

7. Next, we need to check if Firefox is already installed. This command uses the previously defined variable to check if Firefox.exe is present.

#Test to see if any edition of Firefox is installed.
IF (!(Test-Path -path $InstalledFilePath -pathType leaf))

8. If Firefox is not found, we will install Firefox silently and then configure our install options in the file config.ini. The install silently switch is –ms.


#Install if file not found.
Invoke-Expression “cmd.exe /c \\servername\sharename\Firefox\v31\FirefoxSetup31.2.0esr.exe -ms /INI=\\servername\sharename\Firefox\v31\config.ini”

Copy-Item $ConfigFile1Source $ConfigFile1Destination
Copy-Item $ConfigFile2Source $ConfigFile2Destination


9. If Firefox was found, we may still need to install the new version and copy the config files. This will overwrite any manual installs of Firefox with our deployed version.

$InstalledProductVersion = (Get-Command $InstalledFilePath).FileVersionInfo.ProductVersion
IF ($InstalledProductVersion -lt 31.2)
#Install if version is less
Invoke-Expression “cmd.exe /c \\servername\sharename\Firefox\v31\FirefoxSetup31.2.0esr.exe -ms /INI=\\servername\sharename\Firefox\v31\config.ini”

Copy-Item $ConfigFile1Source $ConfigFile1Destination
Copy-Item $ConfigFile2Source $ConfigFile2Destination

10. If Firefox was found to be a higher version than is installed by this script, it is possible that the automatic update function has updated to the latest version. In this case, we don’t need to install Firefox, but we still want our customised configuration copied.

Copy-Item $ConfigFile1Source $ConfigFile1Destination
Copy-Item $ConfigFile2Source $ConfigFile2Destination



A limitation of this script is that the configuration files will be copied on every boot of the computer (whilst they are very small, this is still undesirable). I will leave it up to you to solve this  within the script, but how you solve this needs to take into account how you will handle configuration changes (e.g. your homepage address changes).

Save the script to your deployment share. We will now move onto creating our supporting files.

You can download a complete copy of the script, and other resources here.

Task 2 – Creating config.ini

Config.ini is referenced in the Powershell script to provide a way to set some options that would normally be selected through the installation GUI.

1. Copy the following text into notepad, and save to the deployment share as config.ini

; Remove the semicolon (;) to un-comment a line.
; The name of the directory where the application will be installed in the
; system’s program files directory. The security
; context the installer is running in must have write access to the
; installation directory. Also, the directory must not exist or if it exists
; it must be a directory and not a file. If any of these conditions are not met
; the installer will abort the installation with an error level of 2. If this
; value is specified then InstallDirectoryPath will be ignored.
; InstallDirectoryName=Mozilla Firefox

; The full path to the directory to install the application. The security
; context the installer is running in must have write access to the
; installation directory. Also, the directory must not exist or if it exists
; it must be a directory and not a file. If any of these conditions are not met
; the installer will abort the installation with an error level of 2.
; InstallDirectoryPath=c:\Firefox\

; By default all of the following shortcuts are created. To prevent the
; creation of a shortcut specify false for the shortcut you don’t want created.

; Create a shortcut for the application in the current user’s QuickLaunch
; directory.
; QuickLaunchShortcut=false

; Create a shortcut for the application on the desktop. This will create the
; shortcut in the All Users Desktop directory and if that fails this will
; attempt to create the shortcuts in the current user’s Start Menu directory.
; DesktopShortcut=false

; Create shortcuts for the application in the Start Menu. This will create the
; shortcuts in the All Users Start Menu directory and if that fails this will
; attempt to create the shortcuts in the current user’s Start Menu directory.
; StartMenuShortcuts=false

; The directory name to use for the StartMenu folder (not available with
; Firefox 4.0 and above – see note below).
; note: if StartMenuShortcuts=false is specified then this will be ignored.
; StartMenuDirectoryName=Mozilla Firefox

; The MozillaMaintenance service is used for silent updates and may be used
; for other maintenance related tasks.  It is an optional component.
; This option can be used in Firefox 16 or later to skip installing the service.
; MaintenanceService=false


2. Uncomment any line that you need to customise.

Task 3 – Create autoconfig.js and Firefox.cfg

autoconfig.js and Firefox.cfg work hand in hand to provide a means to configure Firefox options.

Copy the following into notepad and save as autoconfig.js on the deployment share.

pref(“general.config.filename”, “Firefox.cfg”);
pref(“general.config.obscure_value”, 0);

These settings tell Firefox that the configuration file is named Firefox.cfg, and that the configuration file is not bit-shifted to hide the contents. Note that if you intend to set passwords in the config file, this would be a security risk as the file is effectively plain text. For our simple purpose this is acceptable.

Note that this file will be placed on the client PC via our powershell deployment script at C:\Program Files (x86)\Mozilla Firefox\defaults\pref”

Now we will make Firefox.cfg. This file will be where we set the options for the web browser. There are many hundreds of options available to set. I am demonstrating only a couple. Many of the options revealed by typing about:config into the Firefox address bar are usable.


Copy the following into notepad and save as Firefox.cfg to the deployment share.

//Don’t show ‘know your rights’ on first run
pref(“browser.rights.3.shown”, true);
pref(“browser.startup.homepage”, “”);
pref(“network.automatic-ntlm-auth.trusted-uris”, “internalsite1.local, internalsite2.local”);

Tip: Line 1 must always be a comment, as denoted by //. If you place a setting on line 1, your config will not work.

Note that this file will be placed on the client PC via our powershell deployment script at C:\Program Files (x86)\Mozilla Firefox\”

Task 4 – Bringing it all together

We now have several elements to bring together via a group policy to implement our configuration. I would recommend implementing this in a testing scenario before you deploy into production, but this is up to you.

  1. Log onto a domain controller and open up the Group Policy Management Console.
  2. Create a new policy with a descriptive name. Pick a name that will mean something to you after 6 months when you have forgotten all about this project.
  3. Edit the new policy and navigate to Computer Configuration>Policies>Windows Settings>Scripts>Startup
  4. Double-click on the startup and select show files. This will open up the folder for this group policy object, which will have an impossibly long GUID in the folder name which you will have no hope of remembering.
  5. Make a new text file within this folder and write the following command to run your powershell script.

@echo off

powershell.exe \\servername\sharename\firefox\v31\InstallFirefox.ps1


6. Save the file and rename the file extension from .txt to .bat to make it a batch file.

7. Close the folder, then click the add button. Add the script you just made to the startup properties window.

And your done.


After following the above guide, and obviously customising the file and path locations within the scripts, you should have:

Group policy which executes a powershell script.

Powershell script which checks for Firefox, the version of Firefox, and either installs Firefox and copies two configuration files, or just copies the configuration files.

A Firefox install, and two configuration files that end up on the client PC.


Script and configuration files

Deploy and Customise Google Chrome

This guide will lead you through the basic steps to deploy Google Chrome with group policy. It is based on v38, which at the time of writing is the current release. To follow this guide, you should already be familiar with Group Policy in general.

As with any task, first clearly define the objectives you want to achieve before starting. Your objectives will no doubt be different, so this guide should be a general reference only.


1. Install Google Chrome 64bit edition for all users of selected Windows 7 PCs. For our purpose the computers are all in the active directory organisational unit “Computers – Windows 7”.

2. Set home page to a specific address.

3. Reduce automatic update frequency.



Task 1 – Obtain the appropriate Files

  1. Download the 64bit msi package of the enterprise Google chrome that Google helpfully provide. It can be located at
  2. Download the adm and admx group policy templates from
  3. Download the Google Update adm group policy template from


Task 2 – Copy MSI file to the deployment share.

  1. Copy the downloaded .msi file to a deployment share that client computers have read access to.


Task 3 – Create a new GPO to deploy the software and settings.

  1. Open group policy management console on a domain controller, and create a new policy. Give it a descriptive name that will still retain some meaning to you and your colleagues in 6 months time.
  2. Edit the newly created policy (Right-click>Edit) and navigate to the Computer Configuration>Policies>Software Settings>Software Installation node.
  3. In the right-hand pane, right click and select New>Package
  4. Navigate to the package file you earlier placed in the deployment share, and click ok.
  5. Select Advanced for the deployment method and click Ok.
  6. Enter a name for the package. I like to put both the architecture and version number in the package name, but it is up to you really. Note that this is the name that will appear in the installed program list on the client computers. I like to put the word “Deployed” in the name to distinguish the group policy installs from the manual installs.
  7. No further options are required to be set, however depending on your environment, you may wish to set some further options. I always set “Ignore language when deploying this package” which is under Deployment>advanced. Once done, click ok.
  8. The install will now install to any PC’s that are covered by the policy you created. If you are testing, you may wish to run the command “gpupdate /force /boot” on your test PC to force an immediate deployment.
  9. Close the Group Policy Management Editor before continuing.


Task 4 – Customise via Group Policy

Configure Homepage

In my case I need to import the .admx template files into my Windows 2008 R2 central store. Your group policy setup may be different. The below paths are for my environment, and your environment will be different.

  1. Extract the policy templates archive.
  2. Copy Chrome.admx to D:\ADDS\Sysvol\sysvol\xxxxxx\Policies\PolicyDefinitions\
  3. Copy the language specific adml files for your required languages to the central store. i.e. the EN-GB files to D:\ADDS\Sysvol\sysvol\xxxxxx\Policies\PolicyDefinitions\EN-GB\
  4. Open Group Policy Management Editor and edit the policy you created earlier. When you expand Policies>Administrative Templates>Google in both computer configuration and User Configuration, you will see the new settings that can be applied.
  5. In our case, we want to change the default home page, and not allow the user to override this. Navigate to the “Computer Configuration>Policies>Administrative Templates>Google>Google Chrome>Home page and set the”Configure Home Page URL” setting.
    Note that is we had desired users have the ability to override, and wanted to set a default, we could have configured the same setting under the “Google Chrome – Default Settings (users can override)” node.
  6. I will also set the “Use New Tab Page as Homepage” option to disabled, to prevent users from changing the homepage behaviour.
  7. This will now load the homepage you have just configured when the home button is clicked. The default startup action for Chrome 38 doesn’t open the homepage, but a new tab. Navigate to Google Chrome>Startup pages and change both the action on startup (Open a list of URLs) and URLs to open on startup settings.


Configure Update Frequency

Chrome will be updated via the Google Update software that is installed alongside Chrome, even for users without admin rights. To manage this software, we need to use the Google update adm template that we downloaded earlier.

  1. Copy the Google update adm template file to a location on the domain controller.
  2. Within the GPME, right-click the administrative templates node, and select add/remove templates.
  3. Add in the Google update adm template, and click close.
  4. You now have the ability to manage Google update.
  5. Navigate to the “Google update>preferences” node, and set the auto-update check period override to the desired setting. I have set the number of minutes to 10080 to enable a weekly update.

Now you should have a working setup. I would recommend you review the documents located below in the resources section, and the other available group policy settings to identify further opportunities to set default settings as appropriate.



Chrome for Work

Set up Chrome for Work

Set chrome policies for devices

Control Auto-updates

Google Update for Enterprise

Install VMware Tools in Debian 7.3

This article will go through the simple steps required to install the ESXi Vmware tools onto a debian 7 guest.

1. The first step is to install debian’s compiling tools and kernel headers for the current running kernel.

aptitude install build-essential

aptitude install linux-headers-$(uname -r)


2. Mount the VMware tools CD by going to the guest menu and selecting “Install VMware tools”.


3. Mount the CD

mount /dev/sr0 /mnt/


4. Extract the archive to the local tmp folder.

tar xfzv /mnt/VMwareTools-9.0.5-1065307.tar.gz –C /tmp


5. Change to the extracted directory

cd /tmp/vmware-tools-distrib


6. Run the script to build the needed kernel modules.



7. The script will ask you various questions as the install progresses. Just press enter to accept the default choices, unless you desire to change it.


8. Reboot the virtual machine and check that the vmware tools are now listed as running by vmware.

System Image Backup in Windows 8.1

This is actually not the case. Microsoft have just made the feature difficult to find.

To find this option, you must search for “file history” from the start menu (previously known as the metro interface) and run it. Alternatively, you can find the file history program from the control panel in desktop mode.

Once the file history program loads, you will see the “System Image Backup” link at the bottom left of the screen. This gives access to the same backup interface that was available in Windows 7. No 3rd party software and no powershell scripts are required.


Deploy Civica Authority Desktop Client using Group Policy

In this post I will explain the steps I take to deploy the Civica Authority Desktop Client software to my mixed 32bit and 64bit environment. The below process will detail how to deploy an upgrade to a client that has previously been deployed, however the same process can be used for a new deployment of the client with the only change being in the group policy upgrade tab in Step 4.

As the Authority Desktop Client is frequently updated as part of the Authority patching process, it is important to distribute the new client to all your Windows PCs. Doing this manually is generally too much of a burden, and group policy can be used to reduce this burden.

It should be noted that if the Authority Client is going to be deployed through Group Policy, it should not be included in any system images that you are using to distribute your SOE, as this can cause problems when trying to upgrade to new versions.

My goals are:

  • Deploy the Authority Desktop Client version using a single GPO. Since I have previously deployed prior versions of the client to my PCs I will use my existing GPO titled “AuthorityClientDeploy”.
  • Prior versions of the client will be removed before the new version is installed.


Step 1 – Obtain the Appropriate Files


After you have installed a new patch (or anytime after issuing the update_auth6_repo command at the authority command prompt), you will have the latest client files on your Authority Server. As we are on Authority v6.4 the path to the required files is D:\civica\download\6.4\

Contained within this zip file are 5 files.

  • authmsi Test Plan.pdf – This is a testing plan recommended by Civica prior to certifying the new client for use in your environment.
  • authority.ini – This is the default configuration for the client installer. You should have been supplied with a customised version of this file for your specific site from Civica when you first installed Authority. This file should be compared with your customised version, so that any new features can be incorporated into your customised version.
  • authority_64_installation_notes_windows_client.pdf – Well worth reading.
  • Authority- – The file we will deploy
  • CrystalReports.msi – The crystal reports runtime for Authority, which is not updated as frequently as the Authority Desktop Client. I use a separate GPO to deploy this.


Step 2 – Copy Files to Deployment Share

Copy both the Authority- and your sites customised authority.ini files to a deployment share that client computers have read access to.


Step 3 – Generate the Transform (MST) file to Customise the Install


  1. Open up the Authority-  file in Orca
  2. Click Transform>New Transform
  3. Scroll down the left hand tables window and click the “Property” Table.
  4. In the right hand window, edit the values for the properties you wish to change.


For my environment, we are using the Quick Address Pro validation so the following 6 values relating to QAS have been set.

  • REG_QAS_SERVER: yourqasserver.domain.local
  • REG_QAS_PORT: 2120
  • QAS_SERVER: yourqasserver.domain.local
  • QAS_PORT: 2120
  • QAS_VERSION: 6.12
  • QAS_BY_INI: N (This setting allows the QAS settings to be set in an ini file rather than in the mst file we are creating. We set this to N as we have defined the settings within the mst file).

If you are not using QAS, you can leave these values at defaults.

5. We also need to set an INSTALLLEVEL value. This controls which components of the Authority MSI are installed. This property will not be available, and we will need to create it.

6. Right-click in the Property Detail Pane, and select “Add Row”


7. Create the new property with a Property name of INSTALLLEVEL and set a value. Available choices are 1, 3 and 999. I have set this value to 3. Click OK.


Which install level you select can be determined by going to the Feature node in the left hand tree, and looking at what the components are and deciding what you need to install. This information is also available from the installation notes document on page 32.

(Note: that an alternative method of selecting what items to install, the ADDLOCAL Property is detailed on page 32 of the release notes and provides a way to individually select features to install. However as the only level 1 feature that is optional for Authority is the Genero Desktop Client, and generally this is desired, the INSTALLLEVEL property is the easier solution).


Determine which install level you need based on the components installed at each level.

Install level 1 only installs level 1 components
Install level 3 installs level 1 and 3 components – Adds QuickAddress_Runtime
Install level 999 installs all components – Adds Terminal_Server_DLL

8. When you have finished making changes, go to Transform>Generate Transform

9. Save the transform file in the same location as the MSI file on your deployment share. I include the version number in the MST filename, and I make a new mst file every time I deploy a new version of the client, even though the settings are usually identical.

10. Close Orca

Step 4 – Add the Package and Transform to Group Policy

1. Open Group Policy Management Console, right-click the existing GPO and select Edit.

2. Under Computer Configuration>Software Settings>Software installation, Right click on the blank right-hand window and select New>Package.

3. Select the Authority- file. I like to ensure that a UNC path to the package is used, but it is up to you.

4. Select the “Advanced” option and click OK. The package properties window will appear.

5. Change the name of the package to distinguish that it is 32bit. I used “Authority Desktop Client x32 – Deployed”.

6. Click the Deployment Tab>Advanced and check the option “Make this 32-bit X86 application available to Win64 machines”. This is because we need this 32bit package to install on the 64bit PCs in our environment. On the same screen, I usually check “Ignore language when deploying this package”. This prevents differences between US English and Australian English from preventing the install from occurring, but this is a personal preference.

7. On the upgrades tab, clear anything that has been added to the list, then click add, and select all versions of the client previously distributed by Group Policy that you wish to upgrade. I choose the option to uninstall the previous versions, rather than attempt an upgrade.


9. Click the modifications tab and add in the MST file you generated with ORCA.

10. Click OK.

Congratulations, you are now deploying Authority Desktop Client

Update Alerts via Email in Debian Squeeze (apticron)


We all know life is busy for us system administrators. Keeping servers updated is generally a good security practice, but is often overlooked due to more pressing concerns. This can often be especially true for the trusty linux servers that sit in the corner and never cause a problem.

This short tutorial will guide you through setting up the apticron tool to alert you when updates are available for debian.

It relies on the server being able to send emails, so ensure that this is possible through exim, postfix or sendmail first.


1. Open terminal as root



2. run command apt-get install apticron


3. Edit the configuration file with nano.

nano /etc/apticron/apticron.conf




4. Change EMAIL=”root” to a valid email address. Note that quotes must remain around the email address.



5. Press CTRL-O to save, then CTRL-X to quit nano.


All done. You will now receive a daily email with the required updates.

Installing Subversion on Debian Squeeze for HTTP and HTTPS

This tutorial will lead you through installing the source control and versioning software, Subversion. It assumes that you already have a server running Debian squeeze with network access.

The Debian system I use in this tutorial is called bhap04 and has an ip address of

Install Subversion

1. Log into Debian console as root.

2. Install Subversion using apt-get install subversion. Answer Y at the prompt.


3. Next, create a directory that will hold our repositories. mkdir –p /var/lib/svn


4. Now I will create a repository for my software development project called myproject inside /var/lib/svn. You can create other repositories now for other projects you have. The repository will be empty until you import a project into it.

svnadmin create /var/lib/svn/myproject


Subversion is now installed, but can only be used locally, which does not suit our purpose. We need to install apache and configure it to host Subversion.

Enabling HTTP

For HTTP:// we need to configure WebDAV on an Apache2 server. Thus we will install apache2 and apache2 SVN module now.

1. apt-get install apache2 libapache2-svn


2. Next, we configure apache2 SVN module by editing the file /etc/apache2/mods-available/dav_svn.conf

nano /etc/apache2/mods-available/dav_svn.conf


The text editor nano will launch and display the file as below.


3. There is a configuration already commented out. You can leave it commented out as a future guide, and add our configuration to the bottom of the file.

 <Location /svn>
  DAV svn
  SVNParentPath /var/lib/svn
  AuthType Basic
  AuthName "Subversion Repository"
  AuthUserFile /etc/apache2/dav_svn.passwd
    Require valid-user

Add the below lines to the file, then press ctrl-O to save, and ctrl-X to close.

4. Restart apache2 to enable the configuration.

/etc/init.d/apache2 restart


5. Because we will be reading and writing to our repository folders as the Apache user, which is www-data, we must change the owner and group of /var/lib/svn and its children.

chown –R www-data:www-data /var/lib/svn


6. Now we must create the passwords file that will contain all users that will have access to SVN. I ill make the user admin22

htpasswd –c /etc/apache2/dav_svn.passwd admin22

You will be prompted for a password for the new user.


7. You can continue to add additional users with the command htpasswd /etc/apache2/dav_svn.passwd username

Note the lack of the –c switch. This switch creates the password file. If you use it a second time, you will overwrite the existing password file with a new file, which is generally not desired.

You now have a working HTTP Subversion. We must now configure HTTPS. If you don’t desire this option, you may stop here.


1. Enable Apache SSL Module

a2enmod ssl


2. Restart apache2

/etc/init.d/apache2 restart

3. Copy the default-ssl sites file to a new file and name it with the name of the site.

cp /etc/apache2/sites-available/default-ssl /etc/apache2/sites-available/subversion.bhap04.conf

4. (Optional) If you are supplying your own certificate files from a trusted CA, copy them to /etc/ssl/private/. Then edit the site file with the below command, and make the following changes to the existing lines. Otherwise go to step 5.

nano /etc/apache2/sites-available/subversion.bhap04.conf

Edit the lines to point to your supplied certificate files.

SSLCertificateFile /etc/ssl/private/filename-cert.pem
SSLCertificateKeyFile /etc/ssl/private/filename-key.pem
SSLCertificateChainFile /etc/ssl/private/filename-cachain.pem

5. Run command a2ensite subversion.bhap04.conf to enable the new site file.


6. Restart Apache to enable the site.


7. Open a web browser on a separate PC, and go to http://subversion.bhap04/svn/myproject and https://subversion.bhap04/svn/myproject

You should see the project folder with Revision 0 as below.


You are now done.


1. You can disallow HTTP and require SSL by adding the line SSLRequireSSL to the /etc/apache2/mods_available_dav_svn.conf file.

2. Subversion supports other protocols besides HTTP and HTTPS. Do not use any of these other protocols because the ownership of the files will not be www-data user through these other methods.

Free Microsoft eBooks


Today I received a notification from the System Administrators Guild of Australia (SAGE-AU) forum that Microsoft was releasing a large number of their Microsoft Press Books for free, and I thought I would share this with the wider community.

Microsoft’s Director or Partner Experience, Eric Ligman, has posted links to a large number of free eBooks and resources for Developers and System Administrators.

I encourage everyone to check it out.

Create your own Certificate Authority with TinyCA2 and Debian Squeeze


By running your own certificate authority, you can establish the basis for an enterprise trust infrastructure which will enable you to generate certificates that identify your internal websites, devices and staff. Some of the potential uses of this infrastructure are generating certificates to identify internal websites, staff smart card logins, and providing encrypted network communications.

The easy way to create a CA is to create a single root CA which would sign all your certificates. For an organisation that will issue many certificates, this design is inflexible and poses a security problem.

An organisation of significant size should create a single root CA, and multiple sub CA’s. This allows sub CA management to be delegated to different groups depending on what their use is. It also allows for an entire sub CA certificate to be revoked if you find that it has been misused.


This article is intended to be a basic introduction to setting up a Debian based CA using the GUI tool TinyCA2 and OpenSSL. By no means am I an expert in this area, and the notes below should be taken as a general guide only.

This guide assumes that you have installed Debin and the network is functioning

Server Installation

1. Log into debian

2. TinyCA2 is part of the contrib sources, which need to be enabled. Go to System>Administration>Software Sources



3. Tick on the DFSG-compatible software with Non-Free Dependencies

4. Open up a terminal window and issue the command apt-get install tinyca


Install all required packages as requested by apt.

5. .Create a tinyCA2 shortcut on the desktop by right-clicking on the desktop and selecting “Create Launcher”

6. Set Type to be Application, Name to be TinyCA2, Command is tinyca2



The Root CA

We will now create the first CA in our hierarchy, the root CA. This CA should only be used to sign certificates for sub CA’s.

1. Open TinyCA2 from the desktop shortcut.

2. The first time you start TinyCA2 you are asked to create a new CA. This will be your root CA. Fill in the details as per the screenshot, customising to your environment as you see fit.


Some notes

Name and Data for CA Certificate Common Name should be the same

Password should be random, long and difficult to guess. You will only need this password when creating new sub-CAs.

3. When ready, click OK

4. The CA Configuration window will appear. This screen defines how the CA will operate. At this point some important decisions need to be made.



Select weather this CA is critical or not critical

Change the Netscape Certificate Type to “SSL CA, S/MIME CA, Object Signing CA.”

The two revocation URL fields need to be set. This is the address of a web server where the certificates revocation list is accessible to client PCs. To determine if a certificate is valid, this list will be consulted to check if a certificate has been revoked. This cannot be changed after the creation of the CA so you need to have a location setup now. It is recommended that this be hosted on a server separate to the CA itself.

The two policy URL fields relate to a webpage where people can go to read about the policy of the issuing CA, and any certificate use policy you may have. You can make the actual document later, but you must set the web address now.

5. Click ok to accept settings. After the CA has been created you will be presented with the main TinyCA window, open to your root CA.

The Subordinate CA

Now we will create our first sub-CA. This may be the first of many sub-CA’s you create, depending on your specific requirements.

One annoying thing you will notice with TinyCA2 is that none of the buttons on the toolbar have captions or tooltips. This is annoying, although it is very safe to click each one to see what it is (you can cancel every screen).

1. Make sure you have TinyCA2 open with your root-CA displayed. On the CA Tab, click the “Create a new Sub CA” button, which is the 3rd button from the right.

2. Fill in the details for the sub-CA. The CA Password field is the password of the root CA (Or in the case of multiple sub levels, the password of the parent CA). The second password asked for is a password for this CA, which needs to be different from the root-CA password. This password will be used for signing client certificates.



3. Click Ok when satisfied.

The sub_CA is created and you are returned to the main application window with the Sub-CA opened.

4. Exit TinyCA2.


Export the Root-CA and Sub-CA Certificates

In order for this new CA hierarchy to be of any use, it needs to be trusted by the devices that need to use it’s services. Possibly the best way to achieve this in Microsoft domain networks is by using Group Policy. Where this is not available, the files may be imported manually into web browsers on client PCs.

1. Open TinyCA2. You will be presented with a list of all the CA’s currently in use.

2. Select the root-CA and click ok

3. On the main TinyCA2 window, click the “Export CA Certificate” button, which is the second from the right.

4. Select a location to save the certificate file, and click save.

5. Do the same procedure with the Sub-CA.

6. Transport the certificate files for the Root-CA and the Sub-CA to your windows domain controller.

7. Open the Group Policy Management Console.

8. Make a new group policy object and link it to the appropriate location in your domain.

9. Expand Computer Configuration>Windows Settings>Security Settings>Public Key Policies>Trusted Root Certificate Authorities

10. Right-click in the right hand pane and select import

11. Follow the wizard to import your root-CA certificate, and your sub-CA certificate.

12. Exit Group Policy

13. Once Group Policy refreshes on your client PCs, they will trust your new Certificate Authority infrastructure.


Export and publish the Certificate Revocation List (CRL)

One final step remains before our CA infrastructure is complete. We must export the CRL list and publish it to the web location we specified when we established our CA.

1. Open TinyCA2 and select the root-CA.

2. Click the “Export CRL” button, which is the right most button.

3. Select a location for the file, enter the CA password, and select how long this CRL file is valid for.

4. Transport the CRL file to the webserver that will host the file, and ensure it is accessible from the address that you defined earlier.

5. At this point you may wish to create a webpage that outlines your CA policy and place this on the webserver also.


Useful Links


The world of a penguin blog