Bu konuyu okuduğunuzda elde edeceğiniz bazı kazanımlar içerisinde normalde kullanılan eski bir yapı olan on-prem ad ile azure ad arasındaki farkı öğreneceksiniz. Eskiye nazaran daha gelişmiş olan Azure hakkında konuşacağız. Keyifli okumalar….
Azure kimlik doğrulama servisi, uygulamalar için OAuth 2.0 ve OpenID kimlik doğrulamalarını kullanmaktadır. Mesela bir web veya mobil uygulama, kullanıcıyı Azure AD’ye yönlendirip yetkilendirme kodu ile yetki tokenları alır. Aşağıdaki görselde örneğine yer verilmiştir. Kullanıcı Entra ID’ye oturum açma isteği gönderir, Entra ID ise bir yetkilendirme kodu verir, uygulama bu kodu access token’a çevirir ve Azure üzerinde yer alan uygulamaya erişim sağlar. Bu akışta, kullanıcı tarayıcı üzerinden yönlendirme ile Azure AD’nin kimlik endpointlerine erişim sağlar.
Azure AD ile OAuth 2.0 yetkilendirme örneği (Kullanıcı kimlik doğrulayıp kod, ardından token alır. Token ile uygulamaya erişim sağlar
Azure AD’de uygulamalar iki şekilde erişim tokenı kullanabilir. Delegated (yani kullanıcı adı temelli) veya app-only (yani uygulama servis hesabı ile) olarak yetkilendirir. Şekilde bu iki senaryo örneği bulunmaktadır. Sol taraftaki Delegated access modeline kullanıcı uygulamaya oturum açar ve uygulama Microsoft Graph veya başka bir API aracılığıyla kullanıcının izinleri dahilinde yetkilerini getirir. Sağdaki görselde yer alan App-only access örneğinde ise uygulama, kullanıcı olmadan, sadece kendi servis hesabı ile arka planda çalışmaktadır. Bu iki görsel ise Azure AD’nin desteklediği iki farklı yetkilendirme sistemini gösterir.
Buna karşın geleneksel Yerel AD ortamında kimlik doğrulama işlem Kerberos servisi ile sağlanır. Kerberos servisindde ise bir kullanıcı önce KDC üzerinden kimliğini doğrulatıp bir TGT alır, ardından bu TGT’yi kullanarak istediği hizmet için bir ticket elde eder.
- Kullanıcı Authentication Server (AS) ile kimlik doğrulamayı yapar ve bir TGT key alır.
- Kullanıcı TGT keyini TGS’e göndererek ilgili hizmet için Service Ticket alır.
- Kullanıcı servis biletini ilgili servise sunarak hizmete erişir .
Azure AD, kullanıcının dışarıdan gerelerek OAuth/OIDC (OpenID Connect) tokenlarıyla kimliğini doğrulamasına izin verirken, Kerberos sadece domain içindeki kaynaklara süreli biletlerle SSO hizmeti sağlar. Ayrıca Kerberos, şifre tabanlı bu yöntemle FIDO, MFA gibi ikincil doğrulama yöntemlerini desteklememektedir.
Tekli Oturum Açma (SSO) Özellikleri
Kerberos servisinin sağladığı en iyi avantajı ise tekli oturum açma (SSO) imkani sağlamasıdır. Bir kere domain üzerinde oturum açan kullanıcı, Kerberos biletleri sayesinde aynı domaindeki diğer kaynaklara tekrar parola girmek zorunda olmadan erişebilir . Windows istemcisiyle ilk defa domaine oturum açınca kullanıcının kimliği Kerberos TGT ile onaylanır ve bundan sonraki kaynak erişimleri için Kerberos kendi kimlik bilgilerini kullanır ve her seferinde parola istemez.
Azure AD tarafında ise bulut uygulamaları ve hizmetlerde SSO, genellikle Azure AD Join ve Microsoft Entra Hybrid Join gibi cihaz kayıtları veya Seamless SSO (Azure AD özelliği) ile sağlanır. Örneğin kurum içi ağına bağlı bir cihaz kullanıcısı ekranda oturum açtığında Azure AD üzerine otomatik olarak kimliğiyle bağlanabilir; kullanıcı adını veya şifresini girmesi gerekmez . Microsoft Entra Connect aracılığıyla parola karması senkronizasyonu veya pass-through auth ayarlı ise, Seamless SSO özelliği ile kullanıcılar bir kez yerel bilgisayarlarında oturum açmışsa Azure kaynaklarına tekrar şifre yazmadan erişim sağlayabilirler. Yani Azure ortamında SSO, token tabanlı kimlik bilgisi kullanımına dayanır. Kerberos SSO ise sadece domain içindeki makinelere özgüdür ve ağa olan bağlantı gereksinimi vardır. Her iki durumda da kullanıcılar tekrar şifre girmeden birden çok kaynağa erişim elde edebilir.
Token Yapıları ve Güvenliği
Azure AD tarafından verilen Access Token ve ID Token gibi kimlik bilgileri genellikle JWT formatındadır. Bu token’larda issuer, audience, expiration gibi datalar bulunur ve Microsoft tarafından imzalanırlar. Örneğin bir web API, gelen token’ın imzasını doğruladıktan sonra audience datasınnı kendisine uygun olup olmadığını inceler ve sadece geçerli bir tokenın servis metodu çalıştırmasına izin verir. Bu mekanizma sayesinde tokenlar güvenli ve değiştirilmez şekilde iletilir.
Kerberos biletleri ise simetrik şifreleme ile korunur. KDC’dan alınan TGT ve servis biletleri, servis ile kullanıcı arasında paylaşılan şifre tabanlı anahtarlar ile şifrelenir. Kerberos biletlerinin de süresi sınırlıdır ve biletler yalnızca yetkili parçalar ile çözülebilir. Özet olarak JWT token ile Kerberos biletleri farklı temeller ile kontrol altına alınmış kimlik bilgileridir; JWT’da imzalama, Kerberosta şifreleme/kilit anahtarları kullanılır
Kerberos protokolü adımlarını tekrar gözden geçirecek olur isek
- Kullanıcı Authentication Server’a kimlik bilgilerini gönderir ve Ticket Granting Ticket (TGT) alır.
- Kullanıcı TGT’yi Ticket Granting Service (TGS)’e göndererek ilgili hizmet için Service Ticket alır.
- Kullanıcı, servis biletini ilgili uygulamaya sunarak hizmete erişim sağlar.
Token yapısı ve güvenliği açısından ele aldığımızda, Azure AD tokenları doğrudan doğrulanırken (JWT imzalar ve içindeki datalar ile), Kerberos biletleri arka planda KDC tarafından şifrelenir ve istemci tarafında kullanıcı şifresi ile üretilmiş bir anahtarla çözümlenir. Böylece her iki sistem de kimlik bilgisi sorunsuz ve güvenlii taşınır fakat Azure AD’nin JWT tabanlı tokenları internet üzerinden kolayca gönderilirken, Kerberos biletleri yalnızca domain içerisinde kullanılır.
Azure AD Connect, Pass-through Auth, Federation)
Hibrit yapılarda Azure AD Connect ile kurum içi AD DS ile Azure AD senkronizasyon yapılır. Bu süreçte genelde 3 yöntem tercih edilir.
- Parola Hash Senkronizasyonu (PHS): Kullanıcı şifrelerinin hashleri düzenli olarak Azure AD’ye gönderilir. Kimlik doğrulama Azure üzerinde yapılır. Ekstra olarak on-prem sunucuya ihtiyaç duyulmaz. Kurum içi ağ kapalı olsa bile önceden senkronize edilen parolalarla oturum açılır. Bu yöntem en az gereksinim gerektirir.
- Pass-through Authentication (PTA): Kullanıcı Azure AD’ye giriş yapmak istediğinde parola kontrolü Azure’a iletilir ve arka planda kurum içindeki Azure ajanı ile Active Directory’de doğrulanır. Yani şifre doğrulama kurum içinde gerçekleşir. Böylece AD içindeki şifre politikaları direkt uygulanır. Ancak on-prem bağlantısı koparsa oturum açma işlemi başarısız olur.
- Federasyon (AD FS): Azure AD, oturum açma akışını tam olarak kurum içindeki ADFS gibi bir kimlik sağlayıcısına yönlendirir. Kullanıcı tarayıcısı doğrudan kurum içi ADFS sunucularına bağlanır ve ADFS üzerinden kimlik doğrulaması yapılır. Bu sayede kuruluş kendi çok faktör doğrulama veya özel oturum açma senaryolarını (örneğin yalnızca iç ağdan giriş, mfa, usb auth vb.) aynen devam ettirebilir.
- Parola hash’leri Azure AD’ye senkronize edilir. kimlik doğrulama bulutta yapılır. Kullanıcılar Azure AD kimlik bilgileri ile oturum açar, ek sunucu gerekmez.
- Parola doğrulama, kurum içindeki Azure AD Connect ajanı üzerinden on-prem AD’de gerçekleşir. Bu sayede kurum içi parola politikaları hemen uygulanır.
- Azure AD, kullanıcıyı kurum içindeki ADFS gibi güvenilen bir kimlik sağlayıcısına yönlendirir. Kuruluş, mevcut MFA veya özel kimlik protokollerini kullanmaya devam edebilir.
Bu yöntemlerin teknik farklılıkları PHS en az alt yapı ile çalışır (sadece Azure AD Connect), PTA’da yerel domain içinde ajan sunucuları gerekir, Federasyon’da ise bir ADFS altyapısı ve proxy sunucular konfigüre edilir. PHS ve PTA durumlarında Microsoft Entra Join veya Hybrid Join cihazları ile kullanıcı deneyimi özelleştirilebilir. Mesela Seamless SSO birleştirilebilir. Federasyon senaryosunda ise oturum açma tamamen kurum içi AD FS ortamında gerçekleşir.
Conditional Access ve MFA Desteği
Azure AD’nin temel güvenlik özelliklerinden biri Conditional Access’dir. Conditional Access, kullanıcı, cihaz, lokasyon gibi çeşitli filtreleri (kullanıcı grubu, IP adresi, cihaz uyumluluğu, konum) ele alarak “if then” tipinde kurallar uygular. Örneğin, bir kullanıcı ofis dışından Microsoft 365’e bağlanmak istediğinde MFA istenmesi veya belirli ülke IP’lerinden engellenmesi gibi politikalar Conditional Access ile sağlanmaktadır. Microsoft buna “Zero Trust Policy Engine” diyor. Sistem, gelen logları sürekli ele alıp erişimi en uygun insiyatifler ile sağlar. Görselde Azure AD’nin Defender for Identity, Endpoint Manager, Defender for Cloud gibi altyapılardan aldığı parametreler ile koşulları uyguladığı gözüküyor.
Bu sayede örneğin, kullanıcı kuruluş dışından bağlanmaya çalışsa bile örneğin MFA zorunlu kılınabilir. On-prem AD DS’nin kendi başına böyle insiyatif alabileceği bir sistemi yoktur. Sunucular bazında 3. parti araçlar sayesinde veya AD FS ile sınırlı MFA entegrasyonları gerekir.