Retention Label VS Retention Policy

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

Advertisement

What is really PIM?

Currently in all project were I’m involved I’m trying to used Best Practices of Security, including the use of PIM.  Privileged Identity Management it is a service that is available in Azure AD and is part of Azure AD Plan 2, it is used for all admin related tasks, where no employee has standing access within the company, reducing the surface of an attack.

PIM makes it possible to give a user the privilege to elevate his or her access rights for a preset amount of time to a higher role such as User Administrator or SharePoint Administrator.

PIM gives access to huge quantity of roles in Office 365 and Azure resources where the user is by default a reader and can elevate it to be an owner of a resource (group) for a specific amount of time (which is great!)

Enabling a PIM role is done by going to the Azure Portal and select the role you want to elevate. You need to do this for every role separately.

For example, imagine that you have members that need to elevate their account daily to be a SharePoint and User administrator, so they need to do this daily. After enabling they need to sign out and sign in again to make sure the roles are activated.

No more to give the role to a user and forget which role we give to them…

 

Triggering an Azure Policy evaluation manually

Azure Policy is a comprehensive tool to control and govern our Azure environments. in terms of audit, control or prevents some actions in our subscriptions.

As you probably know, once you have assigned a policy or initiative, it usually takes up to 30 minutes to take effect. However, policy effect “deny” prevents affected deployments at submission time on ARM level, but this evaluation occurs then every 24 hours.

If you want to initiate a manually you can trigger the following PowerShell

$subscriptionId = "subscriptionID"
$uri = "https://management.azure.com/subscriptions/$subscriptionId/providers/Microsoft.PolicyInsights/policyStates/latest/triggerEvaluation?api-version=2018-07-01-preview"
$azContext = Get-AzContext
$azProfile = [Microsoft.Azure.Commands.Common.Authentication.Abstractions.AzureRmProfileProvider]::Instance.Profile
$profileClient = New-Object -TypeName Microsoft.Azure.Commands.ResourceManager.Common.RMProfileClient -ArgumentList ($azProfile)
$token = $profileClient.AcquireAccessToken($azContext.Tenant.Id)
$authHeader = @{
    'Content-Type'='application/json'
    'Authorization'='Bearer ' + $token.AccessToken
}
Invoke-RestMethod -Method Post -Uri $uri -UseBasicParsing -Headers $authHeader

And a similar example to trigger the eval cycle on a specific resource group.

$subscriptionId = "SubID"
$resourceGroupName = "RGName"
$uri = "https://management.azure.com/subscriptions/$subscriptionId/resourceGroups/$resourceGroupName/providers/Microsoft.PolicyInsights/policyStates/latest/triggerEvaluation?api-version=2018-07-01-preview"
$azContext = Get-AzContext
$azProfile = [Microsoft.Azure.Commands.Common.Authentication.Abstractions.AzureRmProfileProvider]::Instance.Profile
$profileClient = New-Object -TypeName Microsoft.Azure.Commands.ResourceManager.Common.RMProfileClient -ArgumentList ($azProfile)
$token = $profileClient.AcquireAccessToken($azContext.Tenant.Id)
$authHeader = @{
    'Content-Type'='application/json'
    'Authorization'='Bearer ' + $token.AccessToken
}
Invoke-RestMethod -Method Post -Uri $uri -UseBasicParsing -Headers $authHeader

A happy governance day!

Disabling Teams Creation Prompt in SharePoint Online

The other day a customer asked me why when they access to SPO TS, appears the owners an option saying that a Team has not been associated with a SharePoint Online site, like the image above:

In same scenarios this could lead a problem, taking into account that this kind of things should be governed from the governance plan.

In this case, we can use some PowerShell to hide some propertybags in SPO to hide this option to all users, leading to us to create Teams from the admin site directly.

So we can execute the following:

$tenant = "https://spotenant-admin.sharepoint.com"
$web = "https://spotenant.sharepoint.com/sites/Modernsposite"

