Should I use a single namespace for Exchange Infrastructure? | Part 1#2 | Part 17#36

Page 1 of 30 | Should I use a single namespace for Exchange Infrastructure? | Part 1#2 |

Part 17#36

Written by Eyal Doron | o365info.com | Copyright © 2012-2015

Should I use a single namespace for

Exchange Infrastructure? | Part 1#2 |

Part 17#36

The current article is dedicated to the Interesting and not so clear subject of –

Exchange infrastructure namespace.

Exchange server architecture, enable us to use a different interface with internal

Exchange clients versus external Exchange clients that is based on different

namespace.

The major question that I will try to answer in this article are:

1. Is it good or bad to use a different namespace?

2. What are the characters of Exchange environment that is based on two

different namespaces?

http://o365info.com/should-i-use-a-single-namespace-for-exchange-infrastructure-part-1-of-2-part-17-of-36


https://il.linkedin.com/in/eyaldoron1

http://o365info.com/


Part 17#36


Autodiscover infrastructure | Exchange infrastructure and

namespace convention | The article series

The article series include the following articles:

1. Should I use a single namespace for Exchange Infrastructure? | Part 1#2 | Part

17#36

2. Exchange infrastructure | Implementing single domain namespace scheme |

Part 2#2 | Part 18#36

When reading the article title, the result is many questions that can pop out:

1. What is the meaning of “public naming scheme” or “single name space” for

Exchange Infrastructure?

2. Why do I need to use a single public naming scheme?

3. How does my current Exchange infrastructure is configured?

4. Should I spend my precious time reading this article?

5. What is the meaning of life?

Ok, I promise to answer questions 1–4 and regarding question number 5, my

answer is Thin pizza with mozzarella, cheese, and basil leaves.







http://o365info.com/exchange-infrastructure-implementing-single-domain-namespace-part-2-of-2-part-18-of-36



Part 17#36


Let’s jump to question number 4: Should I spend my precious time reading this

article?

My answer is -Yes

I think that is important to spend the time because very soon, every Exchange

administrator will need to deal with the subject of – using ONE public naming

scheme for Exchange Infrastructure.






Part 17#36


Relating the former questions

Q1 – What is the meaning of the public naming scheme for Exchange

Infrastructure?

Q2 – Why do I need to use ONE public naming scheme?

We cannot answer this question by proving a short answer but, despite that

obstacle I will try to shortly answer this question and, to get a more detailed and

comprehensive answer; you will need to read the rest of the article.

Exchange infrastructure objects are “addressed” by using host names and URL

address.

The communication between Exchange client and the communication between

Exchange servers themselves is implemented by addressing a specific Exchange

server by using his hostname.

The Exchange CAS server publishes Exchange web services to his clients, by

providing them a URL address that include the host name.






Part 17#36


Exchange architecture | Former versus modern

namespace conventions

Exchange server architecture Includes built-in ability to implement a different

interface with internal versus external Exchange clients.

The Realization of the different interfaces is based on three main elements

1. Communication protocol

2. Authentication protocol

3. Namespace

Former Exchange server architecture versus modern Exchange architecture |

Interface with internal Exchange clients versus external Exchange clients.

In former Exchange server versions such as Exchange 2003, 2007 and 2010, the

common convention was – to configure Exchange server for using different

interface with internal Exchange clients versus external Exchange clients.

The basic thought behind this configuration was that the internal network has

different needs and different characters versus external network and for this

reason, there is a need for configuring Exchange to use different configuration

setting when interacting with internal Exchange clients versus external Exchange

clients.

In a modern Exchange environment such as Exchange 2013, the differentiation

between the two environments (internal versus public network) diminishes and

disappears.

In other words, despite the fact that an Exchange 2013 architecture includes the

ability to implement a different interface with internal Exchange clients versus

external Exchange clients, most of the time, the common practice is to use an

identical interface with internal Exchange clients versus external Exchange clients.

For example:

In former Exchange server versions (Exchange 2003, 2007, 2010) a common

configuration was to use different communication protocol and different

namespace with internal Exchange clients versus external Exchange clients.






Part 17#36


The interface with the internal Outlook client, was implemented using RPC

protocol and internal namespace based on an internal domain name such as

“local” domain suffix.

The interface with external Outlook clients, was implemented using

RPC/HTTPS protocol (Outlook Anywhere) and public namespace based on a

public domain name such as “com” domain suffix.

Note – the definition of Exchange server 2010 as part of the “former Exchange

