admin adventure

the ongoing struggle: man vs machine

Category Archives: Security

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

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