Connect-PnPOnline -Url $tenant -SPOManagementShell
$site = Get-PnPTenantSite -Detailed -Url $web
if ($site.DenyAddAndCustomizePages -ne 'Disabled') {
    $site.DenyAddAndCustomizePages = 'Disabled'
    $site.Update()
    $site.Context.ExecuteQuery()
}

Set-PnPPropertyBagValue -Key 'TeamifyHidden' -Value 'True'

Once this has been done, if you refresh the homepage after setting the value, the dialog box to create Teams should no longer appear.

O365 Groups Expiration Policy

By default every licensed user in the tenant can create office 365 groups, it is a great feature, but when you have a company where everyone can create a group which leads in storage, leakage of information, naming standards not allowed… it is not a great thing.

So it is very important to have a governance plan and create some plans to plan the process of group creation and maintenance.

So in this scenario, a great feature is the policy to block group creation, where the admin can configure who are allowed to create groups. Remember, when you are using this approach that you are blocking the creation of O365 groups for all applications, is not possible to choose which applications are allowed or whether not.

In addition to that, we can use the policy expiration group, which enable us to automatically remove obsolete groups. Policy control how long groups can exist within a tenant before a group owner must renew the group. As groups expire, Office 365 can automatically remove them from the tenant. The expiration policy applies to all Office 365 Groups, no matter how they are used.

Things to keep in mind:

• Owners of the group are notified to renew the group as the expiration nears
• Any group that is not renewed is deleted
• Any Office 365 group that is deleted can be restored within 30 days by the group owners or the administrator
• When you first set up expiration, any groups that are older than the expiration interval are set to 30 days until expiration. The first renewal notification email is sent out within a day.
• Admins will need to have Azure Active Directory Premium P1 license
• Configuring and using the expiration policy for Office 365 groups requires you to possess Azure AD Premium licenses for the members of all groups to which the expiration policy is applied.

That’s all!

Azure Governance: Lock Azure resources to prevent accidental deletion

In some cases you want to protect critical resources from accidental deletion, because losing some resources that are key in your infrastructure, recovery can be dramatic. Resource Manager locks will enable you to protect these critical resources from deletion.

Locks do not have any impact the normal functions of the resource. You have two possible types of locks on a resource:

• CannotDelete means authorized users can still read and modify a resource, but they can’t delete the resource.
• ReadOnly means authorized users can read a resource, but they can’t delete or update the resource. Applying this lock is similar to restricting all authorized users to the permissions granted by the Reader role.

In practice user or service principles have the role Contributor on a resource. This role allows the user to delete the resource. A lock on the resource will prevent the user with the Contributor role to delete the resource. Only the roles Owner and User Access Administrator can change the locks on the resources.

Do I need to use Tags in Azure?

I didn’t know which title set to the post, but if you’re looking for a quick answer, the answer is: DEFINITIVELY YES

Tags in Azure form part of one of the key elements of governance, it helps to organize resources and resources group by assigning them a name:value.

Ok, you will be thinking, it’s ok I see your point, but what’s in there for me? I will try to explain it in a easy way:

First of all, tags help to control the access and compliance to the resources that we have inside the platform, for example to keep track of who can interact with which resources, and things like that.

Applying tags to resources, helps to automate everything inside Azure. For example, in my case, each VM that we create in test, is tagged automatically (thanks to automation) and it’s being shut down al 19 everyday, so it helps to save costs.

And speaking of the devil… costs, applying tags to the resources inside Azure it helps organizations to divide invoices to each department, or even to facilitate reporting, for example which workloads are spending most. But as you can imagine in each customer, it has different ways of tagging.

One thing that you have to keep in mind, is that when we apply a tag to a RG, this tag is not inherited to the resources that contain this RG. But don’t worry, PowerShell to the rescue, you can use the following PS, that helps to apply the tag that has been applied to the top level of the RG to all the resources inside it.

You can use the following PS for this task: https://github.com/sympa18/CheckandApplyTags

Tags can also be applied with Azure policies, so don’t forget to use all this tools when you are using Azure, your governance strategist will be happy if you keep resources as simply as possible.