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. İlk kez Exchange Server 2007’de gelen autodiscover servisi, erişim için gerekli bilgilerini ve hizmet ayarlarını otomatik sağlayarak kullanıcı ve mail server’ı en az input ile buluşturmayı amaçlayan kullanışlı bir servistir. Pek severiz.
Az önce ilk görevini tamamlar dedim çünkü örneğin Outlook uygulamasına Exchange Autodiscover servisiyle bir hesap eklendikten sonra her yeniden açılışta ve hatta çoğu zaman açık durumdayken bile 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 credential pop-up’ları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ı.
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 çünkü 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.
Exchange Autodiscover Nasıl Çalışır?
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 temel URL’i vardır. Internal URL’i 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 aldığımızda 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. Konumuz Desktop ve Mobile client’lar.
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’ın kendisidir ve içerisinde Internal Autodiscover URL bilgisi de 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 > …
Eğer domain-member client SCP’den Autodiscover URL bilgisini okuyabilirse bunu alır ve servise ulaşmak için kullanır. Eğer değiştirilmemişse, 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
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 hard-coded olarak birkaç Autodiscover URL kombinasyonunu türetir 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 personeller veya servis olarak e-posta hizmeti almak isteyen müşteriler Workgroup istemcilere güzel iki örnek teşkil ediyorlar. İ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 iletiş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) Ayrıca client’ın istemci kimlik doğrulama için sunucuya gönderdiği credential 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. Eğer URL’lerden birinde doğru Exchange Server Autodiscover servisiyle karşılaşırsa, mail client HTTP POST ile credential bilgisi gönderir ve kendini tanıtarak kimlik doğrulama sürecini ilerletir.
https://serhatakinci.com/autodiscover/autodiscover.xml https://autodiscover.serhatakinci.com/autodiscover/autodiscover.xml
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 credential bilgisi gönderilmez. 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 credential 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ündür)
_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ü 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. Bu noktada 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. Ancak 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.
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
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 kısımdaki örnek senaryo şöyle: 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ı 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.
Bu senaryoda 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 Domain’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 burada 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.
Bu bir hata mesajı değil bir uyarı mesajıdır ve az sonra credential 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.
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 bazı 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 ve SSL sertifikası güvensiz olsa dahi uyarı vermeden ikinci URL’i denemek üzere ilerlerler.
Çözüm için ilk 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.
Bu yöntem hiç de sürdürülebilir değil. 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.
- 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 mobile 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.
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 durum olduğunu fark ettim. 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. Özetle mobile mail client’lara çözüm üretemediği için bu yöntemi de multi-tenant autodiscover serivisini işaret etmek 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 ise 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.
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.
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 & Exchange Online çünkü altyapısında Exchange Server’lar kullanıyor. Kendi domain isminizle bir hizmet açıyorsunuz ve 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 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 :)
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. Bu arada yazının konusu olmadığı için pek 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 konuşuruz.
10.11.2015 - 09:26
Hocam emeğinize sağlık. Çok güzel bir yazı…
08.03.2016 - 13:17
Hocam ellerine saglık, son zamanlarda okudugum en detaylı ve iyi anlatımlı bir yazı bu.şahane gerçekten.
06.04.2016 - 09:31
Parmaklarına sağlık.
05.05.2016 - 10:35
Elinize sağlık gerçekten oldukça açıklayıcı olmuş.
22.05.2016 - 23:22
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.
23.05.2016 - 08:41
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.
25.10.2016 - 14:19
Serhat Bey, ders kitabı olmuş bu. Elinize sağlık.
29.01.2017 - 19:39
Merhaba Serhat Bey,
local exchange üzerinde birden çok domain host ediyorum, ana domainim için ssl var ve ana domain dışındakiler için ssl uyarısı vermemesi adına autodiscover redirect işlemini yaptım. fakat sonucunda outlooklarda ssl uyarısını ekrana veriyor ama sonra http redirect adımına geçip bağlantı sağlasada ssl uyarısının ekrana çıkması büyüyü bozuyor.
testconnectivity.microsoft.com den kontrol ettiğimde ise 2.adımda 443 başarılı gittiğini ve ssl i sorguladığını, ssl de failed verdiğini görüyorum. sonra 3.adımda http redirect ile herşey başarılı oluyor.
aslında aşağıdaki adımları full failed verip , autodiscover redirect http adımına geçmesi gerekmiyor mu? bende 2. sırada ssl buluyor ve sonucunda outlooklar malum ssl uyarası çıkıyor. firewall-nat
1. https://domain.com/AutoDiscover/AutoDiscover.xml
2. https://autodiscover.domain.com/AutoDiscover/AutoDiscover.xml
autodiscover.domain.com iis olan sunucuyu gösteriyor
firewall-nat 80 ise iis olan sunucuya gidiyor
iis üzerinde de anlattığınız sıralı işlemler var.
tabi aynı zamanda ana domain için; aslında owa erişimi vs için, 443 & 80 portları firewall da exchange sunucuya nat şekilde.
yoksa bunumu kapatmalımıyım? denemedim
sevgiler,
29.11.2018 - 18:26
Merhaba,multi domain için ptr kaydını nasıl yapabiliriz? Bir ip için birden fazla domain kaydı yapmamız mümkün mü?
Teşekkür ederim.
11.05.2024 - 00:08
Merhaba Serhat Hocam,
Ben bu yazınızı beğenmedim… Aksine, bu yazınıza adeta vuruldum.. Arayıp bulmak istediğim tüm detayları tamda bu işin ötesinden berisinden içinde olup detayını bilmek isteyen IT Professional’lar için olabildiğince teknik detay olabildiğince akıcı bir uslup ile paylaşmısınız. Tüm seçenekler ve öneriler çok profesyonelce ele alınmış.
Bunu izniniz ile bir LinkedIn post’u olarakta paylaşacağım önümüzdeki günlerde bana mail adresime kullanabileceğime dair bir onay maili iletirseniz.
İyi Çalışmalar,
14.05.2024 - 12:01
Merhaba, blog’da yer alan yazıları dilediğiniz gibi paylaşabilirsiniz.