Managing Office 365 Groups is a key factor in Office 365 Implementation. if you don’t manage your Office 365 Groups Properly. It goes unmanageable from a governance point of view. As most of the below products allow group creation by default. So it’s wise to place a restriction on a top-level and manage the members who can create teams for mid and large Organizations.
Outlook
SharePoint
Yammer
Microsoft Teams
Microsoft Stream
Planner
PowerBI
Roadmap
Once you map a group/group ID,
you can nest them or use Azure AD premium License to have dynamic membership for the security group to allow limited users to create teams for example. Yes, you can configure the naming policy and group expiration policies later. Purpose: Disable Teams Creation by all users. Only members of this security group can create Teams
Let’s see how to create group creators.
Install AzureADPreview
If you don’t install AzureADPreview, you will get a command not recognized. If you already have azureAD module. you need to uninstall and install the same.
Uninstall-Module AzureAD
Install-Module AzureADPreview
if you already installed it. running the script should initiate connect-azureAD
Office 365 Admin Center – Groups – Create a Security Group
Office 365 - Groups Creator
Save the below script as ps1 fill the group name in the first line, save and run it.
To handle an APEX or naked domain (azure365pro.com) to redirect to https://www.azure365pro.com main requirement is that the Domain should use Azure Manage DNS;
Whatever password complexity you apply through group policies, users will always find a way to use the simplest and most used password on the internet like P@$$w0rd, As Active Directory doesn’t have any native feature to protect from this user behavior, Azure AD Password protection comes to the rescue to provide the intelligence of the most used passwords used on password spray attacks so that you keep your users safe from password spray attacks. Even though passwordless is the future. it’s going to take some time to reach there as there are so many legacy dependencies in every brownfield environment.
It’s recommended to have Password Writeback enabled so that users can reset in both places either Cloud or OnPrem seamlessly. You can check the status of password write back, it shows healthy in the below screenshot (Your on-premises writeback client is up and running). As password protection works only with Azure AD Premium P1 or P2, you can enable the password to write back which comes with the same set of licenses as well through Azure AD Connect.
Let’s see how to implement them. As there is no minimum forest functional level or forest functional level for the agent or the proxy. you can implement in any environment. but what we observed is installing them on Windows Server 2012 R2 is a bit hectic as it requires .NET 4.7.2 versions to be installed. Installing them on Windows Server 2019 was seamless as the .NET was pre-installed.
There are two URLs need to be reached by Azure AD Password Protection Proxy to talk to Azure AD to gain the updates.
It’s better to allow them directly as they are standard Microsoft URLs, if you have a proxy and if you don’t want to bypass them you have to update config files which are not covered in this article.
On High Availability, you don’t have to worry as these Azure AD Password Protection Proxy going down doesn’t affect the environment. Only the new signatures (updated banned list for example) will not be updated until the Azure AD Password Protection Proxy server coming up. Unless you have a very large environment you certainly don’t have to bring multiple servers to maintain High availability for this. if you have a good backup we are good. if you have multiple sites you don’t have to bring multiple Proxy servers to each site as its updates the default SYSVOL shares of domain controllers which will be replicated throughout the forest with standard mechanisms as the domain controllers don’t have to speak to the internet directly.
You need a dedicated server on your primary site where the majority of users are in terms of resetting their passwords so that any new changes on the custom password banned list gets updated immediately for you majority of users, Even though you can bring multiple proxy servers on multiple sites to improve that, we don’t have such requirement though on this particular case. let’s see how to download and install the proxy setup,
Once your proxy agent is healthy. let’s make sure one of the domain controllers can access the Proxy agent to get the updates to the SYSVOL shares to replicate them to the whole environment.
To Verify Health using Powershell –
Test-AzureADPasswordProtectionProxyHealth-TestAll
Run as administrator – AzureADPasswordProtectionDCAgentSetup.msi install them on all domain controllers. before installing them on Domain Controllers make sure you are running the password protection on Audit mode. (it’s on Audit mode by default). So that you don’t affect the users.
Now let’s install the AzureADPasswordProtectionDCAgentSetup.msi on all domain controllers. As the password protection mode is on audit mode it’s not going to enforce anything.
Once you install them they come online with Audit mode.
if you try to reset with a simple password “Password@1234” 10025 is generated with Audit only
Event Logs location on Domain Controllers – \Applications and Services Logs\Microsoft\AzureADPasswordProtection\DCAgent\Admin
if the password is healthy 10015 is generated.
Once you feel everything is working as expected you can enforce them.
Resetting with a simple password
You can list the installed Domain Controller agents using the below command
Get-AzureADPasswordProtectionDCAgent
Also, you can get a summary using the below PowerShell which queries the event viewer and gets you collective results.
