SOLVED
Home

Report on users with MFA Enabled

%3CLINGO-SUB%20id%3D%22lingo-sub-165807%22%20slang%3D%22en-US%22%3EReport%20on%20users%20with%20MFA%20Enabled%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-165807%22%20slang%3D%22en-US%22%3E%3CP%3EWe%20are%20not%20currently%20enforcing%20MFA%20for%20all%20users%2C%20but%20have%20sent%20out%20instructions%20to%20allow%20users%20to%20self-enroll%20in%20MFA%20(%3CA%20href%3D%22http%3A%2F%2Faka.ms%2FMFASetup).%26nbsp%3B%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttp%3A%2F%2Faka.ms%2FMFASetup).%26nbsp%3B%3C%2FA%3E%20Looking%20at%20the%20status%20of%20users%20who%20I%20know%20have%20enabled%20MFA%2C%20it%20still%20shows%20Disabled%20for%20them%20in%20the%20Multi-Factor%20Authentication%20page%20(%3CA%20href%3D%22https%3A%2F%2Faccount.activedirectory.windowsazure.com%2Fusermanagement%2Fmultifactorverification.aspx%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Faccount.activedirectory.windowsazure.com%2Fusermanagement%2Fmultifactorverification.aspx%3C%2FA%3E).%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-165807%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAzure%20AD%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-297983%22%20slang%3D%22en-US%22%3ERe%3A%20Report%20on%20users%20with%20MFA%20Enabled%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-297983%22%20slang%3D%22en-US%22%3E%3CP%3EDisabling%20legacy%20authentication%20can%20be%20done%20with%20Conditional%20Access.%3C%2FP%3E%3CP%3EFollow%20these%20steps%3C%2FP%3E%3COL%3E%3CLI%3ECreate%20a%20new%20policy%3C%2FLI%3E%3CLI%3ESelect%20the%20users%20that%20you%20want%20this%20enabled%20on%3C%2FLI%3E%3CLI%3EUnder%20conditions%20select%20Client%20apps%20and%20only%20select%20Other%20clients%3C%2FLI%3E%3CLI%3EGo%20to%20grant%20and%20select%20block%20access%3C%2FLI%3E%3CLI%3ESave%20this%20policy%3C%2FLI%3E%3C%2FOL%3E%3CP%3ESee%20the%20attached%20image%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-292767%22%20slang%3D%22en-US%22%3ERe%3A%20Report%20on%20users%20with%20MFA%20Enabled%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-292767%22%20slang%3D%22en-US%22%3EWe%20let%20enduser%20pre-enroll%20MFA%20via%20%3CA%20href%3D%22https%3A%2F%2Faka.ms%2Fmfasetup%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Faka.ms%2Fmfasetup%3C%2FA%3E%2C%20but%20later%20Enable%20the%20enduser%20for%20MFA.%20After%20that%2C%20the%20possibilty%20to%20setup%20apppassword%20exists.%3CBR%20%2F%3EUsing%20Conditional%20access%20will%20only%20let%20you%20force%20MFA%20for%20modern%20authentication%2C%20it%20doesn%C2%B4t%20%22disable%22%20legacy%20authentication%20with%20apppasswords.%3CBR%20%2F%3EOr%20have%20I%20missunderstood%20this%3F%3CBR%20%2F%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-290639%22%20slang%3D%22en-US%22%3ERe%3A%20Report%20on%20users%20with%20MFA%20Enabled%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-290639%22%20slang%3D%22en-US%22%3E%3CBLOCKQUOTE%3E%3CP%3E%3CSPAN%3EIt%20is%20not%20approved%20Microsoft%20process%20to%20pre%20publish%20the%202fa%20web%20page%20for%20the%20user%20to%20fill%20out.%26nbsp%3B%20You%20will%20notice%20the%20apppassword%20tab%20is%20missing%20as%20when%20till%20enabled.%26nbsp%3B%26nbsp%3B%3C%2FSPAN%3E%3C%2FP%3E%3C%2FBLOCKQUOTE%3E%3CP%3E%3CSPAN%3EThat%20is%20not%20correct.%20Microsoft%20officially%20says%20%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fauthentication%2Fhowto-mfa-getstarted%22%20target%3D%22_self%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehere%3C%2FA%3E%20that%3A%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CEM%3EOnce%20you%20enable%20the%20conditional%20access%20policy%2C%20users%20will%20be%20forced%20to%20enroll%20the%20next%20time%20they%20use%20an%20app%20protected%20with%20the%20policy.%20If%20you%20enable%20a%20policy%20requiring%20MFA%20for%20all%20users%20on%20all%20cloud%20apps%2C%20this%20action%20could%20cause%20headaches%20for%20your%20users%20and%20your%20helpdesk.%20The%20recommendation%20is%20to%20ask%20users%20to%20register%20authentication%20methods%20beforehand%20using%20the%20registration%20portal%20at%20%3CA%20href%3D%22https%3A%2F%2Faka.ms%2Fmfasetup%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Faka.ms%2Fmfasetup%3C%2FA%3E.%20Many%20organizations%20find%20that%20creating%20posters%2C%20table%20cards%2C%20and%20email%20messages%20helps%20drive%20adoption.%3C%2FEM%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-251063%22%20slang%3D%22en-US%22%3ERe%3A%20Report%20on%20users%20with%20MFA%20Enabled%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-251063%22%20slang%3D%22en-US%22%3E%3CP%3EMagnus%2C%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EYou%20can%20find%20the%20different%20user%20states%20for%20user%20MFA%20here%3A%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fauthentication%2Fhowto-mfa-userstates%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fauthentication%2Fhowto-mfa-userstates%3C%2FA%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EThe%20description%20column%20in%20each%20of%20the%20states%20describes%20the%20state.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EHowever%2C%20many%20organizations%20are%20using%20Conditional%20Access%20to%20invoke%20MFA%2C%20or%20policy%20based%20MFA%20which%20will%20show%20the%20users%20as%20Disabled%20for%20user%20state.%26nbsp%3B%20This%20is%20because%20the%20user%20may%20be%20registered%20for%20MFA%20(has%20methods%20registered)%20but%20is%20not%20enforced%20on%20every%20authentication%2C%20and%20using%20the%20sign%20in%20state%20and%20policies%20to%20invoke%20MFA.%20%26nbsp%3B%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fconditional-access%2Foverview%22%20target%3D%22_blank%22%20rel%3D%22noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Factive-directory%2Fconditional-access%2Foverview%3C%2FA%3E%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EJef%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-242066%22%20slang%3D%22en-US%22%3ERe%3A%20Report%20on%20users%20with%20MFA%20Enabled%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-242066%22%20slang%3D%22en-US%22%3E%3CP%3EWhat%20is%20the%20difference%20between%20enabled%20and%20enforced%20for%26nbsp%3B%3C%2FP%3E%3CPRE%3EStrongAuthenticationRequirements.State%3C%2FPRE%3E%3CP%3E%3F%3C%2FP%3E%3CP%3EI%20can%20see%20enabled%20users%20with%20methods%20active%2C%20don%C2%B4t%20really%20understand%20this.%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-219749%22%20slang%3D%22en-US%22%3ERe%3A%20Report%20on%20users%20with%20MFA%20Enabled%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-219749%22%20slang%3D%22en-US%22%3E%3CP%3Ecouldn't%20agree%20more%20with%20Colin%3C%2FP%3E%3CBLOCKQUOTE%3E%3CHR%20%2F%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F5320%22%20target%3D%22_blank%22%3E%40Colin%20Kness%3C%2FA%3E%26nbsp%3Bwrote%3A%3CBR%20%2F%3E%3CP%3EThe%20app%20password%20on%20the%20phone%20is%20the%20hardest%20for%20people%20to%20understand%20as%20well.%26nbsp%3B%20You%20have%20no%20idea%20how%20long%20it%20will%20take%20to%20use%20the%20new%20app%20password%20on%20the%20phone.%26nbsp%3B%20Also%20the%20tab%20for%20app%20passwords%20does%20not%20even%20look%20like%20a%20tab%20and%20is%20often%20over%20looked%20by%20end%20users.%26nbsp%3B%26nbsp%3B%3C%2FP%3E%3CHR%20%2F%3E%3C%2FBLOCKQUOTE%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-187429%22%20slang%3D%22en-US%22%3ERe%3A%20Report%20on%20users%20with%20MFA%20Enabled%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-187429%22%20slang%3D%22en-US%22%3E%3CP%3EIt%20is%20not%20approved%20Microsoft%20process%20to%20pre%20publish%20the%202fa%20web%20page%20for%20the%20user%20to%20fill%20out.%26nbsp%3B%20You%20will%20notice%20the%20apppassword%20tab%20is%20missing%20as%20when%20till%20enabled.%26nbsp%3B%20I%20have%20found%20if%20users%20prefill%20out%20this%20form%20there%20is%20a%20problem%20in%20the%202factor%20process.%26nbsp%3B%20I%20need%20to%20reset%20all%20users%20that%20pre%20filled%20out%20form.%26nbsp%3B%20The%20hole%20process%20of%20enable%20and%20auto%20enforce%20makes%20the%202%20factor%20process%20very%20difficult%20to%20role%20out.%20The%20app%20password%20on%20the%20phone%20is%20the%20hardest%20for%20people%20to%20understand%20as%20well.%26nbsp%3B%20You%20have%20no%20idea%20how%20long%20it%20will%20take%20to%20use%20the%20new%20app%20password%20on%20the%20phone.%26nbsp%3B%20Also%20the%20tab%20for%20app%20passwords%20does%20not%20even%20look%20like%20a%20tab%20and%20is%20often%20over%20looked%20by%20end%20users.%26nbsp%3B%20The%20visibility%20into%20the%20whole%20process%20is%20a%20complete%20different%20experience%20form%20Duo%2C%20reports%26nbsp%3B%20what%20reports%20!%20%26nbsp%3B%20Microsoft%20%3D%20NO%20reports%20of%20value...%20with%20out%20PowerShell.%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-166642%22%20slang%3D%22en-US%22%3ERe%3A%20Report%20on%20users%20with%20MFA%20Enabled%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-166642%22%20slang%3D%22en-US%22%3EWhat%20you%20can%20do%20is%20search%20Azure%20AD%20audit%20logs%20for%20activity%20%22Enable%20Strong%20Authentication%22%20to%20find%20out%20those%20details%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-166325%22%20slang%3D%22en-US%22%3ERe%3A%20Report%20on%20users%20with%20MFA%20Enabled%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-166325%22%20slang%3D%22en-US%22%3E%3CP%3ECorrect%2C%20you%20need%20to%20find%20out%20how%20MFA%20is%20enabled%20for%20those%20users%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-166315%22%20slang%3D%22en-US%22%3ERe%3A%20Report%20on%20users%20with%20MFA%20Enabled%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-166315%22%20slang%3D%22en-US%22%3E%3CP%3ELooks%20like%20you%20are%20correct%2C%20Pablo.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EAlthough%20the%20sign-in%20logs%20show%20that%20MFA%20was%20required%20for%20users%20who%20went%20through%20the%20MFA%20setup%20process%2C%20it%20is%20only%20saying%20that%20when%20either%20they%20were%20in%20the%20Office%20location%20(MFA%20description%20says%20that%20MFA%20requirement%20satisfied%20by%20token)%20or%20they%20were%20elsewhere%20and%20setup%20or%20used%20the%20Self-Service%20Password%20Reset%20which%20must%20use%20the%20same%20MFA%20parameters%20to%20sign%20in%20%2F%20verify%20their%20account%20and%2For%20reset%2Funblock%20their%20account.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EI%20guess%20I%20still%20have%20to%20ask%20users%20to%20be%20put%20on%20the%20MFA%20list%20and%20manually%20intervene.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-166287%22%20slang%3D%22en-US%22%3ERe%3A%20Report%20on%20users%20with%20MFA%20Enabled%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-166287%22%20slang%3D%22en-US%22%3E%3CP%3ENo%2C%20your%20users%20are%20not%20enabling%20MFA%20for%20themselves%20by%20using%20those%20URLs%2C%20That's%20a%20fact.%20You%20may%20have%20some%20other%20configuration%20going%20on.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-166284%22%20slang%3D%22en-US%22%3ERe%3A%20Report%20on%20users%20with%20MFA%20Enabled%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-166284%22%20slang%3D%22en-US%22%3E%3CP%3EMaybe%20it%20is%20a%20bug%2C%20but%20it%20works.%26nbsp%3B%20Try%20it%20out.%26nbsp%3B%20I'd%20like%20it%20better%2C%20if%20it%20updated%20the%20status%20to%20Enabled...%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-166274%22%20slang%3D%22en-US%22%3ERe%3A%20Report%20on%20users%20with%20MFA%20Enabled%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-166274%22%20slang%3D%22en-US%22%3E%3CP%3EI've%20run%20out%20of%20ideas%2C%20but%20for%20sure%20you%20need%20admin%20action%20to%20require%20MFA%2C%20either%20enabling%20it%20in%20Office%20365%2FAAD%2C%20or%20in%20ADFS%20or%20a%20Conditional%20Access%20rule.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-166258%22%20slang%3D%22en-US%22%3ERe%3A%20Report%20on%20users%20with%20MFA%20Enabled%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-166258%22%20slang%3D%22en-US%22%3ENo%20ADFS%2C%20just%20using%20Windows%20Azure%20AD%20for%20SSO.%20%20%3CA%20href%3D%22https%3A%2F%2Faccount.activedirectory.windowsazure.com%2FUserManagement%2FMfaSettings.aspx%3Fculture%3Den-US%26amp%3BBrandContextID%3DO365%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Faccount.activedirectory.windowsazure.com%2FUserManagement%2FMfaSettings.aspx%3Fculture%3Den-US%26amp%3BBrandContextID%3DO365%3C%2FA%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-166257%22%20slang%3D%22en-US%22%3ERe%3A%20Report%20on%20users%20with%20MFA%20Enabled%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-166257%22%20slang%3D%22en-US%22%3E%3CP%3EADFS%20with%20MFA%20configured%3F%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-166254%22%20slang%3D%22en-US%22%3ERe%3A%20Report%20on%20users%20with%20MFA%20Enabled%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-166254%22%20slang%3D%22en-US%22%3E%3CP%3ENo%2C%20we%20just%20have%20MFA%20setup%20with%20a%20couple%20of%20trusted%20IP%20addresses.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-166247%22%20slang%3D%22en-US%22%3ERe%3A%20Report%20on%20users%20with%20MFA%20Enabled%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-166247%22%20slang%3D%22en-US%22%3E%3CP%3EDo%20you%20have%20any%20Conditional%20Access%20rule%20enabled%3F%3C%2FP%3E%0A%3CP%3E%3CA%20href%3D%22https%3A%2F%2Fportal.azure.com%2F%23blade%2FMicrosoft_AAD_IAM%2FConditionalAccessBlade%2FPolicies%22%20target%3D%22_blank%22%20rel%3D%22nofollow%20noopener%20noreferrer%20noopener%20noreferrer%22%3Ehttps%3A%2F%2Fportal.azure.com%2F%23blade%2FMicrosoft_AAD_IAM%2FConditionalAccessBlade%2FPolicies%3C%2FA%3E%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-166238%22%20slang%3D%22en-US%22%3ERe%3A%20Report%20on%20users%20with%20MFA%20Enabled%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-166238%22%20slang%3D%22en-US%22%3E%3CP%3EI%20had%20thought%20the%20same%20thing%2C%20but%20users%20are%20being%20prompted%20for%20MFA%20authentication%20every%20time%20after%20configuring%20it%20(unless%20connecting%20via%20the%20office%2Ftrusted%20IP)%2C%20even%20though%20their%20status%20for%20MFA%20is%20still%20disabled.%26nbsp%3B%20For%20now%2C%20I%20downloaded%20all%20of%20the%20logins%20into%20Excel%20and%20can%20figure%20out%20which%20ones%20are%20using%20MFA%20based%20on%20whether%20the%20MFA%20Required%20column%20is%20set%20to%20TRUE%20in%20any%20of%20their%20login%20attempts.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EAs%20an%20admin%2C%20I%20had%20asked%20for%20volunteers%20to%20turn%20on%20MFA%20multiple%20times%20and%20didn't%20get%20much%20response.%26nbsp%3B%20After%20simply%20sending%20out%20the%20URL%20to%20have%20them%20do%20it%20themselves%2C%20it%20appears%20many%20users%20took%20advantage%20of%20it.%20%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-166232%22%20slang%3D%22en-US%22%3ERe%3A%20Report%20on%20users%20with%20MFA%20Enabled%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-166232%22%20slang%3D%22en-US%22%3E%3CP%3EBy%20those%20URLs%20you%20are%20letting%20users%20configure%20their%20authentication%20methods%2C%20but%20they%20are%20not%20enabling%20MFA%20for%20their%20accounts.%20You%2C%20as%20an%20admin%2C%20will%20have%20to%20enable%20and%2For%20enforce%20MFA%20for%20them.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-166215%22%20slang%3D%22en-US%22%3ERe%3A%20Report%20on%20users%20with%20MFA%20Enabled%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-166215%22%20slang%3D%22en-US%22%3E%3CP%3EThanks.%26nbsp%3B%20For%20whatever%20reason%2C%20when%20I%20ran%20this%20with%20-All%2C%20it%20didn't%20return%20the%20MFA%20Status%20column.%26nbsp%3B%20However%2C%20if%20I%20ran%20it%20with%20a%20single%20user%20or%20the%20-EnabledFilter%20EnabledOnly%20attribute%2C%20it%20worked.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EUnfortunately%2C%20this%20shows%20the%20same%20as%20the%20GUI.%26nbsp%3B%20Users%20that%20I%20didn't%20specifically%20'Enable'%20for%20MFA%20have%20gone%20in%20and%20set%20it%20up.%26nbsp%3B%20I%20can%20see%20via%20the%20Azure%20portal%20sign-in%20activity%20log%2C%20that%20they%20are%20in%20fact%20using%20MFA%20when%20they%20login%20(if%20they%20aren't%20logging%20in%20from%20a%20trusted%20IP)%2C%20but%20I%20can't%20seem%20to%20find%20a%20way%20to%20display%20this%20for%20all%20users.%3C%2FP%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%0A%3CPRE%3EGet-MsolUser%20-EnabledFilter%20EnabledOnly%20%7C%20select%20DisplayName%2CUserPrincipalName%2C%40%7BN%3D%22MFA%20Status%22%3B%20E%3D%7B%20if(%20%24_.StrongAuthenticationRequirements.State%20-ne%20%24null)%7B%20%24_.StrongAuthenticationRequirements.State%7D%20e%0Alse%20%7B%20%22Disabled%22%7D%7D%7D%3C%2FPRE%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-166170%22%20slang%3D%22en-US%22%3ERe%3A%20Report%20on%20users%20with%20MFA%20Enabled%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-166170%22%20slang%3D%22en-US%22%3E%3CP%3EYou%20can%20try%26nbsp%3Bthis%20Msolservice%20PowerShell%26nbsp%3Bquery%20to%20get%20users%20MFA%20Status%26nbsp%3B%3C%2FP%3E%0A%3CPRE%3EGet-MsolUser%20-all%20%7C%20select%20DisplayName%2CUserPrincipalName%2C%40%7BN%3D%22MFA%20Status%22%3B%20E%3D%7B%20if(%20%24_.StrongAuthenticationRequirements.State%20-ne%20%24null)%7B%20%24_.StrongAuthenticationRequirements.State%7D%20else%20%7B%20%22Disabled%22%7D%7D%7D%3C%2FPRE%3E%0A%3CP%3E%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E
Highlighted
Damon Betlow
Contributor

