Exchange Server Kimlik Doğrulama Yöntemleri

Exchange Server kimlik doğrulama yöntemleri Outlook Web Access ve Outlook Anywhere olmak üzere ikiye ayrılır.

Bu yöntemlerden sık kullanılanı Outlook Web Access’tir.

Outlook Web Access (OWA) İçin Kimlik Doğrulama Yöntemleri

Web Üzerinden Outlook için kimlik doğrulama yöntemleri incelenecek olursa seçilebilecek birkaç farklı kimlik doğrulama yöntemi mevcuttur. Bu yöntemler:

Basic Authentication:

Bu yöntem kullanıcılara temel olarak bir kullanıcı adı ve parola penceresi sunar ve kullanıcıdan bu bilgileri ister. Bu bilgiler clear text olarak gönderilir fakat bu bağlantının güvenliği HTTPS ile sağlanır. Basic Authentication çok fazla kullanıcı dostu değildir ve günümüzde Outlook on the Web erişimi için çok fazla kullanılmaz.

Integrated Windows Authentication:

Bu yöntem aktif olduğunda kullanıcıları mevcut durumda makine üzerindeki oturum açma bilgileri otomatik olarak kullanılır ve kullanıcı adı parola bilgileri sorulmadan Outlook on the Web üzerinde oturum açma işlemi gerçekleştirilir. Bu işlemin gerçekleştirilebilmesi için Outlook on the Web URL adresinin internet tarayıcı ayarlarında Intranet veya Trusted Site Zones bölümünde ekli olması gerekir. Hashlenmiş kullanıcı ve parola bilgileri HTTPS kullanılarak ağda güvenli bir şekilde iletilir.

Form-based Authentication:

Bu yöntem aktif olduğunda kullanıcılar için bir oturum açma form ekranı sunulur. Kullanıcı oturum açma bilgilerini form ekranına girdiği için bilgiler clear text olarak gönderilir fakat HTTPS ile güvenli hale getirilir. Bu yöntemde kullanıcı bilgileri birden fazla formatta girilebilir. Bu formatlar aşağıdaki gibidir.

Domain\Kullanıcı Adı
E-posta adresi (UPN)
Kullanıcı Adı

Exchange Control Panel (ECP)

Exchange Control Panel (ECP), Web Üzerinden Outlook ile yakında ilişkilidir. Exchange Control Panel, Web Üzerinden Outlook kullanıcıları için kullanıcı arabirimi seçenekleri sunar. Böylece posta kutusu seçeneklerinde veya Web Üzerinden Outlook seçeneklerinde yapılacak değişiklikler buradan yapılır. Ayrıca Exchange Server’ın web tabanlı yönetimini gerçekleştirirken sistem yöneticileri için Exchange Admin Center (EAC)’ye de hizmet vermektedir.

Exchange Control Panel kimlik doğrulama yapılandırmaları Web Üzerinden Outlook yapılandırmaları ile aynı olmalıdır.

Birden fazla sunucu bulunan ortamlarda aynı kimlik doğrulamasını aynı alan adını paylaşan tüm sunuculara dağıtılması önemlidir. Bu yapılmazsa kullanıcıların bağlandığı sunucuya göre kimlik doğrulama yöntemi farklı olacaktır. Böyle durumlarda ortamda yük dengeleyici (Load Balancer) kullanılıyorsa kullanıcı ilk bağlandığında e-posta adresi istenilip sonraki bağlantısında kullanıcı adı bilgisi istenme olasılığı bulunmaktadır.

Outlook Anywhere İçin Kimlik Doğrulama Yöntemleri

Exchange Server’da Outlook Anywhere için varsayılan kimlik doğrulama yöntemleri aşağıdaki gibidir.

ExternalClientAuthenticationMethod -> Negotiate : Varsayılan olarak Negotiate kullanılır. Kerberos kimlik doğrulaması başarılı bir şekilde kullanılamıyorsa NTLM’e geri döner.

InternalClientAuthenticationMethod -> NTLM : NTLM varsayılan olarak kullanılır.

IISAuthenticationMethods -> Basic, NTLM, Negotiate : Outlook Anywhere’in kullanıldığı IIS Virtual Directory için Basic, NTLM ve Negotiate yöntemlerinden biri varsayılan olarak kullanılır.

Exchange Server 2016 sürümünden itibaren ortamda MAPI over HTTP varsayılan olarak etkindir ve bağlantılar MAPI over HTTP üzerinden yapıldığından istemciler Outlook Anywhere yerine bunu kullanır. Bu nedenle MAPI over HTTP kasıtlı olarak devre dışı bırakılmadıkça veya MAPI over HTTP desteklemeyen bir istemci ile bağlantı kurulmuyorsa ortamda Outlook Anywhere kullanılmaz.

