Microsoft Exchange Autodiscover Servisi ve Multi-tenancy

09.11.2015 | 22:20 Exchange Server 7 Yorum

İlk kez Exchange Server 2007’de gelen autodiscover servisi, erişim için gerekli bilgilerini ve hizmet ayarlarını otomatik olarak sağlayarak kullanıcı ve mail server’ı en az input ile buluşturmayı amaçlayan kullanışlı bir servistir. Pek severiz.

Ortalama bir bir e-posta kullanıcısı genelde 2 bilgiye sahip olur: E-posta adresi ve parola. Ama mesela aynı kullanıcı sunucu adresi, bu sunucunun SSL/TLS isteyip istemediği, hangi port üzerinden yayın yapıldığı gibi diğer bilgilere genelde sahip değildir. İşte autodiscover servisinin çıkış noktası tam olarak burası. Kullanıcı mail client’a sadece e-posta adresini ve parolasını girer, mail client diğer tüm gerekli ayarları autodiscover servisi üzerinden alır, parse eder, uygular ve işler yolunda gitmişse kullanıcıyı servise ulaştırıp ilk görevini tamamlar.

Az önce ilk görevini tamamlar dedim çünkü mesela Outlook’a Exchange Autodiscover servisiyle bir hesap eklendikten sonra her yeniden açılışta ve hatta çoğu zaman açık durumdayken de belirli zaman aralıklarında autodiscover servisiyle iletişim kurularak ayarlarda bir değişiklik olup olmadığı kontrol edilir. Eğer değişiklik varsa hemen mail client’a uygulanır.

Outlook çalışma anında ansızın ortaya çıkan credentials pop-up’larının bir nedeni de hatalı yapılandırılmış Exchange Autodiscover servisleridir.

Exchange Autodiscover servisi mail client’lara aşağıdaki bilgileri/ayarları sağlar.

  • Kullanıcıya ait Display Name.
  • Sunucu adresi, authentication türü, SSL/TLS geresinimi, varsa port numarası gibi bağlantı ayarları.
  • Organizasyon içerisinde Mailbox’ın tutulduğu Mailbox Server lokasyonu.
  • Free/busy bilgisi, UM, Offline Address Book gibi çeşitli özelliklere ait endpoint URL’ler.
  • Outlook Anywhere ayarları.

Exchange Autodiscover Nasıl Çalışır?

Organizasyonda herkesin mutlu olduğu, başarılı ve pürüzsüz bir autodiscover servisi için olayı %50 service side, %50 client side açısından ele almak gerekiyor. Hangi %50’yi evde zor tutuyoruz onu ben bilemiyorum. Ama service side’da mükemmel kurgulanmış ve dört dörtlük çalışan bir autodiscover servisiniz olsa bile, client side’da hizmet alacak istemcileri bu servisle -ve uyumlu bir şekilde- buluşturamadığınız sürece hiçbir anlamı olmayacaktır. Bu yüzden tarafları dışlamayın, iki tarafı da kucaklayın. (?)

Temelde bir web uygulaması olan autodsicover servisi, Exchange organizasyonu içerisinde sadece CAS rolüne sahip sunucular üzerinde yer alabilir. Internal ve External olmak üzere iki farklı URL‘i vardır. Internal URL’ini CAS rolünü çalıştıran sunucunun FQDN’i oluşturur ve genelde organizasyon içerisindeki (domain-member diyelim) mail client’lara hizmet eder. External URL ise dış dünyadan ulaşılabilen bir isme sahiptir ve genelde internet üzerinden gelen mail client’lara hizmet eder.

Exchange Server organizasyonundaki mevcut autodiscover ayarlarını görmek için Get-AutodiscoverVirtualDirectory cmdlet’ini, yapılandırmak için Set-AutodiscoverVirtualDirectory cmdlet’ini kullanabilirsiniz.

Exchange Server’dan hizmet alabilecek mail client’ları ise sanırım 3 gruba ayırmak mümkün.

  • Desktop – En popüleri Outlook uygulamasıdır ve 2007 sürümünden bu yana Autodiscover servisini destekler.
  • Mobile – iOS, Android, Windows gibi mobile OS’lerin native (veya third-party) mail client’ları örnek gösterilebilir. Genelde ActiveSync uyumludurlar veya iddiaları bu yöndedir.
  • Web – Çoğu zaman doğrudan Exchange Server üzerinden sağlanır. En bilinen örneği OWA’dır.

