Office 365'te hibrit dağıtım | Kontrol listesi ve ön gereksinimler | Bölüm 1/3

Exchange Hibrit yapılandırmasının Office 365 ortamında uygulanması basit bir görev veya yorucu bir süreç olarak değerlendirilebilir. Sahip olacağımız deneyim, Exchange On-Premise altyapısının ve diğer ilgili bileşenlerin “hazırlık düzeyine” bağlı olacaktır.

Basit bir deyişle, Exchange Karma Yapılandırma Sihirbazı'nı başlatmadan önce yapılandırılması ve uygulanması gereken ön gereksinimlerin neler olduğunu anladığınız takdirde, HCW'yi (Karma Yapılandırma Sihirbazı) çalıştırmanın büyük olasılıkla kolay bir iş olacağı ve , işlem başarıyla tamamlanacaktır.

Mevcut makalede şunları inceleyeceğiz:

• Exchange hibrit ortamının ön gereksinimleri
• Gerekli hazırlıklar için en iyi uygulamalar ve öneriler
• Şirket içi ortamın doğru yapılandırılıp yapılandırılmadığını kontrol etmemize ve doğrulamamıza yardımcı olacak araçlar ve yöntemler.

Hibrit dağıtım Office 365 - Makale serisi

Makale serisi aşağıdaki makaleleri içermektedir:

• Office 365'te hibrit dağıtım | Kontrol listesi ve ön gereksinimler | Bölüm 1/3
• Office 365'te hibrit dağıtım | Kontrol listesi ve ön gereksinimler | Bölüm 2/3
• Office 365'te hibrit dağıtım | Kontrol listesi ve ön gereksinimler | Bölüm 3/3

Kısaca Exchange Hibrit ortam yapılandırması

Hibrit yapılandırma veya Hibrit ortam terimi, farklı Active Directory ormanlarına ait iki ayrı Exchange kuruluşunun "tek bir birim" olarak çalıştığı bir senaryoyu açıklar.
Hibrit yapılandırma terimi, bu tür bir ilişkiyi tanımlamak için oluşturulmuştur. Exchange On-Premise altyapısı ile bulut (Exchange Online) altyapısı arasında.

Örneğin aşağıdaki şemada Hibrit ortamın mantıksal konseptini görüyoruz.
Genel Alan adı: o365info.com, “paylaşılan Alan” olarak yapılandırılmıştır. Anlamı, iki ayrı Exchange altyapısının bu alan adını “temsil etmesi” veya aralarında aynı alan adını paylaşmasıdır.

Diyagrama baktığımızda iki alıcı görüyoruz: Bob@o365info.com ve Alice@o365info.com

Teknik olarak, alıcı posta kutularının Exchange şirket içi sunucusunda veya Exchange Online sunucusunda yapılandırılması gerekir, ancak mantıksal olarak Bob ve Alice posta kutularının nerede barındırıldığını bilmiyor .

Bob posta kutusunun Exchange şirket içi sunucusunda barındırılması ve Alice'in posta kutusunun bir Exchange Online sunucusunda barındırılması durumunda, Bob ve Alice Serbest\Meşgul süresi, posta ipuçları ve daha fazlası gibi tüm standart Exchange hizmetlerine, sanki aynı Exchange organizasyonunda barındırılıyormuşçasına sahiptir. Bunun nedeni, Hibrit ortamın iki farklı Exchange ortamını "bağlaması" ve bunların tek bir varlık gibi görünmesini sağlamasıdır.

Hibrit konfigürasyon ilişkileri ve Güven konsepti

Daha önce de belirtildiği gibi Hibrit yapılandırma, iki farklı Exchange ortamını "bağlamak" ve bunların tek bir varlık olarak çalışmasını sağlamak için tasarlanmıştır. Güven kavramı, iki farklı ortam arasındaki “parlamayı” hayata geçirir.

