Hardware Tokens for Office 365 and Azure AD Services Without Azure AD P1 Licences

Posted on 2 CommentsPosted in Azure Active Directory, Azure AD, AzureAD, MFA, multi-factor auth, Multi-Factor Authentication, token2

A recent update to Azure AD Premium 1 (P1) licence has been the use of hardware tokens for multi-factor authentication (MFA). This is excellent news if your MFA deployment is stuck because users cannot use phones on the shop floor or work environment or they do not want to use personal devices for work activities. But it requires a P1 licence for each user. Now a P1 licence gives lots of stuff in addition to hardware token support for MFA, such as (but not exclusively) Conditional Access, which is a better way to implement MFA than when used without P1, which requires MFA in all circumstances and for all apps from all locations.

But if you want MFA in all circumstances and for all apps from all locations, and also need hardware tokens, this is where programable tokens come into play. I recently purchased a miniOTP-2 token from Token 2 (www.token2.com) and they provided me with a C300 token as well so that I could write this blog post.

In the scenario that I am going to describe here, I have two different programable tokens and I will walk through the MFA registration process for a user (using the new user interface for this service that was released end of Feb 2019).

IMG_20190226_095155

Enabling the new MFA Registration Process

Open the Azure AD Portal from https://aad.portal.azure.com, click Azure Active Directory from the primary menu and then select User settings from the sub-menu. Under Access panel, click Manage settings for access panel preview features. You will see the following:

image

In this I have previously turned on the preview features for registering and managing security info that was rollout out early 2018 and now I can see a second option for the same, but called refresh.

Set both of these options to All (or a selected group if you want to preview for a subset of users initially). Click Save.

For what follows, it will work even if you have None set for both options, just the screenshots will look different and the latest refresh of this feature is much easier for users to work with – so I recommend it is turned on for both options.

Configure MFA Settings for your Tenant

In the Azure AD portal sub-menu click MFA under Manage MFA Server and click Additional cloud-based MFA settings under Configure. This opens another tab in your browser where you will see the Multi-Factor Authentication / Service Settings.

Under Verification Options ensure that Verification code from mobile app or hardware token is enabled. Other options such as “app passwords”, “skip for federated users”, “trusted IPs” (available if you ever once had the AAD P1 licence on your tenant even if you do not have it now) and “remember multi-factor authentication” can be set to your requirements.

Register a Programable MFA Token for a User

Once you have MFA settings configured you can enable the service for a user and have the token registered for the user. If you have a P1 licence you upload the token serial number to Azure AD, but if you do not have a P1 licence then you need to use a programable token as these appear to act just like authenticator apps you get on your phone.

In Azure AD you can register a user’s token by logging in as the user (they would do this for you) by visiting https://aka.ms/mfasetup. End to end this process takes about 10 seconds – so its very possible to add this process into new user joining procedures or have help desk visit the user or the other way around. This process needs an NFC burner app and device (Android phone is good), but don’t require the user to do this themselves using their phone – burn the token for them using a help desk PC or phone. If you get the end user to walk through all these steps you will confuse them totally!

The new UI for end user security settings:

image

As mentioned above, the UI you see is based upon the User settings options in Azure AD. If you have just the original refresh enabled, you will see the following instead:

image

In the first of the above two screenshots I have already registered some MFA devices. If the user has never registered a device before then they will see the following when browsing to https://aka.ms/mfasetup from the initial login and then the MFA registration page, with the registration process ready to start:

image image

If you have already registered some security info, then you will be able to add a hardware token from the + Add Method button and selecting Authenticator App and clicking Next.

image

The initial steps will show you the following dialog, depending upon if you are a new user (on the left) or adding a new MFA method (on the right):

image image

You are walked through the process of installing the Microsoft Authenticator app on your phone. In this case though, we have a hardware token instead of the app, and so you need to click I want to use a different authenticator app instead. The Microsoft Authenticator App supports push notifications, which hardware tokens do not, and so the QR code provided for the Microsoft Authenticator app will not work for hardware or other authenticator apps.

image image (QR code intentionally blurred)

