In this post I will tell you what you need to know about the MFA-Enforcement @15th of October 2024. For sure you’ve already heard about the MFA-Enforcement per 15th of October 2024 for Entra/Intune/Azure.This post will show you what you need to know and to do. Secure Future Initiative November 2023, Microsoft launched the SFI (short for; Secure Future Initiative) to be prepared for the fastly increasing numbers of cyberattacks.SFI combines every part of microsoft to increase the cybersecurity protection in the whole portfolio. To reach a “secure future” it does not only require technologies, it also requires skilled people and last but not least; security culture. As part of this initiative there will be global security changes, which will impact ALL of us.If you want to know more about that, you can find here more information. Impact on 15th of October and further impacts Following portals will be impacted by the SFI, by the mentioned date in the table: Application Name Application ID Enforcement by Azure Portal c44b4083-3bb0-49c1-b47d-974e53cbdf3c 15th of October 2024 Microsoft Entra admin center c44b4083-3bb0-49c1-b47d-974e53cbdf3c 15th of October 2024 Microsoft Intune admin center c44b4083-3bb0-49c1-b47d-974e53cbdf3c 15th of October 2024 Azure CLI 04b07795-8ddb-461a-bbee-02f9e1bf7b46 Start of 2025 Azure PowerShell 1950a258-227b-4e31-a9cf-717495945fc2 Start of 2025 Azure mobile app 0c1307d4-29d6-4389-a11c-5cbe7f65d7fa Start of 2025 Infrastructure as Code tools Azure CLI or Azure PowerShell IDs Start of 2025 Impacted Accounts All users who sign in into the applications above to perform any Create, Read, Update or Delete operation will require MFA when the enforcement begins. Service Pincipals as well as Workload Identities aren’t impacted from MFA-Enforcement.So make sure, no User identities are used for automated tasks. What happens to my break-glass accounts? Also your break-glass accounts will be required to use MFA.These accounts should be populated for the usage of Hardware Token or configure certificate-based authentication for MFA. If you need inspiration on your FIDO-Token order, I can recommend you Token2.For more information about FIDO-Keys and especially Token2 I recommend you reading the post of Michele here. Summary As a roundup I can say; Make sure you’ve checked your sign-ins for user without MFA. Source used in this post Expanding Microsoft’s Secure Future Initiative (SFI) | Microsoft Security Blog Mandatory Microsoft Entra multifactor authentication (MFA) – Microsoft Entra ID | Microsoft Learn Detect Impact MFA Enforcement – Blog by Morten Knudsen about Microsoft Security, Azure, M365 & Automation
Managed Identity
In this post I will explain what managed Identities are. What is a managed identity? Managed Identity is a way to authenticate at a Azure Resource.Applications can use managed identities to obtain Microsoft Entra tokens without having to manage any credentials .For example; An application running on Azure has credentials for each workload of the application.So that these credentials can be securely stored, you create an Azure KeyVault.But, somehow the application needs to access this KeyVault.That’s when managed identity comes in.With the managed identity, the application can obtain all centrally managed credentials from the KeyVault without any need of secrets and/or certificates. What are the benefits? There’s no need to manage credentials for accessing Azure Resources. These credentials aren’t even accessible for you! Managed Identities can be used to authenticate to any resource that supports Micrsoft Entra authentication They’re free of charge What are the pitfalls? Only Azure Resources (who support Entra ID authentication) can use managed identities Note: If you need to authenticate from Workloads who do not support Microsoft Entra authentication, you can use workload identity federation (WIF). Here you can find, the blog post about WIF. What type of managed identity are there? System-assigned; Some Azure Resource, for example VMs allow you to create a managed identity directly on the resource. So only this resource can use this identity to request token. In addition it is assigned with this resource, so if you delete the resource you also will delete the managed identity. User-assigned; These identities are created standalone and can bi assigned to one or more Azure Resources Source used in this post: Managed identities for Azure resources – Managed identities for Azure resources | Microsoft Learn
Workload Identity Federation
In this post I will explain you what Workload Identity Federation is and how to use it in the context of Azure. If you do not understand what Workload Identities are, refer to this blog post about WIs. What is Workload Identity Federation? Simply said; Workload Identity Federation (or short WIF) is the successor of Client Secret for Service Principals.It allows you to access Azure Resources without the need of managing secret.It can be used in a variety of scenarios such as GitHub Actions, Kubernetes or other Compute Platforms outside of Azure. But…why should I use WIF? I mean, secrets do work. Well, there are many reasons, for you to migrate to WIF.First of all a software workload needs an identity to authenticate and access resources or for communication reasons.So if you run these workloads on Azure, you can use managed identities (Read my blog post about managed identities here)If you have a software workload, which runs outside of azure, you can’t use that. So in the past you either had to use a secret or certificate to access these Resources protected by Entra ID.That’s…insecure.We all know that Passwords are not secret anymore today for our user, so why should they be for software workloads?In addition, they need to be rotated regularly and if you don’t, you’ll risk service downtime, because of expired credentials.WIF is here to configure a user-assigned managed identity or app registration in Entra ID to trust tokens from an external IdP (Identity Provider). Once you created that trust, the external workload will be able to exchange trusted tokens from that external IdP for access token for the Entra ID. The software then uses these access tokens to access the Resources under protection of Entra ID How does it work? Well you establish a trust relationship between the external IdP and Microsoft Entra ID.The federated Identity Credential indicates, which token of the external IdP should be trusted. The workflow for the exchange of external tokens for an access token, is standardized and with that, the same for all scenarios. Following graphic of Microsoft shows the Workflow Source: https://learn.microsoft.com/en-us/entra/workload-id/media/workload-identity-federation/workflow.svg In the first step, the external workload requests a token from the external IdP The token of the external IdP is issued to the workload With that token, the external workload sends an request for an access token Entra ID then checks the trust and validates the token If everything is valid, Entra ID issues the access token directly to the workload Then at the end, the workload can access the resources Note: Microsoft as a IdP only stores the first 100 signing keys when they’re downloaded from the external IdP. When the external IdP publishes more than 100 keys, there might be error when working with WIF. Hands-On
Workload Identity
In this blog post I will explain what Workload Identities are and how to secure them (yes, they need to be secured).Furthermore I will explain Workload Identity Federation in a future blog post. What are Workload Identities? A workload identity is a identity used by software workloads. These can be applications, services, scripts or even containers.They’re used to access resources in Azure.In Microsoft Entra Workload Identities are applications, service principals and managed identities.Managed Identities are a special type of service principal which eliminate the need for managing credentials.In general there are two types of identities; human identities and non-human identities.Non-human identities are grouped by workload identities and device identities.Workload Identities represent as the name already tells; Workload such as software, while device identities represent machines such as Desktops, Smartphones and so on… Securing WIs? Hmm…probably not only human identities should be secured, but also non-human ones.But most solutions on the market are securing just the human identities.So here are a few possibilities to secure your non-human identities. Apply CAPs (Conditional Access Policies) to service principals using CA for workload identities Enable real-time enforcement of Conditional Access location and risk policies through using Continuous access evalution for Workload Identities Managing custom security attributes for an app
Automate Maester with Azure DevOps
In this post I will show you how to automate the Maester-Framework with Azure DevOps.Please make sure, that you read my first blog post about Maester for being familiar with the basic function of the framework. Requirements Azure DevOps Organization Azure DevOps Project Approved Parallelism JobsYou can request them here Set up the Maester Repo In Azure DevOps open Repos in the Menu and select the Import button.Enter the URL https://github.com/maester365/maester-tests and click Import to import the repo into your Azure DevOps project. Set up the Azure Pipeline In this post I will use workload identity federation for authentication on the tenant, for this way it’s required to have an Azure Subscription. Also I’m monitoring the same tenant as I’m using Azure DevOps. If you want to monitor another tenant, you have to choose manual at the 5th step. In the first step you can create a new resource group (e.q. mika-rg-maester-prod-001). After that in Azure DevOps go to Project Settings > Service Connections Click New Service Connection Choose Azure Resource Manager And then select Workload identity federation (automatic) Specify the required informations (Azure Subscription, Resource group and Service Connection Name) Then click save In the next step you will grant the permissions to Microsoft Graph: Go under Project settings > Service connections and choose the previously created Service connections Unter Manage Service Principal and then in the new opened tab, select API Permissions > Add a permission Grant following permission for the service principal:– Directory.Read.All– Policy.Read.All– Reports.Read.All– DirectoryRecommendations.Read.All– PrivilegedAccess.Read.AzureAD At the end we will create the Azure Pipeline: Open the DevOps project Under pipelines, select New Pipeline As the location, select Azure Repos Git Select the previously imported repo Select Starter Pipeline Then select any code with Ctrl+A and insert with Ctrl+V with the code below: # Maester Daily Tests trigger:- main schedules:- cron: “0 0 * * *”displayName: Daily midnight buildbranches:include:- main pool:vmImage: ubuntu-latest steps:- task: AzurePowerShell@5displayName: “Run Maester”inputs:azureSubscription: “Maester Service Connection”pwsh: trueazurePowerShellVersion: LatestVersionScriptType: InlineScriptInline: |# Connect to Microsoft Graph$accessToken = (Get-AzAccessToken -ResourceTypeName MSGraph).Token | ConvertTo-SecureString -AsPlainText -ForceConnect-MgGraph $accessToken # Install MaesterInstall-Module Maester -Force # Configure test results$PesterConfiguration = New-PesterConfiguration$PesterConfiguration.TestResult.Enabled = $true$PesterConfiguration.TestResult.OutputPath = ‘$(System.DefaultWorkingDirectory)/test-results/test-results.xml’ # Run Maester testsInvoke-Maester -Path $(System.DefaultWorkingDirectory)/tests/Maester/ -PesterConfiguration $PesterConfiguration -OutputFolder ‘$(System.DefaultWorkingDirectory)/test-results’- publish: $(System.DefaultWorkingDirectory)/test-resultsdisplayName: Publish Maester Html Reportartifact: TestResults- task: PublishTestResults@2displayName: Publish Pester Test Resultsinputs:testResultsFormat: “NUnit”testResultsFiles: “**/test-results.xml”failTaskOnFailedTests: true At the end you need to Save the pipeline and Run it.Select the job to view the test result. You probably need to permit the pipeline to access the service connection.Open the pipeline log and click on permit and click on permit again: In the summary you will see the status of the pipeline.If you click on 1 published under related, you can view the results from the test. Keeping your Maester tests up to date Clone your fork to you local machine Update the maester Powershell Module and import it Change the working directory to maester-teststests directory Run cmdlet Update-MaesterTests Sources used in this Post Azure DevOps | Maester
Security Monitoring with Maester
What, if there was a Tool helping you to identify possibilities to improve your Microsoft 365 tenant security?Good news; There is a tool.Better news; It’s easy to use.& best news; It’s free and open source. It’s named Maester and is based on Powershell. Requirements Microsoft.Graph.Authentication Module (v2.2.0) Pester (v5.5.0) How to install Maester To install the Powershell Module you need to execute following commands:Install-Module Pester -SkipPublisherCheck -Force -Scope CurrentUserInstall-Module Maester -Scope CurrentUser After that, you create a directory named maester or a name you want to.change the working directory to the created directory and execute:Install-MaesterTests .tests After that you are good to go for executing your first Assessment. How to run a Report Running the first assessment is nothing more than easy.1. Connecting to Microsoft Graph2. Run the test You need following Permissions in Entra ID to run the Script: Directory.Read.All Policy.Read.All Reports.Read.All DirectoryRecommendations.Read.All If you execute connect-maester the scopes will be automatically set to the required ones. By using Get-MtGraphScope it will expose which permissions are consented by executing Connect-Maester.This is very useful because the tool will expand and shrink the required scopes. Connect to Maester Connect using the default scopes:Connect-Maester Connect using the default scopes + send mail as user:Connect-Maester -SendMail Connect using the Graph SDK:$scopes = @(“Directory.Read.All”,”Policy.Read.All”,”Reports.Read.All”,”DirectoryRecommendations.Read.All”,”Mail.Send”) Connect-MgGraph -Scopes $Scopes At the first login you need to approve the permissions as you already know it from other frameworks. Run the default security assessment You can run the default security assessment pre-defined by running:Invoke-MaesterIt will output the Report under .test-results. By executing Invoke-Maester -OutputFolder C:temp you can modify the output path. After a few seconds, it will show the results and open a HTML-Report: By scrolling down you can see the results and by clicking on the info button for each test, you can see the detailed information on the test. Based on these results you can harden your tenant.In my next post I will explain how to automate the assessment with Azure DevOps Thanks to Merill Fernando, Fabian Bader and Thomas Nuanheim for developing this Tool! Sources used in this post Maester | Maester
App Registration and Enterprise Application
As a Cloud System Engineer I often work with Enterprise Applications and App Registrations. But, what are these? How should I configure them & what are possible misconfigurations an engineer should be aware of? In this article I will answer these questions. What is an App Registration? An App(lication) Registration defines an App.Simple as that, it tells Entra ID, what the App wants and which API-access is allowed.For example the App “MyTestApp” wants to read User profiles.So the App Registration defines this, as you can see in the screenshot below:The App Registration, especially their IDs are unique globally, even if they’re only available tenant-internally.Entra ID uses shared components, so it’s necessary that every App Registration is uniqely identifiable and every App Registration can be uniqely spoken to.In addition, the App Registration defines where the application is located, so you can also define Redirect and other URIs. What is a Service Principal? A Service Principal is a security principal and defines what permissions the application has in the tenant and it “represents” the Application in the directory. So you will apply a conditional access policy to a service principal, not the app registration.An other type of security principals are users, so as well as users, we can give a service principal permissions and resources. In difference to the app registration, which defines what the application wants or needs, the service principal defines what the application is allowed to. There are three types of service principals: Enterprise Applications Managed Identities Legacy Legacy shouldn’t be used these days so we won’t focus on this type. What is a Enterprise Application? Enterprise Applications are like a child to service principals and referse to a Application externally or internally.If you were working with Powershell or GraphAPI, you maybe used a cmdlet like Get-AzureADServicePrincipal, simply because Enterprise Applications are service principals. Funfact: Microsoft Applications are using service principals as well, but just more integrated to Entra ID. If you now want to access from another tenant (or maybe the same tenant), you need to have a service principal you can use.You surely know the Consent Grant. That’s nothing more than the creation of a service principal and app registration in your tenant allowing and defining the required permissions. How should I handle the registration process? For example if you want to use the SaaS-application miro you can use Entra ID as a Identity Provider.When signing up with your Entra ID Account on miro as a normal user, the default behaviour is, that it will prompt for the required permission, because User consent ist allowed(!) by default.If a user approves this consent, the application can read or even write in your tenant.Sounds strange, that your user can approve read or even write permissions for external apps without any Know-How? It is!That’s why the default setting allow user consent is absolutely not recommended.Either I recommend the setting verified publisher or even not allowed, if you’re a Company which needs 100% control about the registered applications or just don’t want to risk anything. Summary So check your or your customer tenants and define a setting which fits your needs.In addition I recommend cleaning up your Enterprise Applications after blocking user consent, because with user consent enabled, there will be a looooot of trashy application your user approved, because it’s a *cool* App.