Exchange Integration DME 4.4 Microsoft Exchange 2007, 2010, 2013

(1)

Exchange

Integration

DME 4.4 • Microsoft Exchange 2007, 2010,

2013

(2)

Integration with Microsoft Exchange 2007/2010/2013

Integration with Microsoft

Exchange 2007/2010/2013

This section describes the integration between the DME server and Microsoft Exchange 2007/2010/2013.

When integrating the DME server with a Microsoft Exchange system, the authentication and authorization system is the Active Directory (AD); the DME server interfaces with the AD using LDAP. This document provides information for setting up an Exchange server to accept connections from a DME connector. In addition, prerequisites and requirements for a successful integration between the DME connector and Exchange server are discussed. Please note that this document does not cover all aspects of the Exchange server's functionality, and the Exchange server documentation should be consulted as a supplement to this information.

To set up Microsoft Exchange 2007/2010/2013 with DME, you must go through the following steps:

1. Set up firewall rules (described at the DME Resource Center

http://resources.excitor.com/docs/firewall-rules).

2. Set up Active Directory.

(4)

Active Directory preparation

Active Directory

preparation

When the firewall rules have been set up, your Exchange Active Directory must be prepared for DME. The DME server connects to Active Directory via connectors to verify user credentials and group memberships. In addition, information regarding the location of the user's mailbox is retrieved (that is, server name and file path). For the DME server to operate completely integrated to the existing

collaboration system, information regarding mail server and mail store for each user must be available through Active Directory.

AD users

DME's point of entry into AD is through a user called DME_Server. This user is required in order to get mandatory information about the users (mail server, e-mail address, group membership etc.). The connection to the AD is through LDAP/LDAPS. Make sure that the

DME_Server user has the required read access.

1. Create a Standard Domain User in Active Directory called

DME_Server (case sensitive).

(5)

DME_Server user Domain Administration rights. Ensure that it is only a member of the Domain Users group, and do not make it a member of any other group.

The AD lookup identity DME_Server can be used to scan the users' mailboxes for new e-mails (see Mail access in Exchange

2007/2010/2013 on page 6) for push mail purposes.

AD groups

DME requires the presence of the AD/LDAP groups DME_User ,

DME_Superuser, and DME_Admin. The members of these groups have different levels of access to DME (see below).

The actual groups in Exchange can have other names, and in that case you must use those group names in DME instead. This can be

configured in the Access rights fields in the Domain setup panel of the connector performing authentication in the DME Server

Administration web interface:

For more information, see the online help (click in the web interface).

In Active Directory, create the following groups: DME_Admin ,

(6)

Active Directory preparation

One DME connector is bound to one Active Directory domain to authenticate the users. The Group scope can therefore be Domain local, and the Group type should be Security for each group.

According to Microsoft documentation, having a group scope of

Domain local allows the groups to include groups of larger scope (Global and Universal). Please contact your DME partner if your AD setup involves multiple AD Domains.

Add the Administrator users to the DME_Admin group, superusers to the DME_Superuser group, and the regular synchronization users to the DME_User group. Administrators are the people that have access to administer the DME server through the DME Web

Administration Interface. Superusers can manage settings for groups or users (see the DME Server Web Administration Reference). Please note that members of the DME_Admin and DME_Superuser groups do not have the privileges of the DME_User group by default; if they are also regular users of DME, they must be added to the DME_User

(7)

Mail access in Exchange

2007/2010/2013

In order to enable integration between Exchange 2007/2010/2013 and DME, you are required to set up two areas of permissions:

 Anonymous access to the EWS

 DME scanner access to user mailboxes

This is described in the following sections.

Exchange Web Services access

DME integration with Exchange 2007 requires that anonymous access to the EWS is Disabled.

DME integration with Exchange 2010/2013 requires that anonymous access to the EWS is Enabled.

Exchange requirements for DME integration with Office 365 is similar to Exchange 2010/2013. See Connecting DME with Office