Now you need to scan the QR code using the Token 2 Android app or click Can’t scan image and copy and paste the secret key into the Token 2 Windows app. Links to the apps are available from the Token 2 website software page (with the Windows app shown below):

image

Click the QR button (or Scan QR button if using the NFC Burner 2 software) and scan the QR code on the screen. This enters the seed in HEX into the app. If you need to enter the QR code by hand, click enter Base32 and type in the secret key value that you get under the Can’t scan image link.

Next, turn the hardware token on (it will remain on for 30 seconds) and hold it to the NFC reader on your Android device (usually next to the camera) or plugged into your PC.

IMG_20190302_160227

Click the Connect button (or Connect Token depending upon the app you are using) – one of the Android apps are shown below:

Screenshot_20190302-173645

Then finally click burn seed.

Screenshot_20190302-173653

Turn off the token and turn it back on again – this displays the next valid code. The code that was displayed when the token was first turned on and before the new secret was burned to the device is not valid.

Click Next on the registration wizard on the computer screen. You are asked to enter the code displayed on the token. Azure AD has a 900 second range for codes, so any code displayed in the last 7 or so minutes should be valid to use

image

Success – if not, turn the token off and on again and try again. If not, go back, scan the code again and burn to the device another time – you are not restricted on the number of times you do this (though doing this wipes previous users of the token from using it again).

image

Click Done and see your first method of providing MFA shown to the user.

image

I recommend you add the users phone (for a call or text) as a second method at this point (in case they loose the token, they have a second route in). The user experience for when adding a phone looks as follows:

image

It is a shame we cannot rename the MFA method – that would be useful, as we could indicate the token name/type and then login to Azure AD could ask for this token by name.

If you were adding a new token to a user with existing MFA methods already in place, you end up in a very similar place:

image

Success – a new “app” added:

image

Then at next login when going to the MFA registration page, you need to enter your code:

image

Note that you don’t need the code yet for logging into Office 365 and Azure AD generally – you have to enable MFA for that and that is the next step.

Enforcing MFA for User

For all other logins apart from the MFA registration page, you need to finish by enforcing MFA for the user. If you have a P1 licence and Conditional Access then this will happen based on the rules, but where you don’t have AAD P1 licence, then you need to enforce MFA for all logins. Do this by browsing to the multi-factor authentication and users page via the Office 365 admin portal > active users > ellipses button > setup multifactor authentication:

Search for your user:

image

Once you have found the user to enable, select the user and then click the Enable hyperlink:

image

Followed by enable multi-factor authentication

image

The comment about “regularly sign in through the browser” is not valid for modern authentication supporting apps such as Microsoft Teams or where you have enabled Modern Authentication for Skype for Business Online and Exchange Online (you need to do this if your tenant exists from before August 2017)

image

Finally for completion, there is an MFA setting called Enforce. Enforce requires MFA for all logins including rich client applications that do not support MFA – therefore if you have modern authentication enabled and are using Outlook 2013 (with the Modern Auth settings for Outlook 2013 turned on) or Outlook 2016 and later then having the end user remain in Enable mode is fine. If you are using older clients that do not support MFA then Enforce mode will force them to use App Passwords for non-browser apps, and you want to try and avoid that.

Therefore we need to take the user to a minimum of Enable mode in Office 365 MFA so that MFA is triggered for all logins. This step is probably done after hardware token registration as when we set up the token for the user or when we sent the user through the registration workflow we did not first enabling MFA for the user – therefore the user is registered for MFA but not required to use it to login.

Set the user to Enable mode to trigger MFA for all logins:

image

Azure MFA 503 Error When Authenticating

Posted on Leave a commentPosted in Azure, Azure Active Directory, MFA, Multi-Factor Authentication, Office 365

If you have installed version 7 of Azure MFA Server on-premises (7.0.0.9 or 7.0.2.1 at the time of writing) and have enabled IIS authentication with Forms Based authentication and the Native App, but when you need to authenticate you are presented with a 503 DLL error. The reason for this is that version 7 removed support for 32 bit Windows, but if the application pool in IIS for the website you are running is a 32 bit pool then the 64 bit DLL provided by MFA for authentication will not run. If you change the pool to 64 bit then the MFA authentication DLL will work, and your phone call/text or mobile app verification should occur. Of course, if you change the application pool to 64bit make sure that other DLLs used by the application are not 32 bit and so the application itself, rather than MFA, would not fail.