1. Federasyon güveni - Exchange ortamlarının (şirket içi + bulut) her biri, şu adlı "üçüncü öğeye" ihtiyaç duyar veya ona güvenmelidir: MFG - Microsoft'un federasyon ağ geçidi (şemada 1 sayısı).
2. Exchange organizasyon ilişkileri - iki ayrı Exchange organizasyonu arasındaki güven modeli. Hibrit ortamda Exchange şirket içi Exchange ormanı ile "Office 365 ormanı" (Exchange Online) (şemada 2 sayısı) arasında Exchange organizasyon ilişkisi uygulanır.

Hibrit yapılandırma ve "Güven modeli" her "uç noktanın" (Şirket içi Exchange ve Exchange Online) şunları yapmasını sağlar:

• Birbirinizi doğrulayın
• Birbirinizin kimliğini doğrulayın
• Güvenli bir iletişim kanalı oluşturun: Genel bir sertifika ve SMTP\TLS ve HTTPS gibi güvenli bir iletişim protokolü kullanarak bilgileri şifreleyin ve veri bütünlüğünü uygulayın.

Şirket içi Basit Exchange ortamı ve karmaşık ortam.

"Hibrit yapılandırma" terimi, kuruluşun Hibrit sunucu olarak hizmet veren ve Şirket içi ortam ile Şirket içi ortam arasında "iletişim kanalını" oluşturmaktan sorumlu olan yalnızca bir Şirket içi Exchange sunucusuna sahip olduğu çok basit bir senaryoyu açıklamak için kullanılabilir. “bulut” (Exchange Online).

Hibrit yapılandırmanın başka bir senaryosu daha karmaşık bir durum olabilir; bu durum, karmaşık Şirket içi Exchange altyapısına sahip kurumsal ortamlarda daha yaygındır.

Bu senaryoda, Exchange Online ile "Şirket içi Exchange altyapısı" arasındaki "ilişki", farklı\ayrılmış Şirket içi Exchange sunucularıyla birçok "iletişim kanalına" bölünebilir.

Örneğin, Exchange on-Premises ile Exchange Online arasındaki posta akışı, Exchange Online'a posta göndermek üzere yapılandırılacak "özel" bir Şirket içi Exchange sunucusu ve yapılandırılacak diğer Exchange on-Premises sunucusu kullanılarak uygulanabilir. Exchange Online'dan gelen postaları “kabul etmek” için.

Başka bir Şirket içi Exchange sunucusu, Otomatik Bulma hizmetlerini sağlayacak olan özel Exchange şirket içi sunucusu, EWS hizmetlerini sağlayacak olan özel Exchange şirket içi sunucusu vb. gibi farklı rollere/hizmetlere atanabilir.

Office 365'te Hibrit dağıtım için ön gereksinimler

Sonraki bölümlerde “Hibrit ortam için Ön Gereksinimler listesinde yer alan bileşenlerin her birini inceleyeceğiz. ”

1. Exchange Hibrit sunucu sürümü

“Exchange Hibrit sunucusu” terimi, Hibrit ortamın bir parçası olabilen Microsoft Exchange sunucusunu tanımlayan mantıksal bir terimdir.

Exchange şirket içi sunucusu "Karma sunucu" aşağıdakiler kullanılarak uygulanabilir:

• Exchange 2010 SP3
• Değişim 2013

Hibrit sunucu olarak Exchange 2010 SP3

Exchange 2010'u Hibrit sunucu olarak kullanmak istememiz durumunda minimum gereksinim Service Pack 3'tür. Service Pack 3 gereksiniminin yanı sıra en iyi uygulama şudur: Yazılımların her biri için en güncel Exchange Rollup sürümlerini yüklemek. güncellemeler (Değişim Toplaması), keşfedilen sorunlara/sorunlara yönelik bir çözüm içerir ve düzeltilen, Toplamalara dahil edilir.

Çoğu zaman müşteri veya kuruluşun BT'si, "en güncel Exchange toplamasını yükleme" önerisine "direnecektir", ancak en güncel Toplamaları yüklemenin gelecekteki sorunların çoğunu önleyebileceğini ve bu konuda önemli bir faktör olarak değerlendirilebileceğini vurgulamak önemlidir. Hibrit ortamı oluşturma süreci.

Aşağıdaki alıntı Exchange 2010 SP3 için Toplama 4 ile ilgilidir, ancak siz anladınız.

