Exchange Altyapısı için tek bir ad alanı kullanmalı mıyım? | Bölüm 1#2 | Bölüm 17#36

Mevcut makale, Exchange Altyapısı ad alanının ilginç ve pek de net olmayan konusuna ayrılmıştır.

Exchange sunucusu mimarisi, çeşitli ad alanlarına dayanan dahili Exchange istemcileri ile harici Exchange istemcileri arasında farklı bir arayüz kullanmamızı sağlar.

Bu makalede cevaplamaya çalışacağım başlıca sorular şunlardır:

• Farklı bir ad alanı kullanmak iyi mi yoksa kötü mü?
• İki farklı ad alanına dayanan Exchange ortamının karakterleri nelerdir?

Makale başlığını okuduğunuzda ortaya çıkabilecek birçok soru ortaya çıkıyor:

1. Exchange Altyapısı için “genel adlandırma şeması” veya “tek ad alanı”nın anlamı nedir?
2. Neden tek bir genel adlandırma şeması kullanmam gerekiyor?
3. Mevcut Exchange altyapım nasıl yapılandırılıyor?

Bunun zaman ayırmanın önemli olduğunu düşünüyorum çünkü çok yakında her Exchange yöneticisinin Exchange Altyapısı için TEK genel adlandırma şeması kullanma konusuyla ilgilenmesi gerekecek.

Önceki soruların ilişkilendirilmesi

S1 - Exchange Altyapısı için genel adlandırma planının anlamı nedir?

S2 - Neden TEK genel adlandırma şeması kullanmam gerekiyor?
Bu soruya kısa bir cevap vererek cevap veremeyiz, ancak bu engele rağmen bu soruyu kısaca yanıtlamaya çalışacağım ve daha ayrıntılı ve kapsamlı bir cevap alın; makalenin geri kalanını okumanız gerekecek.

Exchange altyapısı nesneleri, ana bilgisayar adları ve URL adresi kullanılarak "adreslenir".
Exchange istemcisi arasındaki iletişim ve Exchange sunucuları arasındaki iletişim, belirli bir Exchange sunucusunun ana bilgisayar adı kullanılarak adreslenmesiyle gerçekleştirilir.

Exchange CAS sunucusu, istemcilerine ana bilgisayar adını içeren bir URL adresi sağlayarak Exchange web hizmetlerini yayınlar.

Değişim mimarisi | Önceki ve modern ad alanı kuralları

Exchange sunucusu mimarisi Dahili ve harici Exchange istemcileriyle farklı bir arayüz uygulamaya yönelik yerleşik yeteneği içerir.

Üç ana unsura dayalı farklı arayüzlerin gerçekleştirilmesi

1. İletişim protokolü
2. Kimlik doğrulama protokolü
3. Ad alanı

Önceki Exchange sunucusu mimarisi ve modern Exchange mimarisi karşılaştırması | Dahili Exchange istemcileriyle harici Exchange istemcileri arasındaki arayüz.

Exchange 2003, 2007 ve 2010 gibi önceki Exchange sunucusu sürümlerinde, tipik kural, Exchange sunucusunu dahili Exchange istemcileri ile harici Exchange istemcileri arasında farklı bir arayüz kullanacak şekilde yapılandırmaktı.

Bu yapılandırmanın ardındaki temel düşünce, iç ağın harici ağa göre farklı ihtiyaçlara ve farklı karakterlere sahip olduğu ve bu nedenle, dahili Exchange istemcileri ve harici Exchange istemcileriyle etkileşimde bulunurken Exchange'in farklı yapılandırma ayarlarını kullanacak şekilde yapılandırılmasına ihtiyaç duyulduğuydu.

Exchange 2013 gibi modern bir Exchange ortamında, iki ortam (dahili ve genel ağ) arasındaki fark azalır ve kaybolur.

Başka bir deyişle, Exchange 2013 mimarisinin dahili Exchange istemcileri ile harici Exchange istemcileri arasında farklı bir arayüz uygulama yeteneğini içermesine rağmen, çoğu zaman standart uygulama, dahili Exchange istemcileri ve harici Exchange istemcileri ile aynı arayüzü kullanmaktır. harici Exchange istemcileri.

Örneğin:

Önceki Exchange sunucusu sürümlerinde (Exchange 2003, 2007, 2010) ortak yapılandırma, dahili Exchange istemcileri ile harici Exchange istemcileri arasında farklı iletişim protokolü ve farklı ad alanı kullanmaktı.