We are not currently enforcing MFA for all users, but have sent out instructions to allow users to self-enroll in MFA (http://aka.ms/MFASetup).  Looking at the status of users who I know have enabled MFA, it still shows Disabled for them in the Multi-Factor Authentication page (https://account.activedirectory.windowsazure.com/usermanagement/multifactorverification.aspx).

 

 

21 Replies

You can try this Msolservice PowerShell query to get users MFA Status 

Get-MsolUser -all | select DisplayName,UserPrincipalName,@{N="MFA Status"; E={ if( $_.StrongAuthenticationRequirements.State -ne $null){ $_.StrongAuthenticationRequirements.State} else { "Disabled"}}}

 

Thanks.  For whatever reason, when I ran this with -All, it didn't return the MFA Status column.  However, if I ran it with a single user or the -EnabledFilter EnabledOnly attribute, it worked.

 

Unfortunately, this shows the same as the GUI.  Users that I didn't specifically 'Enable' for MFA have gone in and set it up.  I can see via the Azure portal sign-in activity log, that they are in fact using MFA when they login (if they aren't logging in from a trusted IP), but I can't seem to find a way to display this for all users.

 

Get-MsolUser -EnabledFilter EnabledOnly | select DisplayName,UserPrincipalName,@{N="MFA Status"; E={ if( $_.StrongAuthenticationRequirements.State -ne $null){ $_.StrongAuthenticationRequirements.State} e
lse { "Disabled"}}}