Ayrıca, tüm hibrit sunucularınıza Exchange 2010 SP3 için gelecekteki Güncelleme Paketleri 4'ü yüklemenizi öneririz. Microsoft, güncelleştirme toplama paketlerini yaklaşık altı ila sekiz haftada bir yayımlar. Toplama paketlerine Microsoft Update ve Microsoft İndirme Merkezi aracılığıyla ulaşılabilir. Exchange 2010 SP3 toplama paketlerinin bağlantılarını bulmak için Microsoft İndirme Merkezi'ndeki Arama kutusuna "Exchange 2010 SP3 güncelleştirme toplaması" yazın.

Gerekli Exchange şirket içi sunucu yazılımı güncelleştirmeleri için indirme bağlantısı

Değişim 2010 | Mevcut Exchange Toplamasının ne olduğunu nasıl bilebilirim?

Exchange 2010 şirket içi sunucusunun mevcut durumu hakkında bilgi almak isterseniz Yardım menüsünü kullanarak güncel sürümü görüntüleyebilir ve Exchange sunucusu 2010 hakkında.

Aşağıdaki ekran görüntüsünde Exchange şirket içi sunucu sürümünün şu şekilde olduğunu görebiliriz: 14.03.0.195.001

Dolayısıyla bir sonraki soru şu olabilir: Bu numaraya göre Exchange Şirket içi sunucu hizmet paketinin veya toplama sürümünün ne olduğunu nasıl bilebilirim? Değeri daha net bir bilgiye "çevirebilmek" için şu makaleyi kullanabiliriz: Exchange Server yapı numaraları ve yayın tarihleri.

Aşağıdaki ekran görüntüsünde, 14.3.195.1 sürüm numarasının, Exchange 2010 şirket içi sunucusunun Exchange 2010 SP3 için Service Pack 3 + Toplama 6.

Bu durumda en güncel Rollup'ı indirip kurmamız gerekecek (örneğin Rollup 9)

Şirket içi sunucuda çalıştırdığınız Toplu Güncelleştirme (CU), Toplama ve Hizmet Paketleri de gözden kaçırılmamalıdır. Normal şartlarda Exchange için şu anda yayınlanan güncellemenin en fazla iki güncelleme gerisinde kalmanızı destekliyoruz; ancak hibrit ortamlar için daha katıyız ve birden fazla yapının arkasında kalmamalısınız.
En son güncelleme Exchange 2013 CU9 ise, desteklenen bir durumda sayılması için Exchange 2013 CU9 veya CU8'e sahip olmanız gerekir. . Şirket içi ve Exchange Online ortamlarının birbirine ne kadar sıkı bağlanacağından dolayı hibrit gereksinimlerimiz konusunda daha katıyız. Mevcut güncellemelerimiz hakkında daha fazla bilgi için lütfen buraya gidin.

Yeni Hibrit sunucu ve mevcut Şirket İçi Exchange sunucusu karşılaştırması

Kuruluşun Exchange altyapısının Exchange 2003, 2007 gibi eski Exchange sürümlerini temel alması durumunda, “Hibrit sunucu” görevi görecek yeni bir Şirket içi Exchange sunucusunu (2010 SP3 veya 2013) “eklememiz” veya kurmamız gerekecektir. . ”

"Yeni" Exchange Şirket İçi Hibrit sunucusu, Exchange 2010 veya Exchange 2013 olarak uygulanabilir, ancak en iyi uygulama, Exchange 2010 yerine Exchange 2013 sunucusunu kurmaktır çünkü Exchange 2013, Hibrit ortamla ilgili iyileştirici özellikler içerir.

2. Exchange Şirket İçi Hibrit sunucu | Genel IP adresi ve Genel ad (FQDN)

Hibrit yapılandırma, "Hibrit sunucu" olarak yapılandırılan Exchange On-Premise sunucusunun, genel bir ağda bulunan Exchange Online altyapısı ile bir iletişim kanalı oluşturmasını sağlamakla ilgilidir.
Ana bilgisayarlar veya "uç nokta" ile iletişim kurabilmek Genel ağ için Exchange Hibrit sunucusunun aşağıdaki özelliklere sahip olması gerekir:

