Once the Exchange server is deployed in the environment, first thing we need to do is to configure Client Access Services prior to adding users or any other production workloads.During Exchange Server 2019 installation, it automatically configures multiple Internet Information Services (IIS) virtual directories for client access services. Client Access Services can be configured through EAC or Exchange management shell.
Virtual directory settings
The tables below shows the settings for the frontend Client Access services and the default authentication methods in IIS along with required Secure Sockets Layer (SSL) settings. I have listed only exchange virtual directories in below tables. For each virtual directory, you can configure general settings and authentication options. Though we can configure the virtual directories through IIS manager, the preferred method is to use either the EAC or Shell because IIS Manager does not allow us to configure all settings.
Frontend Client Access Services on Mailbox servers
The following table lists the default settings in the Client Access services (the default web site) on Exchange Mailbox servers.
| Virtual directory | Authentication method | Required SSL settings | Management method |
|---|---|---|---|
| Autodiscover | Anonymous, Basic, Windows | SSL with128-bit encryption | EAC or Exchange Shell |
| ecp | Anonymous, Basic | SSL with128-bit encryption | EAC or Exchange Shell |
| EWS | Anonymous, Windows | SSL with128-bit encryption | EAC or Exchange Shell |
| MAPI | Windows | SSL with128-bit encryption | EAC or Exchange Shell |
| Microsoft-Server-ActiveSync | Basic | SSL with128-bit encryption | EAC or Exchange Shell |
| OAB | Windows | SSL with128-bit encryption | EAC or Exchange Shell |
| owa | Basic | SSL with128-bit encryption | EAC or Exchange Shell |
| PowerShell | By default, all authentication methods disabled. | Not required | EAC or Exchange Shell |
| Rpc | Basic, Windows | Not required | EAC or Exchange Shell |
Back End Virtual Directories on Mailbox servers
The following table lists the default settings in the back end services on Exchange Mailbox servers.
| Virtual directory | Authentication method | Required SSL settings | Management method |
|---|---|---|---|
| Exchange Back End | Anonymous | SSL with128-bit encryption | Should not be configured by the user. |
| Autodiscover | Anonymous Windows | SSL with128-bit encryption | Should not be configured by the user. |
| ecp | Anonymous Windows | SSL with128-bit encryption | Should not be configured by the user. |
| EWS | Anonymous Windows | SSL with128-bit encryption | Should not be configured by the user. |
| Microsoft-Server-ActiveSync | Basic | SSL with128-bit encryption | Should not be configured by the user. |
| OAB | Windows | SSL with128-bit encryption | Should not be configured by the user. |
| owa | Anonymous Windows | SSL with128-bit encryption | Should not be configured by the user. |
| PowerShell | Windows | SSL with128-bit encryption | Should not be configured by the user. |
| Rpc | Windows | Not required | Should not be configured by the user. |
| RpcWithCert | Windows | Not required | Should not be configured by the user. |
The following table shows different types of authentication methods that are included in the virtual directories in client access services. The types of authentication may differ depending on the service type provided by virtual directories as in images below.
| Type of authentication | Description |
|---|---|
| Integrated Windows authentication | This method requires that the client system to be a member of the domain that is trusted by the Exchange server’s domain or the same domain as that of Exchange server. Users are not prompted for their account names and passwords. |
| Basic authentication | This is the default value. When basic authentication is used, you should require TLS encrypted connections between client computers and the Exchange server. |
| Digest authentication for Windows domain servers | Digest authentication encrypts user credentials to increase security. User credentials are sent as an MD5 message digest in which the original user name and password cannot be determined. Digest authentication uses a challenge/response protocol that requires the authentication requestor to present valid credentials in response to a challenge from the server. To authenticate against the server, the client must supply an MD5 message digest in a response that contains a shared secret password string. |
| Forms-based authentication | Forms-based authentication provides enhanced security and allows you to configure the type of prompt that’s used to sign-in. However, forms-based authentication won’t provide a secure channel unless TLS is enabled. |
Certificates
It is highly recommended not to use any self-signed certificates as they are not secure and should be replaced with valid certificates either from internal or private CA (e.g. Windows enterprise CA) or Public CA (e.g. GoDaddy, VeriSign or DigiCert). Public CAs are preferred over Private CAs due to their vast scope of trust over public networks.
The certificates pane in the Exchange Admin Center allows you to manage certificates and create new certificate requests.
Exchange servers typically require a certificate to support multiple names. We can add multiple names in a certificate by using the following options
- Subject Alternative Name (SAN) certificate or
- Wildcard Certificate
To configure the Client Access services to use SSL, certificate needs to be installed on all Exchange servers. Once the certificates is obtained, ensure that network traffic between clients and servers are encrypted using SSL. To do this, all the virtual directories in IIS used by Client Access services should be configured to require SSL. Virtual directories that needs to be configured include:
- Autodiscover
- Exchange Admin Center (ECP)
- Exchange Web Services (EWS)
- MAPI
- Microsoft-Server-ActiveSync
- Offline Address Book (OAB)
- Outlook on the web (OWA)
- PowerShell
Namespaces
While deploying exchange server, we set hostname to the server as per design plan and most of the time we do not use these names for publishing exchange services externally. After installation, the virtual directories on each Exchange server are configured with an internal URL using the local server name as the namespace. You should update the Exchange servers to use the correct namespace as soon as possible after installation.
For example, hostname can be mbox01.virtualmaestro.local whereas client may access it as mail.virtualmaestro.in. So basically, we need to plan for namespaces for the environment first before we start working with certificates. This is important as certificates must include the names that are published for client access,
The namespaces used for client access are also completely independent of the Active Directory domain name and the domains used for SMTP. For example, the internal Active Directory domain name might be virtualmaestro.local whereas client access namespace can be virtualmaestro.in.
Choosing the best namespace depends on business requirements and also the number of available datacenter’s with Exchange Servers. The Exchange Preferred Architecture (PA) recommends the use of a single namespace for all servers (behind load balancers) that run Exchange server in an organisation. This means that the internal URL for all Exchange servers in all sites will be the same, This approach is referred as the unbound namespace model.