server version” is not a “scientific definition”. Many times, organizations

implemented the Exchange 2010 infrastructure based upon the characters of

modern mail environments.

The common convention, which dictates the need to differentiate and separate

Exchange interface with internal Exchange clients versus external Exchange clients

were changed over time into a new convention that was based on a “simplify the

concept”” in which the Exchange interface with internal Exchange clients versus

external Exchange clients will be configured as an identical interface.

For example, in an Exchange 2013 environment, the only available communication

protocol with Outlook client is – Outlook Anywhere (RPC\HTTPS or MAPI\HTTPS).

In other words, we cannot set a different communication protocol for internal

Outlook client versus external Outlook client.

Regarding the subject of “namespace”, theoretically, Exchange 2013 enables us to

use the option on “internal namespace” for internal Outlook client versus external

namespace for an external Outlook client but most of the time we will not

implement this option.

Another element that relates to the “new trend” in which we “cancel” the different

Exchange interface with internal Exchange clients versus external Exchange clients

is because in the current time, public certificate cannot and will not support host

name who includes non-public or public domain name suffix.

In other words – even in case that we decide to continue to use Exchange internal

and external namespace, when we need to renew our public certificate, we cannot

ask to include the internal host name as part of the certificate.






Part 17#36


Note – you can read more information about the new public certificate standard in

the article – Public SAN certificate | Deprecated support in the internal server name

| Part 19#36

Existing Exchange infrastructure based on internal and external namespace

In the former section, we have mentioned that modern Exchange environment is

moving toward consolidation or unification of the Exchange interface with internal

Exchange clients versus external Exchange clients.

However, in reality, there are many organizations that still use the former

convention in which we implement two different Exchange interfaces with internal

Exchange clients versus external Exchange clients.

In the next sections, we will review some examples for this type of infrastructure in

which we use two different Exchange interface, the characters of this environment

and the flow that is implemented between Exchange server and his client.

While reading the information, you could feel that my opinion is that organization

that use “separation” of Exchange interface should work toward unification if this

Exchange interface into one global interface.

The next article – Exchange infrastructure | Implementing single domain

namespace scheme | Part 2#2 | Part 18#36, Will deal with the “how to” part in a

scenario in which we decide to use a single namespace with internal Exchange

clients versus external Exchange clients.

Exchange infrastructure – Host’s names and FQDNs

Most of the time when we use the term “Host name” we are mean another term –

FQDN.

The FQDN is the “full” or “complete” name of a host who includes two parts:

1. The hostname

Regarding the subject of Hostnames, whenever we install a new server, we will

need to provide the server a unique name whom we can consider as the server

host name.





http://o365info.com/public-san-certificate-deprecated-support-in-the-internal-server-name-part-19-of-36





Part 17#36


If we want to be more accurate, in a Microsoft based environment, the Exchange

server Host name is a NetBIOS name.

Note – many times, we will “attached” to the Exchange server additional host names

by using the DNS infrastructure but, we will discuss this issue later.

2. The Domain name

By default, Exchange infrastructure inherits his domain name from the Active

Directory domain name.

In case that the Active Directory was configured using a private domain name, the

Exchange infrastructure will also use the private domain name suffix.






Part 17#36


In a scenario in which we use a “dual namespace” meaning private namespace and

public namespace, Internal Exchange clients, will address Exchange resources by

using the internal FQDN of the Exchange servers and Exchange URL address that

include the internal or the private domain name.

External Exchange clients, cannot address, or access Exchange resources using the

“private naming scheme” and for this reason, we will need to build additional

namespace infrastructure, which will be used by the “public” or the external

Exchange mail clients.

The possible namespace scenario matrix

To arrange things in clear format let’s review the possible “combination” of

namespaces.

The characters of this scenario that we will review are as follows:

Scenario 1 – Active Directory private namespace | Exchange dual namespace

In this scenario, the Active Directory is based on a private namespace such

as o365info.local

The Exchange namespace infrastructure will be based on a dual namespace

infrastructure.

Internal Exchange clients, will address Exchange resources using the

internal\private namespace –o365info.local

External Exchange clients, will address Exchange resources using the

internal\private namespace –o365info.com






Part 17#36


Scenario 2 – Active Directory private namespace | Exchange single namespace

In this scenario, the Active Directory is based on a private namespace such as

– o365info.local

The Exchange namespace infrastructure will be based on a single namespace

infrastructure meaning – the private, and the public namespace will be identical.

In this scenario, we will need to change the default Exchange servers FQDN that by

default, use the Active Directory private domain name (o365info.com)





Scenario 3 – Active Directory public namespace | Exchange single namespace

In this scenario, the Active Directory is based on a public namespace such

as o365info.com

The Exchange namespace infrastructure will be based on a single namespace

infrastructure, meaning – the private and the public namespace will be identical.

In this scenario, we will not need to change the default Exchange servers FQDN that

by default, use the Active Directory public domain name (o365info.com)










Part 17#36


Q: Why should I avoid from using the option of – “Exchange dual namespace”?

A: The short version of the answer for that question is – because of two main two

reasons:

1. No internal server names on SAN certificates after 2015

In case that we use the Exchange dual naming scheme infrastructure, the Exchange

public certificate will need to include the host name of internal host (host that use

the Active Directory private domain name) and the Public host name.

This type of configuration will be no longer supported since 1 November 2015

Note – If you need to read more information about this subject, read the article

– Public SAN certificate | Deprecated support in the internal server name | Part

19#36

2. Because it’s the “right way”

The “short version” of the answer is that using the option of Exchange dual naming

scheme infrastructure instead of using ONE public naming scheme for Exchange

Infrastructure is not the “right way”.








Part 17#36


The reason for using dual namespace is because historical reasons that are not

valid or relevant anymore to the modern environment.

Using the option of Exchange dual naming scheme infrastructure makes thing

complicated, makes it difficult for Exchange client that needs to memorize two

different naming convention, makes it difficult to troubleshoot “Exchange issues”

and much more.

Microsoft Active Directory and Private domain name

On-Premise Active Directory” is represented by a domain name.

The domain name that we use as an Active Directory domain name can be

considered as “Private domain name” or a “public domain name”.

Technically speaking, the Active Directory “doesn’t care” if we use a private domain

name or a public domain name.






Part 17#36


As mentioned, the default Exchange domain namespace infrastructure is built upon

the Active Directory domain name infrastructure.

Many organizations use a private domain name for the Active Directory if the

results are that the Exchange infrastructure will have to use two domain names

infrastructure.

Q1: What is the meaning of a private domain name?

A2: The “technically implementation” of a private domain name is, by using a

domain name that uses the “local” as a suffix.

The “local” domain suffix is a preserved suffix and there is no option of purchasing

a domain name with the “local” suffix.

The term “public domain name” is used in case that we have purchased the domain

name from a public provider such as GoDaddy etc.






Part 17#36


Q2: Why does the Active Directory use a private domain name?

A2: In the good old days, the general concept was that using a private domain

name for the Active Directory, is the preferred method because this is a good

security practice.

My personal opinion always was that, this is just a mambo jumbo of a security

personnel because, I have never managed to understand the reason for this

assumption and no one never could provide me a real explanation for this

assumption.

This “theory” of using a private domain name for the Active Directory domain name

was based on a faulty assumption that the use of “private domain name” is

required or mandatory for protecting the origination private network from the risks

and hazards that exist in the “public network” that will harm the private

organization resources.

I use the term -”mambo jumbo” for describing the theory of “using a private domain

name” for protecting internal network resources because it’s simply not true.






Part 17#36


Internal resources use a private IP scheme (Address Allocation for Private

Internets). For this reason, there is no option for internal resources to directly

communicate with “external resource” that use a public IP address.

The only passable way is via “a broker” such as Firewall that protects the internal

network and based on a Firewall ”rule that “expose” specific network hosts (servers)

based on what the administrator want\need to expose to the public network.

If we want to look of additional psychologist’s explanation for the “private Active

Directory domain conspiracy theory” is, that in the old days, the basic assumption

was that the organization’s network is an isolated place that should never need to

be exposed to “external network” or external user who reside on the public

network.

This assumption looks a little radical in now days because, now the common is the

opposite – most, if the organization users are using public network and must have

access to “internal network resources” such as the Exchange CAS server on an

hourly basis.





http://tools.ietf.org/html/rfc1918



Part 17#36


Additional reading

You can read additional information about the concept of private domain name

and the local domain name suffix in the following articles:

.local

Multicast DNS

Top-level domain

The syndrome of mister jackal and mister Hyde

So what is my point?

My point is that because many or even most of the organizations obeys to this

“Private domain miss assumption” the results are quite a mess.

An organization that uses the Active Directory private domain naming scheme will

have to manage two separated naming infrastructure.

The “private naming scheme” will be used only by the internal network client and