If the application is 32 bit and therefore the application pool needs to be using 32bit MFA DLL’s then you either need to upgrade your application to 64 bit or downgrade MFA Server to version 6.3. To obtain version 6.3 you need to raise a support call with Microsoft.

Upgrading Azure Multi-Factor Authentication Server

Posted on Leave a commentPosted in Azure, Azure Active Directory, MFA, Multi-Factor Authentication, Office 365

A new version of Azure MFA Server was released at the end of March 2016, version 7.0.0.9. This provides an in place upgrade to the previous version 6.3.1.1. This version is based on .NET 4.5 and not .NET 2.0, which is the big change in the product, along with new end user functionality in the ADFS Adapter. Note the upgrading the ADFS Adapter piece is prone to issues, which I have documented here.

This blog post just outlines the standard upgrade process. It takes about 10 minutes and the service is uninstalled and reinstalled, but leaves the database and settings in place – so it requires downtime or a load balancer. If you have more than one MFA server in a cluster then the older versions still running 6.3.1.1 will still work for users but the administration screens are read only once at least one server is upgraded. All servers should therefore be upgraded in a short interval.

Before upgrading, take a copy of the “Program Files\Multi-Factor Authentication Server” folder as a backup is useful, especially if you have the ADFS Adapter installed as the service name has changed and that breaks ADFS Server.

Then, the following are just the sequence of screenshots from the installation (upgrade) so you know what to expect:

The old version has a 2013 splashscreen:

image

The MFA admin page points out that a new version is available:

image

Ensure you have the May 2014 Cumulative Update on your Windows Server 2012 R2 boxes (you ought to regardless of this prompt):

image

Visual C++ (x86 and x64) versions will be installed:

image

image

image

image

image

image

Then there follows a long pause of a good few minutes. Hang in there, the old software is still in place and running. The new installer will start shortly:

image

image

And complete in less time than you waited for the installation to start:

image

The service restarts and this machine is now running the 7.0… version

If you start the admin console you will see that it is copyright 2016:

image

You will also get prompts about upgrading any of the installed components. If you look in Programs and Features at this time you will see that there might be some components still on version 6.3.1:

image

 

You will also see that the admin portal is running mixed versions:

image

If you open the admin console on another node, you will be warned about the mixed versions:

image

As long as you upgrade all the components one after the other you should get no issues, so I don’t recommend an order for these components to be installed in, but I do not recommend leaving them not upgraded:

image

image

I also recommend installing the required components in advance, as that is quicker. For an upgrade you need to install ASP.NET45 under IIS Application Development in Server Manager. You will return here at the end to uninstall .NET 2/3.5 if appropriate.

image

When it comes to upgrading though, I do recommend you upgrade on component and then the next. Don’t start them all at once – though you will be prompted all at once to do this. So pick one, click Yes and wait for that to complete. It will take a few minutes for each installer to start, so be patient:

image

Note that the installer does not suggest the correct Application Pool for each component. So make sure you select the correct one each time.

image

image

image

Then move onto the next installer. If you closed the Yes/No prompt for each installer you can reach it via that area of the admin console:

image

Remember to set the Application Pool correctly as well:

image

Like the User Portal installer, there is not much to see so close the installer when finished. Ensure you are running the latest .NET updates as well though:

image

I have documented the ADFS Adapter upgrade on this post, as there are specific issues with it.

If once you have upgraded all the previously installed components, you visit Programs and Features you can see that the Mobile App is not upgraded. The mobile app is not installed via the admin console, so the console will not prompt about the install. To install the Mobile App run MultiFactorAuthenticationMobileAppWebServiceSetup64.msi from C:\Program Files\Multi-Factor Authentication Server. You will need to start this installer from an administrative cmd prompt:

image

