How to recover from a Digital Life Disaster (Part I)

This is part 1 of a 3 part blog, where I share my thoughts on being in control of your Digital Life (Identity, Data and Security) and how to recover when any of them are lost. The 3 parts are broken into:

  • Being Aware (Of your Digital Life)

  • Being Prepared (for Disaster)

  • Identify, Resolve & Rebuild

By the end of the 3 parts I hope to help people understand how to secure their Digital Life. Making a 'Digital Life Disaster Recovery Plan' is probably not high on anyone's to-do list, but I would stress that it is crucial to consider and get on top of in this day and age.

Digital Life Disaster what?

What is a 'Digital Life Disaster'? It is first of all, it is a term that I've coined that encompasses 'Loss of access to a digital account' which may be any of the below scenarios:

  • Loss of access to Digital Account(s) and/or Digital Identity [such as Email Account or Social Media Account]

  • Loss of access to Telephony Account(s) [such as Mobile Number]

  • Loss of access to Digital Device[s] [Such as Smartphone or Computer]

These scenarios are devastating and can occur at anytime, anywhere and anyone. As the digital age has now surrounded us in how we interact with society, it leaves us vulnerable to attackers 24/7/365. This article will explain why and how we can be more mindful when it comes to our digital lives.

I like to think of anything we care about is something worth securing.

In our physical lives, our homes, where we live; are located at an Address, and a Key is needed to access the Door. Inside this home are our valuables, belongings and our identity. We guard our Homes and only give the key to those we trust, the same principles could be applied for your car, workplace and should also be applied to our digital lives.

Before the digital age...

We guarded the money in our Bank Accounts by keeping Bank Cards (A metaphorical Address) in our wallets, the PIN numbers (Keys) were stored in our heads and you could only access the money via Tellers or ATMs (Doors). If you found out that your Bank Card was missing from your wallet, you would call your bank to lock the cards from being used until a new one arrived. Or you found your card in the last place you left it, your pocket! (Phew! It was only a false alarm). If you needed to get a new card or PIN, you would need to call the bank or visit a local branch during business hours, perform some ID verification tests and only then would a new card would be sent to your home address on file.

Now in the digital age, anyone who knows your Bank Account access number (Address) and password (Key) may access this from anywhere in the world from your Bank's website (Door). They could mask their locations using VPNs to pretend they're from your country, use Phishing Sites or Keyloggers to silently steal valuable information from you or even Social Engineer you or your friends and family if they find out who you are through Social Media!

First you'll tell me that you would never fall for any of those tricks and that there's even more security challenges for all your accounts, in addition to Password Challenges. There are things such as SMS Auth, Mobile Phone Auth, RSA Token Auth , 2FA Mobile Apps, USB/FIDO Keys (If you know what this is, don't bother reading anymore, I'm preaching to the choir!) to name a few popular ones. I personally call these Digital Keys as they provide you access to your Digital doors!

Well, what I say to all those additional challenges of authentication is that they're only secure as the process to recover them!

Some food for thought...

What happens if I lose access to that challenge? What steps are needed to recover it?

What steps are required for someone else to steal/recover it?

A Hacker's Digital 'Red Paper Clip' Story

There's a famous true-story about a man bartering & trading his way up to a house using a Red Paper Clip; in a way, exploiting digital security can be similar. You start by finding out a little bit about someone's information starting only with a little bit of info and work your way up to taking over their identity.

A question I like to ask myself is:

"How easy is it for someone to get into an Email Account?"

But before I ask that, why would they want an Email Account? An Email Account is the starting point of a Digital Identity, it provides many of us a place to receive communications but also is the Unique User Identifier (Your Address) for other websites (Doors) to perform banking, social media, store data and is can be considered a key to your mobile smartphone.

To help paint a scenario.. Lets say you visited 'InsecureTechHelp.net' 5 years ago for some Crowd-sourced IT help. It turned out that the owner of InsecureTechHelp didn't update their website, and some hackers got access to a database of 10,000 email address and passwords which includes yours, great!

