"Verification request is not for an activated account” message on iPhone app when authenticating to Azure MFA through ADFS 2016 RRS feed

  • Question

  • Hi all, 

    Has anyone else seen this before. I use the iPhone Authenticator app (v.5.3.3) and it works fine when I authenticate to O365 with any of the authentication methods (verification code, text, call and app notification. However, when I authenticate to through ADFS 2016 using the app notification method, it displays this error: "Verification request is not for an activated account”. Then if I let it timeout and try again (by selecting the app notification method on the ADFS form), it works fine. All other authentication methods works through ADFS - and like I said, even the app notification works on the second attempt. It just doesn't work on the first attempt. (but to Office365 directly, it works on first attempt). 

    It's bizarre but I've tested it through WAP, directly to ADFS, with and without load balancing... the error is always consistent. 



    Friday, May 5, 2017 7:21 AM

All replies

  • Hi Emile,
    We are checking on the query and would get back to you soon on this.
    I apologize for the inconvenience and appreciate your time and patience in this matter.


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Tuesday, May 9, 2017 8:55 AM
  • Hey Emile

    I'm getting the exact same scenario. I've enabled Azure MFA as a secondary authentication method for an internal relying party trust on an ADFS 2016 farm. I get the same results as you have. Have you logged this anywhere else? I'm thinking about shooting it to MS Premier.


    Thursday, May 11, 2017 2:07 AM
  • Hi Emile,

    Thank you for your patience.

    Sorry, I can’t reproduce your error, to troubleshoot this issue more efficiently, please collect event logs and ADFS debug logs then post here. Then we are able to find the detailed behavior of the MFA and ADFS, which is very useful for further troubleshooting.

    More information about enable debug tracing, please follow those steps:

    1. Open Event Viewer.

    To open Event Viewer, click Start, point to Programs, point to Administrative Tools, and then click Event Viewer.

    1. On the View menu, click Show Analytic and Debug Logs.
    2. In the console tree, expand Applications and Services Logs, expand AD FS 2.0 Tracing, and then click Debug.
    3. In the Actions pane, click Enable Log.

    Best regards,


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Friday, May 12, 2017 7:28 AM
  • Hi Mike, 

    Thanks for the feedback. We have logged it with Premier support ( I could give you the ticket number if it helps)

    If they find a solution I'll come back and update here. 



    Friday, May 12, 2017 12:54 PM
  • Hi Jason, 

    Thanks for the instructions. We've captured the events and uploaded it to our Premier case that we have open with Microsoft. 

    As you can imagine, there is a lot of detail in there - but this entry was interesting:

        EvaluateAuthResult: <userid> no phone app response, Result: PhoneAppNoResponse, ContextId: 29f77176-8a48-4a62-afce-31b6309eb757, ActivityId: 00000000-0000-0000-7f3e-0080000000bc, SessionId: 1f6d609a-21eb-4636-999c-9f54904f25e5.

    This is after I approved the request on the app. 

    As I explained, if I then go and do the same after the request times out - it works. Then the event log doesn't show this error. 

    Friday, May 12, 2017 1:00 PM
  • Did you have any luck so far with Premier? I'm about to test it out, grab logs and submit...
    Friday, May 26, 2017 7:42 AM
  • Hi guys, 

    We finally got a good answer from Microsoft on this! Turns out they know about it already. It has to do with case sensitivity. If the username in AD is, it's likely that the username in Azure AD and MFA (as displayed in the app) is also When you first authenticate through ADFS, something in ADFS changes the username to lowercase - Apparently this causes it to fail on the first try - but for some reason works on the second try. 

    We confirmed this by testing with a user account that has an all lowercase username in AD and then it works fine. 

    They said that estimated date for fix is 16 June 2017

    Hope this helps

    Tuesday, June 6, 2017 1:49 PM
  • Hi,

    Thanks for this, I've just discovered it as well today and thought I was going mad.  Hopefully the fix will come next week!


    Tuesday, June 6, 2017 4:42 PM
  • We are also facing this issue. After some testing i have found that if the Authenticator maps the UPN when it has upper case alphabets you get the error  "Verification request is not for an activated account”. The reason being ADFS is always sending the attribute in lower case. this does not happen if i change the UPN to lower case. 

    I have asked MS support these questions, lets see what they say and i will post the update 

    a. Why does ADFS always sends the UPN attribute in lowercase when the actual UPN has uppercase alphabets. 
    b. Why does is not error out on the second attempt and always errors out on the first attempt. 
    c. How does it matter to the authenticator app in which case the attribute is coming in. 
    Thursday, June 8, 2017 2:11 PM
  • Hi folks, 

    It looks like Microsoft fixed it. I've run multiple tests and it seems to work fine now. 



    Friday, June 16, 2017 12:05 PM