Again, change the Application Pool to the correct value for the application. It will show the Virtual Directory as well here, and unlike this example, this is recommended to be something easy to type on a mobile device. Upgrading the app does not recall the previous virtual directory name, and so you should ensure that you enter that here as well. If you upgrade it and do not change the Virtual Directory name then you need to uninstall it and reinstall it, but remember to copy the upgraded web.config from the virtual directory first. It contains the username and password of the SDK user account.

image

Upon completion of all nodes in the MFA cluster, the admin portal shows all versions the same:

image

Finally, note that though you may pick the Application Pools during the various installers, new pools with new names (starting ASP.NET v4.0) are created but not used. The old app pools are upgraded to .NET 4.0 and I recommend removing the unused pools at your convenience as both the unused and used pools are the same apart from in name:

image image

image

Installing Azure Multi-Factor Authentication and ADFS

Posted on 14 CommentsPosted in Azure, MFA, multi-factor auth, Multi-Factor Authentication, Office 365

I have a requirement to ensure that Office 365 users external to the network of one of my clients need a second factor of authentication when accessing Office 365 resources from outside the corporate network. The free Multi-Factor Authentication (MFA) feature of Office 365 will not distinguish between network location so we need to enable MFA on ADFS (or Federated) authentication for external connections. External connections are those that come through a WAP server to the ADFS server and not those that come to ADFS directly.

To set this up, first install ADFS on Windows Server 2012 R2 and install additional ADFS servers and load balancers as required. Install the WAP servers in your DMZ and connect them to the on-premises ADFS server(s). Once this is all up and running enable MFA in Azure. You will need to create an MFA instance for billing purposes. Once this is created you can download the MFA software to the ADFS Server. For this blog we are using MFA Server version 7, released April 2016. This version does not need .NET 2.0 installed and works with .NET 4.0

On the ADFS Server run the MFA installer and follow the prompts. Make sure you have the Dec 2014 Cumulative Update or later (preferable the latest) installed. Accept the prompts for the two Visual C++ Runtime installations and complete the installation.

Following installation the wizard runs to configure MFA and MFA replication. I suggest making a group (called ADFS) and not using the default and setting up replication. The email address and password is obtainable from the MFA download page and is valid for 10 minutes.

Once installed start the MFA software and go to the AD FS page. Install the AD FS connector by pressing the button. On the primary ADFS server you then need to enable ADFS/MFA integration by running in PowerShell .\Register-MultiFactorAuthenticationAdfsAdapter.ps1. You can find this in Program Files\Multi-Factor Authentication Server. This is not needed on secondary servers.

Repeat the MFA install on all ADFS servers and install the MFA connector.

To allow users to set their own phone number and MFA settings install the SDK, User Portal and Mobile App features. These are detailed below:

User Portal

This requires that you install IIS/Web Server role on the server. In the role services for IIS include the HTTP Redirection feature, the ASP.NET 4.5 feature (under Application Development) and IIS 6 Metabase Compatibility (under IIS 6 Management Compatibility). Other role services are added because of these options.

Accept the prompts to create the users. You will be taken to a page about virtual directories. I tend to select the defaults here, apart from the app pool, which I set the the one that matches the name of the feature I am installing. I use HTTP Redirect feature to redirect the user from the root directory to HTTPS://fqdn/MultiFactorAuth.

image

Once the User Portal is installed I set the relevant options in the MFA admin program such as the User Portal URL and the auth methods allowed. If you are going to install the Mobile App feature then allow users to use this option.

If you are configuring HTTP Redirection then set this on the root directory of the default website now. Redirect only the root directory to HTTPS://fqdn/MultiFactorAuth

image

Make sure you turn HTTP Redirect off on all subdirectories and virtual directories of the application will not be reachable. Also check that HTTPS is bound to a certificate in IIS and to the website.

SDK

To install the SDK go to the Web Service SDK node in MFA on each ADFS server and click the Install Web Service SDK button. This requires Basic Authentication enabled in IIS. This is not a default role service, so you will need to add it to the server at this time.

Install the SDK and select the defaults:

image

