Freigeben über

MFA Support for Windows Azure Active Directory PowerShell Module

  • Artikel

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:

https://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

 

This post has been moved here: https://paulwu108883359.wordpress.com/2018/10/03/mfa-support-for-windows-azure-active-directory-powershell-module/

[bing_translator]

Comments

  • Anonymous
    October 11, 2015
    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

  • Anonymous
    October 11, 2015
    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.

  • Anonymous
    October 29, 2015
    The comment has been removed

  • Anonymous
    November 29, 2015
    Hello, is there a target date for the release of this functionality beyond the preview stage?

  • Anonymous
    December 07, 2015
    The comment has been removed

  • Anonymous
    January 10, 2016
    The comment has been removed

  • Anonymous
    February 01, 2016
    Will all the Exchange commands work from this remote power shell  like Get mailbox identity, ect Looking for reply.

  • Anonymous
    February 02, 2016
    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.

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

  • Anonymous
    February 02, 2016
    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.

  • Anonymous
    February 19, 2016
    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

  • Anonymous
    February 19, 2016
    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