ADFS Claim to Flatten Groups and Return full DN

It is possible, one way to do this is:

1) Create a one-way trust from your CustomersDomain to your InternalDomain.

2) Install your SharePoint farm in the CustomersDomain. Because there is a trust between the domains, internal users will be able to connect to it as well.

3) Configure your DNS, firewalls, reverse proxies & co to route traffic to your farm, depending on where they come from.

Note that you don't need ADFS in this setup.

If you don't have trusts between your domains, then you will need 2 ADFS farms (one per domain), create a trust between them, and probably do some customization to route users to the correct server based on their location. It's more complicated.

There is diagram from Microsoft called "Extranet Topologies for SharePoint 2010 Products", you may look at it to find more ideas (available here on technet, it's the 3rd one).

The Microsoft TechNet reference for ADFS 2.0 states the following for Event 364:

This event can be caused by anything that is incorrect in the passive request. It can occur during single sign-on (SSO) or logout for both SAML and WS-Federation scenarios.

https://technet.microsoft.com/en-us/library/adfs2-troubleshooting-fedpassive-request-failures(v=ws.10).

I realize you're using a newer version of ADFS but I couldn't find an updated reference in the 2012 R2 documentation. However, the description isn't all that helpful anyway.

References from some other sources usually point to certificate issues (revocation checking, missing certificate in chain) or a time skew.

http://www.gfi.com/blog/how-to-resolve-adfs-issues-with-event-id-364/

I know you said the certificates were installed correctly but you may want to double check that you can complete the revocation check and the chain validates. The easiest way to do this would be to open the certificate on the server from the Certificates snap-in and make sure there are no errors are warnings on the General and Certification Path tabs.

I've had time skew issues bite me in other authentication scenarios so definitely make sure all of your clocks match up as well.

Another thread I ran into mentioned an issue with SPNs. I know when I setup an ADFS 2012 R2 environment I ran into a problem with the SPN registration because my server's FQDN was the same as my intended Federation Service name (adfs.domain.com) so it was unable to register the SPN for ADFS. I fixed this by changing the hostname to something else and manually registering the SPNs. Unfortunately, I don't remember if this issue caused an event 364 though.

One thing I am curious about that you didn't mention if you had tried is whether or not you tested authentication to ADFS without the MFA extension. The extension name showing up in the exception stack seems to indicate it is part of the issue but that test could help you rule out issues with other aspects of your ADFS deployment.

Finally, if none of the above seems to help I would recheck the extension documentation to make sure that you didn't miss any steps in the setup. Hope that helps!