Password-less authentication with using One-time passcode from Microsoft Authenticator App.
Recently one of my users was in Internet restricted zone and when he tried to sign-in with Password less method, He didn't get the code due to no internet in mobile and in addition to this, he forgot the user sign-in password. Is there any method or way to setup that we can be able to sign-in with using the 6-digit Microsoft Authenticator App Code instead of the push notification and password.
Outlook 365 constantly asking for password authentication
All, For the last month or more, Outlook constantly asks me for my email password for 2 different email providers. This is not happening on my iPhone nor MacBook. I have read dozens of posts to resolve this issue and nothing works. I deleted Office365 and re-installed. Still problems. This is really frustrating. Does anyone have a REAL solution?
AzureAD Joined Device and onprem w/ PIN
I am working on a scenario where we want to move to Azure ADDS, we still have some need for LDAP/S, Unix, etc but want on prem to go away. Endpoints are already azure AD Joined to the 365 Tenant. Tenant is insync with onprem w/ Azure AD Connect w/ password hash as well... here is where it gets fun...endpoint with password login has no problem accessing onprem file server, but as you know Azure Join Devices force pin enrollment and default to it. When user logs in with PIN, I get cred prompt...eventually this box will goto azure, but I suspect this will occur when it gets out there also... I have attempted AzureAdKerberosServer, oneway trust with AADDS/Local and domain certificate avenue, no love...has anyone gone down this rabbit hole?
Generate 2 part / split password for break-glass account
Am planning to configure break-glass / emergency accounts for Azure AD. However, need some help in order to create / generate split passwords ( 2 ) for one emergency account which can further be sent to the custodians. So, scenario is: There will be a break-glass account whose password should be split in 2 parts. Each part is sent to each custodian. Now, is there any tool or script which can do this so that the person executing the script is also unaware of the split password. Thanks.FIDO2 enabled user receive "Protect your account"
We are having issues in two different scenarios with Azure MFA for users who use FIDO2 exclusively. It seems, any settings somehow still require Microsoft Authenticator. First scenario: Registering FIDO2 after the 14 days grace period When a user is created in Azure (either directly or on-prem sync, no difference here), the user has a 14 days grace period. During this period, configuring FIDO2 works flawlessly using a Temporary Access Pass (TAP). After the 14 days, the user logs in using the provided TAP to https://aka.ms/mysecurityinfo, starts the "Add sign in method", follows the steps for the FIDO2 key, once the key is confirmed and the user is redirected back to mysecurityinfo, Azure prompts for a "Additional information is required" and requires the user to register the Microsoft Authenticator app first. The only logs we see is that the user interrupted the MFA setup. We tried several browsers, normal or incognito mode, different users, nothing prevented this, except for configuring MS Authenticator first, then configuring FIDO2 afterwards. We deleted the MS Authenticator app for these users as it was only a workaround. Now these users seem to face the second scenario below. Second scenario: FIDO2 sign in prompts for a "Protect your account" - skippable for 14 days Users are able to sign in using the FIDO2, and immediately after, they are prompted a "Protect your account" window, which asks them to configure MS Authenticator again. They have the option to skip this for 14 times (not days). If we check the user's sign in logs, it shows Failure for the user satisfying the Conditional Access requiring MFA, which is rather unexpected because the user does in fact manage to sign in using the FIDO2 security key, and is able to access the resources when skipping the "Protect your account" request. We thought it may be App specific, but finally the users face this issue with different apps (Workday, Concur, MS Teams...) After asking Google, many articles point out this is related to Security Defaults. This is not our case, as we are using https://learn.microsoft.com/en-us/microsoft-365/business-premium/m365bp-turn-on-mfa?view=o365-worldwide&tabs=condit. The Conditional Access (CA) is enforcing an MFA of a custom Authentication Strength which includes the FIDO2 as one of the accepted options. The per-user MFA settings are configured to be Disabled for the affected users, as it is already enforced by the CA. The only setting that we have not modified yet is the Multifactor authentication registration policy which is set to Enabled - we cannot customise this as we have only P1 license (and we cannot find information if disabling this would later prevent us from enabling it afterwards due to missing license). As mentioned at the beginning, it seems there is somewhere a setting that expects everybody to use MS Authenticator for MFA regardless of what we configure, except if we disable MFA altogether (not gonna happen). Are there any other settings we should check or review or we can test? Thanks in advance.Self Service Password Reset for trusted domain
Hi, I manage a self-contained Forest/Domain in Geo1 which has a two way AD trust with our parent company in Geo2. The Geo1 domain sits in the Geo2 owned and maintained Azure/M365 tenant. SSPR is selectively enabled in Azure by way of Domain Local AD group into which all required AD groups from other business units within the organisation are nested and this works fine for users in Geo1 (all users in Geo1 are in domains which are in the same AD forest as the parent organisation). A Domain Global AD group from Geo2 has also been nested in Geo1's Domain Local Group so, in theory, SSPR should be available to Geo2 users but it isn't working (we see a message on the SSPR page stating that SSPR 'isn't available for this user'). The Geo2 forest syncs to the Geo1 managed Azure AD via AAD connectors located in Geo1's data centres. I can see our users in the Azure Portal and have access to all permitted M365 apps such as Exchange Online, SharePoint et al. All users are have either E3 or E5 licenses. Can anyone suggest a reason why SSPR isn't working for the Geo1 users or maybe point me to any documentation which might deal with this particular scenario? Regards Paul
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.
