Office 365 – Exchange interaction Design

By rzomerman | | No Comments | Office 365, Other

Office 365 is booming.. everyday new companies decide to make the switch to easy online messaging and collaboration services on the cloud. While the cloud should make life easier for administrators, setting up the co-existence environment seems a bit harder. Although Microsoft has tons of help material available .This post is to clearify the interaction when settings up a co-existence environment with Office 365.

For this example I have added a TMG server to validate the requests. As many companies have additional firewalls in front of the TMG server, this is also displayed. And the TMG server serves another role to in the advanced setup, where we explain that it is possible to have OWA users use two-factor authentication while ActiveSync users can continue to authenticate against the federation server with their “passive” clients. (see the next post)

Client Connect

When clients connect to the Online services in a co-existence environment, the following diagram is applicable:

Figure 2: Initiating traffic from clients

There are two possible clients that are able to connect to the environment.

  • External clients: these machines are connected via a public connection. These clients use public DNS to retrieve the records for services used. Clients will connect to the DNS server using standard protocols (UDP 53 / TCP 53). As these clients probably do not have Outlook installed, they will commonly be using the Outlook Web Access service instead. After the DNS has given the location of the Online Web services, the connection will be based on http protocol with certificate validation to achieve a SSL (https) secure connection. During the initalization phase of the secure connection the certificate used is verified by using the certificate services.
  • Internal clients: are clients that are in the internal network. These clients use the internal DNS server for name and service resolving and will connect to the Exchange services through a firewall.The internal clients are more likely to use Outlook as their primary e-mail client. While the mailbox of the user is located on the MSOL Exchange, Outlook will use a SSL (https) secure connection. During the initalization phase of the secure connection the certificate used is verified by using the certificate services.

User validation

When the primary connection to the service is created, the user connecting to the service must authenticate in order to be able to login to his/her mailbox. There are two types of client authentication mechanisms possible. First of all there are the Passive clients. These are clients that for example connect to OWA via a browser. Secondly there are Active clients, these are for example Outlook and your mobile device.

Passive Clients

Passive clients and active clients use a different method for authentication, passive clients are redirected from federation server to federation server in order to retrieve a SAML token to provide logon information to the Exchange Services.

Figure 3: Federated authentication Passive client logon

During the passive logon, the user connects to the Exchange services to access OWA. The page asks for user credentials, but only the UPN name of the user is sufficient. This UPN is used to determine the federation services to be used for further authentication. The Exchange service then ‘knows’ a federated domain in Office 365 is accessed and therefore requests a token from the client. As the client cannot provide one (yet) the client is send to the Federation Gateway to receive one. The Federation Gateway cannot identify the user (as it does not know its password/username) and redirects the client towards the federation services from the customer (as defined by the UPN). When the client connects to the federation services, it must authenticate. Depending on the configuration integrated/kerberos logon can be used, or the user is requested to enter a username/password. The user is authenticated against the Active Directory and after receiving a token for the Federation Gateway, it is redirected back to the Federation Gateway. There the client gives the token received from the federation service, receives a token for the Exchange services and is again redirected to the Exchange services. There the client now can give the token received from the Federation Gateway, and access is permitted.

Active Clients

Active clients are not capable of being redirected and therefore the federation gateway from MSOL performs this request on behalf of the user. Each client has a small piece of software installed that connects the local software to the Exchange Services. When a user starts for example Outlook, the local software challenges the user for username and password.

In case the client is domain joined, this information is automatically transferred. Then the information of the user is sent to the Exchange Services through the local software. Now this is where things become interesting. Instead of requesting the user for a token (or username/password), the Exchange service takes over the initializing role for authentication. For this the given username by the client is matched against the local MSOL user database to find the local object. This local object will authenticate against the Exchange Service, but for this, it will need a token. The Exchange service sends the username to the Federation Gateway which redirects the Exchange Service to the federation service. There a claim is requested on behalf of the original user and as the Exchange server has the basic username and password, the request can be authenticated by the federation services. After receiving the claim, the Exchange server goes back to the federation gateway and receives a local token that can be used to access the service.

