Introduction
Some of you already have seen the message in access control (IAM) blade: Classic admins will be retired on August 31, 2024. Starting on April 3, you won’t be able to add any new co-administrator using the Access control blade. Please remove Co-Administrators and use Azure RBAC for fine-grained access control.
Others have received an email from Microsoft:
History of classic administrators
Azure initially offered only the classic deployment model where each resource existed independently, making it challenging to group related resources together. This model required manual tracking and management of resources. Deployment and deletion of a solution involved handling each resource individually, and there was no easy way to apply and update access control policies or tags for related resources. With this deployment method, the classic administrator roles were introduced.
In 2014, Azure introduced the Resource Manager, which offered the concept of a resource group, a container for resources sharing a common lifecycle. This model offers several benefits:
- It allows for the deployment, management, and monitoring of all services for a solution as a group.
- It ensures consistent state deployment of resources throughout the solution’s lifecycle.
- It enables the application of access control to all resources in a resource group, with policies automatically applied to new resources added to the group.
- It allows for the application of tags to resources for logical organization.
- It uses JavaScript Object Notation (JSON) to define the infrastructure for a solution, known as a Resource Manager template.
- It defines dependencies between resources for correct order deployment.
When the Resource Manager was introduced, all resources were retroactively added to default resource groups. Now, any resource created through classic deployment is automatically created within a default resource group for that service. However, simply existing within a resource group doesn’t mean the resource has been converted to the Resource Manager model. With the Resource Manager the RBAC roles were introduced, and the classic administrator roles were soon to be forgotten.
But what do admins have to do?
This blog post provides a detailed guide on how to migrate any classic administrator roles that still need access to the subscription to an Azure RBAC role.
Migration process
If you have received an email like the one above, you are still using classic administrator roles on your subscription. It is recommended to check other subscriptions and resources, to be sure to migrate them all to RBAC roles. To make changes to the IAM blade, you have to be at least an Owner or User Access Administrator of the resource (keep it in mind).
NOTE: The service administrator won’t retire. This role is still necessary for the billing account.
In the case that you have some user with the co-administrator role, simply just add those as Owner (RBAC role) on the associated resource and remove the classic role. In this process, it is wise to review if the user still requires those privileges.
What should I do if I have a strong dependency on Co-Administrators?
Send an E-Mail to [email protected] and describe your scenario.
Source: Azure classic subscription administrators | Microsoft Learn, Resource Manager and classic deployment – Azure Resource Manager | Microsoft Learn