A week ago, Microsoft released new versions of the Azure AD (2.0.2.104) and Azure AD Preview modules (2.0.2.105). As usual, no release notes were provided, so I did a quick comparison of the cmdlets available in the new releases, as well as any changed parameters. As the last time I did this exercise was 8 months ago, some of the changes listed below aren’t necessarily that new.
Most importantly, we now have cmdlets that allow us to work with Conditional Access policies and named locations:
- Get-AzureADMSConditionalAccessPolicy – list all CA policies in the tenant
- Get-AzureADMSNamedLocationPolicy – list all named locations
- New-AzureADMSConditionalAccessPolicy – create a new CA policy
- New-AzureADMSNamedLocationPolicy – create a new named location
- Remove-AzureADMSConditionalAccessPolicy – remove CA policies
- Remove-AzureADMSNamedLocationPolicy – remove named locations
- Set-AzureADMSConditionalAccessPolicy – modify existing CA policies
- Set-AzureADMSNamedLocationPolicy – modify named locations
Of course, given how complex a CA policy can be, you’d probably want to continue managing those via the UI. On the other hand, reporting on CA policies in the tenant is easier now, as we don’t have to call the Graph API like we did in our recent article on the subject. If you are feeling adventurous, you can certainly use the Graph API or the new PowerShell cmdlets to create CA policies, although my attempts always resulted in validation error for the Conditions variable, even when copy/pasting the examples from the cmdlet help. There’s probably a reason why the cmdlets are in the Preview module, after all 🙂
Luckily, the named location cmdlets seem to work a bit better, so you can use them to report on or manage the corresponding objects. Those come in two flavors, a “country” named location, where you list specific set of countries, or “IP” named location, where you specify a set of IPs and CIDRs. Interestingly, the cmdlets seem to allow you to designate a “country” named range as trusted, but that looks like a parameter set issue and not something that has an actual effect. In any case, here’s how to play with them:
C:\> Get-AzureADMSNamedLocationPolicy | ? {$_.OdataType -eq "#microsoft.graph.countryNamedLocation"}
C:\> New-AzureADMSNamedLocationPolicy -OdataType "#microsoft.graph.countryNamedLocation" -DisplayName "Test2" -CountriesAndRegions @("IN","AL")
OdataType : #microsoft.graph.countryNamedLocation
Id : 1b4420a7-1df9-43ef-9a8a-462b205822ac
DisplayName : Test2
IpRanges :
IsTrusted :
CountriesAndRegions : {IN, AL}
IncludeUnknownCountriesAndRegions : False
Other cmdlets worth mentioning are the Get/Set-AzureADMSAuthorizationPolicy, which allow us to exert more granular control over end-user consent settings, as detailed in this document. As part of the process, you can also modify the set of permissions, resources or application ids/publishers users can consent to, via the so-called Azure AD permission grant policies and the corresponding *-AzureADMSPermissionGrantPolicy set of cmdlets. Although not all relevant controls seem to be currently exposed in the Azure AD blade, I’d still recommend using the GUI-based approach to handle those. There’s also a bunch of application management cmdlets, which aren’t that new so I’ll skip them.
When it comes to changed parameters, the CompanyName attribute has been exposed for the *-AzureADUser cmdlets, thus they now have the corresponding –CompanyName parameter for setting/removing its value. In addition, the Get-AzureADDirectoryRole now has a –Filter parameter. The Get-AzureADMSGroup cmdlet features a –Select parameter as part of the Azure AD Preview module updates, while *-AzureADMSGroup cmdlets bring support for sensitive labels via the –LabelId parameter. Lastly, the New-AzureADMSInvitation cmdlet has a –ResetRedempton switch, meaning we no longer need to delete/recreate invitations and guest users as troubleshooting steps, at least in some scenarios.