Internal ve External Authentication yöntemlerinin çalışma mantığı ise şu şekildedir. Negotiate Kerberos’u dener ve çalışmazsa NTLM’e dönüş yapar. Outlook Anywhere’in aynı hostname’e sahip olan iç ve dış hostname’ler varsa yalnızca Internal Authentication Method kullanılır. Çünkü istemci yaptığı iç veya dış bağlantı arasındaki farkı belirtemediğinden yalnız Internal olanı kullanır. Yalnızca external bağlantılar için temel kimlik doğrulaması gibi farklı kimlik doğrulama yöntemlerini kullanma gereksinimi varsa ve bu bağlantıların ön kimlik doğrulamasını yapan bir Load Balancer ya da Proxy varsa ayrı alan adları kullanılması gerekir (örneğin dış bağlantılar için mail-external.emres.com, iç bağlantılar için mail.emres.com). Kullanıcıların bu alan adlarını bilmelerine gerek yoktur. Bu alan adları Autodiscover tarafından işlenir ve Outlook istemcileri bu iç ve dış alan adlarıyla otomatik olarak yapılandırılır. Önemli olan Outlook Anywhere için internal ve external olarak kullanılan adların ikisi için de SSL sertifikası gerektiğidir.

Kerberos Authentication

Bu metodun yapılandırılması şart değildir fakat önerilir. Öncelikle NTLM kimlik doğrulama sürecinin nasıl işlediğine göz atacak olursak istemci erişim için alan adına bağlanır ve oturum açma isteğini Exchange Server’a gönderir. Exchange Server bir kimlik doğrulama yöntemi ile karşılık verir. Exchange Server aldığı bilgileri Active Directory veritabanıyla iletişime geçerek kontrol eder. Bilgiler doğruysa erişim izni verilir değilse erişim reddedilir. Erişim yapan istemci sayısı arttığında ya da ortama başka bir Exchange Server eklendiğinde tüm bu isteklerin eşit olarak dağıtılması için bir yük dengeleme mekanizması yoktur ve bu durum isteklerin geldiği Domain Controller’da darboğaz oluşturabilir.

Kerberos authentication yönteminin çalışma mantığı daha farklıdır. İstemci ticket almak için bir Key Distribution Center (KDC)’ye bağlanır. İstemci erişim alan ağına bağlanmak istediğinde erişim sağlamak için bir ticket talebinde bulunur. Buraya kadar istemci herhangi bir servis için doğrulanmamış olur. İstemci bu noktada Client Access Namespace’e (mail.emres.com) bağlantı sağlamak ister. Bu nedenle ticketı servis için hedef sunucuda ister. Hedef sunucu KDC servisi sadece bağlanılacak sunucunun şifresini çözebilmesi için bir ticket iletir. İstemci erişim istemek için bu ticketı Exchange Server’a iletir. Bu ticket servis (mail.emres.com) içindir. Fakat sunucu EXC201601’dir. Sunucu bu servis ticketını çözemez. Bu nedenle istemci NTLM olarak süreci tekrar dener ve Kerberos kimlik doğrulaması kullanılamamış olur. Bu durumun çözümü istemci erişim adları için servis adlarının (SPN) (http/mail.emres.com ve http/autodiscover.emres.com) kaydedilmesidir. Fakat aynı SPN birden fazla Active Directory bilgisayar hesabı için kaydedilemez. Yani load blancer arkasında birden fazla Exchange Server sunucusu varsa Kerberos kimlik doğrulaması yine başarısız olur. Bunun çözümü ise SPN’leri Alternate Service Account (ASA) olarak bilinen ayrı bir bilgisayar adına kaydetmektir. Her bir Exchange Server sunucusu ASA bilgisayar hesabı için paylaşılan bir kimlik bilgisi ile yapılandırılır. İstemci erişim isteğinde bulunmak için Exchange Server’a bir ticket sunduğunda Exchange Server ticket’ın şifresini çözmek için paylaşılan kimlik bilgisini kullanır ve Kerberos kimlik doğrulama işlemi erişim isteğini kabul eder ya da reddeder.

Genel olarak Kerberos kimlik doğrulama süreci daha hızlıdır ve NTLM ile benzer sorunlara neden olmaz. Bu nedenle Exchange Server ortamları için önemlidir.

Faydalı olması dileğiyle…