Today I’m happy to share the news with you that we’ve released a Public Preview of Azure AD’s PowerShell Module with support for Azure MFA. This enables admins to turn on MFA while still getting the efficiency benefits of PowerShell Scripting! In addition, we’ve added a new set of PowerShell commands that let you manage devices in Azure AD.
To give you the low down on these new capabilities, I’ve asked Shawn Tabrizi, one of PM leading the work in this area to write up a quick blog post. You’ll find it below.
I hope you’ll find these enhancements useful and as always, we’d love to receive any feedback and suggestions you have.
Alex Simons (Twitter: @Alex_A_Simons)
Director of Program Management
Microsoft Identity Division
I’m Shawn Tabrizi from the Identity team at Microsoft. Today I’m happy to announce the public preview of modern authentication and device management with the Azure Active Directory PowerShell Module. Modern authentication uses the Active Directory Authentication Library (ADAL) to bring a better sign-in experience for the user, with more advance authentication options like Multi-Factor Authentication (MFA). Now when managing your Office 365 services or Azure Active Directory Tenant, you can expect the same secure sign-in experience you currently have with your other Office 365 products. In addition to these authentication changes, we have bundled a new set of cmdlets that allow you to manage your devices in AAD, something that was only previously possible through the Graph API. PowerShell and the Graph API are the only supported public interfaces for programmatic access to AAD, and it is great to know that they now both support modern authentication and device management.
Figure 1: Modern Authentication for Azure Active Directory PowerShell
One of our goals for this public preview is to enable administrators who have accounts protected with MFA to authenticate and use AAD PowerShell, while minimizing the number of changes to the existing cmdlets. You should notice no differences when using the new PowerShell module after you have authenticated, but we have made a few changes to the initial Connect-MSOLService cmdlet:
- We have added a new parameter: Connect-MSOLService –AccessToken where you can sign in to AAD PowerShell by providing an AAD Access Token that you have acquired elsewhere.
- We have removed the Connect-MSOLService –CurrentCredentials parameter.
Let’s walk through a basic Administrative scenario using the new AAD PowerShell Module, which will highlight how it works.
Let’s try it out!
I own a small company called Contoso, and I am looking to expand and hire a few new employees. Adam is my current user administrator who has MFA enabled for his account.
Adam downloads and installs this public preview of the Azure Active Directory PowerShell Module so he can begin to create the new user accounts. He signs in using:
Adam submits his organizational account credentials, and is prompted to enter a verification code that is sent to him via text message:
Now he’s authenticated! Using the commands Adam is already familiar with, he is able to query the existing set of users in the tenant:
He notices that he needs to create a user account for our new hire, Jamie. Again, using the commands he is familiar with he is able to do this:
New-MsolUser -UserPrincipalName JWarner@contosomfa.onmicrosoft.com -DisplayName “Jamie Warner” -FirstName “Jamie” -LastName “Warner”
From this point, Adam can assign Jamie a new license, put her in a different directory role, and more! Anything that the old PowerShell module was capable of, Adam can also do in the new one. Existing scripts that Adam created will continue to work with minimal modification, and all with an MFA protected administrative account.
Along with the updates to how the Azure Active Directory PowerShell module authenticates, you will also find a new suite of cmdlets that allow you to manage the devices registered in your directory. Previously, if you wanted to manage your AAD registered devices, you had to do so through the Graph API. Now you are able to do this through the AAD PowerShell Module, alongside your other administrative tasks. You will find the following new commands:
You can use the ‘help’ command to get more details on how to fully harness these new cmdlets, and we will show a brief example of how to use these below.
Let’s try it out!
Contoso practices the Bring Your Own Device (BYOD) program, where we allow our employees to register their own devices for use at work. One of our employees, Greg, recently lost his laptop that was registered with his account in the directory. We want to make sure that we disable this device until he can find it again.
First thing we do is query all the devices that Greg owns:
Get-MsolDevice –RegisteredOwnerUpn GMonet@contosomfa.onmicrosoft.com
Based on the Device Name, and other information returned by the cmdlet, we can identify which device is the one we are looking to disable. In this case, it is the first device returned with DeviceId = a7892334-730b-4d49-bd13-54c2a4928009
To disable this device, we simply run the disable cmdlet targeting this specific Device Id:
Disable-MsolDevice –DeviceId a7892334-730b-4d49-bd13-54c2a4928009
Once we confirm our actions, the device is disabled. You can see that now the device has Enabled = False
If Greg ends up finding his laptop, we can always enable this device using the enable cmdlet:
Enable-MsolDevice -DeviceId a7892334-730b-4d49-bd13-54c2a4928009
Which will change the device back to Enabled = True
If not, we can remove the device to make sure it does not affect Greg’s device quota:
Remove-MsolDevice -DeviceId a7892334-730b-4d49-bd13-54c2a4928009
You can see that I can no longer find this device in our directory once we delete it.
To install the public preview, you will first need to uninstall any previous version of the AAD PowerShell Module. For the purposes of this preview, we are only supplying a 64-bit version of the module, and we are looking for your feedback to understand the demand for a 32-bit build. In addition, we are looking for you to provide any feedback about specific issues you encounter when using the module, or various authentication and device management scenarios we may have missed here. You should reach out to us via email at AADPowerShellPreview@microsoft.com, and if it is about an error please include:
- The steps to reproduce the error
The log files found here:
We are excited to bring you these highly requested features, and are looking to provide many more updates to AAD PowerShell in the coming future. So what are you waiting for? Check out the program page, download the new bits, and try it!
Note: Avoid needing to install File Transfer Manager by clicking on the “Download” hyperlinks on the right hand side of the table.
I hope you’ll find these new capabilities useful!
Shawn Tabrizi (Twitter: @Deturbanator)
Microsoft Identity Division