Bu mail client’ları autodiscover ihtiyacı açısından ele alırsak; OWA’nın çalışma mantığında doğru giriş adresini biliyor olmanız beklendiği ve zaten o noktadan sonra herhangi bir autodiscover ihtiyacı kalmadığı için Web client‘ları konu dışı bırakıyoruz. Desktop ve Mobile client’ların autodiscover ihtiyacı olabileceği ise gayet açık.

Desktop Tabanlı Mail Client’lar için Autodiscover

Desktop tabanlı mail client’lar Autodiscover URL‘e ulaşmak için sırasıyla 4 bulma yöntemi denerler. Eğer Autodiscover URL’i bulmak için denenen ilk yöntem başarısız olursa sonraki ve gerekli ise daha sonraki bulma yöntemlerine geçilir. Eğer yöntemlerden biri ile URL’e ulaşılırsa sonraki bulma yöntemleri denenmez.

1) Service Conncetion Point (SCP)

Eğer bir istemci Active Directory üyesi ise -mesela Outlook çalıştıran bir domain member Windows- autodiscover servisinin nerede olduğunu anlamak için öncelikle AD configuration partition’da duran bir SCP (service connection point) kaydına bakar. SCP kaydını oraya yazan ise setup/config sırasında Exchange Server’dır ve içerisinde Internal Autodiscover URL bilgisi yer alır. Bir örneğini aşağıda görebilirsiniz.

Adsi.edit > Configuration > Services > Microsoft Exchange > Organization Adı > Administrative Groups > Exchange Administrative Group (FYDIBOHF23SPDLT) > Servers > …

exchange-autodiscover-scp

Eğer domain-member client SCP’den Autodiscover URL bilgisini okuyabilirse bunu alır ve servise ulaşmak için kullanır. Bu bulma yönteminde SCP’den dönen URL bilgisi çoğu zaman CAS rolü çalıştıran sunucuların iç erişim adreslerini işaret eder.

  • https://cas1.domain.com/autodiscover/autodiscover.xml
  • https://cas2.domain.com/autodiscover/autodiscover.xml
  • https://cas3.domain.com/autodiscover/autodiscover.xml

Şunu unutmayın: Bu ilk Autodiscover URL bulma yöntemi Workgroup istemciler için geçerli değildir çünkü onlar tasarım gereği SCP’ye bakmazlar. Workgroup istemciler sıradaki diğer bulma yöntemlerini kullanarak ilerler.

2) Hard-coded URLs

Eğer bir istemci Active Directory üyesi olduğu halde bir nedenden ötürü SCP kaydını okuyamazsa (mesela silinmiş olabilir) ikinci bulma yöntemi olarak mail account’un domain suffix’ini referans alıp birkaç Autodiscover URL kombinasyonunu türetir (hard-coded) ve yine belirli bir sırada DNS servisinden IP adreslerini sorgular. Eğer istemci Workgroup olarak çalışıyorsa da bu ikinci bulma yöntemini kullanır. Mesela evindeki bilgisayara şirket e-posta adresini kurmak isteyen çalışan veya servis olarak e-posta hizmeti almak isteyen müşteriler Workgroup istemcilere güzel iki örnek.

İstemcideki hard-coded URL türetme formülü is şöyle:

  • https:// + domain + /autodiscover/autodiscover + fileExtension
  • https://autodiscover. + domain + /autodiscover/autodiscover + fileExtension

fileExtension, Autodiscover’a erişim yöntemlerinden SOAP veya POX kullanımına göre değişir. SOAP .svc uzantısını kullanırken POX (yani http post) .xml uzantısını kullanır. Mesela Workgroup Windows 10 üzerindeki Outlook 2016 ile internet üzerinden bir e-posta hesabı tanımlamak isterseniz URL’ler aşağıdaki gibi türetilir.

Mail account:

  • isim@serhatakinci.com (P4ssw0rd)

Türetilen Autodiscover URL’ler:

  • https://serhatakinci.com/autodiscover/autodiscover.xml
  • https://autodiscover.serhatakinci.com/autodiscover/autodiscover.xml

Dikkat ederseniz her iki URL de HTTPS’tir (secure) çünkü mail client’ın autodiscover servisinden bilgileri alabilmesi için öncelikle User Name ve Password bilgilerini göndererek kimlik doğrulaması gerekir. Yine HTTPS sayesinde, hassas bilgilerin gönderileceği sunucunun da gerçekten gitmek istediği sunucu olup olmadığını doğrulama şansına sahip olur. Bu yüzden URL’ler secure ve dijital sertifika tabanlıdır.

