How to administer AzureAD, O365 and Skype for Business using PowerShell and Multi-Factor Authentication

Azure Active DirectoryPreviously, support for MFA in O365/AzureAD/Skype/Sharepoint was limited to Office applications that supported it and browser-based administration of O365/Azure.

This changes with version 1.1 of the Azure AD PowerShell module released earlier this month which provides support for MFA.

 

The steps to enable it are as follows:

  1. Enable MFA on the various tenants ()
  2. Download the latest AzureAD PowerShell modules that provide support for MFA (v 1.1 released 15. August 2016)
  3. Make sure you have the correct mobile phone number, alternate email and/or authenticator app installed (you typically want to have more than one MFA option available)
  4. Enable MFA on the user you want to protect with MFA
  5. Instruct the user to go to https://account.activedirectory.windowsazure.com/profile/ to verify their MFA settings (and SSPR if applicable)

Note: There are still some aspects in the Windows OS that are still not really aware of MFA, particulartly the Domain Join functionality.  If have enabled MFA on the account you’re using for the domain join operation and you receive an erroneous “Incorrect Password” error (i.e. code 0x52e in the NetSetup.log debug log)  during a domain join (and assuming you are actually typing in the correct password) then you may need to revert back to using a separate non-MFA account – at least for the domain join operation.

Default MFA settings:

The Office 365 tenant/resource host (Exchange Online, SharePoint Online and Skype for Business Online) will need to be configured to accept a modern authentication connection.
Here is the per service state of modern authentication by default :

  • Exchange Online – OFF by default.
  • SharePoint Online – ON by default.
  • Skype for Business Online – OFF by default.

Once you have MFA enabled and the new version of the AAD PS module installed you should be able to go through the additional MFA verification steps after logon:MFA

Details:

Azure Active Directory PowerShell with Modern Authentication
http://connect.microsoft.com/site1164/content/content.aspx?ContentID=32016

Download Details: Azure Active Directory Connection
http://connect.microsoft.com/site1164/Downloads/DownloadDetails.aspx?DownloadID=59185

Azure AD PowerShell: Public Preview of support for Azure MFA + new Device Management Commands

Azure AD PowerShell: Public Preview of support for Azure MFA + new Device Management Commands

How to install and configure Azure PowerShell
https://azure.microsoft.com/en-us/documentation/articles/powershell-install-configure/

Skype for Business Online: Enable your tenant for modern authentication
http://social.technet.microsoft.com/wiki/contents/articles/34339.skype-for-business-online-enable-your-tenant-for-modern-authentication.aspx

Exchange Online: How to enable your tenant for modern authentication
http://social.technet.microsoft.com/wiki/contents/articles/32711.exchange-online-how-to-enable-your-tenant-for-modern-authentication.aspx

The sign in experience with Azure Multi-Factor Authentication
https://azure.microsoft.com/en-us/documentation/articles/multi-factor-authentication-end-user-signin/

Remote Desktop Gateway and Azure Multi-Factor Authentication Server using RADIUS
https://azure.microsoft.com/en-us/documentation/articles/multi-factor-authentication-get-started-server-rdg/

What are App Passwords in Azure Multi-Factor Authentication?
https://azure.microsoft.com/en-us/documentation/articles/multi-factor-authentication-end-user-app-passwords/

 

Working simultaneously with multiple user accounts in O365

Mongo

When you have Windows Integrated Authentication (WIA) turned on for the ADFS server and it is included in the Local Intranet site in IE settings you will always get automatically logged on as the currently logged on user regardless of who you attempt to log on as.

 

So let’s say you have an admin account in O365 called Super-Man@Contoso.com that you want to use for administering O365 while your normal login name is Man@Contoso.com.
You open up an in-private browser window for O365 and enter your login name Super-Man@Contoso.com into the browser window – hoping to get redirected to your ADFS server where you would enter your alternative credentials.
The results: you get redirected to your ADFS server and WIA logs you in as the currently logged on user – Man@Contoso.com.
This is just the flipside of SSO – turning this off to cater for the subset of users that want to use multiple accounts in O365 (typically your admin team) will force all your users to enter credentials specifically rather than use SSO from the current logon credentials.
I.e. you can’t have your cake and eat it*
A quick workaround is to create a shortcut on your desktop that launches a browser using RunAs (f.x. if you have adminaccounts prefixed with Super-):
C:\Windows\System32\runas.exe /user:%userdomain%\Super-%username% “%ProgramFiles%\Internet Explorer\iexplore.exe”

*unless you buy two cakes

Tracing Issued Claims in ADFS

Quick & Dirty scripting tools – the following Powershell script will dump the last X minutes of issued claims on an ADFS server (Assuming Auditing of Issued Claims has been turned on in the AD FS Management MMC).
$timeView=-5
if($Args.count -gt 0) {$timeView=$args[0]}
$StartTime = (Get-Date).AddMinutes($timeView)
$output=Get-WinEvent -FilterHashtable @{
LogName = “Security”;
StartTime = $StartTime;
ID = 501}
$output |fl
“Total issued claims:$($output.Count)  $($timeView) minute view”