If you have HTTP Redirection enabled, check it is disabled for the virtual directory as it won’t be by default.

Mobile App

To use the Azure Authenticator app to sign in to ADFS (as a second factor of authentication) you need to enable the Mobile App and have the URL reachable from the internet. The URL can be published through the WAP servers as these are available to you. To publish the MFA mobile app through WAP you can use the following cmdlet (changing the URL and certificate thumbprint as required):

Add-WebApplicationProxyApplication -BackendServerUrl ‘https://auth.domain.co.uk/mfaApp/’ -ExternalCertificateThumbprint ‘xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’ -ExternalUrl ‘https://auth.domain.co.uk/mfaApp/’ -Name ‘Multi-Factor Authentication’ -ExternalPreAuthentication PassThrough -ClientCertificateAuthenticationBindingMode None -BackendServerCertificateValidation None -InactiveTransactionsTimeoutSec 300 -ClientCertificatePreauthenticationThumbprint ”

The mobile app needs to be installed on each ADFS server. Do this by opening a command prompt as admin and browse to the installation folder of the MFA server (C:\Program Files\Multi-Factor Authentication Server). Then run MultiFactorAuthenticationMobileAppWebServiceSetup64.msi

image

Change the Virtual Directory to something short, as users might need to enter this on their phone. I use mfaApp for this. Install and when finished If you have HTTP Redirection enabled, check it is disabled for the virtual directory as it won’t be by default.

Open this folder in admin cmd prompt (C:\inetpub\wwwroot\mfaApp in my case) and edit web.config. Modify the following two keys as follows:

<add key=”WEB_SERVICE_SDK_AUTHENTICATION_USERNAME” value=”” />
<add key=”WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD” value=”” />

The username and password here needs to be a member of the PhoneFactor Admins group in Active Directory.

Then locate <setting name=”pfpaws_pfwssdk_PfWsSdk” serializeAs=”String”> and change the Value string that follows from http://localhost:4898/PfWsSdk.asmx to https://fqdn/MultiFactorAuthWebServiceSdk/PfWsSdk.asmx.

Finally enter the MFA App URL in the Mobile App section of the MFA admin program – this setting needs to be done once, as it will replicate to the other servers.

Restart the servers and you are ready to go.

ADFS Adapter Issues With Upgrading MFA 6.3.1 to Version 7

Posted on 2 CommentsPosted in ADFS, ADFS Connector, MFA, Multi-Factor Authentication, Office 365

Upgrading the ADFS Adapter is not straight forward, though the readme notes for the upgrade make no mention of issues!

To upgrade MFA Server 6.3.1 to 7 (so you can remove .NET 2 as a requirement, as that goes out of support soon) then you need to download the MFA installer to each MFA server and run the installation. Once the installation is complete and you restart the MFA admin application you are prompted about the upgrade for the User Portal, the SDK and you need to update the Mobile App software. You are also required to update the ADFS Adapter – which is great, as the ADFS Adapter has new features in version 7.

But this bit is broken. The ADFS Adapter name has changed and so when you restart the ADFS Server you get the following four errors in the AD FS Admin Event Log:

An error occurred loading an authentication provider. Fix configuration errors using PowerShell cmdlets and restart the Federation Service.
Identifier: WindowsAzureMultiFactorAuthentication
Context: Passive protocol pipeline

Additional Data
Exception details:
The external authentication method pfadfs.AuthenticationAdapter, MultiFactorAuthAdfsAdapter, Version=6.3.0.17452, Culture=neutral, PublicKeyToken=31bf3856ad364e35 could not be loaded. Could not load file or assembly ‘MultiFactorAuthAdfsAdapter, Version=6.3.0.17452, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.

and

An error occurred loading an authentication provider. Fix configuration errors using PowerShell cmdlets and restart the Federation Service.
Identifier: WindowsAzureMultiFactorAuthentication
Context: Passive protocol TLS pipeline

Additional Data
Exception details:
The external authentication method pfadfs.AuthenticationAdapter, MultiFactorAuthAdfsAdapter, Version=6.3.0.17452, Culture=neutral, PublicKeyToken=31bf3856ad364e35 could not be loaded. Could not load file or assembly ‘MultiFactorAuthAdfsAdapter, Version=6.3.0.17452, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.

