Forum Discussion
Unable to Enter Password in Outlook Password Prompt After Federation - ADFS Related?
We have configured ADFS 3.0 with a proxy in a DMZ. It has a newly installed and configured certificate. All of the tests return happy results. Everything appears to be as it is supposed to.
When we were fully satisfied that everything was working as desired we executed the necessary commands to federate the two domains and then updated ADConnect with the new sign-in option. Once again, everything appears happy and functioning as required.
Testing with a client machine also returned the results expected. The client was successfully able to connect internally and externally to the desired Office 365 resources with the expected prompts and no errors presented. Most of the users experienced similar results.
A small number of users encountered something else and I'm trying to figure out where to look to diagnose what's happening.
When using the Outlook desktop client the "Connected to:" at the bottom never changes and the client never connects to Exchange.
When the user clicks on the "Connected to:" he is presented with a login prompt, enters his UPN and password and is again presented with the login prompt. His UPN and password are correct.
When we attempt to login with the UPN and password through the Office 365 portal it directs back to the ADFS portal, as desired, but will not populate the password. What I mean by that is the user types in his password and it is immediately removed from the space each time.
I'm chalking this up to an issue with the client and not the ADFS infrastructure as the majority of the user population appeared to be working just fine.
We've rolled back, returned to "Managed", to allow the impacted users to continue to work.
Am I reading this correctly? Is it a client issue? Where should I be looking to troubleshoot? The ADFS logs have not shown anything related to these clients that we can see. Any assistance you might be able to provide would be appreciated. Thanks!
First of all, make sure that all the relevant events are being logged as older versions of AD FS have them off by default: https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/troubleshooting/ad-fs-tshoot-logging#security-auditing
If that doesn't help you locate the relevant events, you can also enable debug tracing (covered in the above article).
Now, judging by the symptoms, the user seems to be authenticating OK (otherwise you would see an error stating password is incorrect), so the issue is most likely related to the claims issuance part of the process. It might be as simple as incorrectly configured attribute on the user object, but you should also check all your claims rules, including any rules that enforce additional authentication. You can rule out some of the user-related issues by checking the idp-initiated flow: https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/troubleshooting/ad-fs-tshoot-initiatedsignon
The above test will also tell you if the issue is specific to the O365 RPT, in which case you can focus on the O365-specific attributes (objectID and UPN most importantly) and claims rules. And you can always capture a Fiddler trace as well: https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/troubleshooting/ad-fs-tshoot-fiddler-ws-fed
Thank you VasilMichev . Good places to start.