the public naming scheme will be used only by the public client.

I can even compare this scenario, to a person that suffer from the illness of Split

Personality!





http://en.wikipedia.org/wiki/.local


http://en.wikipedia.org/wiki/Top-level_domain


Part 17#36


The trend in which we use a private domain name parallel to using an

“external\public” domain name is coming to its end because, the new standard or

public certificate doesn’t support anymore the use of host names that have a

private domain name such as the local domain name suffix.

The publicly available on Exchange infrastructure

versus the private Active Directory infrastructure.






Part 17#36


As mentioned, versus the Active Directory the serve only internal clients and doesn’t

“expose herself” to the public client, the character if the Exchange infrastructure are

the opposite.

Exchange infrastructure will have to “expose” himself to external Exchange

clients located on a public network

The public network infrastructure must use public host names

In the following diagram, we can see an example for the “two worlds” in which

Public facing Exchange CAS server needs to operate.

Q: In case that the Active Directory uses a private domain name, how does

Exchange serve external clients?

A: There are two passable “solutions”:

Option 1: Maintain two different domain name scheme






Part 17#36


In this scenario, the Active Directory private domain namespace will be used also by

the Exchange infrastructure for – communicating with internal Exchange clients.

Exchange infrastructure will use the public domain name scheme for

communication with an external mail client.

In this scenario, the Exchange infrastructure is “linked” to two different domain

names at the same time.

For example – in a scenario in which we use an Exchange CAS server who will also

provide service for external mail clients (Public facing Exchange CAS server), an

internal Exchange client will address the Exchange CAS server by using the host

named- ex01.o365info.local

The external Exchange client will address the Public facing Exchange CAS server by

using the host named – mail.o365info.com






Part 17#36


Option 2: Exchange infrastructure using a “unified domain name scheme”

In this scenario, Exchange infrastructure will use only a public domain name

scheme that will be used by both internal + external mail clients.

The Exchange infrastructure will be “attached” or “linked” only to the public domain

name and not, to the Active Directory private domain name.






Part 17#36


For example, in a scenario in which we use an Exchange CAS server who will also

provide service for external mail clients (Public facing Exchange CAS server), an

internal Exchange client will address the Exchange CAS server by using the

hostname – mail.o365info.com

The external Exchange client will address the Public facing Exchange CAS server by

using the host named – mail.o365info.com

Maintain two different domain name scheme scenario

in more details

In the former section, we provide am high-level review of the passable “Exchange

namespace scenarios”

In the following section, we will continue to review the scenario of- “Maintaining two

different domain namespace scheme” scenario in more details.

In case that you are wondering about the second scenario of -Exchange

infrastructure using a “unified domain name scheme”, you will have to be patient

because I have deducted a different article for this type of scenario.

The charters of our scenario are as follows:

The internal the private domain name is –o365info.local






Part 17#36


The Public domain name that the company has and that is used for publishing

hosts in the external network is – o365info.com

By default, each of the internal hosts in the Active Directory will have a

hostname or if we want to be more accurate, FQDN that is based on the

following naming convention – <host>.o365info.local

All of the “internal hosts”, is automatically registered at the Active Directory

DNS server under the domain named – o365info.local

The company Exchange server, serve as “Public facing Exchange server”, that

provide services to external mail clients.

In this case, external mail clients will address the Public facing Exchange

server by using the “public domain name scheme”, in our scenario

– o365info.com

The public name of the Public facing Exchange server is mail.o365info.com and

additional name, which is used for the Autodiscover service for an external

mail client – autodiscover.o365info.com

The same Exchange server is published in the internal network by using the

internal FQDN –o365info.com

In our scenario, we will need to build two separate infrastructures- one

infrastructure for the internal company users that use the internal company

network and additional public infrastructure, which will be used by external

company users that are located at the public network.

The Internal Exchange infrastructure description

In this part, we review the charters and the workflow of the “internal network

environment” that is available only for internal clients.






Part 17#36


1. Active Directory SCP

The Autodiscover infrastructure in the “internal Active Directory environment” is

implemented in the following way:

Internal Exchange client will query the Active Directory for a name\s of existing

Exchange CAS server\s. Exchange CAS server “know” how to register himself

automatically at the Active Directory SCP.

By default, the Exchange CAS server, will register himself at the Active Directory

Service connection point (SCP) using the FQDN –exo1.o365info.local

2. Internal DNS

The Active Directory internal DNS configured as an authoritative for the Active