The email you used is the same email you use til this day, but the password is some throwaway password you don't care about.. there's no way an attacker could gain access your email account... Wrong!

  1. An Attacker uses your email to find your social networking pages (Facebook, Twitter, Instagram etc)

  2. They work out your friends, family, colleagues and personal information

From here they could:

  • Find out your contact details from your Public Digital Identity

  • Create a fake social media account, add your friends and find out more about you through 'Friends of Friends'

  • Create a fraud LinkedIn account as a recruiter to offer you a 'dream role' extracting further info from your Resume and/or CV even get your phone number through a 'phone interview'

If they some how got the following crucial 4 pieces of information: Full Name, Date of Birth, Home Address & Mobile Phone Number, they could get control over your Mobile Phone Number.

Many telecom providers offer the ability to 're-burn' your Phone Number to a new SIM Card if a caller can validate some simple information; if the attacker knows your network they could call up the network and using same basic challenges, take control of your phone number and use this to elevate access to other accounts.

From here it's all down-hill, they could reset the password to your Email Address so easily using your phone number if you had SMS Auth or Mobile Phone Auth as your additional challenge.

Now what's the likelihood of this occurring? I would honestly say unlikely, if you were slightly aware of security at any stages throughout your digital lifetime you could have implemented something that increases your digital security. But the internet is relentless, there are attackers and robots constantly looking for vulnerabilities whether you like it or not, the best thing is to be protected in the first place.

But what's not to say that the attacker is going to be some foreign person preying on you. Whats preventing someone you know (friend, family or colleague) from taking advantage of knowing your details? Not much, just malicious intent and some IT knowledge that can be found on Google!

Now what about the likelihood of your losing your Digital Keys? Below are some common scenarios:

  • 'You lost your mobile phone'

  • 'You forgot the password to your _____ account'

How would you get gain back access to these accounts if something went horribly wrong? Whether you lose your 'keys' to a foreign hacker or because you forgot it you still need to go through the steps to recover it, these are all similar to if you were to lose a wallet. It's a process that is more arduous more than the cost of the item lost itself.

Where do I start?

You can start by 'being aware'. Being aware does not require one to understand how 'The internet' works or how SSL cryptography will protect us [although it does help].

What it does require is to understand some principles on to be mindful on the internet and our digital places...

  • You DO have something to hide, your privacy is part of your identity, you can be in control of what the internet knows. Security is the key to keeping things private.

  • Anything you put on the internet lives forever, (publicly or privately) whether its your date of birth or some pictures; all it takes for data to live forever is a simple Ctrl+C, Ctrl+V.

  • Don't Trust Anyone, Check what you're opening, who you're talking to, where you're submitting information to... then only then trust that they can keep a secret...

  • Even Organisations! If any organisation you entrust your data to fails their security, YOU will be the person that pays the price! Do you really need to provide them your real information?

  • Anything can fail, the question is what is the likelihood and just how do you get back up to start living you life?

Reality Check

"Ok Tim, so what I've learned is that on the Internet: the floor is lava, everyone is out to get me and I can't have fun". No, I get it, paranoia is not healthy, but what IS healthy is practicing safe internet usage whilst still having fun, being responsible for the data you put out there and putting some thought into what you do.

Look out for Part II which will contain 'Being Prepared', it will look into security vs convenience, how to walk that balance in life and how to deal with the inevitable.

Certificate Based Authentication to Exchange Online using MobileIron Cloud Local CA

This article will briefly walk-through on how to enable Certificate Based Authentication (CBA) to Exchange Online using MobileIron Cloud's Internal Local CA capabilities for automated, streamlined authentication when using iOS's Native Mail App.

Microsoft enabled the functionality for CBA to Exchange Online sometime in 2016, although it has a narrow use case; it's a solution worth having a look if your MDM and AAD set-up is similar since it reduces the on-boarding friction and monthly / quarterly password updates.