By those URLs you are letting users configure their authentication methods, but they are not enabling MFA for their accounts. You, as an admin, will have to enable and/or enforce MFA for them.

I had thought the same thing, but users are being prompted for MFA authentication every time after configuring it (unless connecting via the office/trusted IP), even though their status for MFA is still disabled.  For now, I downloaded all of the logins into Excel and can figure out which ones are using MFA based on whether the MFA Required column is set to TRUE in any of their login attempts.

 

As an admin, I had asked for volunteers to turn on MFA multiple times and didn't get much response.  After simply sending out the URL to have them do it themselves, it appears many users took advantage of it.  

No, we just have MFA setup with a couple of trusted IP addresses.

ADFS with MFA configured?

I've run out of ideas, but for sure you need admin action to require MFA, either enabling it in Office 365/AAD, or in ADFS or a Conditional Access rule.

Maybe it is a bug, but it works.  Try it out.  I'd like it better, if it updated the status to Enabled...

Solution

No, your users are not enabling MFA for themselves by using those URLs, That's a fact. You may have some other configuration going on.

Looks like you are correct, Pablo.

 

Although the sign-in logs show that MFA was required for users who went through the MFA setup process, it is only saying that when either they were in the Office location (MFA description says that MFA requirement satisfied by token) or they were elsewhere and setup or used the Self-Service Password Reset which must use the same MFA parameters to sign in / verify their account and/or reset/unblock their account.

 