1. Genel Ad - Exchange Hibrit sunucusunun genel adı Genel DNS'de yayımlanmalı ve Exchange Hibrit sunucusunun Genel IP'sine çözümlenmelidir.
2. Genel IP adresi - Exchange Hibrit sunucusunu “Yönlendiren” bir Genel IP adresi atanmalıdır. Çoğu zaman Genel IP adresi doğrudan Exchange şirket içi sunucusuna bağlanmaz, bunun yerine Genel IP bir Güvenlik Duvarı sunucusuna tahsis edilir. eGüvenlik Duvarı, Şirket içi Exchange sunucusuna yapılan iletişim isteklerini kabul edecek ve isteği Şirket içi Exchange sunucusunun dahili IP adresine iletecektir.

Örneğin, Giden posta akışının, Exchange Online sunucusuna posta gönderebilen iki Şirket içi Exchange sunucusunu temel alması durumunda, bu sunucuların her birinin özel bir Genel IP adresine sahip olması gerekir.

Şirket İçi Exchange'in Genel adının ne olduğunu nasıl bilebilirim?

Bunun basit yanıtı şudur: Eğer Exchange Şirket İçi Yöneticisi iseniz, Exchange Şirket İçi genel adının ne olduğunu bilmeniz gerekir, ancak bazı senaryolarda aşina olmadığımız bir ortamda yapılandırmak ve hibrit dağıtım yapmak zorunda kalacağız. ile.

Exchange Şirket İçi sunucusunun "Genel adı" hakkında bilgi almanın bir yolu, Exchange MMC'deki sunucu yapılandırması altındaki "istemci erişimi" bölümünde görünen "Harici URL"ye bakmaktır (Exchange 2010 MMC kullandığımızda) ).

Aşağıdaki örnekte "Sunucu yapılandırması\İstemci erişimi\EX01" altına bakacağız

