Office 365 is a constantly evolving suite of services and as such, it’s not uncommon for the developers to change their mind on particular feature implementation and revamp it. One such example are the controls for Office 365 Group creation, which were initially released as part of the OWA mailbox policy settings. Since Office 365 Groups span across multiple workloads, it didn’t make sense for the creation to be controlled by Exchange-specific functionality, so Microsoft moved the relevant controls to Azure AD instead. Since then, other settings related to different object types have made the same journey and in this article we will cover some more recent additions.
To get started, here’s a reminder on how we can work with the Azure AD directory settings and templates. They are managed only via PowerShell, more specifically if you want to get a list of all the settings templates you can use the Get-AzureADDirectorySettingTemplate cmdlet, which is part of the Azure AD Preview module. If you are a fan of the old MSOnline module, you can use the Get-MsolAllSettingTemplate cmdlet instead. Here’s a list of all the currently supported templates:
Get-AzureADDirectorySettingTemplate | ft @{n="DisplayName";e={$_.DisplayName};width=20},@{n="Values";e={$_.Values.Name -join ","};width=90},@{n="Description";e={$_.Description.Split(".")[1] -replace '(^\s+|\s+$)','' -replace '\s+',' '};width=70} -Wrap
where I have played a bit with the output in order to fit the template description and all the values in the PowerShell console. As you can see from the above, there are currently 7 such templates available. The first two, “Group.Unified” and “Group.Unified.Guest” are the ones controlling the different Office 365 Group settings, which you might already be familiar with. In case they are new to you, check out the official documentation.
Probably the most interesting new template is the “Password Rule Settings”, which corresponds to the recently introduced Azure AD Password Protection and Smart Lockout features. This template includes the following settings:
- LockoutThreshold, designating the number of failed password attempts that will trigger the initial lockout. This setting accepts integer values, the default one being 10.
- LockoutDurationInSeconds specifies the duration (in seconds) for which any account that has failed to provide the correct password for the above specified number of times will be locked out. This setting is also an integer valued, and the default duration is 60, or one minute.
- EnableBannedPasswordCheck determines whether Azure AD will compare the passwords against a tenant-specific list of banned values. This is a Boolean-valued setting and the default value is True.
- If the above setting is configured, BannedPasswordList specifies the list of passwords which are not allowed for the given tenant. You can specify the banned passwords in a tab-delimited string.
- The EnableBannedPasswordCheckOnPremises controls whether the banned password check is turned on or not for on-premises system. This is enforced via an agent, installed on one or more servers in the local AD (learn more here). The default value here is True.
- Lastly, the BannedPasswordCheckOnPremisesMode setting specifies the method used to perform the check for password validity. This is a string-valued setting and the two allowed values are Audit and Enforce, with the former being the default one.
As you can see from the below screenshot, those settings closely match the controls we have available in the Azure AD blade, under the Authentication methods -> Password protection tab:
Since the Azure AD settings templates are in general not the easiest feature to work with, I’d recommend using the Azure AD blade when you want to make changes to the password protection policy instead.
Moving on, the next two setting templates, namely “Prohibited Names Settings” and “Prohibited Names Restricted Settings”, cover restrictions you can configure for Azure AD applications. More specifically, you can configure allowed and blocked values for the application display name, as well as validate the name against a list of known trademarked values. As the two templates are closely related, we will cover their settings together. Here’s the list:
- CustomBlockedSubStringsList specifies substrings that are not allowed in an application display names, in a comma-delimited list. Here substring means that the match will be performed as a wildcard, and the corresponding substring will be matched in any part of the display name.
- Contrary, the CustomBlockedWholeWordsList list whole words (as in space-delimited strings) that are not allowed in the application display name. This is also a comma-delimited string-valued setting.
- Similarly, we have the option to configure allowed substrings via the CustomAllowedSubStringsList setting. Again via a comma-delimited list.
- CustomAllowedWholeWordsList on the other hand can be used to whitelist specific words.
- Lastly, the DoNotValidateAgainstTrademark setting controls whether the application display name will be checked against the global list of known trademarked names. This is a Boolean-valued setting and the default value is False.
The “Application” template is used to control tenant-wide application behavior, as the name suggests. This template has a single setting, EnableAccessCheckForPrivilegedApplicationUpdates, which controls the access check for application privileged updates (whatever that means). This is a Boolean parameter with a default value of False.
The “Custom Policy Settings” template governs some settings related to Azure AD Conditional Access. The only setting currently configurable is CustomConditionalAccessPolicyUrl, which is used to designate a custom URL for any conditional access policies. As such, the settings accepts a string as input and has no default value. In the following example, we will configure this setting to point to this website. Here’s how:
$new = (Get-AzureADDirectorySettingTemplate -id 898f1161-d651-43d1-805c-3b0b388a9fc2).CreateDirectorySetting()
$new["CustomConditionalAccessPolicyUrl"] = "https://www.michev.info"
New-AzureADDirectorySetting -DirectorySetting $new
Id DisplayName TemplateId Values
-- ----------- ---------- ------
e37ce2ed-2d78-4d0a-a197-df1bbeafabc7 898f1161-d651-43d1-805c-3b0b388a9fc2 {class SettingValue {...
Where exactly is this URL used, I’m yet to discover. I will make sure to update this article once a proper documentation is published on the above.