• Dahili Outlook istemcisi ile arayüz, RPC protokolü ve “yerel” etki alanı soneki gibi dahili bir etki alanı adını temel alan dahili ad alanı kullanılarak uygulandı.
• Harici Outlook istemcileriyle arayüz, RPC/HTTPS protokolü (Outlook Anywhere) ve "com" alan adı son eki gibi genel bir alan adına dayalı genel ad alanı kullanılarak uygulandı.

Exchange arayüzünü dahili Exchange istemcileri ile harici Exchange istemcileri arasında farklılaştırma ve ayırma ihtiyacını dikte eden standart kural, zaman içinde Exchange arayüzünün dahili Exchange istemcileri ile harici Exchange istemcileri arasında olduğu "kavramı basitleştirmeye" dayanan yeni bir sözleşmeye dönüştü. Aynı arayüz olarak yapılandırılmış harici Exchange istemcileri.

Örneğin, Exchange 2013 ortamında Outlook istemcisiyle kullanılabilen tek iletişim protokolü Outlook Anywhere'dir (RPC\HTTPS veya MAPI\HTTPS).

Başka bir deyişle, dahili Outlook istemcisi ile harici Outlook istemcisi için farklı bir iletişim protokolü ayarlayamayız.

“Ad alanı” konusuna gelince, teorik olarak Exchange 2013, dahili Outlook istemcisi için “dahili ad alanı” seçeneğini, harici bir Outlook istemcisi için harici ad alanı seçeneğini kullanmamıza olanak sağlar ancak çoğu zaman bu seçeneği uygulamayacağız.

Dahili Exchange istemcileri ile harici Exchange istemcileri arasındaki farklı Exchange arayüzünü "iptal ettiğimiz" "yeni trend" ile ilgili bir diğer unsur, şu anda genel sertifikanın, harici Exchange istemcileri içermeyen ana bilgisayar adını destekleyememesi ve desteklememesidir. genel veya genel alan adı son eki.

Başka bir deyişle, genel sertifikamızı yenilememiz gerektiğinde Exchange dahili ve harici ad alanını kullanmaya devam etmeye karar versek bile, dahili ana bilgisayar adının sertifikanın bir parçası olarak dahil edilmesini isteyemeyiz.

Not - Yeni genel sertifika standardı hakkında daha fazla bilgiyi - Genel SAN sertifikası | Dahili sunucu adında destek kaldırılmıştır | Bölüm 19#36

Dahili ve harici ad alanına dayalı mevcut Exchange altyapısı

Önceki bölümde, modern Exchange ortamının Exchange arayüzünü dahili Exchange istemcileri ve harici Exchange istemcileri ile birleştirmeye veya birleştirmeye doğru ilerlediğini belirtmiştik.

Ancak gerçekte, dahili Exchange istemcileri ve harici Exchange istemcileri ile iki farklı Exchange arabirimini uyguladığımız son geleneği hâlâ kullanan birçok kuruluş vardır.

Sonraki bölümlerde iki farklı Exchange arayüzü kullandığımız bu tür altyapının bazı örneklerini, bu ortamın karakterlerini ve Exchange sunucusu ile istemcisi arasında uygulanan akışı inceleyeceğiz.

Bilgileri okurken, Exchange arayüzünün “ayrılmasını” kullanan organizasyonun, bu Exchange arayüzünü tek bir global arayüzde birleştirme yönünde çalışması gerektiğini düşündüğümü hissedebilirsiniz.

Sonraki makale - Exchange altyapısı | Tek etki alanı ad alanı şemasının uygulanması | Bölüm 2#2 | Bölüm 18#36, Dahili Exchange istemcileri ve harici Exchange istemcileri ile tek bir ad alanı kullanmaya karar verdiğimiz bir senaryoda "nasıl yapılır" kısmını ele alacağız.

Exchange altyapısı - Ana bilgisayarın adları ve FQDN'leri

Çoğu zaman "Ana Bilgisayar Adı" terimini kullandığımızda, başka bir terim olan FQDN'yi kastediyoruz.

FQDN, iki bölümden oluşan bir ana bilgisayarın "tam" veya "tam" adıdır:

1. Ana Bilgisayar Adı
Ana Bilgisayar Adları konusuna gelecek olursak, yeni bir sunucu kurduğumuzda, sunucuya sunucu ana bilgisayar adı olarak düşünebileceğimiz benzersiz bir ad vermemiz gerekecektir.

Daha doğru söylemek gerekirse Microsoft tabanlı bir ortamda Exchange sunucusu Ana Bilgisayar adı bir NetBIOS adıdır.

2. Alan adı
Varsayılan olarak Exchange altyapısı, alan adını Active Directory alan adından devralır.

Active Directory'nin özel alan adı kullanılarak yapılandırılması durumunda Exchange altyapısı da özel alan adı son ekini kullanacaktır.

Özel ad alanı ve genel ad alanı anlamına gelen "ikili ad alanı" kullandığımız bir senaryoda, Dahili Exchange istemcileri, Exchange sunucularının dahili FQDN'sini ve dahili veya özel etki alanı adını içeren Exchange URL adresini kullanarak Exchange kaynaklarını ele alacaktır.

Harici Exchange istemcileri, "özel adlandırma şemasını" kullanarak Exchange kaynaklarına erişemez veya bunlara erişemez ve bu nedenle, "genel" veya harici Exchange posta istemcileri tarafından kullanılan ek ad alanı altyapısı oluşturmamız gerekecektir.

Olası ad alanı senaryo matrisi

İşleri net bir biçimde düzenlemek için, ad alanlarının olası "kombinasyonunu" gözden geçirelim.

Bu senaryonun inceleyeceğimiz karakterleri şunlardır:

Senaryo 1 - Active Directory özel ad alanı | Exchange ikili ad alanı

Bu senaryoda Active Directory, o365info.local gibi özel bir ad alanını temel alır.

Exchange ad alanı altyapısı, ikili ad alanı altyapısını temel alır.

• Dahili Exchange istemcileri, Exchange kaynaklarını dahili\özel ad alanını kullanarak adresleyecektir - o365info.local
• Harici Exchange istemcileri, Exchange kaynaklarını dahili\özel ad alanını kullanarak adresleyecektir - o365info.com

Senaryo 2 - Active Directory özel ad alanı | Tek ad alanını değiştirin

Bu senaryoda, Active Directory - o365info.local gibi özel bir ad alanını temel alır.

Tek bir ad alanı altyapısına dayanan Exchange ad alanı altyapısı, yani özel ve genel ad alanı aynı olacaktır.

Bu senaryoda, varsayılan olarak Active Directory özel alan adını (o365info.com) kullanan varsayılan Exchange sunucuları FQDN'sini değiştirmemiz gerekecektir.

• Dahili Exchange istemcileri, Exchange kaynaklarını dahili\özel ad alanını kullanarak adresleyecektir - o365info.com
• Harici Exchange istemcileri, Exchange kaynaklarını dahili\özel ad alanını kullanarak adresleyecektir - o365info.com

Senaryo 3 - Active Directory genel ad alanı | Tek ad alanını değiştirin

Bu senaryoda Active Directory, o365info.com gibi genel bir ad alanını temel alır.

Exchange ad alanı altyapısı tek bir ad alanı altyapısına dayalıdır; yani özel ve genel ad alanı aynı olacaktır.

Bu senaryoda, varsayılan olarak Active Directory ortak alan adını (o365info.com) kullanan varsayılan Exchange sunucuları FQDN'sini değiştirmemiz gerekmeyecektir.

• Dahili Exchange istemcileri, Exchange kaynaklarını dahili\özel ad alanını kullanarak adresleyecektir - o365info.com
• Harici Exchange istemcileri, Exchange kaynaklarını dahili\özel ad alanını kullanarak adresleyecektir - o365info.com

S: “İkili ad alanını değiştir” seçeneğini kullanmaktan neden kaçınmalıyım?

C: Bu sorunun cevabının kısa versiyonu - iki ana nedenden dolayı:

1. 2015'ten sonra SAN sertifikalarında dahili sunucu adı yok

Exchange çift adlandırma şeması altyapısını kullanmamız durumunda, Exchange genel sertifikasının, dahili ana bilgisayarın ana bilgisayar adını (Active Directory özel alan adını kullanan ana bilgisayar) ve Genel ana bilgisayar adını içermesi gerekecektir.

Bu tür yapılandırma 1 Kasım 2015'ten itibaren artık desteklenmeyecektir

Not - Bu konu hakkında daha fazla bilgi edinmek istiyorsanız - Genel SAN sertifikası | Dahili sunucu adında destek kaldırılmıştır | Bölüm 19#36