Exchange sunucusu birkaç hizmeti “yayınlıyor”. Örneğimizde ECP sekmesine bakıyoruz (ECP sekmesi, web yönetimi arayüzünü kullanan Exchange sunucusunun Dahili + Harici URL'sini içerir).

Exchange On-Premise'ın “genel adının” (Harici URL) şu şekilde olduğunu görebiliriz: mail.o365info.com

Exchange Hibrit Sunucu Genel adının (FQDN) Genel IP'siyle eşlendiğini doğrulayın

Exchange Şirket İçi Genel IP doğrulama süreci çok basittir. Komut istemini açın ve Exchange Şirket İçi sunucusunun Genel adına Ping gönderin. Örneğimizde, Exchange Şirket İçi genel adı şu şekildedir: mail.o365info.com

Aşağıdaki ekran görüntüsünde Exchange On-Premise sunucusunun genel IP'sini "cevap" olarak aldığımızı görebiliriz.

En yaygın yanılgılardan biri, "İstek zaman aşımına uğradı" mesajı aldığımız için bir sorun olduğudur.

Bu yanıt bir sorun belirtisi değildir çünkü "ping" yaptığımız ana bilgisayarın (senaryomuzda Exchange On-Premise) ping isteğine yanıt vermesi beklenmiyordu. Bu öngörülebilir bir sonuçtur çünkü çoğu zaman kuruluşun Güvenlik Duvarı ICMP protokolünü (Ping yanıtı için kullanılan) engeller.

Özetlemek gerekirse: Genel IP'ye yanıt almamız gerekli sonuçlardır; bu, Şirket içi Exchange sunucusunun genel bir ada + Genel IP adresine sahip olduğu anlamına gelir.

3. Exchange Şirket İçi Hibrit sunucu | Bağlantı noktası numarası ve protokoller

Exchange Online ile Exchange şirket içi sunucusu arasında veri ve hizmet paylaşımına dayalı hibrit yapılandırma. İki iletişim protokolü kullanılarak uygulanan iletişim kanalı:

• HTTPS - HTTPS protokolü kullanılarak uygulanan Exchange hizmetlerine (Şirket içi Exchange sunucusundan Exchange Online'a ve tam tersi) erişim.
• SMTP - posta akışını uygulamak için kullanılan SMTP protokolü ve veriler TLS (SMTP üzerinden TLS) kullanılarak şifrelenir.

Temel varsayım şudur: Şirket içi Exchange sunucusu bir Güvenlik Duvarı tarafından korunmaktadır. Exchange şirket içi sunucusu ile Exchange Online arasındaki iletişim kanalını başarıyla uygulayabilmek için Güvenlik Duvarının aşağıdaki gelen ve giden kuralları içerdiğini doğrulamamız gerekir:

1. Bağlantı noktası 25 (SMTP) ve 443'ü (HTTPS) kullanarak Exchange şirket içi sunucusuna erişmeyi sağlayan gelen kuralı.
2. Exchange şirket içi sunucusunun, 25 (SMTP) ve 443 (HTTPS) bağlantı noktasını kullanarak Exchange Online'a erişmesini sağlayan giden kural.

Aşağıdaki ekran görüntüsü bir Microsoft makalesinden alınmıştır ve Hibrit yapılandırma için etkinleştirilmesi gereken hizmetleri ve bağlantı noktası numarasını açıklayan bir tablo içerir

Genel ağdan Exchange Hibrit sunucusuna erişimi doğrulama

Kuruluşun Güvenlik Duvarında ve Exchange Şirket İçi Sunucusunda yapılandırılan gerekli kurala genel ağdan erişilebildiğini kontrol etmek için “çevrimiçi tarama” seçeneğini kullanabiliriz. ”

Bir sonraki adımda Exchange on-Premises sunucusundaki mevcut portların neler olduğunu kontrol etmek için MxToolbox'ı kullanıyoruz.

Senaryomuzda, Şirket içi Exchange sunucusunun adı - mail.o365info.com

Mevcut tüm seçeneklere ulaşmak için diğer menüsünü ve ardından tara seçeneğini seçeceğiz.

Taramak istediğimiz ana bilgisayarın ana bilgisayar adını (veya IP adresini) sağlayacağız.

Aşağıdaki ekran görüntüsünde, tarama sonucunun mail.o365info.com ana bilgisayarının 25 ve 443 numaralı bağlantı noktasını “dinlediğini” gösterdiğini görebiliriz.

Exchange Hibrit sunucusunun gerekli bağlantı noktalarını kullanarak harici ağa erişebildiğini doğrulayın.

Exchange şirket içi sunucusunun SMTP (Port 25) protokolünü kullanarak ortak ana bilgisayarlara erişimi olduğunu ve TLS oturumu başlatabildiğini doğrulayabilmek için Exchange şirket içi sunucu komut isteminden Telnet komutunu kullanabiliriz.

Aşağıdaki örnekte, 25 numaralı bağlantı noktasını kullanarak harici bir posta sunucusuna Telnet yapıyoruz (Telnet o365info2.mail.protection.outlook.com 25)

Hedef sunucunun “cevap” verdiğini görebiliriz ve hedef sunucunun hazır olduğuna dair yanıt alırız.

SMTP\TLS oturumunu başlatmak için helo komutunu yazacağız ve hedef sunucudan “yanıt” aldıktan sonra şu komutu yazabiliriz: <irkiliyorum

Aşağıdaki ekran görüntüsünde hedef posta sunucusunun şu mesajla yanıt verdiğini görüyoruz: “220 2.0.0 SMTP sunucusu hazır. ”

Kullanılabilirlik - şirket içi İstemci Erişimi sunucularının İnternet'te doğru şekilde yayınlanması, hibrit dağıtımınızda özelliklerin doğru şekilde çalışması açısından hayati öneme sahiptir.

Hibrit özelliklerin düzgün çalışması için şirket içi güvenlik duvarınızı veya diğer güvenlik cihazlarınızı, şirket içi İstemci Erişimi sunucularındaki Otomatik Bulma ve Exchange Web Hizmetleri (EWS) uç noktalarına Internet'ten gelen erişime izin verecek şekilde yapılandırmanız gerekir. Ayrıca İstemci Erişimi sunucularının da gelen SMTP postasını kabul edecek şekilde yapılandırılması gerekir.

Office 365 kiracı kuruluşunuza dahil olan Microsoft Exchange Çevrimiçi Koruma (EOP) hizmeti şirket içi İstemci Erişimi sunucularına ulaşamıyorsa, Exchange Online kuruluşundan şirket içi kuruluşa güvenli posta aktarımı düzgün çalışmayacaktır.

Devamını oku: Karma dağıtım sorunlarını giderme.

4. Exchange Şirket İçi Hibrit sunucu| Genel IP adresi ve Statik NAT

Doğrulamamız gereken önemli bir faktör, Exchange şirket içi sunucusunun, harici ana bilgisayarların iletişim isteğine yanıt verdiğinde veya harici bir ana bilgisayarla bağlantı başlattığında kendisine atanan genel IP adresini kullanmasıdır.

Bu senaryonun teknik terimi “iki yönlü statik NAT” olabilir.

Örneğin: Exchange 2010 Karma yapılandırma sihirbazını kullanırken, Exchange Online sunucusuna E-posta göndermesine "izin verilen" Exchange şirket içi sunucusunun genel IP'sini sağlamamız gerekir.

Şirket içi Exchange sunucusu Exchange Online ile iletişim kurduğunda, Şirket içi Exchange sunucusunun Exchange karma sihirbazında yapılandırılan genel IP'yi kullanması önemlidir.

Diğer örnekler, Exchange Online'ın Şirket içi Exchange sunucusunun genel IP'sine bir iletişim süreci başlatması olabilir. Bu durumda Exchange Online sunucusu, iletişim kanalını başlatmak için kullanılan IP adresinden yanıt almayı "bekliyor".

Statik NAT kuralına bir örnek şu şekilde olabilir:

Aşağıdaki şemada statik NAT kuralının bir örneğini görebiliriz. Exchange Online gibi harici ana bilgisayarlar, Exchange Şirket İçi sunucusunun Genel IP'si ile iletişim kurmaya çalıştığında, Şirket İçi Exchange sunucusundan gelen "yanıt", Exchange'i "yayınlamak" için kullandığımız genel IP adresinin aynısı kullanılarak uygulanır. şirket içi sunucu.

Exchange şirket içi sunucusunun kullandığı Genel IP adresinin ne olduğunu doğrulayın

Exchange şirket içi sunucusunun "yanıt verdiğinden" veya kendisine atanan Genel IP adresini kullanarak harici ağa eriştiğinden emin olmak istiyorsak (Statik NAT kuralının doğru şekilde yapılandırıldığını doğrulamak için), bir Birçok web sitesi tarafından sunulan ve belirli dahili ana bilgisayarlar tarafından kullanılan Genel IP'yi almamızı sağlayacak ücretsiz hizmet.

Tek yapmamız gereken, Exchange Şirket İçi sunucusundan bir tarayıcı arama sayfası açmak ve şunu yazmak: "IP'm nedir."

Aşağıdaki ekran görüntüsünde Exchange on-Premises sunucusunun “Genel IP’sinin ne olduğunu” görebiliyoruz.

5. ISA-TMG sunucusu ve Güvenlik Duvarı sunucusu

Bir Exchange Şirket İçi sunucusu yayınlamak için ISA\TMG sunucusunu kullanırken, yapılandırmalar "standart Güvenlik Duvarı" ile karşılaştırıldığında biraz farklıdır çünkü ISA\TMG bir Proxy sunucusu ve ayrıca Güvenlik Duvarı sunucusudur.

“Standart Güvenlik Duvarı” kullanıldığında basit bir “erişim kuralı” kullanarak iletişimi dahili Exchange Şirket İçi sunucusuna yönlendiririz.

ISA\TMG Güvenlik Duvarı kullanılırken, dahili Exchange Şirket İçi sunucusuna yönlendirme şu şekilde uygulanır: Web yayınlama kuralı.

ISA\TMG web yayınlama kuralı, -OWA, EWS gibi belirli veya önceden yapılandırılmış Exchange Şirket İçi "yolu" ile ilgilidir. ISA\TMG ortamında kullanılan ek bir bileşen Kimlik Doğrulama ayarlarıdır.
Çünkü ISA\ TMG bir proxy sunucusudur ve çoğu kez kimlik doğrulama işleminin yapılandırması şu şekilde uygulanır: harici ana bilgisayar ISA\TMG'ye kimlik doğrulaması yapar (kimlik bilgilerini sağlar), ISA\TMG sunucusu kimlik bilgilerini onaylar veya onaylamaz ve ISA başarıyla tamamlanırsa \TMG, harici ana bilgisayarların iletişim isteğini "iletecektir".

Hibrit ortamda bu konfigürasyon sorun ve hatalara neden olacaktır. Basit bir ifadeyle: ISA\TMG sunucusunu kullanarak Exchange On-Premise sunucusunu yayınladığımızda, ISA\TMG sunucusunun harici ana bilgisayarın iletişim isteğini doğrulaması seçeneğini iptal etmemiz veya devre dışı bırakmamız gerekir.

1. ISA\TMG ve Kimlik Doğrulama ayarları

Exchange Online ile Exchange şirket içi sunucusu (veya tersi) arasındaki iletişim, şifreli bir iletişim kanalı oluşturularak ve tarafların her birinin birbirini kimlik doğrulaması ve tanımlamasına olanak tanınarak gerçekleştirilir.

Bu “kanalın” hiçbir kesintiye, müdahaleye uğramadan var olmasını sağlamamız gerekiyor.

ISA\TMG sunucusu, bazen uç nokta veya "dahili ana bilgisayar" ile iletişim kurmak isteyen ana bilgisayar için kimlik doğrulama işlemini zorunlu kılmak üzere yapılandırılan bir proxy sunucusudur. Hibrit ortamla ve ISA\TMG'nin Şirket içi Exchange sunucusunu yayınladığı bir senaryoyla ilgili olduğunda, harici uç noktayı "ISA\TMG sunucusunda kimlik doğrulaması" yapmaya zorlayan ayarı iptal etmemiz gerekir.

Exchange şirket içi sunucusu Otomatik Bulma ve EWS hizmetlerini yayınlamak için ISA\TMG kuralını kullanırken, TMG web yayınlama kuralının şu ayarla yapılandırıldığını doğrulamamız gerekir: Yetki verme yok, ancak istemcinin kimliğini doğrudan doğrulayabilir .

2. ISA\TMG | Şirket İçi Değişim | Web Yayıncılığı kuralı ve Yolu

Exchange On-Premise gibi dahili ana bilgisayarları yayınlamak için ISA\TMG Güvenlik Duvarı kullanıldığında, "erişim kuralı" bir Web Yayınlama Kuralı tarafından uygulanır.
ISA\TMG Web yayınlama kuralı, şu gibi parametreleri içerir: yayınlamak istediğimiz dahili ana bilgisayar (Web Sunucusu) ve ayrıca web sunucusunun belirli bir yolu.

Hibrit bir ortamda, ISA yayınlama kuralının aşağıdaki yolu içerdiğini doğrulamak önemlidir:
/ews/*

/Otomatik Keşfet/*

ISA\TMG web yayımlama kuralı, OWA, Active Sync vb. gibi ek Exchange Şirket İçi web hizmetlerine erişimi sağlayacak şekilde yapılandırılmalıdır.

Hibrit yapılandırma senaryosuyla ilgili olarak, ISA\TMG kurallarında yapılandırılması gereken ilgili sanal klasör EWS ve AutoDiscover klasörleridir.

Aşağıdaki ekran görüntüsünde, Exchange Şirket İçi hizmetlerine giden gerekli "Yolu" içeren ISA\TMG web yayınlama kuralı örneğini görebiliriz.

Aşağıdaki ekran görüntüsü bir Microsoft makalesinden alınmıştır.

Aşağıdaki tabloda aşağıdakilere ilişkin referansı görebiliriz:

• ISA\TMG yayınlama kuralına eklenmesi gereken yol adı
• Kimlik doğrulama - Kimlik Doğrulaması gerektiren ISA\TMG özelliğini devre dışı bırakma veya iptal etme ihtiyacı (ve bunun yerine, istemcinin doğrudan Exchange Şirket İçi sunucusundan önce kimlik doğrulaması yapmasına izin verme)

6. Güvenlik duvarı gelen ve Giden erişim politikası | Office 365 ve Exchange Online Genel IP aralığı

Birçok kuruluşta, bir düzenleme veya diğer güvenlik gereklilikleri nedeniyle, erişimi yalnızca özel veya önceden tanımlanmış bir IP aralığıyla kısıtlayan bir giden ve gelen politika uygulaması vardır.

Örneğin: "Exchange on-Premises sunucusu, Exchange Online ile bir iletişim kanalı oluşturuyor" dediğimizde, "IP aralığı" açısından ne anlama gelir?
Exchange Online altyapısı belirli bir veya bir grup tarafından temsil ediliyor mu? önceden tanımlanmış genel IP aralığı?
Bu sorunun yanıtı: "Evet."

Windows Azure Active Directory, Exchange Online, SharePoint Online vb. gibi tüm Office 365 ortamı, "yayınlama" veya iyi bilinen bir genel IP aralığına dayalıdır.

Erişimi yalnızca belirli veya önceden tanımlanmış bir IP aralığına kısıtlayan giden ve gelen güvenlik duvarı kurallarının uygulanması, güvenlik açısından "iyi uygulama" olarak kabul edilir. Ancak aynı zamanda Exchange On-Premise ile Exchange Online sunucusu arasında "Hibrit iletişim kanalı" oluşturmak için kullandığımız "ilk kez yapılandırma" sürecini karmaşıklaştırabilir ve kesintiye uğratabilir.

Kısıtlı bir IP aralığıyla giden/gelen politikasını uygulamak için belirli bir organizasyonel gereksinimi uygulamaya başlamadan önce önerilerim aşağıdaki gibidir:

1. TEST\Pilot Aşaması

Yalnızca Test/Pilot aşamasında olmanız durumunda asıl amaç, Exchange On-Premise ile Exchange Online (veya tam tersi) arasında iletişim kanalını oluşturmak için HCW'yi (Karma Yapılandırma Sihirbazı) başarıyla kullanabileceğimizi doğrulamaktır. ).

Bu aşamada tavsiyem outbound\inbound politikasını kısıtlı bir IP aralığı ile uygulamamanızdır çünkü bu aralığın doğru yapılandırılmaması durumunda Hibrit yapılandırma sihirbazı başarısız olur ve hatanın nedenini bulmak o kadar da kolay değildir. .

Hibrit için gereken tüm ayarları başarıyla oluşturduktan sonra (HCW'yi kullanarak veya PowerShell komutunu kullanarak) ve Exchange şirket içi sunucusu ile Exchange Online arasındaki iletişim yolunun "çalıştığını" doğruladıktan sonra, herhangi bir giden giden bağlantıyı uygulayabilirsiniz. Kısıtlı IP aralığına sahip \inbound politikası.

2. Office 365 Genel IP aralığını öğrenin ve bunlara aşina olun.

“Office 365 Genel IP aralığı” konusu hakkında çok fazla ayrıntıya girmeyeceğiz ancak “Office 365” teriminin yalnızca çok karmaşık bir dizi altyapıyı, hizmetleri, hizmetleri tanımlayan mantıksal bir terim olduğunu anlamak çok önemlidir. Genel IP aralıkları vb.

Benim tavsiyem, Güvenlik Duvarı kuralları, Ağ aralığı vb. oluşturmaya başlamadan önce, farklı Office 365 altyapıları ve Microsoft tarafından farklı Office 365 altyapılarının her biri için atanan özel Genel IP aralığı hakkındaki bilgileri iyice okumanızdır.

3. Genel IP aralığının dinamik yapısı

Office 365 dinamik bir ortamdır. Temel varsayım, zaman zaman Office 365 genel IP aralığıyla ilgili güncellemelerin olacağıdır. Güncel kalabilmek ve Office 365 Genel IP aralıklarıyla ilgili özellikler veya güncel güncellemelerden haberdar olmak için Office 365 URL'lerini ve IP adresi aralıklarını okuyabilirsiniz.