September 25 2012

Defining multifactor authentication

I was recently having a discussion about the definition of multifactor authentication and what actually constitutes one, two or three factor authentication.  There seems to be confusion around these definitions, so I am posting some industry accepted definitions for all to see or reference.  Authentication methodologies involve three basic “factors”:

  1. Something the user knows (eg. password, personal identification number, personally identifiable information)
  2. Something the user has (eg. smartcard, security token, telephone, signed digital certificate)
  3. Something the user is (eg. fingerprint, voice, retinal pattern, DNA)


According to the Federal Financial Institutions Examination Council’s Authentication in an Internet Banking Environment, August 15, 2006, two-factor authentication (aka multifactor authentication) is described as:


“By definition true multifactor authentication requires the use of solutions from two or more of the three categories of factors. Using multiple solutions from the same category would not constitute multifactor authentication.”


Therefore, two factor (aka multifactor) authentication is a combination of any two of these factors. For example – a fingerprint scan and a password is two factor authentication; a password and a signed computer digital certificate is two factor authentication.  However if you use a password, a signed computer digital certificate, a PIN and a number generated from your RSA SecurID token then you are still using two factor authentication as the identifiers only come from two of the three categories listed above.

There is a great article here ( which discusses this in detail, and it is also worth checking out the PCI Security Standard Council Quick Reference Guide, especially section 8.3 (, FFIEC’s Authenitcation Guidance whitepaper ( and Australia’s DSD security advice article (



September 17 2012

VMWare ESX support for Windows Server 2012

I found it quite hard to find this information so I figured I would share it. I was looking for an official line from VMWare on the versions of ESX that would Windows Server 2012 as a guest operating system.

Directly quoted from :

The release of vSphere 5.1 introduces support for Windows Server 2012 on ESXi 5.1, with the following support considerations:

  • Installation instruction can be found here
  • Snapshots, checkpoints and VMotion actions for virtual machines with Windows 8 or Windows Server 2012 are incompatible between hosts running ESXi 5.0 Update 1 or ESXi 5.0 P03 with host running later versions of ESXi ( ESXi 5.0 Update 2, ESXi 5.1, etc.). Please refer to KB-2033723 for more information.
  • The Guest OS Customization feature in vCenter does not support Windows 8 or Windows Server 2012 in vSphere 5.1.
  • vSphere client will use EFI BIOS for VMs configured for Windows 8 or Windows Server 2012 with hardware version 9, however, EFI BIOS is not compatible with the Fault Tolerance feature. Therefore to use Fault Tolerance feature, it is recommended to use Legacy BIOS instead of EFI BIOS.

For more information about software support, please check the VMware Compatibility Guide

Also from  I have extracted this one liner:

Windows 8 / Windows Server 2012 will not be supported on ESXi/ESX 4.0 or 4.1.

And finally, from (page 103) I read that supported releases are ESXi 5.1 or ESXi 5.0 U1.

More information:

Category: Windows | LEAVE A COMMENT
September 6 2012

Application Approval Workflow Solution Accelerator

Straight from the TechNet website ( – Application Approval Workflow (AAW) takes an application request submitted through the System Center 2012 Configuration Manager Application Catalog and transforms it into a System Center 2012 – Service Manager service request, allowing flexible approval lists and activities.

In my scenario I was interested in having a different approvers for different applications when users were requesting applications through the SCCM Application Catalog (Self Service portal).  It was not sufficient to have SCCM Administrators as application approvers, sometimes we needed department manager to be the approver, sometimes the line manager and sometimes the application owner.  After implementing SCCM, SCSM and SCORC, here are a few of the things I learnt along the way when implementing the AAW Solution Accelerator (mostly for self reference later on!):

  • Even after installing AAW you still don’t have any workflow templates – there are 3 sample ones here ( – line manager approval, department manager approval and multistep approval process. Like a lot of Service Manager administration, you need to use PowerShell to import these (Import-SCSMManagementPack cmdlet);
  • The account used in the SCSM Orchestrator connector needs to be a member of the OrchestratorUsersGroup  group;
  • The account used in the Orchestrator Integration Packs configuration needs to be a member of the OrchestratorSystemGroup group;
  • At one stage I was getting ‘The object ‘Get Extended Application Information’ in the Runbook ‘CM-> SM Synchronization’ failed’ error in SCORC, this seemed to be happening because SCORC was installed on the same server as SCCM, I moved SCORC to a different server and the error did not reappear. I believe this is something to with having SCORC on the SCCM primary server as the Orchestrator Integration Packs configuration would not let me use credential to set up the connection to SCCM as it considered this a ‘local’ connection;
  • ‘Selection Criteria’ needs to be created through SCSM to associate the workflow template with the application or user – this then needs to be put into ‘production’ status;
  • Upon first attempt to access the SCSM Self Service portal, ‘Access Denied’ error is shown. Solution is here –;
  • You will come across this issue if you are using the default which is to use a self signed certificate – I needed to create a new certificate, ensure the issuing CA was trusted on the client and update the webconfig file – and

Maybe this well assist someone else along the way….