posts - 104 , comments - 115 , trackbacks - 0

Tuesday, October 20, 2015

Office 365: Authentication

When we’re talking authentication the first thing that pops up in our minds is Active Directory. For years, active directory has been the staple identity provider for most companies and the foundational building block upon which most applications were built.

With Azure and O365, we need to think about the different authentication methods that could be. Are we going to an “all in the cloud” model? Federated identities? Hybrid active directory? Or maybe something else completely?

All in the Microsoft cloud

With the first possible solution we’re looking at an identity solution where nothing exists on premise. The most unlikely solution for the larger businesses, but if you’re a small or new business, this might be an option. You’re still in charge and you can still do, pretty much, the same things when it comes to authentication, but you’re hosting all your user information in the cloud with no servers on-prem.


1 - From the identity and authentication in office 2013 and O365 document



2 - From the Identity and authentication in office 2013 and O365 document


Living in a hybrid world

Most of the world does not live in an all Microsoft cloud only world. Companies have existing infrastructure, applications that need time to be ported and so much more items that restrict them from doing away with existing on-prem servers (and thank god for that or we would be out of a job!) that living in a hybrid world is necessary. But what does that look like?

Same-sign on

Behind door number one is the same-sign on option. Minimal on-prem infrastructure (a dirsync server is required) allows companies to leverage the “same sign-on” method. Historically the DirSync server would not sync end users password but we have that possibility now. OK, before anyone freaks out, let me clarify: Password Sync does not synchronize the password. It has no way of doing that. What it actually does is take the hash of the users password that exists in active directory, hashes that again, and syncs it up to Azure Active Directory. That way, Users can be authenticated using the same password they have in their on-prem active directory. But they will have to authenticate again. It is not single sign-on!

And yes, that’s a hash of a password hash. Hashception… (I really had to do that!)

Single sign-on

Single sign-on is what Microsoft preaches, but does require some extra infrastructure. For a start, you will need at least one ADFS server in order to authenticate against. Ideally you would have multiple so there is redundancy and you don’t lose your authentication infrastructure due to patching.

Authenticating against an ADFS server also means that users don’t need to re-enter their credentials when they are already logged in. Hence the name “Single Sign-On”.

Authentication flow with ADFS for an intranet user


1. An intranet user tries to access an application on Office 365, but hasn’t been authenticated before

2. The application redirects the user to Azure AD for authentication.

3. The user enters the username for the application and, because Azure AD knows ADFS has been set up, redirects that user to the ADFS server for authentication.

4. Since this is a Single sign-on scenario, and the user is working on a desktop which is domain-joined, ADFS issues a user token.

5. User token gets sent to the Intranet User.

6. The User token gets sent to Azure Active Directory, is validated and generates a new token for the application the user is trying to access.

7. The user can happily use the application.

Authentication flow with ADFS for an extranet user


1. Our extranet user tries to access the application for the very first time.

2. The application issues a redirect to Azure AD.

3. Once the redirect is processed, the user enters his or her credentials in the webpage. Azure AD, knowing the organization has ADFS enabled, issues a redirect to the ADFS server.

4. As the user is using the internet (Extranet) to access the ADFS server they hit the ADFS Proxy server which proxies all traffic to the ADFS server living in the internal network. Just like with the Intranet user the ADFS server issues a token.

5. The token gets sent to the user.

6. The token is passed on to Azure Active Directory, validated, a new token is created and passed down to the user.

7. The token is then used to authenticate against the application and the user can start working with vigor!


  • Identity and authentication in Office 2013 and O365

Posted On Tuesday, October 20, 2015 3:43 PM | Comments (0) | Filed Under [ Exchange Office 365 ]

Exchange Hybrid deployment scenarios


Hybrids: The final frontier. These are the voyages of the starship Enterprise.
Whether Exchange or Lync, hybrids are the wave of the future, something everyone will have to start dealing with at one point in their career.

With Exchange Hybrids in particular, we enable coexistence between our on-prem exchange environment and Office 365’s Exchange Online, enabling features such as:

  • Secure mail routing
  • Unified GAL
  • Free/Busy sharing
  • Centralized SMTP control & mail box management
  • A single Outlook Web App URL
  • Moving mailbox back and forth
  • Message tracking, mail box search and mail tips across both environments
  • The possibility to use message archiving in the cloud for on-prem mailboxes (Which could result in a huge cost savings!)

For those who have been in the exchange field a while, these all start to look fairly familiar with cross forest exchange deployments, don’t they? OK, not all these features are available in the same form if we do this between different on-prem forests, but Microsoft had to take its inspiration from somewhere now don’t they!

In essence there are a few deployment options we can consider for our Exchange Hybrid, but just to clarify, I’m talking about a full rich coexistence hybrid here, not some cutover migration plan.

Scenario 1: Direct connection in to the on-prem environment




The simplest of scenarios in that sense that we have a direct connection in to the on-prem environment. No hassle with reverse proxies and edge servers. Just open the ports, configure the hybrid and you’re ready to rock!

Scenario 2: Direct connection in to the on prem with mail routing through O365

A variation on scenario 1 would be to have your MX traffic going through the Exchange Online environment, which would have it protected by EOP.




Scenario 3: Direct connection in to the on-prem environment with edge server




In this scenario we still have a direct connection in to our exchange environment but are utilizing the edge server to have mail traffic filtered before coming in to the on-prem environment. A direct smtp connector still exists between Exchange Online and the Exchange on-prem environment.

Scenario 4: Direct connection in to the on-prem environment with mail routing through the edge server.

A variation on scenario 3 would be to let the edge server handle the mail routing to Exchange online.



Scenario 5: Direct connection in to the on-prem environment with mail arriving in O365 and routing down to the on-prem through the edge server

Or, we could have all the mail traffic come in to Exchange Online, using the awesome powers of EOP (Exchange Online Protection in case you have been wondering) and route the on-prem mail in through the edge server(s).




Scenario 6: No direct connection

And this is where things start to get slightly complex. There are a lot of companies out there that do not like opening up their internal network to O365 directly (I’m looking at you, security teams!). Whilst I can relate to some of the concerns that are raised with that setup, let’s not forget that Exchange is secure by design, and, if you let external users access you exchange servers directly, you should not have any concerns about O365 doing the same!

But how do we solve this conundrum? After all, in order to have rich coexistence Exchange Online will need to be able to access the on-prem EWS services for things like for free/busy lookups…

Enter the reverse proxy (Microsoft Application Request routing)!




Or, the mail routing alternative:



The attentive reader will have noticed two things. One, I didn’t put EWS traffic arrows on the last two images (we will cover that configuration and flow in a future article). And two, there is no directory sync in the diagrams. Nor are any ADFS servers displayed. I’ll cover all that and more in future articles!


Ports, IPs and URLs

One important thing to keep in mind is the ports, urls and ip adresses Microsoft uses for traffic. Since these get updated regularly I’ll refer you to the following article:

Posted On Tuesday, October 20, 2015 12:16 PM | Comments (0) | Filed Under [ Exchange Build Guides Deployment Office 365 ]

Powered by: