Exchange Integration DME 4.4 Microsoft Exchange 2007, 2010, 2013

Transcription

1 Exchange Integration DME 4.4 Microsoft Exchange 2007, 2010, 2013 Document version 1.1 Published

2 Integration with Microsoft Exchange 2007/2010/2013 Contents Integration with Microsoft Exchange 2007/2010/ Active Directory preparation... 3 AD users... 3 AD groups... 4 Mail access in Exchange 2007/2010/ Exchange Web Services access... 6 EWS in Exchange EWS in Exchange 2010/ Scanner access... 9 Multiple Exchange servers Attachment size readout Connecting DME with Office Office 365 and AD AD-FS Directory synchronization and test DME setup for Office Multiple domains and trusts Top-level domains Child domains AD route syntax Common errors Excitor

3 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 2. Set up Active Directory. 3. Identify server with Client Access Role. 4. Set up mail access Excitor

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, 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). 2. Allow the new user it to have its own mailbox Excitor

5 Active Directory preparation Do not use a Domain Administrator Account or give the 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 s (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 interface). in the web In Active Directory, create the following groups: DME_Admin, DME_Superuser (optional), and DME_User. The group names are case sensitive, and the groups must not be added to any other groups Excitor

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 group as well Excitor

7 Mail access in Exchange 2007/2010/2013 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 for the CAS server), or if you experience that the connector hangs when using NTLM. For more information, see the Connector installation document Excitor

8 Mail access in Exchange 2007/2010/2013 EWS in Exchange 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. EWS in Exchange 2010/ Start the IIS manager Excitor

9 Mail access in Exchange 2007/2010/ Go to the EWS site/application. 3. Click Authentication. 4. Check the Anonymous Authentication setting: 5. Anonymous Authentication must be Enabled. Note also that either Windows Authentication or Basic Authentication must be enabled Excitor

10 Mail access in Exchange 2007/2010/2013 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 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 command like this: Excitor

11 Mail access in Exchange 2007/2010/2013 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 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 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 attempt fails, then DME_Server does not truly have full access Excitor

12 Mail access in Exchange 2007/2010/ 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 In the pop-up window, click Add Select DME_Server, and click OK 7. Click Manage -as illustrated in the following: Excitor

13 Mail access in Exchange 2007/2010/2013 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 regexp in the Functions setup panel of the connector Excitor

14 Mail access in Exchange 2007/2010/2013 Attachment size readout For some reason, reading out the size of 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 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). If Require secure channel (SSL) is selected in IIS, then make sure the field Secure (SSL) is also selected in the connector. If IIS does not require a secure channel, then you are free to choose the setting of Secure (SSL) in the connector Excitor

15 Connecting DME with Office 365 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. In the following sections, we outline how DME can be made to work with Office 365. This is an outline only; you may need to resort to Microsoft documentation or other online guides for specific steps Excitor

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 C_DADK_FX _XT 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 (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. You can skip steps 2-7 if you are already running a secure (https) server Excitor

17 Connecting DME with Office Click Create Certificate Request, and complete the guide. 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. Now you must make Office 365 aware of the users in your AD Excitor

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 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 address in the field. Office 365 will then use this address by default rather than the auto-generated (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 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 and PIM subtab. 3. In the Server field, enter the path to Outlook in Office for example pod5445.outlook.com. You can find the path, Excitor

19 Connecting DME with Office 365 which is generated by Microsoft, by clicking Outlook in Office 365. Copy the part after and up until the first slash 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. Your Office 365 users are now able to use DME on their mobile devices Excitor

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 syntax described in the section AD route syntax on page Excitor

21 Multiple domains and trusts 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 syntax described in the section AD route syntax on page Excitor

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 domain down; you will be unable to search up through the specified domain Excitor

23 Common errors 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 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. Mail scan login Message: User - null Reason: The Secure Collaboration server is configured to True in DME, but the IIS is not set to use SSL, or the IIS is not running Excitor

24 Common errors Mail scan login Message: User - dme.base.exchange.exchangeerrorloginexception: Login error. User: DME_Server@Domain to server QAT-EX2K7 (uri: 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 > and PIM in the Connector tab; see below). WebDAV = Exchange 2003; Web service = Exchange 2007 and 2010/2013. Connection to LDAP ( ) 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). Mail scan login 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. Mail scan login Message: User - dme.base.exchange2007.communicationexception: org.apache.axis2.axisfault: Transport error: 503 Error: Service Unavailable OR Excitor

25 Common errors User - dme.base.exchange2007.communicationexception: org.apache.axis2.axisfault: Stream closed Reason: The IIS (Default Web Site) is stopped. Mail scan login 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 DME_Server might appear to have the required "full access". However if this setting is "inherited" then it may not work through EWS. For more information, including reference to the relevant Microsoft KB articles, see item 1.3 in Scanner access on page Excitor