Identity Bindings: A Cleaner Model for Multi‑Cluster Identity in AKS
AKS has supported assigning Azure Managed Identities to pods for some time, first through Pod Identity and then later through Workload Identity. Using these tools it is possible to give a pod an Azure Identity that it can use to interact with other Azure services - pull secrets from Key Vault, read a file from Blob Storage or write to a database. Workload Identity is the latest incarnation of this feature and significantly simplified this feature, removing the need to run additional management pods in the cluster and to have the identity injected in every node however it does have some issues of it's own. These issues are particularly evident when operating at scale and wanting to share the same Managed Identity across multiple workloads in the same cluster, or across multiple clusters. Workload Identity relies on creating a Federated Identity Credential (FIC) in Azure that defines the trust relationship between the AKS OIDC issuer and Entra ID. Each combination of Service Account and Namespace that uses the same Managed Identity requires a separate FIC, as do services running in different clusters. As your scale grows, this can start to become a problem. Each managed identity can only support up to 20 FICs. Once you hit that limit, your only option is to create another Managed Identity. This leads to the proliferation of Managed Identities that have the same permissions and do the same job, but only exist to work around this problem. In addition to the 20 FIC limit, there are some other issues with Workload Identity: Creation of the FIC is an Azure Resource creation that often needs to occur alongside Kubernetes resource creation and makes automation of app deployment harder There can be a cyclic dependency issue where the service account in Kubernetes needs to know the Identity details before the pod is created, but the FIC needs the service account and namespace details to create the OIDC binding Additional outbound rules are required to allow the AKS cluster to access the Entra ID (login.microsoftonline.com) endpoints Introducing Identity Bindings Identity Bindings are currently in preview. Previews are provided "as is" and "as available," and they're excluded from the service-level agreements and limited warranty. AKS previews are partially covered by customer support on a best-effort basis. As such, these features aren't meant for production use. Identity Bindings introduce a cleaner, RBAC-driven approach to identity management in AKS. Instead of juggling multiple federated credentials and namespace scoping, you define bindings that link Kubernetes RBAC roles to Azure identities. Pods then request tokens via an AKS-hosted proxy, no external egress required. Key benefits: Centralised Access Control: Authorisation flows through Kubernetes RBAC. Cross-Cluster Identity Reuse: Federated credentials can be shared across namespaces and clusters. Reduced Networking Requirements: No outbound calls for token acquisition; everything stays within the cluster. Simplified IaC: Eliminates the “chicken-and-egg” problem when deploying identities alongside workloads. Identity Bindings act as the link between applications running in AKS and the Azure managed identities they need to use. Instead of every cluster or namespace requiring its own federated identity configuration, each application is authorised through an Identity Binding defined inside the cluster. The binding expresses which workloads (via service accounts and RBAC) are allowed to request tokens for a given identity. When a pod needs a token, AKS validates the request against the binding, and if it matches, the request is routed through the cluster’s identity proxy to the single Federated Identity Credential (FIC) associated with the managed identity. The FIC then exchanges the pod’s OIDC token for an Azure access token. This pattern allows multiple clusters or namespaces to share one managed identity cleanly, while keeping all workload‑level authorisation decisions inside Kubernetes. With Workload Identity, every workload using a managed identity required its own Federated Identity Credential (FIC) tied to a specific namespace and service account, and you had to repeat that for every cluster. Hitting the 20‑FIC limit often forced teams to create duplicate managed identities, and deployments had to be carefully ordered to avoid cyclic dependencies. You also needed outbound access to Entra ID for token requests. Identity Bindings significantly simplifies this. You create a single binding per cluster–identity pair, authorise workloads through RBAC, and let AKS handle token exchange internally with no external egress. There is no FIC sprawl, no need for identity duplication and less complexity in your automation. Using Identity Bindings To get started with using Identity Bindings, you need an AKS cluster and a Managed Identity created. Your Managed Identity should be granted permissions to access the Azure resources you require. The first thing you need to do is ensure the feature is registered. az feature register --namespace Microsoft.ContainerService --name IdentityBindingPreview Next, we need to do is create the identity binding. This is a one-to-one mapping between AKS cluster and Managed Identity, so only needs to be created once for each clusters/identity mapping. You provide the name of the cluster you want the binding mapped to, the full resource ID of the Managed Identity resources, and the name you want to give this binding, and this maps the two resources together. This only needs to be created once per cluster and all further administration is done via Kubernetes. az aks identity-binding create -g "<resource group name>" --cluster-name "<cluster name>" -n "<binding name>" --managed-identity-resource-id "<managed identity Azure Resource ID>" Once this has been created, we need to configure access to it inside Kubernetes. To do this we create a ClusterRole which references the Managed Identity ID. Note that this must be a ClusterRole, it cannot just be a Role. apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: identity-binding-user rules: - verbs: ["use-managed-identity"] apiGroups: ["cid.wi.aks.azure.com"] resources: ["<MI_CLIENT_ID>"] Once this ClusterRole is created, we can assign it to any Namespace and Service Account combination we require, using a ClusterRoleBinding. Indentity Bindings are accessible to all Pods that use that Service Account, in that Namespace. apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: <clusterrole name> roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: identity-binding-user subjects: - kind: ServiceAccount name: <service account name> namespace: <namespace of service account> Now all that is left to do is configure the Pod to use the Identity Binding, there are a two steps to this. First we need to apply the required labels and annotations to the pod to enable Identity Binding support: metadata: labels: azure.workload.identity/use: "true" annotations: azure.workload.identity/use-identity-binding: "true" Then, we need to ensure that the Pod is running using the Service Account we granted permission to use the Identity Binding. spec: serviceAccountName: <service account name> Below is an example deployment that uses Identity Bindings. apiVersion: apps/v1 kind: Deployment metadata: name: keyvault-demo namespace: identity-binding-demo spec: replicas: 1 selector: matchLabels: app: keyvault-demo template: metadata: labels: app: keyvault-demo azure.workload.identity/use: "true" annotations: azure.workload.identity/use-identity-binding: "true" spec: serviceAccountName: keyvault-demo-sa containers: - name: keyvault-demo ... Once this Pod has been created, the Identity Binding should be attached and you should then be able to use it within your application using your SDK and language of choice. You can see an example of consuming an Identity Binding in GO here . Demo App If you want to deploy a demo workload to test out your bindings, you can use the Pod definition below. This requires you to deploy a Key Vault, and grant your managed identity the "Key Vault Secret User" role on that Key Vault. You will also need to update the service principle and namespace to match your environment. apiVersion: v1 kind: Pod metadata: name: demo namespace: demo labels: azure.workload.identity/use: "true" annotations: azure.workload.identity/use-identity-binding: "true" spec: serviceAccount: demo containers: - name: azure-sdk # source code: https://github.com/Azure/azure-workload-identity/blob/feature/custom-token-endpoint/examples/identitybinding-msal-go/main.go image: ghcr.io/bahe-msft/azure-workload-identity/identitybinding-msal-go:latest-linux-amd64 env: - name: KEYVAULT_URL value: ${KEYVAULT_URL} - name: SECRET_NAME value: ${KEYVAULT_SECRET_NAME} restartPolicy: Never Once deployed, if you look at the logs, you should see that it is able to read the secret from Key Vault. kubectl logs demo -n demo I1107 20:03:42.865180 1 main.go:77] "successfully got secret" secret="Hello!" Conclusion Identity Bindings offer a much cleaner model for managing workload identities in AKS, especially once you start operating at scale. By moving authorisation decisions into Kubernetes and relying on a single Federated Identity Credential per managed identity, they avoid the FIC sprawl, cyclic dependencies, and networking requirements that made Workload Identity harder to operate in larger environments. The end result is a simpler, more predictable way to let pods acquire Azure tokens. If you’re already using Workload Identity today, Identity Bindings are a natural evolution that reduces operational friction while keeping the security properties you expect. Further Reading Identity Bindings Overview Setup Identity Bindings
MFA alerts for when a alternative phone number is added
Hi, i need to be able to find a way when someones adds a alternative phone number to MFA it sends an alert via email that would go into a shared mailbox but haven't been able to find a way to get the MFA alerts for alternative phone numbers. can someone help please?Troubleshooting Azure Virtual Desktop Sign-In Failures After Tenant Migration
Migrating an Azure subscription between tenants can sometimes surface unexpected authentication issues, especially for environments like Azure Virtual Desktop (AVD) that depend deeply on Microsoft Entra ID (formerly Azure AD) for identity and access control. This post walks through a real-world scenario where users were suddenly locked out of AVD sessions after a tenant migration, the investigation that followed, and the steps taken to restore access. Scenario Overview Shortly after an Azure subscription was migrated from Tenant A to Tenant B, several users reported being unable to connect to their virtual desktops. The error message displayed: “Your account does not exist in this organization’s directory.” This problem appeared immediately after the migration—even though access roles had been correctly reassigned under the new tenant. Interestingly, users who had active sessions before the migration remained signed in until their tokens eventually expired. Symptoms Observed Authentication failures during AVD sign-in Error code AADSTS53003, indicating a Conditional Access policy block The issue primarily affected macOS clients Reinstalling or resetting the AVD client did not resolve the problem Root Cause Analysis The investigation uncovered that cached tokens on user devices were still attempting to authenticate against the legacy tenant. Contributing Factors Token persistence in macOS Keychain Cached refresh tokens still bound to the old tenant’s directory ID This mismatch meant that even though users had permission in the new tenant, their local authentication context still pointed to the previous one. Understanding Token Behavior on macOS The AVD client on macOS uses tokens stored in the system Keychain. Token Type Default Lifetime Renewal Behavior Access Token ~1 hour Automatically renewed via refresh token Refresh Token 90 days of inactivity (rolling) Each successful refresh resets the timer Persistent Session Until refresh token expiry or manual deletion Cached in Keychain until removed Key Takeaways: Conditional Access (CA) or Sign-In Frequency policies can shorten token validity (e.g., 12 hours or 7 days). Cached tokens remain active until: The refresh token expires. They are manually deleted from Keychain. A tenant mismatch triggers forced re-authentication. Resolution Steps Validate AVD Configuration Verify that the host pool, workspace, and application group references all point to the new tenant’s directory ID. Confirm that the appropriate service principals and role assignments exist under the new tenant. Clear Cached Tokens On macOS, manually remove AVD’s cached MSAL tokens from Keychain Access. Once users signed out and back in, authentication succeeded without further issues. Mitigation Options Option 1 – Revoke Active Sessions via Microsoft Graph PowerShell Connect-MgGraph -Scopes "User.RevokeSessions.All" Revoke-MgUserSignInSession Option 2 – Manual Cleanup Instruct affected users to delete cached credentials or MSAL tokens from macOS Keychain. Have them sign back in to re-establish authentication with the correct tenant. Key Learnings Cached tokens can retain old tenant information long after migration—especially on macOS devices. Conditional Access policies may inadvertently block token issuance during silent sign-ins. Proactively revoking sessions and clearing tokens helps minimize user disruption. Best Practices for Future Tenant Migrations Validate all AVD resources (host pools, workspaces, app groups) against the new directory ID. Instruct users to clear cached credentials before reconnecting. Allow sufficient propagation time for identity and access updates to take effect. Review Conditional Access policies to prevent unintended sign-in blocks during transition periods. Closing Thoughts Tenant migrations are complex, and even small gaps in token or directory synchronization can interrupt access to services like Azure Virtual Desktop. By planning token cleanup and access validation steps in advance, you can ensure a smoother transition with minimal user downtime.Azure Container Registry Repository Permissions with Attribute-based Access Control (ABAC)
General Availability announcement Today marks the general availability of Azure Container Registry (ACR) repository permissions with Microsoft Entra attribute-based access control (ABAC). ABAC augments the familiar Azure RBAC model with namespace and repository-level conditions so platform teams can express least-privilege access at the granularity of specific repositories or entire logical namespaces. This capability is designed for modern multi-tenant platform engineering patterns where a central registry serves many business domains. With ABAC, CI/CD systems and runtime consumers like Azure Kubernetes Service (AKS) clusters have least-privilege access to ACR registries. Why this matters Enterprises are converging on a central container registry pattern that hosts artifacts and container images for multiple business units and application domains. In this model: CI/CD pipelines from different parts of the business push container images and artifacts only to approved namespaces and repositories within a central registry. AKS clusters, Azure Container Apps (ACA), Azure Container Instances (ACI), and consumers pull only from authorized repositories within a central registry. With ABAC, these repository and namespace permission boundaries become explicit and enforceable using standard Microsoft Entra identities and role assignments. This aligns with cloud-native zero trust, supply chain hardening, and least-privilege permissions. What ABAC in ACR means ACR registries now support a registry permissions mode called “RBAC Registry + ABAC Repository Permissions.” Configuring a registry to this mode makes it ABAC-enabled. When a registry is configured to be ABAC-enabled, registry administrators can optionally add ABAC conditions during standard Azure RBAC role assignments. This optional ABAC conditions scope the role assignment’s effect to specific repositories or namespace prefixes. ABAC can be enabled on all new and existing ACR registries across all SKUs, either during registry creation or configured on existing registries. ABAC-enabled built-in roles Once a registry is ABAC-enabled (configured to “RBAC Registry + ABAC Repository Permissions), registry admins can use these ABAC-enabled built-in roles to grant repository-scoped permissions: Container Registry Repository Reader: grants image pull and metadata read permissions, including tag resolution and referrer discoverability. Container Registry Repository Writer: grants Repository Reader permissions, as well as image and tag push permissions. Container Registry Repository Contributor: grants Repository Reader and Writer permissions, as well as image and tag delete permissions. Note that these roles do not grant repository list permissions. The separate Container Registry Repository Catalog Lister must be assigned to grant repository list permissions. The Container Registry Repository Catalog Lister role does not support ABAC conditions; assigning it grants permissions to list all repositories in a registry. Important role behavior changes in ABAC mode When a registry is ABAC-enabled by configuring its permissions mode to “RBAC Registry + ABAC Repository Permissions”: Legacy data-plane roles such as AcrPull, AcrPush, AcrDelete are not honored in ABAC-enabled registries. For ABAC-enabled registries, use the ABAC-enabled built-in roles listed above. Broad roles like Owner, Contributor, and Reader previously granted full control plane and data plane permissions, which is typically an overprivileged role assignment. In ABAC-enabled registries, these broad roles will only grant control plane permissions to the registry. They will no longer grant data plane permissions, such as image push, pull, delete or repository list permissions. ACR Tasks, Quick Tasks, Quick Builds, and Quick Runs no longer inherit default data-plane access to source registries; assign the ABAC-enabled roles above to the calling identity as needed. Identities you can assign ACR ABAC uses standard Microsoft Entra role assignments. Assign RBAC roles with optional ABAC conditions to users, groups, service principals, and managed identities, including AKS kubelet and workload identities, ACA and ACI identities, and more. Next steps Start using ABAC repository permissions in ACR to enforce least-privilege artifact push, pull, and delete boundaries across your CI/CD systems and container image workloads. This model is now the recommended approach for multi-tenant platform engineering patterns and central registry deployments. To get started, follow the step-by-step guides in the official ACR ABAC documentation: https://aka.ms/acr/auth/abac
Azure AD PIM token lifetimes
Does anyone know if Azure AD PIM has any impact on token lifetimes? I know an access token remains valid for 1 hour whereas a refresh token can have long life. Does this mean if user activates their role for only 30mins, they will continue to have privileged access for at least one hour unless user explicitly logs-out of the session.
Set Force a user to change password on next logon via Powershell
I have created a script to try and change the user setting 'force password change at next login'. I wish to do this without having to change their password. I have tried both user authentication (using a global admin account) and application authentication (via Client Secret). When I run the script in either authentication context I get access denied when it comes to updating the user. The script was to read in a csv file and do this but I have simplified a script to the following to show the basic concept of the commands I am trying to run and the authentication process. $secureSecret = ConvertTo-SecureString "xxxxxxxxxxxxxxxxx" -AsPlainText -Force $credential = New-Object PSCredential("xxxxxxxxxxxxxxxxxxxxx", $secureSecret) Connect-MgGraph -TenantId "xxxxxxxxxxxxxxxs" -ClientSecretCredential $credential Get-MgUser -UserId "email address removed for privacy reasons" -Property "userPrincipalName,userType,onPremisesSyncEnabled" Update-MgUser -UserId "email address removed for privacy reasons" -PasswordProfile @{ForceChangePasswordNextSignIn = $true} In the application I have created I have assigned the permissions I believe would be required to support this action (I added Directory.ReadWrite.All, just in case) The read user works fine but I get the error below when trying to update Update-MgUser_UpdateExpanded: Insufficient privileges to complete the operation. Status: 403 (Forbidden) ErrorCode: Authorization_RequestDenied Date: 2025-10-15T13:36:46 I have tried this is two different 365 tenants but both fail with the same error. The tenant is a cloud only with no synchronisation from on-premise. I have tried many iterations but have reached the dead end point. Is it possible to force a password reset via a PowerShell script and if so what am I doing wrong with my permissions? TIA
Not able to logon office 365 account or change it
If I want to logon to my Office 365 account I have to enter my emailaddress. Its is an @.onmicrosoft.com account. Entering password is ok, but then I am have to verify my phone number. The last two digits are shown, but clicking on this phone number I am getting an error like: 399287. There is no way of resetting this. I already contacted helpdesk but they cannot solve this problem. I have a bussniess account and I need some help about this. Every time I want to reset or want to make a change the account I am stuck in this error screen (endless loop). Please help me.Problem restoring deleted user with mggraph
Hello, I have done a few 365 migration and almost everytime there are some user data that has been missed in the migration. Earlier I solved this by restoring the 365 user in the source tenant to another domain using this msol script in powershell: Restore-MsolUser -UserPrincipalName email address removed for privacy reasons -Verbose Restore-MsolUser -UserPrincipalName email address removed for privacy reasons -Verbose -AutoReconcileProxyConflicts Restore-MsolUser -UserPrincipalName email address removed for privacy reasons -Verbose -AutoReconcileProxyConflicts -NewUserPrincipalName email address removed for privacy reasons I know it is not perfect but it worked well and saved a bunch of times. I have now done another migration now and got the same issue so I need to restore the users so we can access the data again and move it. BUT! I realized today that msol service is no more, so I am kinda stuck with figuring this out in mggraph. I have tried for a few hours now and I am not sure if this even possible with mggraph. Whenever I try to build a script using Restore-MgDirectoryDeletedUser/Item which google, copilote etc tells me to use I only get this error: The term 'Restore-MgDirectoryDeletedUser/item' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. Or I get that it "works" but that the proxy/domain conflicts: Errors detected while trying to restore the user restoreUserErrors: ErrorValue:<pii><pii>E*****.E*******</pii>@domain.com</pii> ObjectType: ConflictingObjectId:, ErrorType:UserPrincipalName, ErrorId:InvalidDomainErrorValue:<pii>smtp:<pii>ee</pii>@domain.com</pii> ObjectType: ConflictingObjectId:, ErrorType:ProxyAddress, ErrorId:InvalidDomain Status: 400 (BadRequest) ErrorCode: Request_BadRequest Date: 2025-09-08T13:49:36 Since I do not have the first domain in the source tenant anymore I need to restore the user to a different domain. Does anyone have any idea on how I can recreate the msol version to mggraph? I feel like I have tried everything to my knowledge now so hopefully anyone here can give me help or tips. Thanks! /AdamPeople Settings Appear in the Microsoft 365 Admin Center
The Org Settings section of the Microsoft 365 admin center has a new People Settings section where you can choose properties for the Microsoft 365 profile card instead of using PowerShell. The kicker is that the old method of using Exchange custom properties to customize what appears on the profile card is being replaced with standard Entra ID properties. A migration is needed, and it’s easily done with PowerShell. https://office365itpros.com/2025/09/04/microsoft-365-profile-card-2/Develop Custom Engine Agent to Microsoft 365 Copilot Chat with pro-code
There are some great articles that explain how to integrate an MCP server built on Azure with a declarative agent created using Microsoft Copilot Studio. These approaches aim to extend the agent’s capabilities by supplying it with tools, rather than defining a fixed role. Here were some of the challenges w encountered: The agent's behavior can only be tested through the Copilot Studio web interface, which isn't ideal for iterative development. You don’t have control over which LLM is used as the orchestrator—for example, there's no way to specify GPT-4o. The agent's responses don’t always behave the same as they would if you were prompting the LLM directly. These limitations got me thinking: why not build the entire agent myself? At the same time, I still wanted to take advantage of the familiar Microsoft 365 Copilot interface on the frontend. As I explored further, I discovered that the Microsoft 365 Copilot SDK makes it possible to bring in your own custom-built agent.
