This new feature for Teams, allows administrator to customise meeting invitations, to display the information of meeting in up to two languages ton all email platforms
In order to enable this, we can apply a new policy in their admin portal by enabling the MeetingInviteLanguages parameter in the CsTeamsMeetingPolicy at the user or group level, or for the entire organization
To enable this, we must use PowerShell, so let’s go:
#connect to Teams PowerShell
Set-ExecutionPolicy -ExecutionPolicy Unrestricted
#check the current configuration
Get-CsTeamsMeetingPolicy -identity global | fl *lang*
#apply the new config
Set-CsTeamsMeetingPolicy -Identity Global -MeetingInviteLanguages "en-US,es-ES"
It may take several hours before the policy becomes active, but in the end, we will be able to find this in a new teams meeting:
The following are recommendations and thoughts that I extracted by working with several customers, maybe you will find it obvious, but for other people could be useful. So, let’s begin:
In the identity plane, we could say that exists 2 categories:
Resist Common attacks
Contain successful attacks
I don’t want to enter of how to resist or contain attacks, because probably I covered some of these topics in other blog entries, but for me, there is another category which is: understand the human nature.
Nothing more that understand that almost every rule that we impose to the end users, result in degradation of security. Why? Because we force users to use long passwords, with special characters, and in the end, users tend to reuse passwords which makes easier to guess or crack passwords for malicious actors.
So, in the post I will resume some of my experiences as AntiPatterns and recommendations:
Antipattern – Requiring long passwords: excessive length passwords (more than 10 characters) can result in a behaviour predictable, users tend to choose repeating patterns (heyholetsgoheyholetsgo) that meet the character length but clearly not hard to guess. We can say that this kind of passwords are hard to guess but lead to poor behaviours to guess the password.
SuperPRO Tip: You can use a long password, but in this case what I recommend is something that engineers from Microsoft do. They use a very loooooooong password, they forget it, and instead of it, they use passwordless mechanisms such as Windows Hello to sign in.
My tip: Use minimum 8 length requirement but ban common passwords with Azure AD Password Protection.
Antipattern – Require use of multiple character sets: probably you’re not in the same line as me, but I’ve seen that this rule do more harm than good. People use patterns as substitutions such as $ for s, @ for a, 1 for I. So keep it in mind
Antipattern – Password expiration: Policy expiration drive users to use very predictable password (for example, the next password can be predicted on the previous password), end users do not tend to use a new password, the tend to update the old one.
My tip for the two previous points: Azure AD Password Protection + Conditional Access based on User Identity
Recommendation – Ban common passwords: For me, the most important restriction is to ban the use of common password to reduce the possibility of brute force or password spray attacks
Tip: Look at my first tip 😊
Recommendation – Educate end Users not to use organization credentials anywhere else: Yes I know that educate users are difficult, but you have to do it, because the tend to reuse the same password across multiple sites. It is a common practice for cyber criminals to try compromised credentials across many sites.
Recommendation – Enforce MFA registration and enable MFA: ensure that users maintain their security information up to date, so they can respond to security challenges if needed. Doing this, I have seen that end users are more implicated concerning digital security
Enabling MFA prevents up to 99.9% of identity attacks, and if we use other controls such as user location, the better.
EndUser TIP: Consider turning on two-step verification everywhere you can
Recommendation – Enable risk-based Authentication: when the system detects suspicious activity, it challenges the user to ensure that they are the legitimate account owner. Personally, I think that this feature is great, but the only drawback that it is only included with AAD P2
Probably you will have different ones based on your experience but these are my recommendations. Till next time and stay safe!
This a service that I discovered the other day, which is Office cloud policy service: lets you enforce policy settings for Microsoft 365 Apps for enterprise (what was named in the past Office 365 ProPlus) on a user’s device. It doesn’t matter if the device isn’t domain joined or otherwise managed.
The magic here flows when a user signs into Microsoft 365 Apps for enterprise on a device, then the policy settings roam to that device. Also, some other cool features is that you can enforce some policy settings for Office for the web, and anonymous users.
Some of the policies to configure are also included in GPO or in EndPoint Manager, so take into account this. But also keep in mind the following requirements:
At least Version 1808 of Microsoft 365 Apps for enterprise.
User accounts created in or synchronized to Azure Active Directory (AAD).
Office cloud policy service supports security groups and mail-enabled security groups created in Azure AD.
to create policy configurations, you need to have one of the following roles: Global Administrator, Security Administrator, or Office Apps Admin.
To enable security policy recommendations, sign in to the portal for managing Microsoft 365 Apps for enterprise, click Security, and then choose On for the Security Policy Advisor.
How Security Policy Advisor creates recommendations
When a security group has been assigned a policy configuration, Security Policy Advisor analyzes how users in that group work with Microsoft 365 Apps for enterprise. Based on this analysis and on Microsoft best practices, recommendations are created for specific security policies and insights about the impact of those policies on productivity and security.
Recommendations are usually generated within a few minutes of a policy configuration being applied to a group. On rare occasions, it may take longer. In such instances, please revisit Security Policy Advisor to check if new recommendations are available.
that’s all for know, keep playing and discover some cool jewels hided in the M365 portal
Retention is a great way to drive information governance and user behaviour, it is a good practice to have implemented a retention policy in organization content in order to enable long term retention in some of the workload such as SPO, Teams, ODFB, EXO…
But when it comes to the question what feature do I need to use in each case, it is when the doubts comes, so, with the following post I expect to clarify some of those points:
Use Retention Labels when:
Information within the same location requires different classifications to drive lifecycle
Information is required to be managed as a record or a regulatory record
Information requires manual classification by users or auto-classification using Keywords, metadata or machine learning
Use Retention Policies when:
A single baseline retention period is applicable to all information with a location (ODFB, EXO etc.)
Joiner / Leaver scenarios are required to be automatically managed
No user intervention is expected or required with the baseline policy
Have you ever used Whiteboad? If not it is a useful application where users can create a canvas, to shared ideas and content, also Whiteboard can be used to collaborate with yout team wether you’re in the same place or multiple locations.
But, the main problem is to be able to store & retrieve canvas or share them with other people, you’ll need to sign in with Office 365 credentials.
In my case, I was receiving the following message “Your admin has disabled sign in for Whiteboard”
But the fix is pretty simple… Simply go to the Office 365 admin portal, navigate to Settings and then to “Services & add-ins”, where you will see the new Whiteboard option and you will see that it is set to Off, so slide it over to On and press save:
The effect is immediate, and you’ll then be able to log in straight away and start working on whiteboards together!
This is an all or nothing approach, and at this point there are no administrative controls to enable or disable this on a per-user level – so you will need to be wary of content being stored in yet another location
Legal Hold can be used as an alternative to using third-party backup solutions since all emails are retained and cannot be deleted by the user or admin, except by retention policies.
Admins can place mailboxes on litigation hold or in-place hold. When you place content locations on hold, content is held until you remove the hold from the content location or until you delete the hold.
Litigation hold in O365 originally only existed for Exchange Online mailbox data, but has been extended to SharePoint Online, Teams, OneDrive, etc.
The user you wish to place on hold must a subscription that includes at least Exchange Online (Plan 2). This includes the following online licenses:
Microsoft 365 E5
Microsoft 365 E3
Office 365 E5
Office 365 E3
Users in subscriptions that include Exchange Online (Plan 1) can also be put on hold if the user has the add-on Exchange Online Archiving . Holds only apply to mailbox data with this license.
One great advantages of hold is that the user account can be deleted after they leave the company and the data will still be preserved for eDiscovery. So you won’t be burning a license for a user who does not access their mailbox any longer.
I know that we have to take security seriously, but I faced this problem so many times. Have you recently created a new Microsoft 365 or Office 365 account and users are being forced to setup MFA within 14 days despite MFA not being configured?
we are in the same boat!
I’m constantly setting up new tenants for clients and performing migrations and while enforcing MFA is a great idea and having it enabled by default is good it does cause issues during the configuration stage of a tenant.
The issue is being caused by a new security default policies being applied to the tenant.
Here is how to temporally (take it seriosly yo!) disable the new security default policies to turn off this behaviour.
Log into your tenant and go to the Admin console https://admin.microsoft.com and click in ‘Azure Active Directory’ from the left hand menu.
now click on ‘Azure Active Directory’ then ‘Properties’ then ‘Manage Security Defaults’.
Set ‘Enable Security Defaults’ to ‘No’.
Tick an option which most applies to you and click ‘Save’.
Now users will not be forced to configure MFA but remember weak passwords are causing us all major issues so please enable MFA for user accounts as soon as you can.