Secure HTTP sayesinde;

  • İletişim öncesinde sunucu tarafından istemciye gönderilen dijital sertifika vasıtasıyla istemcinin credentials bilgisi göndereceği sunucuyu doğrulama şansı olur. (sunucu kimlik doğrulama)
  • Client’ın istemci kimlik doğrulama için sunucuya gönderdiği credentials bilgisinin transferi sırasında MITM gibi araya girme ataklarına karşı güvenliği artırır.

Secure HTTP URL’lerin kendi içinde denenme sırası ise aşağıdaki gibidir. Mail client ilkinden doğru bir yanıt alamazsa diğerine geçer.

  1. https://serhatakinci.com/autodiscover/autodiscover.xml
  2. https://autodiscover.serhatakinci.com/autodiscover/autodiscover.xml

Eğer URL’lerden birinde doğru Exchange Server Autodiscover servisiyle karşılaşırsa, mail client HTTP POST ile credentials bilgisi gönderir ve kendini tanıtarak süreci ilerletir.

3) HTTP Redirection

Eğer mail client bu aşamaya kadar geldiyse bir önceki yöntemde doğru HTTPS URL’lere ulaşamamış demektir. Bu durumda yine mail account’un domain suffix’ini referans alarak aşağıdaki gibi secure olmayan bir HTTP URL türetir ve bu sefer GET yapar.

  • http://autodiscover.serhatakinci.com/autodiscover/autodiscover.xml

Ve buradan doğru autodiscover servisine ait Secure HTTP URL’e yönlendirilip yönlendirilmediğine bakar. Yani aslında bu HTTP servise herhangi bir bilgi göndermez (POST yapmaz) ve ondan herhangi bir yapılandırma ayarı beklemez. Sadece HTTP Redirection (yeniden yönlendirme, 302/301) yanıtı bekler.

  • HTTP Redirection için istemci kimlik doğrulaması gerekmez, bu yüzden credentials bilgisi gönderilmez.
  • GET metoduyla çağırılı ve secure HTTP değildir. Yani dijital sertifika yoktur ve bu yüzden sunucu kimlik doğrulaması yapılmaz/gerekmez.

Eğer bir yanıt alırsa -ki bu genelde farklı bir HTTPS URL’e yönlendirme mesajı olur- o zaman HTTP URL ile işi biter ve yönlendirme mesajıyla öğrendiği HTTPS URL‘e gidip tıpkı 2. adımdaki gibi sunucu kimlik doğrulama sonrası POST yaparak credentials bilgisi gönderme ve servis ayarlarını alma sürecini ilerletir.

4) SRV Record (DNS)

Eğer önceki bulma yöntemlerinden hiçbiri mail client’ı bir autodiscover servisine ulaştıramazsa, son olarak serhatakinci.com’un DNS zone’una aşağıdaki SRV kaydının karşılığını sorar. (Priority sayesinde aynı isimli birden fazla SRV kaydı oluşturmak mümkün)

  • _autodiscover._tcp.serhatakinci.com

Bu kaydın karışılığı aşağıdaki gibi bir HTTPS URL olmalıdır.

  • https://autodiscover.serhatakinci.com/autodiscover/autodiscover.xml

Mail client bu URL’i alabilirse autodiscover iletişimini başlatmayı dener. Eğer bu aşamada da doğru bir URL alamazsa client için autodiscover macerasının sonu demektir ve kullanıcıdan gerekli mail servis bilgilerini manual olarak girmesi istenir. Giremez ise e-posta hesabı ekleme işlemi başarısız bir şekilde sonlanır.

Mobile Tabanlı Mail Client’lar için Autodiscover

Mobile mail client‘lar için durum biraz karışık çünkü mesele cihaz üreticisinin implementasyon politikasına kalmış durumda. Genelde birçoğu Autodiscover servisinin Exchange Server 2010 ve sonrasını destekler ama yine de bazı tuhaflıklar yok değil.

Mobile client’lar Autodiscover URL‘e ulaşmak için SCP dışındaki 3 bulma yöntemini kullanabilirler. Yine ilk denenen yöntem başarısız olursa sonraki bulma yöntemlerine geçilir. Eğer ilk yöntem ile URL bilgisine ulaşılırsa, gerek kalmadığı için sonraki yöntemler denenmez.

Detayları tekrar yazmayacağım. iOS, Andorid, Windows gibi mobil işletim sistemlerinde çalışan native veya third-party mail client’ların iddiası Exchange Autodiscover servisine aşağıdaki sıralamada baktıkları yönündedir, çünkü ActiveSync uyumluyuz derler.