365 on page 14 for a description of how to enable users of Office 365

to connect with DME.

Anonymous access is configured in the IIS manager. The configuration of Exchange 2007 is different from the configuration of Exchange 2010/2013, and the configurations are described separately below.

Note that if Exchange 2007 is running on Windows 2008 and AD

2008, authentication may require special setup. For more information about this we refer to the Microsoft knowledgebase.

As of DME 3.6 SP1 there are two ways of using NTLM authentication: Java native NTLM support and Oakland NTLM. This is configured on the connector. By default, the DME connector is configured to use the native Java NTLM. However, in some cases you need to switch to using Oakland. For instance, you need to use Oakland for Exchange 2010/2013 if NTLM SSP v2 is required (the local policy security

setting Network security: Minimum session security for NTLM

SSP based (including RPC) servers is set to Require NTLMv2

(8)

Mail access in Exchange 2007/2010/2013

EWS in Exchange 2007

1. Start the IIS manager.

2. Open Properties for the EWS site.

3. Click Edit... in the group Authentication and access control. 4. The setting Enable anonymous access must be Disabled.

Otherwise, when the connector tries to access the EWS, it will receive "HTTP 403 Forbidden" error messages.

Note also that either Windows Authentication or Basic

Authentication must be enabled.

(9)

3. Click Authentication.

4. Check the Anonymous Authentication setting:

5. Anonymous Authentication must be Enabled. Note also that either Windows Authentication or Basic

(10)

Scanner access

The second part of enabling integration between DME and Exchange is to grant the DME notification scanner access to look for changes in the users' mailboxes.

In order to be able to notify each user of new e-mail etc., DME must have access to scan the users' mailboxes for changes. DME supports two modes of mail scan:

1. Using the users' own user name and password.

If the option Store user password (encrypted) is selected in the section Server configuration > Authentication in the DME Server Administration Web Interface, the user's ID and password will be used for mail scanning. The user password is encrypted on the DME server.

This works without any additional configuration.

2. Using an AD lookup identity (DME_Server) for all mail scanning. See AD users on page 3 for information about creating the

DME_Server user. This Domain User will also act as the Service Account to operate the DME Server as a Service (see

Administration Tools > Services in Exchange).

Note that in mixed 2003/2007 environments, the DME_Server

user must have a 2007 mailbox in order to be able to scan 2007 mailboxes.

Now give the DME_Server user full administrator access to client mailboxes. To do this, you have two options:

1. Using the Exchange Management Shell:

1. To give the service user (DME_Server) access rights to the mailbox store of all users at a given point in time, pipe the

Add-MailboxPermission command into the Get-Mailbox

(11)

Get-Mailbox | Add-MailboxPermission -user "DME_Server" -AccesRights FullAccess

2. To add the right to an individual user (every new user created after running the command above), use:

Add-MailboxPermission -Identity "user" -User "DME_Server" -AccessRights FullAccess

3. A shortcut to executing the Add-MailboxPermission right to

all existing mailboxes is to If you want to want to give access to DME_Server at mailstore level, that is for all users (current and future), you can run the following command (according to this Microsoft technote

http://technet.microsoft.com/en-us/library/bb310792%28EX CHG.80%29.aspx):

Add-ADPermission -identity "mailbox database" -user "DME_Server" -ExtendedRights Receive-As

According to some sources, you may have to add the

undocumented ms-Exch-Store-Admin access right as well by

adding ,ms-Exch-Store-Admin to the command above.

However, according to the following Microsoft KB article

http://support.microsoft.com/kb/940846/en-us, there is a

bug in the Add-ADPermission command, so on your version of

Exchange 2007 this may not work. If this is the case, best practice would be to run the commands in items 1 and 2 above.

To check if it works, run the Get-MailboxPermission

-Identity "User" command on a user you suspect is not

working (a user getting a DME error "unable to fetch inbox" or similar when using the DME_Server scan user):

If the console lists the DME_Server with (FullAccess) and

IsInherited set to True, then you MUST run the

Add-MailboxPermission command in item 2 above.

Another way to test if the DME_Server user has the correct access to the user mailbox is by using the OWA. Log in as

DME_Server, and use the drop-down box in the upper right-hand corner to open another user's mailbox. If the

(12)

2. Using the Exchange Management Console:

1. Go to Recipient Configuration 2. Click Mailbox

3. In the middle window, click the user to which you want

DME_Server to have full access

4. Right-click, and select Manage Full Access Permission... 5. In the pop-up window, click Add...

6. Select DME_Server, and click OK 7. Click Manage

(13)

Multiple Exchange servers

If the Exchange 2007 system contains more than one mail server, you must identify the mail server which has the Client Access role (not the Mailbox role). To ascertain this, open the Exchange Management Console on the Exchange server:

Enter the IP address or name of this client access mailbox

(QAT-EX2K7 in the example below) in the Functions setup panel of the connector in the DME Server Administration Web Interface (the field Server in the illustration below). If you only have one mail server, you do not need to complete this field; if you have more than one server with the Client Access role, you only need to enter the IP address or server name for one of them if they are at the same

location.

Exchange 2007 contains an administrative group called

FYDIBOHF23SPDLT. Sometimes DME recognizes this

administrative group as the mail server, but this is not correct. You can prevent this from happening by tweaking the regular expression which extracts the mail server from LDAP in the field Server

(14)

Attachment size readout

For some reason, reading out the size of e-mail attachments is not possible using Exchange Web Services (EWS). To work around this limitation, you can set up DME to use the WebDAV protocol for this purpose (as in Exchange 2003).

To enable DME to do this, you must do the following:

1. WebDAV must be running on your Exchange 2007/2010/2013 server. This is the Exchange service in the IIS Manager. 2. In the DME web interface, edit the Exchange connector(s)

responsible for synchronizing e-mail and calendar, and click the

Functions setup panel.

3. In the Exchange integration > Advanced section, make sure the field Read attachment sizes (2007/2010) is selected. 4. In the Connection section, check the field Secure (SSL). This

setting describes the connection to the WebDAV service, and must match the corresponding setting in the IIS WebDAV setup: 1. In IIS Manager, open your Web Site, and click Exchange. 2. In the Directory Security tab, click Edit... in the Secure

communications section of the dialog.

3. In the Secure Communications dialog, check the setting of the field Require secure channel (SSL).

(15)

Connecting DME with

Office 365

It is possible to run DME alongside the Microsoft cloud solution Office 365. DME authenticates users via Active Directory lookups, so having an AD is required as described in Active Directory preparation on page 3. In Office 365, users are managed in Windows Azure AD, and such users are not supported for use with DME. Users of DME must exist in the "real" AD. Microsoft allows access to on-premises AD for purposes such as this; this is called "Active Directory integration". It is also possible to run the so-called "hybrid" solutions, in which Exchange is installed on-premises as well as in the cloud. In such cases, at least two DME connectors must be installed; one servicing Office 365 users, and one servicing on-premises Exchange users. Exchange must be version 2010 or 2013, and must be set up as described in EWS in Exchange 2010/2013 on page 7 and elsewhere in this document.

The graphic below shows the overall setup of a DME/Office 365 system. Only elements mentioned in this guide are shown. Note also that the phrase "on-premises" is used for elements (AD, Exchange, or DME) installed anywhere other than in Office 365; they could be installed locally in-house or be hosted in the cloud somewhere else.

(16)

Connecting DME with Office 365

Office 365 and AD

1. First acquire an Office 365 subscription. There are several different offerings, but the subscription must support "Active Directory integration", and that requires an Office 365 Midsize

Business plan at minimum. See office.microsoft.com

http://office.microsoft.com/en-us/business/?WT%2Eintid1=OD C_DADK_FX010064710_XT104029222 for more details.

2. You now need to connect Office 365 with your on-premises

AD. To do this, log in to Office 365.

Add the domain that points to your on-premises AD, and confirm that you actually own that domain. To do so,

1. Click domains in the menu on the left 2. Click Add a domain

3. Enter the name of your AD server, e.g. company.com.

You then need to confirm that you actually own the domain you entered, by adding a TXT (preferred) or MX record to your DNS. Office 365 provides an on-screen guide how to do this.

4. Confirm the domain addition.

You may have to repeat this process after the DNS record changes have come into effect.

Next, set up a trust between Office 365 and your AD.

AD-FS

1. Now set up a trust between your on-premises AD and

Office 365 by installing AD Federation Services (AD-FS) on your

AD server. This allows you to let another service extract user names and passwords from AD, encrypt them, and send them to Office 365 (more about this later).

1. To do this, you must download the Active Directory Federation Services 2.0 RTW from Microsoft

http://www.microsoft.com/en-us/download/details.aspx?id= 10909 (if the link does not work, you can search for the tool).

The tool guides you through the installation of AD-FS. 2. Then install a certificate using IIS Manager > Server

Certificates on the server on which you installed AD-FS.

(17)

In the Common name field, use the domain you entered in Office 365. We recommend getting a wildcard certificate, so include a wildcard character before the domain name - like this: *.company.com

4. Have the request (CSR) processed at a public certification authority (CA) such as Verisign. They will provide you with a certificate.

5. Import the certificate using IIS Manager > Server

Certificates. Click Complete Certificate Request, and

browse to the certificate file you received from the CA. 6. Enter the friendly name of the certificate - in our example,

*.company.com - and click OK.

7. In the Default Web Site in IIS Manager, click Bindings, and add an https site binding. Select the newly imported certificate, and click OK. This enables secure connections to the server.

8. Now configure AD-FS. Start by clicking AD FS 2.0

Management in the server's Administrative Tools.

9. Click AD FS 2.0 Federation Server Configuration

Wizard.

10. In the wizard, choose Create a new Federation Service. 11. Click New federation server farm. Choose this option

unless you are absolutely sure you will never install a second AD-FS server. Having a farm with only a single server does not hurt anything, but it might give you more options later if you want to add redundancy.

12. Now choose the certificate to use, in the field Federation

Service name. Specify a full name, for instance

fs.company.com. Clients will connect to this name.

13. Specify an AD Service account that will be used by AD-FS, and complete the guide.

(18)

Connecting DME with Office 365

Directory synchronization and test

1. Enable directory synchronization. This must be installed on a

64-bit server that is not domain controller, but the server must be member of the domain, using an account with Enterprise Admin rights to the local AD. The DirSync tool is called Microsoft Online Services Directory Synchronization (DirSync for short). It ensures that an encrypted copy of user credentials from the AD are stored in and accessible from Office 365.

1. Log in to the Office 365 administration center, and click users

and groups.

2. Activate Active Directory synchronization.

3. Download the Directory Synchronization tool (DirSync.exe).

Make sure to use the 64-bit version of tool. The 32-bit version is being deprecated.

4. Run DirSync.exe, and install the DirSync tool. When you click

Finish, a configuration guide appears.

5. Enter your Office 365 Administrator credentials and your AD Enterprise Admin credentials.

6. Enable Rich coexistence (recommended; does not affect DME).

7. Click Finish to begin the initial synchronization.

The DirSync tool runs every 3 hours by default. However, you can manually initiate a sync from the interface.

2. To test the directory synchronization, create a new user in AD. When you do, make sure to put the user's e-mail address in the

E-mail field. Office 365 will then use this e-mail address by default

rather than the auto-generated e-mail

(yourdomain.onmicrosoft.com) as user name for the user. Run

DirSync. After a while the user will appear in Office 365 as proof that AD integration works correctly.

It is now time to enable DME to service Office 365 users.

DME setup for Office 365

1. Finally, set up DME to support Office 365 users. To set up DME, 1. Install a new Exchange connector.

2. In the DME web administration interface, open the Connector setup page on the E-mail and PIM subtab.

(19)

in the web browser URL, and paste it into the Server field in DME.

4. Make sure to select the Exchange version you are actually using in Office 365, in the field Protocol. This will typically be

Exchange 2010 (use this for Exchange 2013 also). This field must not be left at Auto detection.

5. Click Save.

(20)

Multiple domains and trusts

Multiple domains and

trusts

Up until DME 4.1 SP1, you have been able to use one connector for one AD domain only. With 4.1 SP1, DME supports cross-domain search, enabling one connector to serve users from multiple domains. This section describes how to set up AD and DME to support AD trees and AD forests. This is described through an example, in which a company with the domain AD1 merges with another company with domain AD2. Two possible scenarios are described:

1. Where AD1 and AD2 are two top-level domains in a domain forest

2. Using AD2 as a child domain of AD1 in a domain tree

Top-level domains

You can use both AD1 and AD2 as juxtaposed, top-level domains. In order for DME to be able to service users in multiple top-level domains using just one connector, you must assign the role of Global Catalog (GC) Server to the domain controller to which DME

connects. The global catalog is a distributed data repository that contains a searchable, partial representation of every object in every domain in a multi-domain AD forest.

By setting the DME connector up to connect to a Domain Controller in AD1, acting as a GC server, you will now be able to validate and look up users in the entire AD trust (depending on your

configuration), using only one DME connector.

The DME connector can be routed to a domain controller in the

Domain section of the connector setup panel. In the field Domain info directory server you can specify the AD entry point using the

(21)

Child domains

In order for DME to be able to service users in a domain tree using just one connector, we recommend that you assign the role of Global Catalog (GC) Server to a domain controller. The global catalog is a distributed data repository that contains a searchable, partial

representation of every object in every domain in a multi-domain AD forest. This makes AD lookups faster.

By setting the DME connector up to connect to a Domain Controller, acting as a GC server, you will now be able to validate and look up users in the entire AD tree (depending on your configuration), using only one DME connector.

You can point the connector to a domain controller anywhere in the AD tree, as illustrated below.

Example 1 Example 2

The DME connector can be routed to a domain controller in the

Domain section of the connector setup panel. In the field Domain info directory server you can specify the AD entry point using the

(22)

Multiple domains and trusts

AD route syntax

The domain controller used for AD lookups is specified in the field

Domain info directory server in the Domain section of the

Connector setup panel.

In this field you must enter the DNS name or IP address of the directory server (LDAP/AD) used by the current connector for looking up domain information such as mail file and group membership for authorized DME users. You can specify a

non-standard port by adding a port number (:<port>). On Domino, it will always search the entire LDAP tree from the root.

In this field you must enter the DNS name or IP address of the Active Directory Domain Controller used by the current connector for looking up domain information such as mail file and group

membership for authorized DME users.

You must use a certain syntax, which is as follows. For performance reasons, we recommend reading from a domain controller designated as Global Catalog Server. This is done by specifying gc://.

Read from absolute AD root:

gc://[DomainController][:port]/

Note the trailing slash, which means that the entire tree will be searched from the root.

Read from specific AD container:

gc://[DomainController][:port]/DC=Users,DC=company,DC=com

In this example, the search will be targeted to the Users container. If you do not use a Global Catalog, you can prefix the domain controller path with ldap:// instead of gc://. A disadvantage of

using ldap is that you risk slower performance or no response at all,

depending on your AD configuration.

Note that if you use secure connections, you can use the following syntax: gcs:// or ldaps://.

If you do not specify either gc:// or ldap://, it will default to using

the domain name root of the domain controller that you specify. For instance, ad1.company.com. This will enable you to search from this

(23)

Common errors

The following are examples of common errors you may encounter when running DME against Exchange 2007 and above. The errors are shown when running the automatic diagnostic test (click Test

connection in the E-mail and PIM setup panel of the connector):

 The DME connector hangs when testing the connection to

your Exchange server using NTLM as authentication.

As of DME 3.6 SP1 there are two ways of using NTLM

authentication: Java native NTLM support and Oakland NTLM. This is configured on the connector. By default, the DME connector is configured to use the native Java NTLM. However, in some cases you need to switch to using Oakland. For instance, you need to use Oakland for Exchange 2010/2013 if NTLM SSP v2 is required (the local policy security setting Network security: Minimum

session security for NTLM SSP based (including RPC) servers is set to Require NTLMv2 for the CAS server). If the connector hangs, switch to using the Oakland NTLM

authentication method. See the Connector installation document for more information.

 Mail scan login

Message:

User - dme.base.exchange2007.ExchangeException: Find folder operation error. Exchange returned error code:

ErrorItemNotFound (The specified object was not found in the store.)

Reason:

The DME_Server user does not have access to the mailbox of the user.

Message:

User - null

Reason:

(24)

Common errors

Message:

User - dme.base.exchange.ExchangeErrorLoginException: Login error. User: DME_Server@Domain to server QAT-EX2K7 (uri: http://SERVERNAME:80/exchange/USER@domain/);

Authentication scheme: BASIC; Connection is unencrypted

Reason:

This error can occur if you have configured the DME server to synchronize against Exchange 2003, when it should be Exchange 2007 or 2010 (for 2013 also use the "Exchange 2010 (Web service)")

(Connector setup > E-mail and PIM in the Connector tab; see below).

WebDAV = Exchange 2003; Web service = Exchange 2007 and 2010/2013.

 Connection to LDAP (172.16.12.72)

Message:

No communication with LDAP server

Reason:

The LDAP server is down, or a wrong address is configured on the DME connector for the LDAP server (Connector tab >

Connector setup > Authentication panel > Authentication > LDAP Server).

Message:

User - dme.base.exchange2007.ExchangeException: Find folder operation error. Exchange returned error code:

ErrorAccessDenied (Access is denied. Check credentials and try again.)

Reason:

Possibly the DME_Server user does not have a mailbox. See AD

users on page 3.

Message:

User - dme.base.exchange2007.CommunicationException: org.apache.axis2.AxisFault: Transport error: 503 Error: Service Unavailable

(25)

org.apache.axis2.AxisFault: Stream closed

Reason:

The IIS (Default Web Site) is stopped.

Message:

User - dme.base.exchange2007.CommunicationException:

org.apache.axis2.AxisFault: Transport error: 403 Error: Forbidden

Reason:

EWS (Exchange Web Services) in the IIS is set to use SSL, and DME is not.

 Cannot authenticate users

Message:

java.util.concurrent.ExecutionException: dme.sync.LoginException: Wrong authorization

Reason:

Neither Windows Authentication nor Basic Authentication is enabled in the EWS. See EWS in Exchange 2007 on page 7 or

EWS in Exchange 2010/2013 on page 7.

 Cannot authenticate user

Message:

Org.apache.axis2.AxisFault: Transport error: 401 Error: Unauthorized

Reason:

Basic/NTLM configuration for the affected user or users is wrong. Furthermore, if you have been using the Add-ADPermission

command to grant the DME_Server user access to all mailboxes, the

Exchange Integration DME 4.4 Microsoft Exchange 2007, 2010, 2013

Exchange

Integration

DME 4.4 • Microsoft Exchange 2007, 2010,

2013

Contents

Integration with Microsoft

Exchange 2007/2010/2013

Active Directory

preparation

AD users

AD groups

Mail access in Exchange

2007/2010/2013

Exchange Web Services access

EWS in Exchange 2007

Scanner access

Multiple Exchange servers

Attachment size readout

Connecting DME with

Office 365

Office 365 and AD

AD-FS

Directory synchronization and test

DME setup for Office 365

Multiple domains and

trusts

Top-level domains

Child domains

AD route syntax

Common errors