How should home and small org users address Kali365 Hijacking Microsoft 365 Access Tokens?
How should home and small organization small business users address the recent Federal Bureau of Investigation Public Service Announcement “to warn the public about an emerging Phishing-as-a-Service platform called Kali365, first seen in April 2026” See Alert Number I-052126-PSA 21 May 2026
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.Broken Account Recovery (discontinued product)
Hello everyone, We have the MSFT Office Family plan which has the now discontinued custom domain support that used to be an option as a "Premium" feature. Back in August we upgraded the phone of one of the account members on the family plan and lost connection to their MS Office account with the only device that was accessing to the account (the phone with access was reset as part of the upgrade/trade in process). I have tried the account recovery form and it simply doesn't work. I have tried to explain to MSFT support that the tool is broken but can't get anywhere. For the account in question we have an Outlook email client (with non working password) that has a cache of all of the email until loss of access occurred. So when I do the account recovery form, I have name, DOB, region, past passwords and data for all fields including sent email Id's and send subjects, But every time the MSFT recovery mechanism says "Unfortunately, we have determined that the information provided was not sufficient...". WTF. Every time I contact MSFT support I get the same answer, an explanation of the point system used to reset the the account. Same steps to recover....based on this, the recovery should work...yet it doesn't. I have tried somewhere 50+ attempts now over the last 9 months. I even have a contact who is VP level at MSFT who sponsored a support ticket internally but that just ended up with the support person sending me a link to the account recovery form and closed the ticket without looking in the details of the ticket. I can't modify / add a new account as MSFT has as a discontinued product no longer allow members to add/change id's. So I'm locked at the current user set. I have created another email address by saving the cached data to OLM file and importing via the Outlook client but that doesn't restore use of the @mydomain.com for that person. I even retained a lawyer who send a demand to MSFT legal...but the email address didn't go anywhere so at the point of needing to do this on headed paper/send via snail mail. Does anyone have any idea how to get through to MSFT explain the recovery tool is broken? I assume there are so few accounts using custom domains pin family plans that they simply don't test this recovery path. At this point without some internal guidance is a) lawyer and force a demand for password reset b) give up, ditch all of the users using the custom domain, configure an alias for all of the accounts and then change my MX record to a company doing email forwarding and then forward to the new/old legacy accounts (i.e. the ones with the mailto:email address removed for privacy reasons).
Outlook 2016 blank MFA screen for some users
I have a Conditional Access rule so that when someone connects from outside a trusted IP it requires MFA, I have a few users that get the "Requires password" message come up, they get a window and type in their username and click next, then the window disappears without prompting for MFA and it's back to where they were. Same thing if they go to File->Accounts if they are signed out and try to sign in they get asked for Email and then it just closes and they are still signed out. It's not for all users and everyone is using the same Office 365/2016 installation, monthly channel 1903, we use ADFS
Frequent Account lockouts
We are having passthrough authentication setup and we see lot of errors recently with the below process Process Information: Caller Process ID: 0x8e4 Caller Process Name: C:\Program Files\Microsoft Azure AD Connect Authentication Agent\AzureADConnectAuthenticationAgentService.exe Users are getting locked out too frequently. The auditing software points to the server where AD connect is installed. I am not sure why this is happening but need your advice and suggestions please. Thank you all.
NgcSet stays NO despite working WHFB setup - RPC 0x800706ba error
Hi everyone, I need help with a Windows Hello for Business certificate trust deployment that's almost working but stuck on the final step. **What's Working:** - Manual certificate enrollment works perfectly: `certreq -enroll -user -config "MyCA.domain.local\MyCA-CA" "MyWHFBTemplate"` - TPM 2.0 is ready, enabled, and functional - All Group Policies applied correctly (computer and user) - CA server healthy, templates published **What's NOT Working:** - `dsregcmd /status` shows `NgcSet : NO` (should be YES) - `NgcSvc` (Microsoft Passport) service is stopped on client - Getting error: "RPC server is unavailable (0x800706ba)" during automatic certificate enrollment - PIN setup fails because NGC containers won't create **The Strange Part:** Manual certificate enrollment works perfectly, but automatic enrollment fails with RPC errors. Both should use the same communication path to the CA. **Environment:** - On-premises certificate trust deployment (no Azure AD) - Domain-joined Windows 11 clients - Windows Server 2019/2022 infrastructure **Questions:** 1. Should NgcSvc start automatically when WHFB policies are applied? 2. Why would manual cert enrollment work but automatic fail with RPC errors? 3. Is there a difference in how system context vs user context accesses the CA? Has anyone seen this specific combination before? Any ideas what could cause this behavior? Thanks for any help!
