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 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


Azure Active Directory PowerShell with Modern Authentication

Download Details: Azure Active Directory Connection

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

Skype for Business Online: Enable your tenant for modern authentication

Exchange Online: How to enable your tenant for modern authentication

The sign in experience with Azure Multi-Factor Authentication

Remote Desktop Gateway and Azure Multi-Factor Authentication Server using RADIUS

What are App Passwords in Azure Multi-Factor Authentication?


Office 365: Using Lync or Skype on Linux

Ubuntu-LogoDebian logoRedHat-logoFreeBSD Logo

When you have a *nix crowd to cater for in your Office 365 or Lync deployment the following information will be useful:

– You can use the SIPE plugin to enable your *nix users to chat on O365 or Lync servers with several IM products, f.x. Pidgin

– There’s a client-side bug in pidgin-sipe v. 1.18.2 where it used the user’s SIP address entered as the login address being presented to the ADFS server regardless of what was entered into the console

– This was fixed upstream in v 1.18.4

– This bug is invisible when the user has the same UPN and SIP address

– On the AD FS server side a possible workaround would be to allow extended attribute lookup during logon (f.x. use the ‘mail’ attribute if it matches the SIP address)

Note: The Alternate Login ID feature is not compatible with Exchange Online Hybrid Deployments.
Customers that wish to configure Exchange Online Hybrid Deployments with Office 365 must not configure Alternate Login ID.

The Alternate Login ID feature may impact various other Azure AD and Office 365 scenarios including:

  • Office 365 ProPlus activation may require explicit sign-in
  • InTune customers using SCCM connectors may require additional configuration.

Further details:

Configuring Alternate Login ID [for AD FS 3.0]

Pidgin IM

The SIPE project

The Missing Lync

How present are you?

Office applications that integrate with IM applications and generate a presence accomplish this by contacting the IM application that is listed as the default as per the corresponding registry key (DefaultIMApp).
This is frequently populated with the name of the last IM application that was installed on the machine.

In some cases the IM application even monitors the registry key and overrides any changes made to the default IM application by other IM applications (shades of IE/Firefox/Chrome default browser ping-pong).

From the perspective of the IM application this may sound like a perfectly logical idea as it is making sure it is the default. If you are trying to either integrate several different IM applications on the same workstation or you want to select a specific application yourself to be the default for any presence information in Sharepoint, Outlook, etc. then it becomes a real headache when one application insists on setting itself as the default regardless of your wishes.

The net effect will be that only the default IM application will count as a valid Presence for the user, if the user isn’t active in that application then the user doesn’t generate any presence in Sharepoint or Office.


  • the user will be signed in to one IM application on the workstation (f.x. Lync 2013 or Skype for Business)
  • another IM application has overwritten the HKCU\Software\IM Providers\DefaultIMApp registry key (f.x. Jabber or Communicator 2007)
  • that IM application isn’t currently active on the workstationEnd result: The user doesn’t generate a presence even if he or she is active on the Lync or Skype application


HKCU\Software\IM Providers\DefaultIMApp

This key specifies the IM application Office integrates with when it starts up



How Office integrates with an IM client application

When an Office 2013 application starts, it goes through the following process to integrate with the default IM client application:

  1. It checks the registry to discover the default IM client application and then connects to it.
  2. It authenticates with the IM client application.
  3. It connects to specific interfaces that are exposed by the IM client application.
  4. It determines the capabilities of the currently signed-in user (local user), including getting the user’s contacts, determining the user’s presence, and determining the user’s IM capabilities (instant messaging, video chat, VOIP, and so on).
  5. It gets presence information for the local user’s contacts.
  6. When the IM client application shuts down, the Office 2013 application silently disconnects.


Further reading: