MFA Support for Windows Azure Active Directory PowerShell Module


Administering O365 is quite easy using the O365 Portal. However, power users may prefer the flexibility of script based management via PowerShell. The “Windows Azure Active Directory Module for Windows PowerShell” (WAADMfWP) provides such capability. With just a few lines of code, the power user can provision millions of accounts and modify O365 resources with no user interaction.

As one famous comic book character once said: “with great power comes great responsibility”. It is important to secure such power and adding Multi-Factor Authentication (MFA) is a good way to add an additional layer of protection.

Enabling MFA for Azure Active Directory (and O365 by extension) is quite easy for web based access. This is because Azure MFA uses HTTP redirection to control the authentication flow and the Web browser understands HTTP redirection nativily.

MFA support for the current version of WAADMfWP is not possible because the current WAADMfWP uses the “Microsoft Online Services Sign-In Assistant” to handle credential authentication.

This sign-In assistant only works with non-MFA enabled identities because it is not designed to understand the HTTP redirection associated with a MFA enabled authentication flow.

The good news is that there is a new version of WAADMfWP in public preview. This new WAADMfWP uses ADAL based authentication UI which is able to follow HTTP redirection. Because of this, the new module will work with MFA enabled identities.

 

Before installing the new WAADMfWP, you must do the following:

1)   Uninstall the old WAADMfWP if you have one installed. The old one is 4.88 mb in size

2)   Uninstall the Microsoft Online Services Sign-In Assistant

Download the preview version from here:

http://connect.microsoft.com/site1164/Downloads/DownloadDetails.aspx?DownloadID=59185

Once you have it installed, you must be aware of the following before starting:

With the old WAADMfWP, you can use Connect-MsolService with or without the –Credential parameter. If you do not supply the Credential parameter, you’ll be prompted with a UI to
enter the credential.

The new WAADMfWP works slightly different in that if you want it to support MFA, you’ll need to call Connect-MsolService without the -Credential parameter.

The new WAADMfWP module uses ADAL to prompt the user credential with a browser based UI.

If the user account is in a domain that is federated, the user is redirected to the federated STS

 

In this example, the STS is an ADFS server. The user enters the password

ADFS validates the password and determines whether the user needs step-up authentication. In this case, we've configured Azure MFA server as an MFA provider and this user satisfies an ADFS rule to require MFA. The user clicks [Continue] to initiates the configured MFA option

In this example, this users is configured to have the MFA server send a One Time Passcode (OTP). The user must enter the OTP to authenticate.

If the user fails to provide the correct OTP, the user will receive the appropriate error message from ADFS (customizable) and the Connect-MsolService command will fail

If the user enters the correct OTP, the control is returned back to the WAADMfWP and a valid session now exists.

The Credential parameter is still supported but works only for non MFA enabled identities.

A new AccessToken parameter is added to the Connect-MsolService cmdlet. I'll cover this in a future post if there is enough interests.

The new WAADMfWP also adds other new cmdlets:

  • Get-MsolDevice
  • Enable-MsolDevice
  • Disable-MsolDevice
  • Remove-MsolDevice

 

Note that this new WAADMfWP will not work with tenants in China.

Enjoy

[bing_translator]

Comments (12)

  1. Neil G. says:

    Awesome that this is happening.

    Question #1 Will the workflow only with ADFS federation but not with pure WAAD MFA accounts the are azure or office 365 only accounts?

    Question #2: Will this work with the new Azure AD B2B preview so that my azure AD account run PowerShell against my customer services? (will connect-msolservice have a -tenant or -subscription parameter)

    Thanks

  2. Neil,

    Regarding Question #1: the short answer is yes – it will work with both federated and cloud Org IDs. The long answer is the preview version now uses ADAL based Modern Authentication which means your SSO experience will behave the same as browser based SSO – the same as if you point your browser to http://portal.office.com or http://portal.azure.com .

    For Question #2 – it doesn't support -tenant or -subscription parameter and I'll look into how it support B2B scenarios.

  3. Sreenivasa Pilla says:

    If I need to implement an automation PS scripts, then MFA enabled accounts doesn't work as it waits for a manual input of the OTP (One Time Password). Is there any work around to automate the execution of the  PS scripts for Azure subscriptions which are MFA enabled without manually entering OTP?

    Thanks.

  4. Eric Iversen says:

    Hello, is there a target date for the release of this functionality beyond the preview stage?

  5. Simon M says:

    Hi,

    Great that this is being supported.

    Newbie question if I may: how do I get to connect to O365 Exchange after using the new MFA Connect-MsolService command mentioned above?  Usually, the sequence might look something like this:

    $UserCredential = Get-Credential

    $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri outlook.office365.com/powershell-liveid -Credential $UserCredential -Authentication Basic -AllowRedirection

    Import-PSSession $Session

    but I cannot find a way of tweaking this that works with the new Connect-MsolService.  Changing Get-Credential for Connect-MsolService doesn't work.  I have tried various edits on the $session = … line too, but to no avail.

    Can someone point me in the right direction on how to complete creating a new O365 Exchange session with MFA enabled?

    Many thanks, Simon.

  6. Aaron C Lawrence says:

    I've tried this, with my Microsoft account I use for administering Azure.

    Although login appears to be successful (takes me to the Microsoft sign on page, no authentication error), a different set of errors appears immediately.

    Is this expected?

    Connect-MsolService : An unexpected error occurred.

    At line:1 char:1

    + Connect-MsolService

    + ~~~~~~~~~~~~~~~~~~~

       + CategoryInfo          : OperationStopped: (:) [Connect-MsolService], Mic   rosoftOnlineException

       + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.InvalidHeaderException,Microsoft.Online.Administration.Automation.ConnectMsolService

    Connect-MsolService : Exception of type

    'Microsoft.Online.Administration.Automation.MicrosoftOnlineException' was thrown.

    At line:1 char:1

    + Connect-MsolService

    + ~~~~~~~~~~~~~~~~~~~

       + CategoryInfo          : OperationStopped: (:) [Connect-MsolService], MicrosoftOnlineException

       + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.MicrosoftOnlineException,Microsoft.Online.Administration.Automation.ConnectMsolService

  7. Ankit Verma says:

    Will all the Exchange commands work from this remote power shell  like Get mailbox identity, ect

    Looking for reply.

  8. Simon & Ankit,

    Exchange commands are invoked with a PSSession to EXO which normally takes a credential from the Get-Credential command. Get-Credential currently does not support ADAL based sign in flow. The alternative is to use certificate based AuthN to create the session.

  9. Aaron,

    You should use an Organizational ID. Besides, you'll find the external Identities cannot be enabled for MFA in the MFA admin screen.

  10. Sreenivasa.

    Connect-MsolService now has a -AccessToken parameter. You'll have to programmatically obtain a valid access token. You can use the ADAL library to help with that.

  11. Andy Herbert says:

    Paul – If I understand your reply to Aaron correctly, there's currently no way for an Azure Subscription Administrator, Co-Administrator and/or Domain Global Admin to administer Azure Active Directory via PowerShell?  If I've understood that correctly, could you confirm that the only way in which this can be done is via a Domain-specific user which we have to create by hand in the old Azure Portal?

    Thanks in advance,

     Andy

  12. Andy,

    That comment was meant for administering Azure Active Directory. For Azure PowerShell, see this link:

    stackoverflow.com/…/how-to-use-microsoft-not-organizational-account-with-add-azureaccount

Skip to main content