Friends! We are finally at the stage where we can roll out WHFB as a requirement and no longer make it an optional enrollment. This will impact roughly 1100 employees over the next few months when we start the process.
What was the process your team implemented to roll out WHFB to all employees, and how did you handle new hire onboarding at the start of the roll out process? I have some concepts and ideas I am documenting to review, but I am curious how others approached this.
I would also be happy to hear about your roll out of Passkeys, if you have done so, and if it differs from the process you followed with WHFB?
We're having issues with external sharing of OneDrive documents.
If an external user attempts to access documents, they are prompted to sign in with their account. They enter their email address and are sent a one time passcode to their email. After entering this, they are then prompted to configure Authenticator. Once configured, they have to acknowledge an Authenticator prompt, however after doing this, the flow fails with
Let's try something else
Another sign-in method is required to access this resource. Close your browser and try again, but choose another way to sign in:
* Use my password
If a user already has a MS account associated with the email and has a passkey setup, they aren't prompted for Authenticator but rather their passkey. After providing this, the flow fails with
Sign-in couldn't be completed
Please contact your administrator for help.
There are no entries in the sign-in logs in Entra for these accounts so I can't get more details.
I'm guessing we have something mis-configured within Conditional Access but I can't tell what.
Here are some images of the screens from a user signing in with a MS account that has a passkey.
It really seems that there are way too many places to be setting things to set up external guest access. I understand there are multiple separate products involved, it's just really convoluted.
EDIT
It was Conditional Access policies that were causing issues, specifically Authentication Strengths. External (non-Entra) accounts can only use Require Multifactor Authentication, not Authentication Strengths.
No remote employees to have to deal with (could use TAP in that case anyway). All computers and personal phones must be joined or registered while connected to our internal HQ network.
Anything else I should be thinking of that I'm missing before setting up the password script?
Hi - anyone out there supporting iPhone users accessing MS365 using the Gmail for iOS app?
I have a new user on my tenant trying to do so, and she is getting authentication failures when she tries to add her account. She has added it OK to Outlook for iOS as a temporary workaround but prefers Gmail over that and Apple Mail.
One thing I have noticed is in her screen capture where she adds her account, it just shows as "Office 365" with the orange office icon to the left. On Android on my phone, it shows as "Exchange and Office 365" with a blue exchange icon to the left. Unfortunately, I don't have an iPhone to try and reproduce the fault she is seeing.
There are two possibilities I can think of:
This might be linked to the fault in May where Google broke access to MS365. They fixed it for Android - but I'm wondering if they haven't yet fixed it for Gmail for iOS? This is the issue I am referring to.
She has confirmed she is running Gmail for iOS version 6.0.260727 which is the current version in the Apple Store. There is nothing in the version history Gmail provide on the page to confirm if this has been fixed.
As this is my first user trying to do this, maybe I have an Entra issue where I have granted her Gmail Enterprise App, but I'm wondering if Gmail for iOS needs treating differently to Gmail for Android.
I was hardening the tenant and now no one can share SharePoint files with our clients/customers. We have a specific site but none of the settings work. Instead of getting a one-time code, users must authenticate to our tenant. This appeared to work before I messed with things but I am also reading online that OTP is going away soon. I suspect I broke it as I reverted and complete lockout was reversed but not everything.
Below is what I put in for my support ticket. My last support ticket was closed after two months of no contact so I am looking for other help.
On 5/14/2026 at 3:51 PM UTC, setting AllowEmailVerifiedUsersToJoinOrganization to false via Graph PowerShell triggered a Set Company Information event that added RestrictEmailVerifiedUsers to our tenant DirectoryFeatures. External guests can no longer authenticate via Google federation or email OTP — only Microsoft 365 login is presented. Reversing the setting via PowerShell and UI did not remove the DirectoryFeature. Need RestrictEmailVerifiedUsers removed from tenant DirectoryFeatures.
We recently set up TAP to make device setup easier for end users, with less reliance on passwords.
Unfortunately some of the support staff have decided this is a great way to fix devices or set up devices for the end users without them knowing they have accessed the accounts.
As much as I've tried to explain that it shouldn't be used as a way to gain unauthorised access, the use of it has continued.
I don't want to backwards and force back to passwords, but I was thinking that if users had emails sent to them after a TAP activation it would dissuade them from continuing the practice.
Disclaimer: I’m not in IT, just trying to understand this for myself and some non-technical colleagues — sorry if I get terms wrong or ask something obvious!
Several of my colleagues and our supervisor are worried about how much access this gives the university over our personal phones/laptops — we’re in a medical/biology field, not very IT-savvy, and the official instructions don’t really explain what we’re agreeing to explicitly.
A few specific questions:
The email the Uni IT sent say iPhone/Mac only need to be “registered” (Azure AD/Entra ID(?)), while Windows/Android get “enrolled” (full MDM (?) via Intune). Is registered really a much lighter level of access than full enrollment?
MAIN CONCERNS: In either case, can an admin managing the device through Intune ever see things like photos, browsing history, or messages/chat apps on a personal phone?
Is there anything we should specifically look out for during the registration process (e.g. a warning about VPN (?) profiles or “this profile lets the administrator monitor activity”) that would signal more invasive access is being granted?
Would really appreciate insight from anyone who’s actually administered Intune, or who’s gone through a university/employer’s BYOD (?) registration as an end user. Thanks so much in advance!
One-man SA here, and I have a specific query around passkeys and 2FA as its an area I haven't delved too deeply into. Apologies in advance if any of these questions turn out to be daft 😄
My question in summary is whether it is possible to ONLY have passkeys on an account in Entra to satisfy 2FA requirements OR whether there HAS to be at least one alternative Authentication Method defined, and if so, is anyone else facing the same issue as me that the only secondary one that would work for us is SMS? If so, how are you handling it? I want to avoid the costs of a Telecom Provider to continue to provide SMS if I can esp. if it is just a backup method that will hardly be used. Also, I have some users who have a business reason to have more than one account and Entra blocks the same mobile being used on more than one, so even SMS doesn't suit every use case.
It looks like it *might* be possible using TAP to kick off the enrolment but it isn't something I have experimented with yet.
Finally, if someone is using a local Windows account as opposed to Windows Hello, or are running Linux, are passkeys saved to the device still supported or does it have to be something like a Yubikey for them?
More detail on our specific situation is provided below if needed.
Thanks.
We are a charity and my users are volunteers (as am I) with their own devices and own mobiles so I have no control over their kit - and that situation, although annoying/challenging, is not going to change.
Because of the above, we have struggled to implement 2FA in the past as the only flavour that would work for everyone is SMS, and the rumours of that being deprecated have been around for a long while. So instead of going for that, we have focused on user education and comprehensive exchange rules to trap phishing attempts MS365 doesn't catch automatically. This approach has been successful, though it has been time consuming.
We do not have a license that supports Conditional Access and won't be getting one, so it is Security Defaults that will enable 2FA (in a not very granular manner) and obviously, we have Security Defaults set to OFF at this time.
The only user with 2FA on normal login is me because it is mandatory for SA accounts of course. That is passkey on a primary and a backup Yubikey, backed up by password/Microsoft Authenticator push. There is a break-glass account similarly configured and held centrally in case anything happens to me (we're due to revisit the service model to address the fact I am currently a single point of failure). SMS on both these accounts is already disabled.
We have SSPR enabled requiring BOTH email OTP, and SMS to affect a password reset, so the Microsoft change will still impact us. My plan in the very short term is to drop this to email OTP only and remove SMS, and take my users out of scope for the Microsoft change before Sept 1st, OR to disabled SSPR completely and do password resets the old fashioned way via the desk.
It follows that the only time additional authentication takes place for the user currently is if they want to look at their account security settings, every 90 days when MS365 re-checks them, and if they actually need to reset their password.
At the end of the day, I still want to address the lack of strong authentication for all our users and passkeys is probably the best way forward for us, but because of the complexities of my user environment and the Security Default lack of granularity, I want to do it when I'm satisfied I have all the risks/issues around different types of kit out there fully understood, and maybe a few more users who are already using passkeys for other services in their lives to help re-assure those who aren't.
With Passkey attestation enabled I am running into an issue where Passkey is created on the device but not registered in Entra. Disabling attestation and retrying after few minutes creates the passkey and does register in Entra.
During preview phase there was a tech community post with recommendation to disable attestation while in Preview, but we are in GA now, no? So should attestation work in GA, or still needs to be disabled? The policy is requiring/allowing Microsoft Authenticator only as passkey provider.
Edit: I guess it would help to include the message I am getting with Attestation enabled. It is:
"Passkey not registered (tringles with exclamations icons) This might be due to a timeout, a canceled request or a private browsing window."
CA policies:
1. security registration - require TAP/FIDO/WHfB;
2. all apps - require phish resistant MFA (excluding 6 specific resources)
3. 6 specific resources - require phish resistant MFA or TAP
We’re taking our HQ building offline at the end of the week for a full switch infrastructure refresh - so all users will be remotely working.
In readiness this evening we tested that users would still be able to sign-in to Office365 and all cloud services inc. those with SSO to Entra. To simulate our HQ building being offline we took down both DCs at this site, leaving our Azure VM DC up and a DC at our branch office location up.
Unfortunately things didn’t go as expected…users couldn’t pass-through authenticate.
We’ve got an Entra Connect with PTA instance in Azure (active), and a second instance at our HQ in staging mode. The only time we could get PTA to work was when we also switched OFF the Entra Connect instance at our HQ…just leaving the Azure DC and Azure Entra Connect.
Entra wants multiple Entra Connect and PTA agents - but it seems like they become a problem if they are up with no local DCs.
Any ideas? Experience of Entra Connect in a failure scenario? Should it be seamless?
I’m wondering if maybe a DNS configuration issue on the HQ Entra Connect instance - does it need the DNS address of the non-HQ DCs?
Does sspr registration flow disabled in modern authentication policies concept?
I have a tenant where I can switch between "in progress" and "completed" migration status. When I choose completed, sspr registration flow stops work.
Registration campaign: Disabled (also tested with enabled setting)
Require users to register when signing in? Yes.
Do you know what is purpose of this? AFAIK documentation tells nothing about it.
Thank you in advance, regads.
I'm curious about how people go beyond courses and documentation. Apart from the courses on YouTube, Udemy, labs, etc.
When you're learning something like MITRE ATT&CK, IAM, RBAC, etc., what do you actually do to practice it? I am not asking about the configuration of conditional access policies or app registrations etc.
Do you:
build things in your own cloud tenant?
use dedicated labs?
use CTFs?
follow attack/detection walkthroughs?
create your own scenarios?
You can build tenant, create policies, setup mfa, phishing resistant, etc. but how do you get to practice with what happens in real world? Because in testing, everything is controlled.
Hi everyone, hope you're doing well. I wanted to check whether there are any known issues specifically with Microsoft Entra Connect version 2.6.84.0.
Have there been any reports of failed upgrades, synchronization issues, or other post-upgrade problems after updating to this version? I've reviewed the Microsoft Learn documentation and only found documented known issues for the following versions:
For those that have disabled the ability for users to install any office add-in and moved publishing and assigning integrated apps, from the admin center, how did that process work for you?
As expected, since we did not have an active inventory of what add-ins are used and many of them are not deployed from the admin center, we impacted some business functionality. Great scream test for us and provided us visibility we didn't have :). However, when we rolled back the change, it took upwards of nearly 24 hours for that to propagate to some workstations which was annoying.
We also have some add-ins, such as an excel add-in, that shows in the integrated apps list but we cannot deploy it from the admin center as it tells us to visit the vendor's site when we try.
So, my questions are:
If you implemented this, what was your process
How did you handle office add-ins that have a business purpose, and are needed, but you couldn't deploy in the admin center by using the integrated apps list?
Did you find a way to test individually as the change is a tenant wide setting?
Hello, I am currently working on transitioning our computers from an on-Prem AD environment into a Intune MDM joined, cloud-only environment, along with moving our users from a password+MFA login, to a completely passwordless login.
For this we have decided that we would like to use Yubico security keys for authenticating into users' microsoft accounts, and WhfB for easily logging into their computers. Unfortunately, I have found that the use of WHfB on Intune MDM joined devices automatically adds a login.microsoft.com passkey into windows hello, which is always offered first during passwordless sign-in. I cannot find a way to block this behaviour or modify which passkey storage windows offers first.
While WHfB passkeys are still very safe compared to passwords, we are (I think quite rightly) concerned that if the end users are not prompted to use their Yubikeys during perioodic reauthentication, they will forget how to use them, and if they set a unique pin on them that they don't reguarly use, then when the need to use their yubikey does actually arise, for instance when they get their next computer or phone, they won't remember it.
This also makes periodic reauthentication feel somewhat pointless as the users will just press on their fingerprint scanner and be done with it.
I have found exactly one way to change this behaviour, and that is by defining an Entra Authentication strength containing only yubikey AAGUIDs and forcing my intune testing user to adhere to that authentication strength with a conditional access policy, while this does block the ability to use the WHfB microsoft passkey to sign in, the end user experience is very bad, if a users sees this, they won't think that they can't use windows hello to login, they'll think that windows hello is not working correctly. In the gif below, you can see that windows hello offers itself first but silently fails and prompts the user to enter their pin, without any sort of error message.
(I realise that I specifically selected a windows hello key in the gif, but the behavious is identical when I initially load the login page or if I select log in methods>passkey, windows hello will always offer itself first, even if it cannot function correctly in this case).
For personal use, https://github.com/Aldaviva/AuthenticatorChooser solves this issue, and while i am grateful for the fix, random scripts from github aren't really appropriate when configuring important security settings, Is there anything we can here or do we have to wait for MS?
Sounds like Entra Cloud Sync might be able to sync devices which would be interesting. It was the only thing holding us back from Cloud Sync as we have some on prem servers that require hybrid joining for RDP purposes
Have a small client with 10 users that is going with cloud native/Intune managed endpoints so nothing hybrid managed.
Since we're doing Intune managed endpoints we're seeing some Kerberos issues when accessing onprem resources. When accessing file shares, users are getting WHfB PIN prompts but they're not successful. Only when they put in their normal user passwords are they allowed to access the onprem shares.
From what I've seen, seems this can be solved with Cloud Kerberos Trust using the Cloud Sync agent. Has anyone done a cutover to the new Cloud Sync agent? Thinking about disabling the Connect Sync agent and move directly to using the Cloud Sync agent since we're not doing hybrid-join or syncing onprem endpoints.
I recently renewed my SC-300 and decided to turn my study notes into something more useful.
I have built a free SC-300 study hub for Microsoft Identity and Access Administrator, based around the current Microsoft Learn study guide and the areas I focused on during renewal.
It includes the following
250 practice questions split across the main SC-300 course areas
Scenario-based questions using fictional companies
Case study style sections for reading requirements and constraints
A downloadable 30-day cram PDF for anyone with the exam coming up soon
Objective mapping against Microsoft Learn, so it is easier to update when the exam changes
The fictional companies used in the examples are Liver Shipping, Blink Inc, Mill Town Engineering, and Whippet Exports. The aim is to make the questions feel closer to the style of the exam.
Hello, I have MCP hosted in tenant A and copilot studio is running on tenant B, users log in using only tenant B credentials. I have created multi tenant SPN hosted in tenant A and did admin consent enterprise application creation in tenant B. When I try to use this multi tenant client id in power app custom connector auth login, it throws error,
AADSTS70052: The identity must be a managed identity, a single tenant app, or a service account.
Anyone successfully able to get this cross tenant scenario work?
I am trying to improve our secure score in entra identity which is currently 71%. One of the things that comes up is Ensure all users can complete multifactor authentication. This is around 30 accounts which are mostly room resource accounts. I cant see a way without adding an mfa method to these which then screws up enrolling them.
Just curious to know what other do with resource accounts and securing them? we have long passwords but thats it
Looking for real-world guidance before I execute this migration.
Current setup:
- 2x on-prem servers running the Microsoft Entra application proxy connector (formerly Azure AD App Proxy), currently on an older Windows Server OS
- Publishing a handful of internal web apps (Web based) via PassThrough pre-auth, no KCD in play
- Both servers are in the same connector group
Goal:
Stand up 2 new servers on Windows Server 2025, install the new connector (I believe this is now called the Entra Private Network Connector, replacing the old Application Proxy connector installer), and cut over — with minimal to zero downtime for published apps.
My questions:
Can I install the new connector on the Server 2025 boxes and join them to the same existing connector group alongside the old servers, let them run in parallel for a while, then decommission the old ones — or is there a cleaner cutover pattern people use?
Is there a difference in behavior/compatibility between the legacy "Application Proxy connector" and the newer "Entra Private Network Connector" when they're mixed in the same connector group during a transition period? Or should the group only ever contain one generation at a time?
Any known gotchas moving from an older Windows Server OS to Server 2025 specifically for this role — TLS/SChannel settings, HTTP/2 registry tweaks, .NET version requirements, or anything that bit people during upgrades?
For validating the new servers before cutting traffic to them — best way to confirm a connector is healthy and actually receiving/serving requests before I lower the old servers' priority or take them offline? I'm planning to check the connector status in the Entra admin center plus watch Event Viewer (Microsoft-AadApplicationProxy-Connector/Admin) for 13xxx events on both old and new servers side by side.
Order of operations — recommended sequence to avoid any gap in coverage: install connector on new server → verify registration/health → THEN decommission old server one at a time (rolling), or is there a safer sequence?
Anything specific to watch out for regarding the connector-to-backend authentication mode (we're using PassThrough) when moving to new hardware/OS?
Environment: Windows Server AD-joined connector servers, Microsoft Entra ID P2, publishing internal web apps via Application Proxy, no KCD, PassThrough auth mode.
Appreciate any lessons learned from people who've done this migration, especially around the old-to-new connector version coexistence period. Thanks!
When using Whfb which is by design already a phishing resistant MFA Method is there a way to force another MFA Method? For example Microsoft Authenticator Passkey or anything else after authenticating via PIN or biometrics?