1) Hard-coded URLs

  • https://serhatakinci.com/autodiscover/autodiscover.xml
  • https://autodiscover.serhatakinci.com/autodiscover/autodiscover.xml

2) HTTP Redirection

  • http://autodiscover.serhatakinci.com/autodiscover/autodiscover.xml

3) SRV Record (DNS)

  • _autodiscover._tcp.serhatakinci.com

iOS ve Android üzerindeki mail client’ları test ettiğimde kesinlikle SRV kaydına bakmadıklarını gördüm. Eğer Autodiscover servisini mobil client’lar için kullanmak istiyorsanız SRV kaydına güvenmeyin, mutlaka ama mutlaka 1. veya 2. bulma yöntemlerinde yakalayıp autodiscover servisiyle buluşturun. Aksi durumda mobile cihazlara autodiscover hizmeti sağlayamazsınız.

Exchange Server Multi-tenant ve Autodiscover (Hosted)

Buraya kadar senaryoda hep tek mail domain vardı. Eğer aynı Exchange organizasyonu içerisinde birden fazla mail domain’e sahipseniz, ya da ne bileyim bir multi-tenant (çok kiracılı, hosted) yapı işletiyorsanız autodiscover servisini nasıl tasarlamanız gerektiğini iyi anlamanız gerekiyor.

Biz Türkiye’de hizmet vermeye hazırlanan bir müşterimiz için Exchange Server ve Lync Server (Skype for Business) ürünlerinin multi-tenant modda kurgulanıp deploy edildiği bir proje yürütüyoruz. Bu sırada Autodiscover servisleri konusunda (ki Lync Server’da da bir autodiscover servisi yer alıyor) fazlaca çalışma şansım oldu; Outlook ve mobile device HTTP trafiğini dinleyerek POST/GET metodlarının analizinden tutun da DNS sorgularının takibine, XML/SVC içeriklerinin parse edilmesine, hatta URL bulma algoritmalarının çözümlenmesine kadar…

Bu bölümdeki daimi senaryo şu: Exchange organizasyonu serhatakinci.com isimli AD forest root domain içerisinde kurulu. Üzerinde birden fazla mail domain host ediliyor ki zaten birden fazla olduktan sonra kaç adet olduğunun pek bir önemi yok; 10 olur, 100 olur, 5000 olur… 2 ve sonrası aynı. Diğer mail domain ismi de musteri.com.

Hedef ise şu: Tüm desktop veya mobile mail client’lar hiçbir uyarı mesajı ile karşılaşmadan yeni e-posta adresi ekleyebilmeli ve servise bağlanıp hizmet alabilmeliler. Kısaca hedef pürüzsüz bir e-posta ekleme deneyimi.

Şimdi hosted hizmet veriyoruz ya, haliyle bir iç organizasyon yok ve tüm müşteriler internet üzerinden geliyor. Bu durumda Autodiscover servisinin ancak External URL adresine gelebilirler. Haliyle SCP gibi bir kayda bakma şansları da yok (Workgroup senaryosu). Ayrıca Exchange’in tüm özellikleri sağlıklı çalışıyor ve başlangıç autodiscover yapılandırması aşağıdaki gibi.

Pek önemli değil ama Autodiscover Internal URL’ler:

  • https://e-cas1.serhatakinci.com/autodiscover/autodiscover.xml
  • https://e-cas2.serhatakinci.com/autodiscover/autodiscover.xml
  • https://e-cas3.serhatakinci.com/autodiscover/autodiscover.xml

Autodiscover External URL:

  • https://autodiscover.serhatakinci.com/autodiscover/autodiscover.xml

Autodiscover Public IP:

  • 44.55.66.77 (temsili)

Autodiscover DNS Kayıtları (zone: serhatakinci.com)

  • (A) autodiscover.serhatakinci.com –> 44.55.66.77
  • (SRV) _autodiscover._tcp.serhatakinci.com –> autodiscover.serhatakinci.com

Dijital Sertifika (SSL)

  • *.serhatakinci.com (Public sağlayıcıdan alınmış bir Wildcard veya SAN kaydı)

Mail Ddomain’ler:

  • @serhatakinci.com
  • @musteri.com