and

An error occurred loading an authentication provider. Fix configuration errors using PowerShell cmdlets and restart the Federation Service.
Identifier: WindowsAzureMultiFactorAuthentication
Context: Proxy TLS pipeline

Additional Data
Exception details:
The external authentication method pfadfs.AuthenticationAdapter, MultiFactorAuthAdfsAdapter, Version=6.3.0.17452, Culture=neutral, PublicKeyToken=31bf3856ad364e35 could not be loaded. Could not load file or assembly ‘MultiFactorAuthAdfsAdapter, Version=6.3.0.17452, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.

and

An error occurred loading an authentication provider. Fix configuration errors using PowerShell cmdlets and restart the Federation Service.
Identifier: WindowsAzureMultiFactorAuthentication
Context: Proxy device TLS pipeline

Additional Data
Exception details:
The external authentication method pfadfs.AuthenticationAdapter, MultiFactorAuthAdfsAdapter, Version=6.3.0.17452, Culture=neutral, PublicKeyToken=31bf3856ad364e35 could not be loaded. Could not load file or assembly ‘MultiFactorAuthAdfsAdapter, Version=6.3.0.17452, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ or one of its dependencies. The system cannot find the file specified.

Each of these errors have Event ID 105 and the Event Source is AD FS.

To fix these errors you need to unregister the MFA ADFS Adapter by its old name. The cmdlet for doing this is Unregister-AdfsAuthenticationProvider -Name WindowsAzureMultiFactorAuthentication. This is run from an admin PowerShell instance on the primary ADFS Server. The MFA documentation says that you can use .\Register-MultiFactorAuthenticationAdfsAdapter.ps1 and .\Unregister-MultiFactorAuthenticationAdfsAdapter.ps1 to add and remove the adapter from ADFS, but as the adapter name has changed if you use the MFA provided scripts it will only unregister/register the new version of the adapter and leave the old in place.

As you can see from the screenshot below, the ADFS Adapter appears as the Azure Multi-Factor Authentication Server, but it used to be called the Windows Azure Multi-Factor Authentication Provider and so this is the source of the upgrade issue. The upgrade replaces the old named adapter with the new named adapter and does not remove the old named adapter in ADFS’s database!

image

Once User Portal, Adapter, MFA App and SDK are upgraded you can uninstall .NET 2 from your Windows Server 2012 R2 MFA boxes

Office 365 MDM (Mobile Device Management) From A Users Perspective

Posted on 4 CommentsPosted in ADFS, ADFS 2.0, ADFS 3.0, IAmMEC, MDM, Mobile Device Management, Multi-Factor Authentication, OD4B, ODFB, Office 365, OneDrive, OneDrive For Business, OWA for Devices

The following list of steps and screenshots are taken during the enrolment process to add an iPhone and an Android phone to Office 365 once the free MDM solution that comes with Office 365 is enabled for the user.

Step Details Image from iPhone Image from Android

1.

Once your IT Administrator enables MDM for your Office 365 account you will get the following email on your device if you already have email configured. It may take 24 hours from the admin configuring MDM for this to arrive. Once this email arrives no further email will arrive from that account any device until the devices are enrolled with the company for management.

01 Initial Email Screenshot_2015-06-29-10-55-47

2.

Click “Enrol your device” link in Step 1 of the email. This will take you to the relevant app store of your device to install the Company Portal (iPhone as shown and Android devices). Windows Phone users will see the Workplace Join settings (not shown)
In the iOS example, the Company Portal app is already installed so we can click Open at the top.

For Android to the right, it shows that the app needs installing from the page they see in the App Store.

02 Clicking Enroll Screenshot_2015-06-29-10-56-20
3. Once the app is installed you are required to login. Enter your Office 365 username.
Upon entering your username you will either be directed to your network to login (if your company uses AD FS to login) or you enter the password here. Step 4 shows the AD FS login page, which will probably have your company logo on it.
If your IT department does not use AD FS you enter your password here (the page will wait for you to enter it)
03 Login Page Screenshot_2015-06-29-10-58-51
4. This is an example AD FS login page with company logo. If you are required to login with other information as well as your password you will be prompted for this as well.