I guess I still have to ask users to be put on the MFA list and manually intervene.

Correct, you need to find out how MFA is enabled for those users

What you can do is search Azure AD audit logs for activity "Enable Strong Authentication" to find out those details

It is not approved Microsoft process to pre publish the 2fa web page for the user to fill out.  You will notice the apppassword tab is missing as when till enabled.  I have found if users prefill out this form there is a problem in the 2factor process.  I need to reset all users that pre filled out form.  The hole process of enable and auto enforce makes the 2 factor process very difficult to role out. The app password on the phone is the hardest for people to understand as well.  You have no idea how long it will take to use the new app password on the phone.  Also the tab for app passwords does not even look like a tab and is often over looked by end users.  The visibility into the whole process is a complete different experience form Duo, reports  what reports !   Microsoft = NO reports of value... with out PowerShell. 

couldn't agree more with Colin


@Colin Kness wrote:

The app password on the phone is the hardest for people to understand as well.  You have no idea how long it will take to use the new app password on the phone.  Also the tab for app passwords does not even look like a tab and is often over looked by end users.  


 

What is the difference between enabled and enforced for 

StrongAuthenticationRequirements.State

?

I can see enabled users with methods active, don´t really understand this. 

Magnus,

 

You can find the different user states for user MFA here:

 