MobileIron Cloud is a suitable candidate for this solution; this is because MobileIron Cloud's Local CA capabilities fit the requirements of Azure AD's CA CRL requirements; as the CRL is publicly accessible. This makes it convenient to deploy this solution for iOS end users when using iOS's Native Mail Client.

This walk-through will not cover the MobileIron configurations of Exchange Profile or Identity Certificate.

Usage in Production Notes

This is not recommended for a Production Solution as the CA and auth relies on MI Cloud's uptime. Should MI Cloud be down for maintenance, access to emails may be impacted.

Prerequisites:

  • MobileIron Cloud with Local CA configured

  • Azure AD enabled and Federated to ADFS 2.0+

  • Basic Authentication is enabled for Exchange Online

  • iOS Native Mail Client as primary Mail Client

Setting the Trusted Cert Authority on Azure AD

  • Log into MobileIron Cloud Admin Console

  • Navigate to Admin > Infrastructure > Certificate Authority

  • Download your MobileIron Certificate and take note of the MobileIron CRL URL to a local location to be used in future (I saved mine to a Windows machine as my Mac couldn't run all the Azure AD Powershell commands)

MobileIron Cloud as a Certificate Authority Feature

MobileIron Cloud as a Certificate Authority Feature

Open up Powershell, connected to Azure AD using a Global Administrator Account, run the following commands replacing the MobileIron Certificate Location and MobileIron CRL URL with your corresponding values.

# Connect to Azure AD
Connect-AzureAD

# Extract the Encoding Information into $cert
$cert=Get-Content -Encoding byte "C:\Users\Administrator\Desktop\cert.cer"

# Set the CA Certificate Type
$new_ca=New-Object -TypeName Microsoft.Open.AzureAD.Model.CertificateAuthorityInformation
$new_ca.AuthorityType=0
$new_ca.TrustedCertificate=$cert

# Set the CA CRL URL
$new_ca.crlDistributionPoint="http://ap2.mobileiron.com/c/ca/12345/MI%20Cloud%20-%20Local%20CA.crl"

# Command to Set the CA using the above $references
New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_ca

Testing the CA was uploaded successfully

Run the following PowerShell command to confirm that your Azure AD tenant has a trusted Root CA info set.

Get-AzureADTrustedCertificateAuthority

ADFS Changes

Enabling ADFS Certificate Authentication

  1. Edit the ADFS Authentication Methods for 'Certificate Authentication' under Extranet, set this value to Enabled.

  2. Make sure that Network Port 49443 is available externally to your ADFS & WAP Server. Devices will use Port 49443 when performing Cert-Based Auth to the WAP / ADFS server.

'Certificate Authentication' enabled in Extranet Auth Methods in ADFS Management

'Certificate Authentication' enabled in Extranet Auth Methods in ADFS Management

ADFS Transform & Issuance Rules

Log into your ADFS Server and via the AD FS Management tool, edit the following Claim Rules for your Active Directory from Claims Provider Trusts and Claim Issuance Policies for the Relying Party Trusts.

These are necessary to allow ADFS to revoke Certificates.

Add these Custom Rules as Send Claims Using a Custom Rule, you will be required to add them separately via the Add Transform Claim Rule Wizard. (Give them friendly names to easily identify them in future)

c:[Type == " http://schemas.microsoft.com/ws/2008/06/identity/claims/serialnumber"] => issue(claim = c);

c:[Type == " http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer"] => issue(claim = c);

The following Claims are to be added to the Office 365 (Microsoft Office 365 Identity Platform Worldwide) Relying Party Trusts as Custom Claim Issuance Policies (Also give them friendly names to easily identify them in future)

c:[Type == " http://schemas.microsoft.com/ws/2008/06/identity/claims/serialnumber"] => issue(claim = c);

c:[Type == " http://schemas.microsoft.com/2012/12/certificatecontext/field/issuer"] => issue(claim = c);

Example of the ADFS Cert Claim Issuer Custom Rule

Example of the ADFS Cert Claim Issuer Custom Rule

Configuration of Device Profiles on MI Cloud

On MobileIron Cloud, configure an Identity Certificate profile that deploys the User Principal Name or the RFC822 Name Value of the Subject Alternative Name Field.

A Certificate Profile was already configured in MobileIron Cloud that had the following SAN values:

Screen capture from MobileIron Cloud Identity Certificate Settings

Screen capture from MobileIron Cloud Identity Certificate Settings

The Native Mail Exchange Profile had the following notable settings

Exchange URL: outlook.office365.com

Username / Email Address: ${userEmailAddress}

Identity Certificate: <The Certificate Profile from above>

Enable OAuth for Exchange Payload: False

Screen capture from MobileIron Cloud Exchange Settings

Screen capture from MobileIron Cloud Exchange Settings

Deployment to the device is straight forward, the profile should deploy to the device containing the Certificate, Exchange configurations.

The device should have no prompts for passwords or errors.

Considerations

Here are some notable additional configurations that may need to be taken into account:

  • MobileIron Access: If you have MI Access enabled, play around and configure a pass-through value for Exchange / Baseline authentications

  • Basic Authentication vs Modern Authentication: If Basic Auth can be enabled, you will need to disable it in multiple locations; Azure AD, MI Cloud Exchange Configuration and MI Access's Access Policies

External Resources

The following vendor resources were helpful to get this enabled:

ADFS Onload.js - ADFS Automation of Identity Provider Selection based on Device Type

Microsoft's Active Directory Federation Services (ADFS) is a great solution that has been implemented throughout many organisations that utilise Microsoft's Active Directory. The product is built into the existing Microsoft Server deployments as an add-on and is quite flexible when it comes to customisation when being compared to newer platforms such as Azure Active Directory.

Whilst this information may be considered obsolete as many of these organisations move from on-premise to cloud-based identity providers (e.g. Azure AD or OKTA) the usage of additional claims providers allows administrators to specify the authentication methods on an per-application, per-domain or even per-device-type basis.

After working with the VMware Identity Manager product, ADFS was still the primary IdP for many. This article post will walk through how forward certain device types to an additional non-ADFS claims provider thanks to changes in ADFS from ADFS version 3.0 onwards.

ADFS 3.0 introduced the ability for administrators to customise the javascript that's used by all devices & users when hitting the Home Realm Discovery screen. This is really useful since ADFS does not have the finetuning capability for contextual selection via the standard ADFS settings.

Below are some example Javascript inputs that an administrator can put into their 'Onload.js' script to automate selection of Identity Provider based on Device OS / Device Type.

Before you start with the below, check out Microsoft's detailed article on 'Advanced Customization of AD FS Sign In Pages'

Automatically select Active Directory for Desktop Devices but still display Claims Provider selection for Mobile Devices:

// Automatically select Active Directory for Desktop Devices

if (navigator.userAgent.match(/Windows NT|Macintosh|Linux/i) != null) { HRD.selection('AD Authority')};

Automatically select Additional Claims Provider for Mobile Devices but still display Claims Provider selection for Desktop Devices:

// Automatically select Additional Claims Provider for Mobile Devices

if (navigator.userAgent.match(/iPad|iPhone|Android|Windows Phone/i) != null) { HRD.selection('https://claimsprovider.com/replacethisurl.xml')};

Automatically select 3rd Party Claims Provider for Mobile Devices and Active Directory for Desktop Devices:

// Automatically select Additional Claims Provider for Mobile Devices and Active Directory for Desktop Devices

if (navigator.userAgent.match(/iPad|iPhone|Android|Windows Phone/i) != null) { HRD.selection('https://claimsprovider.com/replacethisurl.xml')}; else {HRD.selection('AD AUTHORITY')};

Hope this code comes in handy for any VMware Identity Manager or ADFS administrators out there!

Updates to this code can be found via my github