04 ADFS Login Page  
5. Upon login being successful your device will start the enrolment process by connecting to both Office 365 and the device manufacturer to download required secure management info. 05 Enrolling Screenshot_2015-06-29-11-00-07
6. For iOS click Enroll to start the process. For Android you need to click Activate.

The company you are enrolling your phone into will have some rights over some of the data on your phone – for example they will be able to remove the work email account from it if you leave the company.

Enrolment conditions will be enforced based on your companies requirement for using phones to access company data, for example a PIN number of a minimum length (see http://bit.ly/o365mdm for more on this)

06 Notice About Enrolling Screenshot_2015-06-29-11-00-55
7. Enrolment goes through a series of steps with the screen changing a few times automatically. Within a seconds you end up at the “Install” screen. Click Install to add the management profile for the displayed company here.

Android and Windows Phone have less steps to go through.

07 Certificate 1 Screenshot_2015-06-29-11-03-50
8. A unique encryption key is generated for your device when using iOS devices.

For Android, you need to accept the compliance requirements configured by your administrator. If you do not complete these requirements then business applications will not be available on the device.

08 Key Generation 1 Screenshot_2015-06-29-11-20-47
9. You need to click install at the personal settings screen when using iOS devices.

For Android, once compliance requirements are set (in this case a PIN number is entered). Note that for iOS, you have 1 hour to enter a PIN number to become compliant, but not for the Android.

09 Warning Screenshot_2015-06-29-11-22-49
10. You need to confirm that you trust this company for remote management of your device when using iOS devices.

For Android you need to name and install the certificate.

10 Install Trust Screenshot_2015-06-29-11-23-05
11. The management profile is installed and you can click Done when using iOS devices. 11 Profile Installed  
12. Device checks that it is enrolled and what the device settings are and if these settings are compatible with the companies required restrictions on the device.

On Android you may get a prompt about entering a PIN number or other compliance requirements if you did not enter them earlier

12 Checking  
13. Enrolment is confirmed. Notice that my device(s) are displayed and my current device is not compliant with company policy (the red exclamation mark).

For Android devices, the My Devices tab will show your devices, including if there are any compliance issues.

13 Enrolled  
14. Clicking my device in the Company Portal app shows the compliance status of the device. Here the device is still checking compliance 14 Checking Compliance 1st Time  
15 And here the device is shown not to be compliant.

For Android devices not in compliance, it shows an Enrollment update available (if you did not meet compliance requirements during the Company App enrollment process) or if you are not compliance (for example device is not encrypted) then it will show that the device is not in compliance as shown.

15 Not In Compliance Screenshot_2015-06-29-11-36-13
16 Details on compliance state is iOS shows the “This device is not in compliance” message.

Further details on the compliance failure are shown under the message. In this case the iOS device is unable to set up an email profile on the device and the Android devices need a longer password and device encryption

16 Not In Compliance Details Screenshot_2015-06-29-11-36-27
17 Clicking the “Unable to set up email on the device” message shows the full details. In this case the device already has an email profile configured and for the iPhone this needs to be removed and the Company Portal will recreate it. It is this recreated email profile that the iPhone/iPad can manage.

Android and Windows Phone users do not need to delete their email profile and have the device recreate it but Compliance requirements must still be met.

17 Actual Reason for not in compliance Screenshot_2015-06-29-11-37-47
18 For the iPhone/iPad the steps to delete the existing profile are Settings > Mail, Contacts, Calendars > Click the email profile > click Delete Account

For Android, if the device is compliant in the Company App then you need to check Exchange Server to validate this for you so that your email continues to work. Back in the email program view the enrollment email as shown – click hyperlink #2 in the email and sign into the web based Device portal

18 Deleting original email profile Screenshot_2015-06-29-11-57-54
19 Once the account is deleted on the iOS device it is not visible in the list of email accounts.

In this example the iCloud account remains along with two Exchange / Office 365 accounts that are not managed by MDM. You can only have one MDM managed account per device at any given time.

Other compliance settings may be required such as a PIN number. You have 60 minutes in iOS to enable this if required.

19 Seeing list of email profiles - work email is gone  
20 Once the Company App checks for compliance again and if you are compliant, a new email profile for your work appears. Clicking it (called “Office 365 email”) requires entry of your password.

In Android, once the device is shown as compliant in #2 of the email, click the hyperlink for #3 in the email. Click Allow on the certificate prompt if you see one.

20 Work Email Profile Arrives Screenshot_2015-06-29-12-00-26
21 You then see the email profile created. Compare this to the image in Step 19 for the difference.

An Android, you will be informed that your device has successfully authenticated for email.

21 Email Configured Automatically Screenshot_2015-06-29-12-00-40
22 It is possible to rename the email profile. In this case it is via Settings > Email, Contacts, Calendars > Office 365 email > Account and then change the “Description” value 22 Renaming Email Profile  
23 Updated email profile listed 23 Email Profile listed  
24 Email should now sync with your device again. Notice that the email about needing to set up MDM is now missing and has been removed automatically.

On the Android, drag the Inbox screen down to refresh it and your emails will appear.

24 Email available on device, enrollment email not available now Screenshot_2015-06-29-12-01-57
25 Now that the device is compliant (excepting the PIN number, which gives you 60 minutes of grace to complete this step) you can start other Office 365 aware applications. Here we are going to sign into OneDrive and show our OneDrive for Business data 25 Other Apps Screenshot_2015-06-29-12-03-12
26 Your app requires a login 26 Login for other apps Screenshot_2015-06-29-12-03-58
27 Which if you have an AD FS additional login you may also see 27 ADFS Login  
28 Your other app is now working, and in the case of OneDrive for Business did not need configuring 28 Other App Also Working  

How To Change Your Office 365 App Password

Posted on 11 CommentsPosted in ADFS, app password, Azure, IAmMEC, MFA, multi-factor auth, Multi-Factor Authentication, Office 365

If you are enabled for Multi-Factor Authentication (MFA) in Office 365 then you will need an App Password for some applications that do not support MFA. The user interface for creating a new App Password is well hidden in Office 365 (its not on the Password page for example).

Post updated in 2016 to take account of the changes in the Office 365 portal.

Post updated in 2017 to show that Microsoft have added a short URL to reach this page. You can skip the below and go to http://aka.ms/CreateAppPassword

Post updated in Aug 2018 to take consideration of the new SSPR and MFA converged UI. If you have this turned on then App Password changes are as described at https://docs.microsoft.com/en-gb/azure/active-directory/user-help/security-info-app-passwords. If you have not enabled this yet (late 2018 it will probably become the default regardless) then the above link will work for you.

Here is how to find it now:

  1. The user logs into Office 365 portal (http://portal.office.com) and clicks their photo to the top-right of the page
  2. Click My Account
  3. Click Security and Privacy menu to the left or the Manage Security and Privacy link on the main area of the page
  4. Click Additional Security Verification
  5. Click Create and manage app passwords
  6. This takes you to https://account.activedirectory.windowsazure.com/AppPasswords.aspx. You can (and therefore should) bookmark this page now so you don’t need these instructions again!
  7. Create yourself an additional app password and give it a description.
  8. Use the new app password in the program that you need to login to.

Here is how to find it (in the old Office 365 portal)

  1. The user logs into Office 365 portal (http://portal.office.com) and clicks the cog icon to the top-right of the page
  2. Click Office 365 Settings
  3. Scroll down past Password and choose Additional Security Verification
  4. Click Update my phone numbers used for account security
  5. Answer your phone to approve your request to go to this page (you might not be asked for this)
  6. Click “app passwords” on the top menu. This takes you to https://account.activedirectory.windowsazure.com/AppPasswords.aspx. You can (and therefore should) bookmark this page now so you don’t need these instructions again!
  7. Create yourself an additional app password and give it a description.
  8. Use the new app password in the program that you need to login to.