Fido passkeys blocked by policy
Hi all I'm helping out a customer with deploying physical passkeys and I'm running into a weird error. I've activated the sign in method and selected the two AAGuids for the Authenticator app and I've added the right AAGuid for the brand and model of passkey we are using. We can select the authentication method and enroll the security correctly but when trying to sign in using it we get the error as displayed in the attached picture. When checking the sign in logs i get this error message FIDO sign-in is disabled via policy and the error code is: 135016 I've not been able to track down any policy that would be blocking passkeys. anyone got any ideas?
Migration from Hosted Exchange (Hybrid) to M365 Classic Outlook Client Problems and Solutions
Hello Everyone, I'm a tech who started on a 8088 processor in the 80's. Not mentioning the Vic20 and C64 since that hardly seem relevant! I'm posting here to hopefully help the next person with the issues I've had over the last few weeks. My client had to port his email from a provider with an on-perm Exchange server in a Hybrid setup with M365 to his own M365 environment. I expected this was to be about 3 hours of work for me - setup M365 environment, plan the cut-over window, update the Outlook clients on each PC. It ended up being roughly 20 hours of my time and at least 10 hours of dedicated time for my client. For those wanting to jump directly to what mostly fixed it use this link, it should get you past the dreaded "an encrypted connection to your mail server is not available" when trying to add the mail account into a clean profile. Use https://support.microsoft.com/en-us/windows/classic-outlook-troubleshooters-086e3d66-5404-4034-9cc5-545909dcc166 and pick "Classic Outlook Profile Setup Troubleshooter" Most hits are going to tell you its an autodiscovery issue, but if you're reading this I'm going to assume you've already confirmed that. Our issue was some ghost configuration, only on the PCs previously setup for mail on the old server. A new PC could add the same account without issue. Some of the research suggested this would not happen if the proper Microsoft migration process is followed to move the account - but in our case the previous provider was unable to perform the migration. I'll skip over the research we tried along the way, such as New Outlook Profiles, Registry entry changes, MS Personal users with the same email as MS Business Users, Autodiscover problems (including concerns that the base website for the client was offering invalid data), and so on. After each hit where we applied a fix we again had to try adding the mail to the profile, and each time we sat watching the little circle for up to 5 minutes only to get the same error. Now, once we found the link above - which did not come up in most searches - things got better, but not 100%. We added the profile ok but then Outlook gave a permission error while starting. To fix that, the user signed in must have administrative access and you use File Explorer to navigate to the folder identified in the error. In our case it was in folders kept under \Windows\System32\. When prompted that we need to grant permanent access we said yes. In our case this is where Outlook was storing the ost files. That worked for most of the clients, but we had one additional issue where the error was pointing to a folder that didn't exist. Just creating the folder was not enough, the final fix was to hold CTRL-SHIFT down while opening Outlook to start in administrative mode to allow it to create the ost file in the newly created folder. Finally 3 weeks after our cut over window, while the client had to use OWA, we were able to get outlook running. This was critical for my client because they did not have access to the mail history since the migration didn't happen - they had to open a copy of their PST in Outlook and use mail in OWA and constantly bounce back and forth. I hope this helps someone avoid the pain we went though!
Sole Microsoft 365 Admin Locked Out After Phone Replacement / Lost MFA Device
I am the sole admin for a Microsoft 365 tenant and I am currently locked out after replacing my phone. The old phone was wiped before Microsoft Authenticator was fully re-registered on the new device. Authenticator was the only MFA method configured on the account. Current situation: password is known, Teams desktop sessions are still active, Authenticator cloud backup restored successfully, but all Microsoft security and admin pages still require approval from the old Authenticator registration. I cannot access Security Info, Entra Admin, or Microsoft 365 Admin Center because every path loops back to the dead MFA registration. I have already attempted Microsoft business support phone lines, Authenticator restore and recovery, and existing desktop sessions, but support queues are disconnecting and I cannot open business support tickets because the admin account itself is MFA locked. Tenant: lowepfg.onmicrosoft.com What is the fastest recovery or escalation path to force MFA reset or re-register Microsoft Authenticator for the tenant admin account?Signing in to Microsoft Foundry from OpenClaw using Azure AD: a smoother way to bring your models in
This post is a quick update to walk through the new flow. If you read the previous one, think of this as the easier path I wish I had the first time round. If you have not seen the original, you can find it here: Integrating Microsoft Foundry with OpenClaw: Step by Step Model Configuration | Microsoft Community Hub Pre-requisite: You will need the Azure CLI (azure-cli) installed on your machine. The official install guide for Linux is here: https://learn.microsoft.com/en-us/cli/azure/install-azure-cli-linux?view=azure-cli-latest I am on Linux so I went the Homebrew route, which keeps things simple. The formula is here: https://formulae.brew.sh/formula/azure-cli Microsoft also has official docs covering the Homebrew/Linuxbrew install: https://learn.microsoft.com/en-us/cli/azure/install-azure-cli-macos?view=azure-cli-latest#install-with-homebrew Once Homebrew is ready, run this in your terminal: brew install azure-cli Why this matters: Before this update, every Foundry model you wanted to use in OpenClaw needed its own API key and endpoint pasted into the config. It worked, but it was tedious, and keys are easy to leak if you are copying them around. The Azure AD path solves both problems. You authenticate as yourself (or a service principal), OpenClaw asks Azure for the list of Foundry resources you have access to, and it brings the models in automatically. Signing in to Microsoft Foundry from OpenClaw via Azure AD A device-code OAuth handshake replaces the old static-API-key flow. OpenClaw delegates auth to the local Azure CLI; the CLI handles the browser-side sign-in, holds the resulting tokens, and refreshes them silently. OpenClaw then walks the Azure resource graph, subscriptions → Foundry resources → model deployments and registers each model into its own config. No API keys move through OpenClaw at any point. Sequence diagram of the OAuth 2.0 device-authorization flow as orchestrated by OpenClaw. Phases 1–3 establish identity (the developer authenticates once, in a real browser, against Azure AD). Phases 4–5 perform service discovery (OpenClaw walks the ARM resource hierarchy, subscriptions → Foundry accounts → model deployments and persists the result to a local provider config). After registration, every model call OpenClaw makes against Foundry reuses the same Azure-CLI-managed token cache: tokens refresh transparently, and access is gated by the Foundry resource's RBAC assignments rather than a static API key. Dashed lines denote return values; the teal line in step 7 marks the single token-issuance event the rest of the system pivots on. Walking through the new flow: Start with the command to onboard openclaw as if you were setting up OpenClaw for the first time: openclaw onboard Kick things off with the OpenClaw onboard command, the same one you would use when setting up OpenClaw for the first time. When it prompts you, choose update values. Next, you will be asked to configure your models. Scroll down a little and you will see Microsoft Foundry listed as a supported provider. Pick it. From here, you have two options. You can sign in with an API key, which is what I covered in the previous blog post, or you can sign in through Azure AD. The Azure AD path is easier and more secure, so that is the one we will use. OpenClaw will give you a URL and a device code. Copy the URL into your browser and use the code to complete the sign in. (This is where the az CLI from the pre-requisite section earns its keep.) If everything worked, you should see a success prompt similar to this: Once you are signed in, OpenClaw will ask you to pick the Azure subscription that your Microsoft Foundry resource lives in. Pick the subscription, then pick the Foundry resource where your models are deployed. And that is pretty much it. All the models you have deployed to that Foundry resource get pulled into OpenClaw automatically. Compared to the old way of pasting API keys and endpoints one by one, this is a huge time saver, and you do not have to babysit any keys. From here you can start using your Foundry-deployed models inside OpenClaw straight away: Wrapping up The Azure AD sign-in option in OpenClaw is one of those small updates that quietly removes a real pain point. If you have ever juggled multiple Foundry endpoints and rotated keys across them, you already know why. With this flow, you sign in once, your models show up, and you can get back to actually building. If you have not tried OpenClaw with Microsoft Foundry yet, this is a good time to give it a go. And if you were holding off because of the key management overhead, that excuse is gone now. References Previous post on integrating Microsoft Foundry with OpenClaw using API keys: Integrating Microsoft Foundry with OpenClaw: Step by Step Model Configuration | Microsoft Community Hub Install the Azure CLI on Linux: https://learn.microsoft.com/en-us/cli/azure/install-azure-cli-linux?view=azure-cli-latest Install the Azure CLI on macOS: https://learn.microsoft.com/en-us/cli/azure/install-azure-cli-macos?view=azure-cli-latest#install-with-homebrew Homebrew formula for azure-cli: https://formulae.brew.sh/formula/azure-cliApril 2026 Recap: Azure Database for PostgreSQL
April brought several updates for Azure Database for PostgreSQL, focused on improving developer productivity, strengthening security and connectivity, and helping customers scale and optimize their PostgreSQL workloads. From new Entra ID token refresh libraries across .NET, JavaScript, and Python to simplify authentication, to guidance on migrating from VNet to Private Endpoint capable configurations, we continue to make it easier to build and manage secure applications. We also introduced enhancements to the PostgreSQL VS Code extension and published deep dives on query performance, data modeling, and real-world scaling patterns. We also published a blog on how PostgreSQL enters its AI era, which explores ways with which developers can adapt PostgreSQL to meet the needs of AI-driven and rapidly growing applications, with practical guidance on running and scaling PostgreSQL more effectively in these evolving workloads. POSETTE 2026 Before we dive deeper into the feature updates, POSETTE: An Event for Postgres 2026 is just around the corner, PostgreSQL’s free, virtual conference bringing together the global community. Taking place from June 16–18, the event will feature four livestream tracks with a strong lineup of content, including 44 sessions, 2 keynotes, and 50 speakers. It’s a great opportunity to hear from PostgreSQL experts, learn about the latest trends, and discover real-world best practices across a wide range of topics. Register today for updates and be part of three days of learning, insights, and community-driven discussions across a wide range of PostgreSQL topics. Features Entra-ID token refresh libraries for .NET, JavaScript, and Python: Preview Migrating from VNet to Private Endpoint: Preview New enhancements in the PostgreSQL VS Code Extension Improving Query Performance and Modeling in PostgreSQL Scaling PostgreSQL for Real-World Application Workloads Learning Bytes: Preventing accidental server deletion Entra-ID Token refresh libraries: .NET, JavaScript and Python We’ve introduced Entra ID token refresh libraries for .NET, JavaScript, and Python to simplify how applications authenticate with Azure Database for PostgreSQL using Entra ID. When using Entra ID–based authentication, access tokens are short-lived and need to be refreshed periodically. This often requires additional logic in the application to handle expiration, retries, and reconnection scenarios. These new libraries take care of that complexity by automatically refreshing tokens behind the scenes, so applications can maintain uninterrupted database connections without custom token management. With built-in support for token renewal, these libraries help: Reduce the need for manual token refresh logic in your application code Improve reliability for long-running or connection-pooled workloads Simplify adoption of Entra ID authentication across different language stacks Whether you're building new applications or migrating existing ones to use Entra ID, these libraries make it easier to integrate secure, passwordless authentication while keeping connection handling straightforward. Migrating from VNet to Private Endpoint Azure Database for PostgreSQL flexible server can now be migrated from a VNet‑integrated deployment to a network configuration that supports Private Endpoint connectivity. Servers originally deployed inside a VNet may require greater flexibility in networking management. Private Endpoints provide a simpler and more scalable model. Following migration, private access to the server continues over Azure’s backbone network, dependency on delegated subnets is reduced, and database networking can be better aligned with evolving architectural or organizational standards. The migration can be initiated through Azure CLI, API, or SDK and is designed to be straightforward. Although the operation involves a period of downtime, it enables adoption of Private Endpoint connectivity without recreating the server or manually moving data. After migration, Private Endpoints or firewall rules can be configured based on the desired access model, and infrastructure-as-code templates can be updated accordingly. Read more here: Migrate from VNet to a Private Endpoint Capable Network Configuration | Microsoft Learn New enhancements in the PostgreSQL VS Code Extension The latest release (v1.21) of the PostgreSQL VS Code extension delivers enhancements to query authoring and analysis workflows, improved cross-extension interoperability, reliability improvements across Object Explorer and connection management, and a set of targeted bug fixes. Schema-Aware Query Creation: You can now open a new query directly from a schema in Object Explorer, automatically setting the appropriate search_path so unqualified object names resolve correctly without additional setup. Query Plan Visualization Enhancements: The query plan visualizer now uses PostgreSQL-specific node icons across all views, making it easier to identify scan, join, and aggregate operations during performance analysis. Improved Multi-Extension Compatibility: The extension now coordinates editor ownership with the MSSQL extension when both are installed, reducing duplicate UI actions and avoiding conflicts in query execution workflows. Object Explorer Reliability Improvements: The Object Explorer has been refactored for more consistent refresh, expansion, and reconnection behavior, especially in long-running sessions and databases with many schemas. Enhanced IntelliSense Behavior: IntelliSense now respects the configured search_path, improving the relevance of suggestions and helping you work more efficiently across schemas. Bug Fixes: This release includes fixes across object scripting (including partitioned tables), connection profile handling, Docker container creation, and initial extension setup for improved reliability and stability. Improving Query Performance and Modeling in PostgreSQL This month, we also shared a set of technical blogs highlighting advanced PostgreSQL scenarios and practical guidance for real-world workloads: Guide on workload observability with Query store: This blog dives into how Query Store can be used to gain end-to-end visibility into query performance across both primary and replica nodes. It highlights the importance of understanding query behavior in distributed setups and how bottlenecks can surface differently across nodes. The post also shares practical guidance on using these insights to troubleshoot issues and optimize workload performance effectively. Guide on Common Table Expressions(CTEs) with Data Skew: This deep dive unpacks a complex query planning scenario in PostgreSQL v17, where data skew can lead to unexpected and suboptimal execution plans involving CTEs. It explains why the optimizer may choose inefficient plans and how this impacts real-world workloads. The blog also outlines strategies to diagnose and mitigate these issues, helping users better predict and tune query performance. Guide on PostgreSQL as a Graph Database: This blog explains how PostgreSQL can be leveraged to model and query graph-like relationships, making it highly relevant for AI-driven applications. It demonstrates how relational capabilities can be extended to support graph workloads without introducing additional systems. The post also highlights practical patterns and use cases that enable developers to build more connected, intelligent applications using PostgreSQL as a unified data platform. Scaling PostgreSQL for Real-World Application Workloads Alongside performance tuning and data modeling topics, we also explored how PostgreSQL behaves under real-world application patterns especially in scenarios involving high concurrency, background job processing, and connection-heavy workloads. These blogs focus on common architectural choices developers make and the trade-offs to consider when scaling reliably. Guide on using Postgres as a Job Queue: Thisblog takes a deeper look at the implications of using PostgreSQL as a job queue, a pattern commonly adopted for simplicity and tighter integration. It walks through how queue-like workloads can introduce contention due to frequent updates, row locking, and long-running transactions. The post highlights how these patterns can impact throughput, vacuum efficiency, and overall database health as scale increases. It also discusses when this approach is appropriate, and when teams should consider dedicated queuing systems to avoid performance bottlenecks. Guide on Connection Scaling with Elastic Clusters: This blog dives into the challenges of handling large volumes of concurrent connections, which is a common bottleneck for modern, microservices-based applications. It explains how Elastic Clusters help distribute connections and workload across multiple nodes, improving scalability and resilience under heavy load. The post also touches on connection management patterns, including pooling strategies, and how they work in conjunction with Elastic Clusters to prevent resource exhaustion and ensure consistent performance at scale. Azure Postgres Learning Bytes 🎓 Preventing accidental server deletion In production environments, accidental deletions can lead to significant downtime and data loss. To safeguard critical resources like Azure Database for PostgreSQL servers, Azure provides resource locks that add an extra layer of protection beyond standard role-based access control (RBAC). A commonly used option is the CanNotDelete (Delete Lock), which ensures that a resource cannot be deleted even by users with elevated permissions until the lock is explicitly removed. You can apply a delete lock easily using the Azure CLI by targeting the specific resource: az lock create --name PreventDelete --lock-type CanNotDelete --resource-group <rg-name> --resource-type Microsoft.DBforPostgreSQL/flexibleServers --resource-name <resource-name></resource-name></rg-name> Once applied, any delete operation on the resource will be blocked, helping prevent accidental or unintended deletions during maintenance, deployments, or testing. Locks can be applied at different levels subscription, resource group, or individual resources allowing flexibility based on your protection needs. For more details and step-by-step guidance, read our blog on Preventing accidental deletion of an Azure PostgreSQL Instance.passkeys in the Authenticator app regarding attestation
I have a question about passkeys in the Authenticator app regarding attestation in connection with QR code-based cross-device sign-in. When we register a passkey with attestation enabled in the Authenticator app, it can be used to complete the sign-in process on another device via QR code and Bluetooth Low Energy. According to Microsoft’s documentation, this shouldn’t be possible with attestation enabled, yet it works. What are we misunderstanding here? https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-enable-authenticator-passkey Thanks for your inputs. Johannes
Web-signin 3rd party IDP not working
We have a working Entra ID SAML federation to a third-party IdP that uses FIDO2/WebAuthn (IdP as Relying Party) for browser sign-in, and we are trying to use the same federation through Windows Web sign-in on an Entra-joined Windows 11 device — but the IdP page loads blank in the WebView and Microsoft-Windows-WebAuthN/Operational records zero events, while the same security key works fine for FIDO2 sign-in with login.microsoft.com as RP on the same device. Questions: - Is WebAuthn brokering to third-party Relying Parties inside the Web sign-in WebView supported? - If not, is it on the roadmap? - What is the supported architectural path for delivering passwordless Windows sign-in using a federated IdP's own FIDO2/WebAuthn credentials, given Graph API passkey provisioning is Beta-only?
How to target Azure VPN (Microsoft-Registered) app with Conditional Access Policies?
I have an Azure Point-to-Site VPN Gateway configured using the Microsoft-registered Azure VPN Client App ID (Audience value: c632b3df-fb67-4d84-bdcf-b95ad541b5c8). Everything is working correctly for our users. The issue I am having is that anyone with an Entra account can connect to the VPN and I want to restrict this with a blocking Conditional access policy. I do not want to create a custom app registration, because then I will have to change the 'audience' value on the app gateway and all user's will need to modify their VPN clients. The problem is I need to target the Microsoft-registered Azure VPN app in a Conditional Access policy but it does not appear in my Enterprise Applications list or in the CA app picker when searching. My questions: Why does the Microsoft-registered app not automatically create a service principal in my tenant the way other Microsoft apps do? Is there a supported way to make it appear in the CA app picker without creating a custom app registration or changing the gateway Audience value? Has anyone successfully targeted c632b3df-fb67-4d84-bdcf-b95ad541b5c8 in a CA policy while keeping it as the gateway Audience value? Thanks for the assistance hereHow Do I Target the Azure VPN Client in a Conditional Access Policy?
I am using the Azure VPN Client to connect users to an Azure VPN Gateway using their Entra ID credentials to authenticate. I want to target this application with a CA policy that requires MFA every time it connects. The problem is that I don't see the applications in my Enterprise Apps and all of my searching says that it won't appear because it was "pre-certified" by Microsoft. In the Gateway setup I used the Audience GUID of c632b3df-fb67-4d84-bdcf-b95ad541b5c8. And this is working as expected. The only solution that I have found for targeting the Azure VPN Client app is to create a Service Principal using that Audience GUID. This seems like a bit of a hack, so I am posting here to see if there are any other methods that I am missing to target this app when it doesn't appear in my Enterprise Apps list.
