Disable approval popup in MS Authenticator app
Hi, I have a tenant with MFA setup on all accounts and most people have used the Microsoft Authenticator app. Unfortunately someone was silly enough to press approve on their phone when they weren't getting prompted on their PC, and let a hacker in who knew their password. We're trying to educate them better but still I'd like to remove the feature where the they get that popup in the MS Auth app, and make them have to get a code from the app only so they can't accidentally let a hacker in. Can I do this by powershell somehow? I have 50+ users in this tenant and other tenants I may want to change too so not viable to ask them all to setup their MFA again a different way. Running powershell reports shows they all have two MFA methods of PhoneAppNotification and PhoneAppOTP and so I assume I just need to remove PhoneAppNotification. I found a script in the below thread to switch the default, but I assume that means a hacker could still try the other method and make their app do a approval popup, I want it removed. https://techcommunity.microsoft.com/t5/azure-active-directory-identity/powershell-cmdlets-for-mfa-settings/m-p/157678/thread-id/132 $m1=New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationMethod $m1.IsDefault = $true $m1.MethodType="PhoneAppNotification" $m2=New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationMethod $m2.IsDefault = $false $m2.MethodType="PhoneAppOTP" $m=@($m1,$m2) set-msoluser -Userprincipalname "UPN" -StrongAuthenticationMethods $m ThanksHow to interpret non-interactive user sign-ins?
While investigating the sign-in logs of a specific user I stumbled upon the following entries. The interactive sign-ins all failed because of conditional access policies. The non-interactive on the other hand were all successful. How does that make sense, or what does that mean?Private Network is currently disabled in my tenant
Hi All, I am interested to test the Entra ID private access, but when I go to the connectors, it shows as "Private Network is currently disabled for your tenant.". Does anyone knows what is the reason for this and How should I overcome this? Thanks in advance, DilanHow To Work Around The Azure SAML Group Claim Limitations?
We recently implemented a model in which our users can create Office 365 groups, which then can be used in all our SAML-connected third-party cloud applications to grant access to resources withing the cloud app. The way this works is that is this: The Office 365 groups are synced back to our on-premises AD. The Office 365 groups must have the prefix 365sec_ in their CN and SamAccountName. The cloud application must support group membership claims and the groups must be created in the app with the same name. When the user authenticates, ADFS adds all groups to the token, that have the prefix "365sec_" and the user is a member of. The user is now able to access all resources within the cloud app that grant him access based on group name and membership. As an example, a SAML token for user Jon Doe would look like this: Name-ID: jon.doe@exmaple.com E-Mail: jon.doe@exmaple.com GivenName: Jon Surname: Doe Groups: 365sec_Account-SeeShell Groups: 365sec_Account-Wayland Groups: 365sec_Project-Samson Groups: 365sec_Project-VisION We planned to move to Azure SAML, but I learned that Azure does not support adding the group CN or SamAccountName to the token, but only the objectId. All of our cloud apps only support adding groups by Name. This seems to be the de-facto standard. It is not possible in the cloud apps to create groups with an ID and a canonical name. Consequently, the admins would need to know the objectId of the groups and the users would only be able to assign permissions on "cryptic" objectIds. That is not user friendly and blocks us from moving our SAML authentication to Azure. Can you recommend a way that enables to migrate to Azure while keeping group names (CN/SamAccountName) in the SAML token?
ID token issued by AAD doesn't match public signing key
Hi, I've encountered an issue that ID tokens (JWT) issued by AAD do not match a public signing key. This is my JWKS url: https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flogin.microsoftonline.com%2F1d063515-6cad-4195-9486-ea65df456faa%2Fdiscovery%2Fv2.0%2Fkeys&data=02%7C01%7Cyu.kuang.lu%40LEGO.com%7C83d34dcb3e744cd9498508d8294edcdf%7C1d0635156cad41959486ea65df456faa%7C1%7C0%7C637304765982427993&sdata=9WgGhPx7T%2B9ngD3RSu6zT3ePFwIfr3IwKk2m9JiNAxE%3D&reserved=0 However the ID token I receive has a unmatched kid like below { "typ": "JWT", "alg": "RS256", "kid": "ylQQc6jLgNEIt8AMAPm8jR27QCE" } It's been working fine until a couple of days ago. It is mentioned somewhere that AAD rotates public keys but it seems tokens might be persisted without knowledge that the signing key has changed. However access token match one of the keys like { "typ": "JWT", "nonce": "ExKWqBKO2TvzbusXVkALk0RQhka3YiNxEKQg69gs27Q", "alg": "RS256", "x5t": "huN95IvPfehq34GzBDZ1GXGirnM", "kid": "huN95IvPfehq34GzBDZ1GXGirnM" } Is this the expected behaviour? AAD is my IDP and AWS Cognito is the auth server in my set up. Because of this issue, Cognito is unable to verify signature of ID tokens therefore users can sign in but cannot proceed further because of this. Has anyone come across a similar issue before?AADSTS75011 Error on Edge (Azure AD Joined machines)
I have just setup SSO for a new enterprise application. On AzureAD joined machines, it works in Chrome and Edge InPrivate mode. In normal edge, we get the following error: AADSTS75011: Authentication method 'X509, MultiFactor' by which the user authenticated with the service doesn't match requested authentication method 'Password, ProtectedTransport'. I have read about adding the following to SAML request but this is not possible with the vendor currently: 'authnContextClassRef' : false This only affects AzureAD joined machines on Edge. When I test from a Hybrid joined machine there is no such issue. Is there any way to resolve this from the Azure side?
UPN Mismatch between Local AD and Azure AD (Entra ID) impact on user sign-ins and SSO?
Hello Smart people, I have a Active Directory domain to be synced with Entra ID. This Entra ID tenancy though, is already exists and users are created. There are two different UPNs in current environments. Local AD - user1@company.com.nz Azure AD - user1@company.com Local AD doesn't have any Suffixes configured. email address removed for privacy reasons is the email address of Local AD account properties where as UPN is email address removed for privacy reasons. So there's a mismatch of the two UPNs. My question is, as this issue will have a major impact on user sign-in/SSO due to this mismatch, what's the best way to overcome this ? Do I have to add the suffix company.com in AD and change on-prem user UPNs with that suffix and then sync? Is there any better ways to deal with this? Any ideas/inputs are greatly appreciated. Thank you! Kev
