Adding to this in hope that others find it useful… Using the various resources that are further up this thread (for which thanks), I have got ADFS + Google authenticator working both on the intranet and the extranet but there are a couple of things along the way that required a bit more digging.
- Exchange 2019 on Win2019
- ADFS on WIn2019, upgraded to latest version
… both behind an inner firewall
- WAP in a DMZ
- Internal CA but a LetsEncrypt-provided cert on the Internet-facing interface on the WAP server
I used this provider: [[GitHub - privacyidea/adfs-provider: Authentication provider for Microsoft AD FS to use with privacyIDEA.]([GitHub - privacyidea/adfs-provider: Authentication provider for Microsoft AD FS to use with privacyIDEA.]] at v 1.0.1. It’s easy to install. All the required parameters are dealt with in an installation dialog. The bit that’s “tricky” here (for me) was the choice around providing (or not) the service_user, service_pass (and which they were) and the choices about trigger_challenges vs send_empty_pass. I went for:
Service user = the account name used to log on to the PrivacyIDEA website
Service pass = password for the same
Trigger Challenges = 1
Notes: (1) The password for the service account is stored in clear text in the registry and (2) is written in clear text in the registry
- The ADFS signing certifcate needs to be copied to your Exchange Server and put in Trusted Root Certification Authorities
- When this certificate expires it will need to be update manually in the Exchange Server
- I had replaced the self-signed certificate on the PrivacyIDEA server with one signed by the internal CA
Claim issuance policies:
- The “*” in the text provided in the Quickbreach post should be replaced by “==”
- If you have a sub-domain setup then UPN != corporate email… I did briefly try adding another rule to see if I could work with email address but that did not work but domain\username did as well as UPN
- I reached a point where going to the OWA URL would pop up the ADFS login page and then when i had provided AD credentials I would get an error (Event ID 364 including this “Microsoft.IdentityServer.Web.WebConfigurationException: No style sheet is configured in the active theme for default locale [en-GB/2057].”). Fixing this involved hunting down the SID for the ADFS service account and then updating the internationalisation (??) data for that SID in the registry. See here for something similar and the fix required AD FS 4.0, Custom MFA Provider, International locales, and style sheet exception
With these in place, I could make everything work on the intranet but it failed on the Internet-facing interface.
Making it work on the Internet-facing interface:
I needed to add a CNAME for the interface that referred to my adfs FQDN but aliased the single public IP address I have.
Imperfect notes but possibly of use to others.