Desktop PC üzerinde Outlook‘a veya örneğin iPhone (iOS) üzerinde mail client’a ilk kez isim@serhatakinci.com‘u eklemek istersem sorunsuz ve tam istediğim şekilde tamamlanacaktır. Çünkü sertifika uygun ve sunucu ismi ile eşleşiyor, herhangi bir HTTP Redirection’a gerek yok, URL isimlerinden DNS kayıtlarına kadar herşey perfect!

Peki aynı cihazlara isim@musteri.com‘u eklemek istersem? İşte problem başlıyor.

Müşteri hesabı doğası gereği bir dış client olduğu için Autodiscover servisini bulmak adına öncelikle Secure HTTP URL‘leri türetip bağlanmayı dener.

  • https://musteri.com/autodiscover/autodiscover.xml
  • https://autodiscover.musteri.com/autodiscover/autodiscover.xml

Bu amaçla mail client, türettiği URL’lere işaret eden IP adreslerini bulmak için DNS Server’a sorar. O halde aşağıdaki DNS kayıtlarının da açılmış olduğunu kabul edelim. A ile IP address, CNAME ile domain name işaret etmenin bu senaryo açısından herhangi bir farkı yok. İkisi de aynı sonuca ulaştırır.

Autodiscover DNS Kayıtları (zone: musteri.com)

  • (A) musteri.com –> 44.55.66.77
  • (A) autodiscover.musteri.com –> 44.55.66.77

veya

  • (CNAME) musteri.com –> autodiscover.serhatakinci.com
  • (CNAME) autodiscover.musteri.com –> autodiscover.serhatakinci.com

Dış istemci musteri.com veya autodiscover.musteri.com URL’lerine ulaşmak için IP adreslerini DNS’e sorduğunda, mail client’a 44.55.66.77 (veya aynı IP adresine işaret eden CNAME karşılığı) döner. Ancak işaretlenen servis serhatakinci.com domain’i adına yayın yaptığı için Secure HTTP’den *.serhatakinci.com sertifikası gönderilir ve mail client’a sunucu kimlik bilgisinin doğrulanamadığını söyleyen bir güvenlik uyarısı gösterilir. Ve tabii tüm büyü bozulur.

autodiscover-sertifika-guvenlik-uyarisi

Mobile mail client’larda da benzer bir güvenlik uyarısı görüntülenir.

Bu bir hata mesajı değil bir uyarı mesajıdır ve az sonra credentials gönderilecek sunucunun kimliğinin doğrulanamadığı anlamına gelir. Yani diyor ki “bak birazdan buraya username/password göndereceğim ama bu servisin ismi senin gitmek istediğin servis ile eşleşmiyor, yine de gönderyim mi?” Eğer kullanıcı yine de Yes ile onaylayıp devam etmeyi tercih ederse autodiscover servisine bağlantı sağlanır, gerekli ayarlar alınır, uygulanır ve e-posta hesabı ekleme işlemi tamamlanır.

outlook-autodiscover-ayarlar

Yukarıdaki örnek bir desktop mail client olan Microsoft Outlook içindi ama iOS gibi, Android gibi mobil OS’ler üzerindeki mail client’lar için de aynı durum geçerlidir. Ve hatta mobile mail client’larda ekstra özel durumlarla da karşılaşabilirsiniz. Hani Autodiscover tasarımı gereği ilk olarak https://musteri.com/autodiscover/… ‘a bakılıyor ya, eğer o domain üzerinde autodiscover servisi değil de mesela şirketin herhangi bir web yayını yer alıyorsa ve bu web yayınındaki SSL sertifikası bir nedenden ötürü güvensiz durumdaysa (önemsenmediği için süresi dolmuş, geçerli ama eşleşmiyor, vs.) mobile mail client’lar hemen güvenlik uyarısını ekrana yapıştırır. Halbuki orada autodiscover’la ilgili hiçbir içerik yoktu. Desktop mail client’lar ise bu konuda daha kontrollüler ve o ilk URL’de bir SSL yayını olsa da, eğer bu yayın bir autodiscover servisi değilse -SSL sertifikası güvensiz olsa dahi- uyarı vermeden ikinci URL’i denemek üzere ilerlerler.

Çözüm var mı?

İlk akla gelen sanırım şu: Eğer gidip serhatakinci.com domain’inden yayın yapan autodiscover servisindeki SSL sertifikasına Subject Alternative Name (SAN) olarak autodiscover.musteri.com, autodiscover.musteri2.com, autodiscover.musteri3.com gibi mail domain adlarını eklerseniz güvenlik uyarısı sorununu aşabilirsiniz. Teknik açıdan doğru bir yöntem. Ama pratikte her senaryoya uygulamak mümkün değil.