Directory private domain name – o365info.com

By default, the Active Directory, DNS supports the feature of DDNS (Dynamic DNS)

and authenticated hosts such as our Exchange server, can register themselves

automatically.

In our scenario, the internal Exchange CAS server registers himself automatically in

the DNS zone- o365info.local






Part 17#36


The FQDN of the Exchange CAS server is – exo1.o365info.local

The private IP address of the Exchange CAS server is – 192.168.1.5

3. Server certificate

In an Exchange environment, the server certificate is a mandatory component.

Because the Exchange CAS server should be available also for the external mail

client, the certificate that was acquired is a public certificate that includes the

following host names:

o365info.local – the name whom the Exchange server use for his internal mail

client for all types of communications and services.

o365info.com – the “external” or the public name of the Public facing

Exchange CAS server who is “allocated” for the Autodiscover services. External

mail client will use this name for locating their Exchange CAS server

(Autodiscover Endpoint).

o365info.com – the “external” or the public name of the Public facing

Exchange CAS server who external mail client use for accessing and

communicating with their Exchange server.






Part 17#36


When an internal Exchange client needs to access his mailbox, he needs to find +

communicate his Exchange CAS server. In the internal network, the communication

path between the Exchange client and the Exchange CAS server is based on the

following workflow:

1. The mail client connects the local Active Directory (SCP) and asks for a list of

available Exchange CAS server\s

In our scenario, the Active Directory reply with an answer such as –

https://exo1.o365info.local/autodiscver/autodiscover.xml

2. The mail client connects the local DNS server and asks for the IP address of

exo1.o365info.local (the DNS reply will include the Private IP address: 192.168.1.5)

3. Mail client connects to the local Exchange CAS server, verify that he can

communicate using HTTPS and ask for the server certificate.






Part 17#36


When the Exchange CAS server provides his certificate to the mail client, the mail

client will check and verify only one host name – exo1.o365info.local

The internal Exchange client will “ignore” all the rest of the host names who appear

in the certificate.

The reason for this is that the Exchange client “acknowledge” or relate to the

internal Exchange CAS server, using only the hostname – exo1.o365info.local

The mail client “doesn’t care” about additional host names who exist in the

certificate that the Public facing Exchange CAS server provides

(mail.o365info.com and o365info.com).

The external\public Exchange infrastructure description






Part 17#36


The mail infrastructure that is used by the external mail client has a very different

character.

The external mail infrastructure will include the following “parts” and components:

1. Public IP

A public IP address should be acquired and assigned to the Exchange CAS server

who serves as a “Public facing Exchange CAS server” (most of the time, this public IP

address will be assigned to the company Firewall server who will forward requests

from external mail client to the internal IP address of the Exchange CAS server).

2. Public\external DNS server

Every Public facing Exchange CAS server will have at least, two public host names.

These “public names” (FQDN’s) will have to be registered at the public DNS server

who hosts the company public domain name.

In our scenario, we will need to register under the o365info.com zone (domain

name) the following host names – mail and autodiscover

3. Public Exchange server certificate

The Exchange CAS server certificate will need to include the two public names who






Part 17#36


“represent” the Public facing Exchange CAS server

(autodiscover.o365info.com and, mail.o365info.com)

When an external Exchange client needs to access his mailbox, the following flow is

implemented:

1. Locking for the Public IP of the Autodiscover Endpoint

The mail client connects the public DNS looking for the IP address of

– mail.o365info.com (in the reality, the mail client will start the Autodiscover process

by looking for the host name –o365info.com and only if he cannot find or connect to

this host, he will create an NDS query looking for the FQDN of the Autodiscover

Endpoint).






Part 17#36


2. Mail client and Public facing Exchange CAS server

The Exchange client, connect to the Public facing Exchange CAS server and verify

that he can communicate using HTTPS.

In case that the server supports HTTPS communication, the mail client asks for the

server certificate.

When the Public facing Exchange CAS server provides his certificate, to the mail

client, the mail client will check and verify, only two host names:

autodiscover.o365info.com and, mail.o365info.com

The reason for this, is that the Exchange client “acknowledge” or relate to the Public

facing Exchange CAS server using only the host names

– autodiscover.o365info.com andmail.o365info.com

The mail client “doesn’t care” about additional host names, the exists in the

certificate that the Public facing Exchange CAS server provides (ex01.o365info.lcoal)






Part 17#36






Documents

Should I use a single namespace for Exchange Infrastructure? | Part 1#2 | Part 17#36