Directory Synchronization

In order to provision mailboxes in the MSOL Exchange environment, the internal Active Directory identities must be created in the MSOL environment. In order to support the automated provisioning and linking of accounts within the MSOL environment, the DirSync component needs to be installed. This component is a small application that reads information from the local Active Directory and passes this information to the MSOL environment (and backwards).

The Directory Synchronization tool is based on the synchronization service of Microsoft Identity Integration Server (MIIS). It uses management agents to connect to the local Active Directory and the online webservice. The management agent for Active Directory reads information from the AD database and adds that information to a local SQL database instance. The information is then transferred over the online management agent so the data can be exported to the MSOL environment.

Note: The Directory Synchronization tool does not include options for high availability, nor is there the option to provide automated failover services. If the Directory Synchronization tool is not operational, existing users will still be able to use the MSOL services. New users will not be provisioned and changed attributes in the Active Directory will not be visible in the MSOL environment. E-mail services will continue to operate.

So the directory synchronization has two interfaces that are used to send and receive data from the two sources. The first source is the internal Active Directory. The second is the web access management agent. The Active Directory connection is based on LDAP with Kerberos/NTLM authentication and is signed and encrypted with a session key based on the login session of the service account used to retrieve and write information from and to the database.

The second connector is the connector to the MSOL services. This connector is based on http traffic encrypted with certificates. As the directory synchronization tool initates the connection to the MSOL service the MSOL public certificate is validated by the certificate services.

Federation Services

During the configuration of federation services, the federation servers are required to be able to connect externally to the MSOL Federation services. This is due to the fact that the creation of the WSS-Trust is fully automated for the on-premise federation service and the MSOL federation service. During the configuration (only) there will be a direct connection from the on-premise federation farm towards the MSOL federation farm. After this initial connection for configuring the federation farm, there are no active connections required for normal operations.

Figure 7: federation service setup interaction

During the setup of the federation WSS-trust, the federation service will connect to the MSOL federation URL. This URL is resolved using DNS (1) and then a connection is made to the MSOL federation service using an SSL connection (2 and 3). As the federation URL is secured with a certificate, a validation on the certificate will be performed (4).

Exchange to Office 365

The Client Access role serves three important URL’s when combined with Office 365. The three URL’s allow for remote management, access to the Offline Address Book and Active Sync to connect to the mailboxes during mailbox movement.

Figure 8: Services delivered by CAS servers

The three services are accessed by the Online Exchange services in various scenario’s. The following scenario is the retrieval of the Offline Address Book and or calendar information:

Figure 9: Exchange interaction design – Retrieving information from on-premise Exchange

The other scenario is used during mailbox migration and thus mailbox data retrieval:

Figure 10: Exchange to Office 365 interaction

In Figure 10: Exchange to Office 365 interaction the process of the interaction between Office 365 and the on-premise Exchange is displayed. When changes are made through the management console (like moving a mailbox) the request is sent to the Online Exchange services over an SSL (https) connection. As the request is sent directly to Office 365, the initial request cannot be used to retract data or service information. Office 365 will initiate a new request to the Exchange published URL’s for service and data retrieval. For this sequence to start, the Office 365 will query public DNS servers for the service and IP information of the on-premise Exchange environment. After the initial connection and certificate validation (as ssl / https is used) the Office 365 connect directly to the published services. The connection is validated by Active Directory by using RPC ports.

The following services should be made available for Office 365 interaction:

  • Exchange Web Services – extensibility point for clients that connect to the Exchange server and retrieve information about user availability and the manipulation of items in the Exchange data store
  • Offline Address Book – a copy of a collection of address lists that can be downloaded so Microsoft Outlook users can access the information it contains while disconnected from the server.
  • ActiveSync – a protocol used for Exchange ActiveSync capable devices to synchronize e-mail, calendar, contacts and tasks.
Tagged