Force additional MFA for PIN WH4B
so got a request from one of my clients and if you think about it, its on the verge of being valid but an edge case... Lets say you implement WH4B and leverage PIN, how do you prevent someone shoulder surfing and leveraging the PIN on that device if they take it? Or restrict pin patterns? (the patterns I am looking into) I know Fido2 is the best way along with biometrics...but they were wondering if there was a way to reprompt MS Auth App for a code after login/reboot... I couldnt find anything on this but I did find forcing a mfa device revalidation via graph api Any able to accomplish this with the entra joined device?
Deactivating Option to change Profile Picture at myaccount.microsoft.com
As the title says. I would like to deactivate the option for users to change their profile picture at myaccount.microsoft.com. The profile picture at our company is synchronized to AD and via Entra Connect to Entra ID. Is there an option as an admin to deactivate that option without deactivating the entire portal? Kind Regards Christopher Siebertz
Entra invitation manager for guests
A while ago there was a change that the SharePoint invitation manager has been converted to the Entra invitation manager. This is a good thing because every guest can use the OTP for logging in. Only I see this behaviour: When a guest has been added to a group or a team. The guest can sign in with OTP to the team. Also there is a guest account created. When I share a folder or a document the guest can sign in with the OTP to the folder or document. But there is no guest account in M365 for this user. So you don't have an overview of the guest accounts in your tennant where a document has been shared with. With Powershell you can edit the entra invitation manager a bit: Set-SPOTenant -EnableAzureADB2BIntegration $true After completing this command also the users when you share something will be addeAuthenticationd as a guest. Is it default that guests are not vissible when you share a folder or document with them? Is this the right approuch to get a view of those accounts? Maurits Knoppert
Intune - disable Windows Hello
I have a goal: 1. Disable Windows Hello for Business without impacting current users on EntraID via Intune, 2. Configure password sync on the Okta site and Entra ID and MDM device What could be the way to disable PIN (for onboarded devices) and switch only to a password on endpoints? the password must be synchronized with Okta in both directions. Thank you,
Additional Microsoft 365 users not showing as registered users on an Entra ID joined device.
Most of our clients are on M365 these days, and they consist of the following variations in how they integrate: On-prem AD with no Entra ID sync to M365. On-prem AD with Entra ID sync to M365 but no hybrid connection for devices. On-prem AD with Entra ID sync and hybrid connection for devices with Intune. No on-prem AD with all devices connected directly to Entra ID and Intune. For clients using integration methods 1 and 2, we always see multiple device registrations in Entra ID, and for clients using integration method 3, we see a primary user that was used to hybrid join the device, along with additional users showing up as registered in Entra ID. However, we have just recently discovered that clients that use method 4, i.e. they are 100% Entra ID with no on-prem AD, the only user that shows in Entra ID is the user that joined the device. Any other use that logs in and creates a profile on one of these machines is not recorded as a registered user in Entra ID for that device. So, for clients that use integration methods 1-3, if we want to remotely block access on a particular device for a specific user, we just need to delete their Entra ID registration for that device. However, for clients using method 4, we have no visibility for the additional user, nor can we remotely block a user in this scenario. Is this behaviour a current bug in the Entra ID join/register process? Or is this the expected behaviour? If the latter, then this seems to be a flaw in the join/register process.
App password for service account when using Security Defaults
We are using M365 Business Standard licenses and have security defaults enabled. We need to have a service account setup to allow devices (printers, scanners, etc...) to send mail outside our tenant. I cannot find a way to setup an app password or exclude this account from MFA since we can't use conditional access. Is there a way to do this without disabling security defaults? Hoping I'm missing something here. Thanks!
Azure AD Security Defaults MFA not working (as expected?)
Hi, We use Microsoft 365 Standard and have enabled Security Defaults ( https://learn.microsoft.com/en-us/microsoft-365/admin/security-and-compliance/set-up-multi-factor-authentication?view=o365-worldwide ) so thought that our accounts would be as secure as they could be without Conditional Access. One of our users was Phished and emails were sent from their account. Checking the Interactive sign-in logs I can see the attacker attempted to login from Nigeria (we don't operate from Nigeria) using Chrome on Windows 10 and was denied login due to MFA (which is as expected - part log shown below) Date (UTC): 2023-05-10T09:12:20Z Username: email address removed for privacy reasons Application: Microsoft Authentication Broker IP address: 105.112.183.103 Location: Lagos, Lagos, NG Status: Interrupted Sign-in error code: 50074 Failure reason: Strong Authentication is required Client app: Browser Browser: Chrome 112.0.0 Operating System: Windows 10 Multifactor authentication result: User needs to perform multi-factor authentication. There could be multiple things requiring multi-factor, e.g. Conditional Access policies, per-user enforcement, requested by client, among others Authentication requirement: Multifactor authentication Sign-in identifier: email address removed for privacy reasons Token issuer type: Azure AD 2 minutes after that attempt the attacker then tried using Safari on iOS 14 and this only asked for single factor authentication and let them in, which certainly wasn't expected! From there, they were able to monitor the email in this instance and send / modify emails until we detected them and locked them out. It could of been worse, we were lucky this time. The successful (part) log is shown below: Date (UTC): 2023-05-10T09:14:27Z Username: email address removed for privacy reasons Application: Microsoft Authentication Broker IP address: 105.112.183.103 Location: Lagos, Lagos, NG Status: Success Sign-in error code: Failure reason: Other Client app: Mobile Apps and Desktop clients Browser: Mobile Safari 14.1 Operating System: iOS 14 Multifactor authentication result: Authentication requirement: Single-factor authentication Sign-in identifier: email address removed for privacy reasons Token issuer type: Azure AD I have logged this with Microsoft but all they are concerned with is that the account is now secure and not the fact that with Security Defaults on and a phished account was accessed without MFA (and from a country we don't operate from). I have since done some more testing with another account and after revoking sessions and MFA, they could login to the same PC they normally use and access www.office.com without MFA prompts only finally being asked when going into Security Settings in My Account. I can accept as the location this was from is the main office it might be flagged as safe by MS. So then I used the same account to login from another clients office not associated with us (using a VM there) and again it was able to login to www.office.com without any MFA prompts, which again is quite concerning. I wondered if anyone had any insights into why this might have happened like this? As far as I can see Security Defaults isn't really doing a very good job. Thanks Rob
