Dou for OWA, Multi-Tenant OWA. The Catch? Only one Tenant wants it

Got a puzzler here for you all.

We host a multi-tenant Exchange environment. One of our tenants is looking to implement Duo and I am a bit lost for how to implement it for only their tenant. We use it just about everywhere for our purposes, but it is on a singular domain. For the Tenant, we need to trigger the Duo prompt only for their OWA session (AD group/OU segregated). Is there a way to prompt for Duo in OWA after the initial login similar to how RDP sessions are setup?

If there isn’t, our next step would have to be to explore integrating them into O365 and setting up 2FA there, probably would still be Duo since they already have it in place.
We’re not exactly excited for this second option, especially after the last Azure outage!

The Duo OWA application adds Duo via an IIS module that is implemented in the web.config for the /owa and /ecp FrontEnd virtual directories. In multi-tenant Exchange don’t all tenants share the same OWA virtual directories and the tenancy is done through address book views (2013 and later)? If all users in every tenant access the same OWA virtual directory, then trying to implement Duo per tenant is likely not possible.

ETA I should say that I can think of some ways to do it that I would not actually recommend, like “install Duo OWA and leave the new user policy set to allow access without 2FA, and then that one tenant who wants 2FA should go enroll their users in Duo” (which would be an imperfect solution that doesn’t strictly enforce that the one tenant’s users only log in with 2FA), or “add every user from every tenant as Duo users and apply bypass 2FA status to the users who do not belong to the one tenant that wants to use 2FA” (which would be $$$ from a Duo licenses consumed perspective w/o providing the value of 2FA inherent in the license cost).

I was afraid of that answer as that was what my research was implying. I am however, interested in the “Allow Access without 2FA” option, but only if I can find an alternate way of enforcing 2FA outside of Duo. I’m not exactly hopeful about it, but I’ll chase down that road just to confirm it.

wouldn’t this be possible with ad security groups and application policies to either enforce / allow bypass?

That was what I was wondering after @DuoKristina’s response. Whatever methodology though would have to be enforceable and if it is possible to go this route, we’re already set for it as we’ve been very diligent with keeping things organized. Has anyone else been able to successfully implement it this way? I’ll explore this route further to see if it looks promising.

wouldn’t this be possible with ad security groups and application policies to either enforce / allow bypass?

Assume…

  • there are Exchange 5 tenants, TenantA through TenantE
  • there is a group in AD TenantA-Duo that contains all the users that belong to TenantA

One could…

Which would result in…

  • OWA users from TenantA who are members of the TenantA-Duo group in AD/Duo must enroll in Duo upon first access of OWA and must 2FA in every time they log in after enrolling
  • OWA users from TenantB - TenantE can access OWA without being asked to enroll in Duo or complete 2FA. They will see a flash of the Duo prompt as it grants access without any action by them.

This strategy relies on the TenantA-Duo group always containing the right members, and may require manual syncs by you as the Duo admin to immediately import new group members as they get added to the TenantA-Duo group in AD (because scheduled sync only runs once a day at a time randomly assigned). If any TenantA user didn’t get added to the AD group, or was removed by accident, that user would then not need to complete Duo 2FA for access.

Another option for the TenantA-Duo group policy would be setting the new user policy = deny access, and check the box in the AD sync config to send out enrollment emails to imported users, and require they complete enrollment in Duo via the emailed link before they can log into OWA instead of letting them enroll upon accessing OWA.