2. Çünkü bu “doğru yol”

Cevabın "kısa versiyonu", Exchange Altyapısı için TEK genel adlandırma şeması kullanmak yerine Exchange çift adlandırma şeması altyapısı seçeneğini kullanmanın "doğru yol" olmadığıdır.

Çift ad alanının kullanılmasının nedeni, artık geçerli olmayan veya modern çevreyle alakalı olmayan tarihsel nedenlerden kaynaklanmaktadır.

Exchange çift adlandırma şeması altyapısı seçeneğinin kullanılması işleri karmaşık hale getirir, iki farklı adlandırma kuralını ezberlemesi gereken Exchange istemcisinin zorlaştırır, "Exchange sorunlarını" gidermeyi zorlaştırır ve çok daha fazlasını yapar.

Microsoft Active Directory ve Özel alan adı

Şirket İçi Active Directory” bir alan adı ile temsil edilir.

Active Directory alan adı olarak kullandığımız alan adını “Özel alan adı” veya “genel alan adı” olarak değerlendirebiliriz.

Teknik olarak konuşursak, Active Directory özel bir alan adı mı yoksa genel bir alan adı mı kullandığımızı "umursamıyor".

Belirtildiği gibi, varsayılan Exchange etki alanı ad alanı altyapısı, Active Directory etki alanı adı altyapısı üzerine kurulmuştur.

Sonuç olarak Exchange altyapısının iki alan adı altyapısı kullanması gerekecekse, birçok kuruluş Active Directory için özel bir alan adı kullanır.

S1: Özel alan adının anlamı nedir?

C2: Özel bir alan adının "teknik olarak uygulanması", "yerel" son ekini kullanan bir alan adının kullanılmasıdır.

“Yerel” alan adı eki korunmuş bir ek olup, “yerel” alan adı satın alma seçeneği bulunmamaktadır.

Alan adını GoDaddy vb. gibi kamuya açık bir sağlayıcıdan satın almamız durumunda "kamu alan adı" terimi kullanılır.

S2: Active Directory neden özel bir alan adı kullanıyor?

C2: Eski güzel günlerde genel konsept, Active Directory için özel bir alan adı kullanmanın tercih edilen yöntem olduğu yönündeydi çünkü bu, iyi bir güvenlik uygulamasıdır.

Benim düşüncem her zaman bunun bir güvenlik personelinin saçma sapan bir oyunu olduğu yönündeydi çünkü bu varsayımın nedenini hiçbir zaman anlayamadım ve hiç kimse bana bu varsayım için gerçek bir açıklama getiremedi.

Active Directory alan adı için özel bir alan adı kullanılmasına ilişkin bu “teori” hatalı bir varsayıma dayanmaktadır. Özel kuruluş ağını, özel kuruluş kaynaklarına zarar verecek "kamu ağında" var olan risk ve tehlikelerden korumak için "özel alan adı" kullanımının gerekli veya zorunlu olduğu düşünülüyordu.

Dahili ağ kaynaklarını korumak için "özel alan adı kullanma" teorisini tanımlamak için "mambo jumbo" terimini kullanıyorum çünkü bu kesinlikle doğru değil.

Dahili kaynaklar özel bir IP şeması kullanır (Özel İnternetler için Adres Tahsisi). Bu nedenle iç kaynakların, genel IP adresi kullanan “dış kaynak” ile doğrudan iletişim kurma seçeneği bulunmamaktadır.

Mümkün olan tek yol, iç ağı koruyan ve yöneticinin genel ağa göstermek istediği/gerektiği şeye göre belirli ağ ana bilgisayarlarını (sunucularını) "ortaya çıkaran" bir Güvenlik Duvarı "kuralını temel alan Güvenlik Duvarı gibi bir "aracı" aracılığıyladır.

"Özel Active Directory etki alanı komplo teorisi" için ek psikolog açıklamasına bakmak istersek, eski günlerde temel varsayım, kuruluşun ağının asla "dış ağ"a maruz kalması gerekmeyen izole bir yer olduğu yönündeydi. veya genel ağda bulunan harici kullanıcı.

Bu varsayım bugünlerde biraz radikal görünüyor çünkü artık ortak olan tam tersidir; çoğu kuruluş kullanıcıları genel bir ağ kullanıyorsa ve Exchange CAS sunucusu gibi "dahili ağ kaynaklarına" saatlik olarak erişmeleri gerekiyorsa.