https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-userstates

 

The description column in each of the states describes the state.

 

However, many organizations are using Conditional Access to invoke MFA, or policy based MFA which will show the users as Disabled for user state.  This is because the user may be registered for MFA (has methods registered) but is not enforced on every authentication, and using the sign in state and policies to invoke MFA.   https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview

 

Jef

 

 

It is not approved Microsoft process to pre publish the 2fa web page for the user to fill out.  You will notice the apppassword tab is missing as when till enabled.  

That is not correct. Microsoft officially says here that:

 

Once you enable the conditional access policy, users will be forced to enroll the next time they use an app protected with the policy. If you enable a policy requiring MFA for all users on all cloud apps, this action could cause headaches for your users and your helpdesk. The recommendation is to ask users to register authentication methods beforehand using the registration portal at https://aka.ms/mfasetup. Many organizations find that creating posters, table cards, and email messages helps drive adoption.

We let enduser pre-enroll MFA via https://aka.ms/mfasetup, but later Enable the enduser for MFA. After that, the possibilty to setup apppassword exists.
Using Conditional access will only let you force MFA for modern authentication, it doesn´t "disable" legacy authentication with apppasswords.
Or have I missunderstood this?

Disabling legacy authentication can be done with Conditional Access.

Follow these steps

  1. Create a new policy
  2. Select the users that you want this enabled on
  3. Under conditions select Client apps and only select Other clients
  4. Go to grant and select block access
  5. Save this policy

See the attached image

Related Conversations