SCIM - Provision null values
Hoping to get some more official feedback regarding Entra's in-ability to provision null values, mainly outbound provisioning. The SCIM standard caters for this use case, so what is Microsoft's reluctance on this functionality? If it's the concern of breaking functionality, surely it can be an 'opt-in' setting like the bulk delete setting? I know some good conversation has taken place here:https://learn.microsoft.com/en-us/answers/questions/223936/sending-an-empty-value-with-user-provisioning-(sci
Advice needed: Multitenant organization issues
Hey peeps, a client of mine is asking for an optimal solution to their sub-optimal organization structure. I want to see if there's something more I can do here or if we are stuck with our environment the way it is. It's such a strange ask that it will take a few paragraphs to describe, so bear with me. Client has a central corporate entity, but the "branch" entities operate separately and have a fair amount of self-governance. This central corporate entity has a Microsoft365 tenant and that's what everyone's email matches, including branch members. Let's call it corp.onmicrosoft.com with a verified domain of corp.com. So, everyone at corporate and the branches have addresses/UPNs of @corp.com. Before my time, one of the self-governing branches chose to setup a Sharepoint site specific to their branch. They put all the files on a separate 365 tenant of corp-ny.onmicrosoft.com with verified domain corp-ny.com. There are a couple of identities on that 365 tenant, but since everyone uses their corp.com email, they access the Sharepoint data from their primary corporate identities as GUESTS of the branch's tenant. So the branch tenant has 3 members and 100+ guests. We perform IT for just the BRANCH, not the corporate structure. Since corporate IT is not interested in changing infrastructure at this time, we would like to convert all the guest identities on the branch tenant to members and we can then leverage technologies like Intune & CA and move them off of their on-premise AD server that is not doing AD Connect. I have a quick script that will do all of that - convert, license, set some properties for all 100 members. Seems okay! After the change, members will have their corporate identity for email, and the branch identity for Sharepoint and Windows login. We've identified a problem, however, with notifications. When you comment on a file in Sharepoint, a notification is generated for anyone that participates in that file. The notification is sent from the commenter's identity. Currently, that means notifications come from @corp.com . However, after the change those notifications will come from corp-ny.com. This domain does NOT have an MX record associated with it 😞 and we think this will lead to a LOT of confusion if people try to reply directly to the emails. It might also have the potential(?) to fail email spoofing checks or be flagged as suspicious by email servers. Additionally, the notifications would be sent to their branch identities, which I assume would not deliver. Even if it did deliver and we added an MX record, it would be in an inbox that's not checked by the team. My question is: Can I mask the notification email to be from "email address removed for privacy reasons" for all of the notifications? Or, Can I "spoof" the emails so that they appear to be sent from the corporate identity? Secondly, What's the best way to deal with notifications headed to the wrong inbox? Can a transport rule redirect these emails to their corporate emails?MFA denied; duplicate authentication attempt
We see a lot of entries in the Entra ID Sign in logs with "MFA denied; duplicate authentication attempt". Most of the time a lot of them are registered in a short amount of time Users are not (yet) complaining. May be users don't even see something wrong. Anyone who knows what this means? (MFA denied; duplicate authentication attempt) kind regards JurgenAdditional 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.
Google Federation with Entra ID - doesn't support MultipleAuthN SAML claim
Entra ID has a new Microsoft-managed conditional access policy that will be enabled from October 2024. However, Google doesn't support the MultipleAuthN claim that ADFS (and other IdPs) do. Is there a work-around for this, or we just need to ensure that the new Microsoft-managed conditional access policy is disabled for all users? Otherwise, we somehow need to enable double MFA (MFA at both Google and Microsoft). I imagine this might be an issue for any other federated IdPs that don't support this specific SAML claim. There is a new alternative to the `SupportsMFA` setting in the `Set-MsolDomainFederationSettings` powershell command, but it doesn't allow you to 'always assume MFA is utilised in the federation' -https://learn.microsoft.com/en-us/graph/api/internaldomainfederation-update?view=graph-rest-1.0&tabs=http#federatedidpmfabehavior-values Thanks in advance, NigelMFA Login does not Authenticate
I am trying to retrofit an existing C# asp.net appliction with an MFA login on Azure. I am able to get the MFA prompt, and I click on my account and the code successfully returns to the redirect URL. However, IsAuthenticated is never true and User.Identity.Name is always blank. I based my code on another MFA application for my company that works, but I can't figure out why mine doesn't. I then created a brand new app from scratch to see if I could figure out what went wrong. However, in the new app, IsAuthenticated is always true, both before login, after login and after logout, and yet User.Identity.Name is blank here as well, so the authentication is clearly not valid. I have the most recent Owin DLLs installed, which at the time of this writing are mostly version 4.2.2. My code includes the usual MFA code found in many online examples. The Startup.cs file includes this code: string clientId = ConfigurationManager.AppSettings["ClientId"]; string tenantId = ConfigurationManager.AppSettings["TenantId"]; string authority = "https://login.microsoftonline.com/" + tenantId + "/v2.0"; string redirectURI = ConfigurationManager.AppSettings["MFARedirect"]; string postLogoutRedirectUri = ConfigurationManager.AppSettings["PostLogoutRedirectUri"]; app.UseCookieAuthentication(new CookieAuthenticationOptions { AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie, ExpireTimeSpan = System.TimeSpan.FromMinutes(90), CookieManager = new Microsoft.Owin.Host.SystemWeb.SystemWebChunkingCookieManager(), Provider = new CookieAuthenticationProvider { OnResponseSignIn = (context) => context.Properties.ExpiresUtc = DateTime.UtcNow.AddMinutes(sessionTimeout.TotalMinutes), }, SlidingExpiration = true, CookieSecure = CookieSecureOption.Always }); app.UseOpenIdConnectAuthentication( new OpenIdConnectAuthenticationOptions { ClientId = clientId, Authority = authority, PostLogoutRedirectUri = postLogoutRedirectUri, RedirectUri = redirectURI, UseTokenLifetime = false, Scope = OpenIdConnectScope.OpenIdProfile, ResponseType = OpenIdConnectResponseType.CodeIdToken, Notifications = new OpenIdConnectAuthenticationNotifications() { AuthenticationFailed = OnAuthenticationFailed } }); app.UseExternalSignInCookie(DefaultAuthenticationTypes.ExternalCookie); The Login method in the Home Controller includes this code: HttpContext.GetOwinContext().Authentication.Challenge( new AuthenticationProperties { RedirectUri = redirectUri }, OpenIdConnectAuthenticationDefaults.AuthenticationType ); I have tried many suggestions found on Google, but nothing has made any difference. If anybody has some insight as to what might be going on here, I would greatly appreciate any help I can get.Microsoft Entra ID (Azure AD) support for Passkeys
Hi, Has anyone seen any reference or blog as to whenMicrosoft Entra ID (Azure AD) will support Passkeys on iOS or Android devices and will this be classified as Phishing-Resistant MFA under Conditional Access Sign In policies. When you navigate to aka.ms/mysecurityinfo and attempt to enroll and new Security Key it now defaults to a QR Code to setup a Passkey and lets you go through the enrollment process however once you reach the final stage to give the Passkey a logical name under your account it prompts with an error message (see below). We have been using YubiKey as a FIDO2 Security Key forPhishing-Resistant MFA however as this is not supported for use with iOS and Android and has limited support for macOS we are hoping that Passkeys will be able to fill this gap. We have also explored Azure CBA however we do not have an existing PKI infrastructure and managing the lifecycle of certificates is painful and expensive compared to the cost of using a FIDO2 Security Key or Passkey.
Permit access only O365 Admin Center
Hi I have several users assigned to the user administrator role, to perform user activation/deactivation tasks, adding to groups etc. I would like to be able to block the admin panels and have them only use the 365 admin center (not Entra ID, Azure Portal, Exchange Online Portal etc). I created a conditional access policy but when I added "Windows Azure Service Management API" and the lock condition, block entra id (ok) and other panels, but it also blocks the 365 admin center. Is there any way to allow access only through the 365 admin center? Thanks!
