Exchange 2019: Configuring CAS virtual directories for on-premises

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 directoryAuthentication methodRequired SSL settingsManagement method
AutodiscoverAnonymous, Basic, WindowsSSL with128-bit encryptionEAC or Exchange Shell
ecpAnonymous, BasicSSL with128-bit encryptionEAC or Exchange Shell
EWSAnonymous, Windows SSL with128-bit encryptionEAC or Exchange Shell
MAPIWindowsSSL with128-bit encryptionEAC or Exchange Shell
Microsoft-Server-ActiveSyncBasicSSL with128-bit encryptionEAC or Exchange Shell
OABWindowsSSL with128-bit encryptionEAC or Exchange Shell
owaBasicSSL with128-bit encryptionEAC or Exchange Shell
PowerShellBy default, all authentication methods disabled.Not requiredEAC or Exchange Shell
RpcBasic, Windows Not requiredEAC or Exchange Shell
Table: Microsoft Docs

Back End Virtual Directories on Mailbox servers

The following table lists the default settings in the back end services on Exchange Mailbox servers.

Virtual directoryAuthentication methodRequired SSL settingsManagement method
Exchange Back EndAnonymous SSL with128-bit encryptionShould not be configured by the user.
AutodiscoverAnonymous
Windows
SSL with128-bit encryptionShould not be configured by the user.
ecpAnonymous
Windows
SSL with128-bit encryptionShould not be configured by the user.
EWSAnonymous
Windows
SSL with128-bit encryptionShould not be configured by the user.
Microsoft-Server-ActiveSyncBasic SSL with128-bit encryptionShould not be configured by the user.
OABWindows SSL with128-bit encryptionShould not be configured by the user.
owaAnonymous
Windows
SSL with128-bit encryptionShould not be configured by the user.
PowerShellWindows SSL with128-bit encryptionShould not be configured by the user.
RpcWindows Not requiredShould not be configured by the user.
RpcWithCertWindows Not requiredShould not be configured by the user.
Table: Microsoft Docs

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 authenticationDescription
Integrated Windows authenticationThis 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 serversDigest 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 authenticationForms-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.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.