Bay Çakal ve Bay Hyde sendromu

Peki benim amacım ne?

Demek istediğim şu ki, kuruluşların çoğu, hatta çoğu, bu "Özel alanın gözden kaçırıldığı varsayımına" uyduğu için sonuçlar oldukça karmaşıktır.

Active Directory özel etki alanı adlandırma şemasını kullanan bir kuruluşun iki ayrı adlandırma altyapısını yönetmesi gerekecektir.

“Özel adlandırma planı” yalnızca dahili ağ istemcisi tarafından kullanılacak, genel adlandırma planı ise yalnızca genel istemci tarafından kullanılacaktır.

Hatta bu senaryoyu Bölünmüş Kişilik hastalığından muzdarip bir kişiyle karşılaştırabilirim!

“Harici\genel” alan adı kullanımına paralel olarak özel bir alan adı kullanma eğilimi de sona eriyor çünkü yeni standart veya genel sertifika, özel bir alan adına sahip ana bilgisayar adlarının kullanımını artık desteklemiyor. yerel alan adı son eki olarak.

Exchange altyapısında herkese açık olan ve özel Active Directory altyapısı karşılaştırması.

Bahsedildiği gibi, Active Directory'ye kıyasla yalnızca dahili istemcilere hizmet eder ve kendisini genel istemciye "göstermez"; Exchange altyapısında ise durum tam tersidir.

• Exchange altyapısının kendisini halka açık bir ağda bulunan harici Exchange istemcilerine “açığa çıkarması” gerekecek
• Genel ağ altyapısı genel ana bilgisayar adlarını kullanmalıdır

Aşağıdaki diyagramda Public'e dönük Exchange CAS sunucusunun çalışması gereken "iki dünyanın" bir örneğini görebiliriz.

S: Active Directory'nin özel bir alan adı kullanması durumunda Exchange harici istemcilere nasıl hizmet verir?

C: İki olası "çözüm" vardır:

1. Seçenek: İki farklı alan adı şemasını koruyun

Bu senaryoda, Active Directory özel etki alanı ad alanı aynı zamanda Exchange altyapısı tarafından dahili Exchange istemcileriyle iletişim kurmak için kullanılacaktır.

Exchange altyapısı, harici bir posta istemcisiyle iletişim için genel alan adı şemasını kullanacaktır.

Bu senaryoda Exchange altyapısı aynı anda iki farklı alan adına "bağlanmıştır".

Örneğin, harici posta istemcileri için de hizmet sağlayacak olan bir Exchange CAS sunucusu kullandığımız bir sahnede (Genel kullanıma açık Exchange CAS sunucusu), dahili bir Exchange istemcisi, ex01.o365info.local

Harici Exchange istemcisi, - mail.o365info.com adlı ana bilgisayarı kullanarak Genele açık Exchange CAS sunucusuna adres verecektir.

2. Seçenek: "Birleşik alan adı şeması" kullanan değişim altyapısı

Bu senaryoda, Exchange altyapısı yalnızca hem dahili hem de harici posta istemcileri tarafından kullanılan genel alan adı düzenini kullanacaktır.

Exchange altyapısı, Active Directory özel alan adına değil, yalnızca genel alan adına "eklenecek" veya "bağlanacaktır".

Örneğin, aynı zamanda harici posta istemcileri için de hizmet sağlayacak olan bir Exchange CAS sunucusu kullandığımız bir senaryoda (Genel kullanıma açık Exchange CAS sunucusu), dahili bir Exchange istemcisi, ana bilgisayar adını kullanarak Exchange CAS sunucusuna adres verecektir - mail.o365info.com

Harici Exchange istemcisi - mail.o365info.com adlı ana bilgisayarı kullanarak Genele açık Exchange CAS sunucusuna adres verecektir.

İki farklı alan adı şeması senaryosunu daha ayrıntılı olarak koruyun

Önceki bölümde olası "Exchange ad alanı senaryolarının" üst düzey incelemesini sunuyoruz

Bir sonraki bölümde “İki farklı alan ad alanı şemasının sürdürülmesi” senaryosunu daha detaylı incelemeye devam edeceğiz.

"Birleşik alan adı şeması" kullanan -Exchange altyapısının ikinci senaryosunu merak ediyorsanız sabırlı olmanız gerekecek çünkü bu tür senaryo için farklı bir makale çıkardım.

Senaryomuzun chartları aşağıdaki gibidir:

• Dahili özel alan adı -o365info.local
• Şirketin sahip olduğu ve ana bilgisayarları harici ağda yayınlamak için kullanılan Genel alan adı - o365info.com
• Varsayılan olarak, Active Directory'deki dahili ana bilgisayarların her birinin bir ana bilgisayar adı olacaktır veya daha doğru olmak istersek, aşağıdaki adlandırma kuralına dayanan FQDN - .o365info.local
• Tüm “dahili ana bilgisayarlar”, Active Directory DNS sunucusuna o365info.local adlı alan adı altında otomatik olarak kaydedilir.
• Şirketin Exchange sunucusu, harici posta istemcilerine hizmet sağlayan "Genel kullanıma açık Exchange sunucusu" olarak hizmet eder.
  Bu durumda, harici posta istemcileri, Genele açık Exchange sunucusunu "genel alan adı şemasını" kullanarak adresleyecektir. senaryomuz - o365info.com
• Herkese açık Exchange sunucusunun genel adı mail.o365info.com'dur ve harici bir posta istemcisi için Otomatik Bulma hizmeti için kullanılan ek addır - autodiscover.o365info.com
• Aynı Exchange sunucusu, dahili FQDN - o365info.com kullanılarak dahili ağda yayınlanır.

Senaryomuzda, iki ayrı altyapı oluşturmamız gerekecek: iç şirket ağını kullanan şirket içi kullanıcılar için bir altyapı ve genel ağda bulunan harici şirket kullanıcıları tarafından kullanılacak ek genel altyapı.

Dahili Değişim altyapısı açıklaması

Bu bölümde yalnızca iç istemcilerin kullanımına sunulan “iç ağ ortamının” sözleşmelerini ve iş akışını inceliyoruz.

1. Active Directory SCP
“Dahili Active Directory ortamındaki” Otomatik Bulma altyapısı şu şekilde uygulanır:
Dahili Exchange istemcisi, mevcut Exchange CAS sunucularının adları için Active Directory'yi sorgulayacaktır. Exchange CAS sunucusu kendisini Active Directory SCP'ye otomatik olarak nasıl kaydedeceğini "bilir".

Varsayılan olarak Exchange CAS sunucusu, FQDN -exo1.o365info.local kullanarak kendisini Active Directory Hizmeti bağlantı noktasına (SCP) kaydeder.

2. Dahili DNS

Active Directory özel alan adı için yetkili olarak yapılandırılmış Active Directory dahili DNS'si - o365info.com

Varsayılan olarak Active Directory, DNS, DDNS (Dinamik DNS) özelliğini destekler ve Exchange sunucumuz gibi kimliği doğrulanmış ana bilgisayarlar, kendilerini otomatik olarak kaydedebilirler.

Senaryomuzda, dahili Exchange CAS sunucusu kendisini otomatik olarak DNS bölgesine kaydeder - o365info.local

Exchange CAS sunucusunun FQDN'si - exo1.o365info.local

Exchange CAS sunucusunun özel IP adresi - 192.168.1.5

3. Sunucu sertifikası

Exchange ortamında sunucu sertifikası zorunlu bir bileşendir. Exchange CAS sunucusunun harici posta istemcisi için de mevcut olması gerektiğinden, alınan sertifika, aşağıdaki ana bilgisayar adlarını içeren genel bir sertifikadır:

• o365info.local - Exchange sunucusunun her türlü iletişim ve hizmet için dahili posta istemcisi olarak kullandığı ad.
• o365info.com - Otomatik Bulma hizmetleri için "tahsis edilen", Herkese açık Exchange CAS sunucusunun "harici" veya genel adı. Harici posta istemcisi, Exchange CAS sunucusunu (Otomatik Keşfet Uç Noktası) bulmak için bu adı kullanacaktır.
• o365info.com - harici posta istemcisinin Exchange sunucularına erişmek ve onunla iletişim kurmak için kullandığı, Herkese açık Exchange CAS sunucusunun "harici" veya genel adı.

Dahili bir Exchange istemcisinin posta kutusuna erişmesi gerektiğinde, Exchange CAS sunucusunu bulması ve iletişim kurması gerekir. Dahili ağda, Exchange istemcisi ile Exchange CAS sunucusu arasındaki iletişim yolu aşağıdaki iş akışını temel alır:

1. Posta istemcisi yerel Active Directory'ye (SCP) bağlanır ve kullanılabilir Exchange CAS sunucularının listesini ister

