Office 365 tenant established. Exchange Online (EOL) for the user mailbox. Skype for Business on-premises for IM/P. Users are mixed – some have full Office suite, others are just a browser. Security is tight. No federation is desired or allowed with partners, vendors, spammers, or public (consumer) Skype. In addition, the requirement also stipulates that no authorized user can use the system remotely without going through a VPN.
This last requirement means that remote users via the Edge server must be disallowed – but….won’t the Office 365 users be remote? Great question. We will cover that down below.
Because of the user software mix, we need the pure browser user to have OWA (EOL) integrate with the SfB on-premises. Not the most attractive (visually and functionally) solution from the user perspective, but it does work. Specifically, the function requirement was for OWA users to have presence information and be able to IM.
This article will not attempt to show the end user how to muddle through using SfB with EOL OWA. The focus is just providing the service.
So, here is a visual of what we want… presence going both directions between the on-premises SfB users, and at least one of the users is using EOL OWA.
Obviously, we need an on-premise pool of some sort, and an edge server. And then get your hybrid working. In this case, the tenant (and the EOL work) was up and running before the SfB project started, so all we had to do was make sure that the Azure AD Connect was done right.
Danger Will Robinson!
Because the AAD Connect was done prior to to SfB schema extension, the AAD connect will need to be FORCED to reread schema and synchronize. You can read about this in a somewhat related post here.
Having taken care of the obvious install and configuration items, the next thing is to establish hybrid posture. If you have not already done so, you can read up on it here, here, and here. Pay particular attention to this last reference. Failure to do this will result in a no-go.. If you want all the fancy-schmancy integration, then you will need to do this here also.
Now that you have all that done, we are done. Right?
Well, no. Remember that we needed to have no federation with anyone other than an Office 365 user, and no remote user access? That seems to be a bit conflicting, yes? But no. A remote user is someone using a full client. A bit of testing showed that Office 365 connecting to the on-premises SfB was a federation user not a remote user.
As a final bit of constraint, we did not want to be changing the external firewall. So what to do? Maybe we need to do a little something with Edge configuration and policy, eh?
Here is our Access Edge Configuration:
From the top down, we need to federate – Office 365 is a federation. Per security requirement, no partner domain discovery, which closes out contacting anyone other than our own domain. No need to send an archiving disclaimer to people we cannot talk to. Per security, no remote user access. Lastly, no outside access to web conferencing, so no need for those pesky anonymous attendees. Just to confirm your deepest doubts, here is the SIP Federated Domains list:
Here is the External Access Policy:
Again, from the top, and note that we only have one thing checked…federated users is the requirement. Nothing else needed… XMPP is pretty much dead nowadays anyhow; no remote users, ergo, no need for that, and without public user federation, no need for that either.
We had a set of requirements: OWA integration between EOL and on-premises SfB. Security concerns were that no other domains be contacted, and none of our domain users can be remote. EOL users were not using Outlook, just OWA and we needed presence and IM. We did not do the full OAuth as those features were not part of the specification.