Konu birkaç mail domain ise mesela en baştan bu kapsamda bir sertifika satın almak evet sorunu çözecektir. Ama örneğin Exchange Server üzerinden e-posta hizmeti vermek isteyen bir servis sağlayıcıyı konuşuyorsak; her yeni gelen müşteri, mevcut sertifikaya yeni bir kayıt (SAN) eklenmesini anlamına gelir. Bu da başa çıkılması gereken yepyeni sorunlar demek.

  • Her bir ilave SAN kaydı ekstra maliyet getirir. Ayrıca SSL sertifikalarının belirli zamanlarda yenilenmesi gerektiğini de unutmayın; bu maliyet daima peşinizde olacak.
  • Yeni bir müşteri geldiğinde en az 1 yıl geçerli SAN kaydı ekleyebilirsiniz (daha az süreli sertifika sağlayan var mı bilmiyorum). Mesela 3 aylık hizmet almak isteyen bir müşteri sizi ekstra zarara uğratacaktır.
  • Küresel sağlayıcılardan (yetkili otoriteler) temin edilen bazı SSL sertifikalar için SAN ekleme limitleri vardır (mesela 100 adete kadar). Bu rakama ulaştığınızda, yeni gelen müşter için sertifikada yer kalmadığından o müşteriler ancak güvenlik uyarılarına onay vererek bağlanabilirler.
  • Sertifikanın içerisinde yeni bir SAN kaydı eklemek o sertifikanın yeniden üretilmesi, imzalanması ve ilgili servislere atanması anlamına gelir. Bu süreçteki operasyonel iş yükü bir tarafa yeni sertifika gelene kadar müşteri hizmetinin başlatılamayacak olması (belki 2 gün) ve müşteri provizyon sürecini otomatikleştirmeyi imkansız hale getirmesi gibi sorunlarınız da olacak.
  • Sertifika SAN listesini takip etmek için işe yeni birini almanız gerekebilir. Sr. SAN Specialist :)

Bu yöntem bence sürdürülebilir değil. Ha SSL Termination‘ı NetScaler veya F5 gibi cihazlarla yaparak bu sorunların bir kısmını aşmak mümkün (ki biz de faydalanıyoruz) ama hala önemli sorunlarınız olacak ve maliyet aşılamayan en önemli kalem.

***

DNS’te açılacak bir SRV kaydı ile doğrudan ana autodiscover servisine yönlendirmek aslında güzel bir fikir gibi duruyor. Hem sertifika geçersiz olmadığı sürece SSL güvenlik uyarısı oluşma ihtimali ve SAN’e kayıt ekleme gereksinimi de yok çünkü bu yöntemle mail client’a “mail domain’in musteri.com ama sen doğrudan autodiscover.serhatakinci.com’a git” deme şansınız oluyor. Bir nevi redirection ama HTTP’den değil DNS’ten…

SRV kaydı ile autodiscover servisini bulma yöntemi sıralamada en altta duruyor. Yani mail client’ın bu bulma yöntemine kadar inebilmesi için daha öncekilerin kullanılamıyor olması gerekli; SCP olmayacak, HTTPS URL’leri yanıt vermeyecek (mesela DNS kayıtlarını açmayabilirsiniz) ve herhangi bir HTTP Redirection yöntemi devrede olmayacak…

SRV kaydı ile bulma yöntemini kullanmak için gereksinimleri sağlamak da kolay ama bu yöntemin önünde 2 önemli engel var.

İlki Outlook gibi desktop mail client’lar SRV kaydına kadar rahatlıkla inebilirken iOS, Android gibi mobile OS’lerin üzerindeki mail client’lar SRV kaydına bakamıyor :) Tuhaf olan ise ActiveSync tasarımında SRV kaydının sorgulanması 4. sırada yer alıyor, ama ActiveSync uyarlaması olan bu mobiile mail client’lar SRV kaydına bakmıyor. Üreticilerin implementasyon politikası mıdır bilmiyorum ama bir işler döndüğü kesin.

İkincisi ise mail client’a eklenmek istenen mail domain ismi ile SRV kaydı üzerinden yönlendirilen autodiscover domain isminin farklı olmasından ötürü görüntülenen uyarı mesajı. Bu uyarı mesajı sadece Outlook gibi desktop mail client‘lar tarafından gösterilir. Yani bir implementasyon farkı.

exchange-autodiscover-redirection-yonlendirme

Allow this website to configure isim@musteri.com server settings?