Senaryomuzda, Active Directory aşağıdaki gibi bir yanıtla yanıt verir:

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

2. Posta istemcisi yerel DNS sunucusuna bağlanır ve
exo1.o365info.local IP adresini sorar (DNS yanıtı Özel IP adresini içerecektir: 192.168. 1.5)

3. Posta istemcisi yerel Exchange CAS sunucusuna bağlanır, HTTPS kullanarak iletişim kurabildiğini doğrulayın ve sunucu sertifikasını isteyin.

Exchange CAS sunucusu sertifikasını posta istemcisine sağladığında, posta istemcisi yalnızca bir ana bilgisayar adını kontrol edecek ve doğrulayacaktır - exo1.o365info.local
Dahili Exchange istemcisi “ sertifikada görünen diğer tüm ana bilgisayar adlarını görmezden gelin.

Bunun nedeni, Exchange istemcisinin yalnızca ana bilgisayar adını - exo1.o365info.local kullanarak “kabul etmesi” veya dahili Exchange CAS sunucusuyla ilişki kurmasıdır.

Posta istemcisi, Herkese açık Exchange CAS sunucusunun sağladığı sertifikada bulunan ek ana bilgisayar adlarını "umursamıyor" (mail.o365info.com ve o365info.com).

Harici\genel Exchange altyapısı açıklaması

Harici posta istemcisinin kullandığı posta altyapısı çok farklı bir karaktere sahiptir.

Dış posta altyapısı aşağıdaki “parçaları” ve bileşenleri içerecektir:

1. Genel IP
“Genel kullanıma açık Exchange CAS sunucusu” olarak hizmet veren Exchange CAS sunucusuna genel bir IP adresi alınmalı ve atanmalıdır. Çoğu zaman bu genel IP adresi, harici posta istemcisinden gelen istekleri Exchange CAS sunucusunun dahili IP adresine iletecek olan şirketin Güvenlik Duvarı sunucusuna atanır.

2. Genel\harici DNS sunucusu
Genel kullanıma açık her Exchange CAS sunucusu en az iki genel ana bilgisayar adına sahip olacaktır.
Bu "genel adların" (FQDN'ler), şirketi barındıran genel DNS sunucusuna kaydolması gerekecektir. genel alan adı.
Senaryomuzda, o365info.com bölgesi (alan adı) altına aşağıdaki ana bilgisayar adlarını kaydetmemiz gerekecek - posta ve otomatik bulma

3. Genel Exchange sunucusu sertifikası
Exchange CAS sunucusu sertifikasının, Herkese açık Exchange CAS sunucusunu "temsil eden" iki genel adı içermesi gerekecektir (autodiscover.o365info.com ve mail.o365info.com)

Harici bir Exchange istemcisinin posta kutusuna erişmesi gerektiğinde aşağıdaki akış uygulanır:

1. Otomatik Keşfet Uç Noktasının Genel IP'sini Kilitleme

Posta istemcisi - mail.o365info.com IP adresini arayarak genel DNS'ye bağlanır (gerçekte posta istemcisi, ana bilgisayar adını arayarak Otomatik Bulma işlemini başlatacaktır) -o365info.com ve yalnızca bu ana bilgisayarı bulamazsa veya bu ana bilgisayara bağlanamazsa, Otomatik Keşfet Uç Noktasının FQDN'sini arayan bir NDS sorgusu oluşturacaktır).

2. Posta istemcisi ve Herkese açık Exchange CAS sunucusu

Exchange istemcisi, Herkese açık Exchange CAS sunucusuna bağlanın ve HTTPS kullanarak iletişim kurabildiğini doğrulayın.
Sunucunun HTTPS iletişimini desteklemesi durumunda, posta istemcisi sunucu sertifikasını ister.

Herkese açık Exchange CAS sunucusu sertifikasını posta istemcisine sağladığında, posta istemcisi yalnızca iki ana bilgisayar adını kontrol edecek ve doğrulayacaktır:

autodiscover.o365info.com ve mail.o365info.com

Bunun nedeni, Exchange istemcisinin yalnızca ana bilgisayar adlarını (autodiscover.o365info.com ve mail.o365info.com

Posta istemcisi ek ana bilgisayar adlarını "umursamıyor"; bu adlar, Herkese açık Exchange CAS sunucusunun sağladığı sertifikada mevcut (ex01.o365info.lcoal)