Their exists a scenario with ADFS and SSO based apps (to include 365) where there is a common user logged into their PC but need to access their webmail. However it detect the user logged and and wants to leverage WIA. Current work around is to do a REGEX and push user agent string to those impacted PCs to not perform WIA and results in Forms Auth. However with Microsoft pushing Edge and Chromium going towards client hints, this bandaid is slowly loosing its adhesive.

Ideally it would be nice to specify a group and force them to forms based auth in lieu of WIA. That plus a link to include private mode and then users could log in and check mail, etc while staying logged into the endpoint via the common kiosk account

My company uses O365, AD FS 2016 and Azure AD, recently our internet provider had repeated outages where the AD FS servers access to the internet was compromised. This was a unavoidable outage for users on our internal network but since O365 leveraged Azure MFA in a CA policy external users could not get to O365 resources because they could not do MFA at ADFS. I want to create a plugin that checks for access to Azure MFA if it fails it places a default hardcoded claim in the token package validating MFA but raising a RIsk factor whtich will allow Business continuance.

Currently, if a browser-based user comes to the AD FS sign-in page, AD FS can only decide whether to use integrated authentication by looking at the browser's user agent string. However, t

There are cases where not all users arriving at the AD FS sign-in page can perform a Kerberos login - they might be within the IP range of the "internal" part of AD FS (in a split-brain DNS configuration) but the client may not be domain joined for various reasons, for example wireless users using BYOD. For these users Kerberos fails and it falls back to NTLM/Basic auth methods. The user receives an ugly popup box asking for credentials, with no context, branding, or guidance.

It would be better if this user was instead directed to the forms-based authentication method instead so that they received a recognisable sign-in experience (i.e. the same as if they were accessing externally).

Previously, this could be mostly worked around by setting a custom useragent string for IE and using AD group policy to push it out to all domain-joined devices, however, with the move to Windows 10 and Edge as the preferred browser, this is no longer possible (Edge does not have a customisable useragent string), so a choice needs to be made between turing on WIA for all users and accept that non-domain-joined devices will have a poor sign-in experience, or turn off WIA for all users except thouse using IE11 (dwindling population).

Possible solutions in order of preference:
1. Find a way to fall back to Forms-based auth if Kerberos fails
2. Often inability to perform WIA can be location-related, so introduce a new setting that would blackist certain network segments as being non-WIA compatible, and default to Forms-based for users accessing from those IP ranges
3. Allow Edge to have a customisable user_agent string controlled by group policy

AD FS should support a user consent option besides the now provided admin consent only.
We'd like to use AD FS as a Federation Service with external parties, which is possible for single external targets, but not for bigger federations like InCommon, SWITCH or similar, since an admin cannot decide, which attributes a user wants to release to an service provider. Especially not, when the users (as in our case) are students and employees.
Other implementations of federatet authentication such as Shibboleth 3 or Thinktecture Identity Server 3 do support user consent. Online Authentication providers (Facebook, Live, Google, etc.) also support that - it would be good to see this in ADFS, too.

It would be incredibly helpful if Access Authorization Rules would allow the selection of a specific MFA Adapter or mechanism as a part of a ruleset.

For example, if a user was authenticating from a managed device, use certificate authentication, otherwise prompt for second factor using the Azure MFA adapter, or, if a user belongs to a specific group, always use certificate authentication forst, then attempt for Azure MFA, otherwsie if a user belongs to group "B", always prompt for the Azure MFA Adapter (or any other MFA provider integrated with ADFS)

At the moment it's an all-or-nothing option. If you have mroe than one adapter the user is prompted with all of them and asked to select their mechanism, which isn't very elegant.