Bu uyarı mesajıyla aktarılmak istenen şu: “email adresin isim@musteri.com ama seni mail domain’inle eşleşmeyen bir autodiscover servisine yönşendirmek istiyorlar, izin veriyor musun?” Eğer Allow derseniz süreç devam eder ve autodiscover servisine bağlanıp ayarlar alınır. Eğer Don’t ask me about this website again seçeneğini işaretlerseniz serhatakinci.com domain’indeki bu gibi URL’lere daima güvenmiş olursunuz ve aynı domain’den yeni bir hesap tanımlamak istediğinizde veya Outlook çalışma anında karşınıza bu uyarı penceresi tekrar çıkmaz.

Bu uyarı penceresini sertifika güvenlik uyarısı ile karıştırmayın. Eğer yönlendirilen sunucunun sertifikası geçersiz olsaydı üstteki mesaja ek olarak -ve yeni bir pencerede- bir de sertifika güvenlik uyarısı gösterilecekti.

Bu arada testconnectivity.microsoft.com‘u bilirsiniz ve test senaryolarından bir de mobile için Exchange ActiveSync Autodiscover‘dır. Mesela orada şöyle bir sorun olduğunu farkettim. Eğer autodiscover servisini sadece SRV kaydıyla işaret ediyorsanız testconnectivity.microsoft.com sonucu Success olarak gösteriyor ve ayarları alıyor. Ama gerçek dünyadaki iOS ve Androind üzerindeki mail client’lar Fail ediyor :) testconnectivity.microsoft.com sonucu success gösteriyor çünkü adamlar web servisi gidip SRV’ye bakacak şekilde yazmışlar. Ama ActiveSync tabanlı mail client’sa sahip mobile OS’ler SRV’ye bakmıyor, bu yüzden de ayarları alamıyorlar.

Kısaca mobile mail client’lara çözüm üretemediği için bu yöntemi de multi-tenant autodiscover serivisini işaretlemek için kullanamazsınız.

***

Geriye kalan tek yöntem ise HTTP Redirection ve güzel haber şu: hem Desktop hem de Mobile mail client’lar tarafından kullanılabiliyor.

Autodiscover servisini bulmak için kullanılan yöntemlerin sıralamasını hatırlayın:

1) Service Connaction Point (SCP) (Sadece domain-member client’lar kullanabilir)

2) Hard-coded türetilen URL’ler

  • https://musteri.com/autodiscover/autodiscover.xml
  • https://autodiscover.musteri.com/autodiscover/autodiscover.xml

3) HTTP Redirection

  • http://autodiscover.musteri.com/autodiscover/autodiscover.xml

4) DNS SRV kaydı

HTTP Redirection da aslında hard-coded olarak türetilen bir URL ancak farklı olarak Secure değil. Mail client ilk 2 yöntemle autodiscover servisini bulamazsa bu HTTP URL’i türetir, DNS’ten IP adresini öğrenerek bir HTTP GET mesajı gönderir ve karşı taraftan bir yeniden yönlendirme mesajı (310/302) bekler. Eğer uygun bir yanıt alırsa, autodiscover servisini bulmak üzere yönlendirildiği sunucuya doğru iletişim başlatır.

Exchange Autodiscover HTTP Redirection için gerekenler oldukça basit.

Önce DNS üzerinde sadece autodiscover.musteri.com için A kaydı açın ve HTTP Redirection mesajını dönecek olan web servisinin IP adresini işaret edin. Bu web servisi Windows Server üzerinde çalışan bir IIS olabileceği gibi, Linux+Apache veya NetScaler, F5 gibi donanımsal çözümler de olabilir.

Sonra web servisinde gerekli yönlendirme işlemini uygulayın. Mesela IIS üzerinde yeni bir site yaratın. Altında Autodiscover isimli bir virtual directory ve onunda içerisinde Autodiscover.xml isimli boş bir dosya oluşturun. Ardından aşağıdaki gibi redirection yapılacak asıl autodiscover servisinin HTTP URL‘ini girin.

autodiscover-http-redirection

Bu noktadan sonra http://autodiscover.musteri.com/autodiscover/autodiscover.xml URL’ini çağıranlar https://autodiscover.serhatakinci.com/autodiscover/autodiscover.xml Secure URL’ine yönlendirilirler. Tarayıcıya http://autodiscover.musteri.com/autodiscover/autodiscover.xml yazarak yönlendirmenin çalışıp çalışmadığını basitçe test edebilirsiniz.

Organizasyondaki tüm mail domain’leri bu yöntemle asıl autodiscover URL’ine yönlendirebilirsiniz. Bu sırada herhangi bir ek sertifika veya SAN gerekmez. Autodiscover servisi üzerindeki sertifikanın geçerli ve asıl servisin ismini içeriyor olması yeterlidir.

Tek kötü yanı ise şu: Maalesef bu yöntemde de aşağıdaki uyarıdan kurtulamıyorsunuz. Kullanıcının bir kez Allow ve Don’t ask me about this website again demesi gerekiyor.

exchange-autodiscover

Acaba bu uyarıyı kaldırmanın bir yolu olabilir mi diye düşünürken aklıma küresel servis sağlayıcılar geldi. Mesela en güzel örnek Office 365 çünkü altyapısında Exchange Server’lar kullanıyor. Kendi domain isminizle bir hizmet açıyorsunuz, ama Outlook’a eklerken hiçbir yönlendirme uyarısı gelmiyor? Demek ki bir yolu olmalı :)

Aslında bir yolu var ama bunu sizin kendi müşteriniz için yaygınlaştırmanız hiç kolay değil. Bu yönlendirme uyarısının sadece Windows + Outlook kombinasyonunda göründüğünü söylemiştim (MAC OS + Outlook’da var mı bilmiyorum). Eğer aşağıdaki registry anahtarına autodiscover servis URL’ini eklemeyi başarırsanız, Outlook ilk rediection sırasında bile uyarı penceresini göstermez ve adrese güvenerek devam eder.

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\XX.0\Outlook\AutoDiscover\RedirectServers

New > Binary Value > Name = autodiscover.serhatakinci.com

Ama kabul edersiniz ki bu kaydı önceden müşterilerin Windows’larına eklemek mümkün olmayacaktır. Peki Office 365 bunu nasıl yapıyor? Cevap basit: Tüm Office 365 müşterilerinin autodiscover url’leri HTTP Redirection ile autodiscover-s.outlook.com isimli bir domain’e yönlendirilir, ve oradan da coğrafi bölgelere göre göre farklı domain’lere… İşte bu ilk domain adresi Outlook kurulumuyla birlikte otomatik olarak \AutoDiscover\RedirectServers anahtarı altına ekleniyor ve bu yüzden de Outlook kullanan Office 365 müşterileri redirect olsalar bile uyarı mesajı görüntülenmiyor. Ufaktan bir kıyak geçme durumu yani :)

registry-redirectedservers

Sonuç olarak Exchange Server ile multi-tenant yapıda hizmet vermeyi planlıyorsanız -ve mecburen HTTP Redirection yöntemini kullanacağınızı da düşünürsek- müşterilerinizin bu yeniden yönlendirme uyarısını kabul etmesi gerekecek. Bir diğer seçenek olarak ise autodiscover servisini kullanmamayı tercih edebilirsiniz.

Ha  bu arada, yazının konusu olmadığı için girmedim ama benzer bir durum Lync Server Multitenant Hosting Pack ile inşa edilen yapılar için de geçerli. Belki bir başka yazıda ele alırım.

Hoşça kalın.

Yazı Etiketleri: , , , ,

Sayfa Başı ▲

Yorumlar (7)

  1. Murat KOÇAK

    Hocam emeğinize sağlık. Çok güzel bir yazı…

  2. Erdinc Colak

    Hocam ellerine saglık, son zamanlarda okudugum en detaylı ve iyi anlatımlı bir yazı bu.şahane gerçekten.

  3. Emre

    Parmaklarına sağlık.

  4. Sinan arslan

    Elinize sağlık gerçekten oldukça açıklayıcı olmuş.

  5. Gökhan Sezen

    Exchange 2013 / 2016 üzerinde kullanılacak sertifika mutlaka SAN olmak zorunda mı. Kullanacağımız domain sadece mail.abc.com olacak. Sertifikayı alacağım kurum fazla maaliyet yaratmak istemiyor onun için soruyorum.

  6. Gökhan Sezen

    Bir önceki mesajımdaki sorunumu çözdüm hocam sertifikayı eklerken bende cer uzantılı dosya olduğu için ekleyememiştim. Bu sebeple acaba sertifika Mutlaka SAN mı olmalı diye düşünüyordum ki değilmiş. Ufak bir tool ( DigiCert Certificate Utility for Windows ) sayesinde sertifikanın pfx olanını oluşturarak sorunumu çözdüm.

  7. Volkan

    Serhat Bey, ders kitabı olmuş bu. Elinize sağlık.

Yorum Ekle