Active Directory Authentication Nasıl Çalışır? Kerberos Nedir?

Merhabalar,

Active Directory ile ilgili, kimlik doğrulama mimarilerine ait bilgileri daha önceki yayınlarımda paylaşmıştım. Giriş niteliğindeki bu yayınıma, aşağıdaki linkten ulaşabilirsiniz.

Windows Server Authentication Architecture-Windows Server Kimlik Doğrulama Mimarisi

Active Director Directory Services (AD DS) güvenliği, kullanıcı kimlik korumasının temeli olduğundan dolayı, her ortam için kilit noktadan bir konudur. Bir ortamdaki AD DS güvenliğinin geliştirmelerine bakmadan önce, Active Directory kimlik doğrulamasının Kerberos ile nasıl çalıştığını anlamak önemlidir. Bu makalede, Active Directory kimlik doğrulamasının, sahne arkasında nasıl çalıştığını aktarmayı uygun gördüm. Artık bir adım daha ileri taşıyıp, kimlik doğrulamanın nasıl gerçekleştiğine dair bilgiler elde edeceğiz.

Altyapıda kullanılan, farklı kimlik doğrulama protokolleri vardır. Active Directory, sunucu ile istemci arasında kimlik doğrulaması sağlamak için kimlik doğrulama protokolü olarak Kerberos sürüm 5’i kullanılır. Kerberos v5, Windows Server 2003’ten bu yana, Windows sunucusu için varsayılan kimlik doğrulama protokolü haline gelmiştir. Açık bir standarttır ve aynı standartları kullanan diğer sistemlerle birlikte çalışabilirlik sağlar.

Kerberos protokolü, diğer sistemlerin de bağlı olduğu açık bir ağda, sunucu ve istemci arasındaki kimlik doğrulamasını korumak için oluşturulmuştur. Kimlik doğrulamanın arkasındaki ana kavram, iki tarafın bir parola (secret-sır) üzerinde anlaşması ve her ikisinin de bu parolayı, kimliklerini belirlemek ve doğrulamak için kullanmasıdır.

Şimdi birkaç örnekle devam edeyim…

Aşağıdaki örnekte, Yusuf kullanıcısı ile Sunucu A’nın düzenli iletişimleri olduğunu düşünelim. Gizli verileri, kendi aralarında sık sık değiş tokuş etsinler. Bu iletişimi korumak için, veri alışverişi yapmadan önce, kimliklerini doğrulamak için ortak bir sır olan 1234 üzerinde anlaşmış olsunlar. Yusuf ilk iletişimi kurduğunda, sırrını sunucu A’ya aktarır ve “Ben Yusuf’um” der. Sunucu A, sırrın doğru olup olmadığını kontrol eder. Doğruysa, onu Yusuf olarak tanımlar ve daha fazla iletişime izin verir.

Örneğimizi bir adım ilerye götürelim…

Yusuf ve Sunucu A arasındaki iletişim, açık ağda gerçekleşir, bu da başka bağlı sistemler olduğu anlamına gelir. Örneğin Ahmet, Yusuf’un içinde bulunduğu ağa bağlı bir kullanıcı olsun. Yusuf ile Sunucu A arasındaki iletişimin de farkında. Aralarındaki veri alışverişiyle ve bunlara ortak olmakla ilgilendiğini düşünelim. Kullandıkları sırrı öğrenmek için bu iki sunucu arasındaki trafiği dinlemeye başlasın. Bulduğunda ise, Sunucu A ile iletişim kurmaya başlar, kendisinin de Yusuf olduğunu söyler ve aynı zamanda 1234 sırrını da sağlar. Sunucu A tarafından, artık her ikisi de doğru sırrı sağladığından, Yusuf ve Ahmet’den gelen mesaj arasında fark görmez. İşte bu noktada Kerberos devreye girer.

Kerberos, sırlar yerine paylaşılan simetrik şifreleme anahtarı kullanarak bu sorunu çözmektedir. Şifreleme ve şifre çözme için aynı anahtarı kullanır.

Kerberos Güvenlik Protokolü Nedir?

Kerberos, MIT (Massachusetts Institute of Technology)‘de çalışan bir grup mühendis tarafından, üzerinde çalıştıkları Athena projesi sırasında geliştirilmiştir. Protokolün ilk versiyonu, versiyon 4 olarak ortaya çıkmıştır. IT dünyasında, bazı sistem üreticileri tarafından kabul gördü ve daha sonra da, yazarları tarafından geliştirilerek versiyon 5 olarak güncellendi. Sonrasında ise, IETF (Internet Engineering Task Force) tarafından, bir bilgisayar ağını ve kaynaklarını kullanmak üzere, bu ağa bağlanma sırasında maksimum güvenliği sağlamak amacıyla kullanılacak şekilde standartlaştırılmıştır.

Kerberos adı, Yunan mitolojisinde Alt Dünyanın kapılarında nöbet tutan üç başlı, güçlü köpek olan Cerberus’tan gelmektedir. Üç başlı köpek olarak adlandırılmasının nedeni, üç ana bileşeni olduğu içindir. Bu bileşenler;

Client
Server
Anahtar Dağıtım Merkezi (Key Distribution Center)

Anahtar Dağıtım Merkezi, güvenli anahtarları dağıtan güvenilir otoritedir ve Key Distribution Center (KDC) olarak adlandırılır. Kerberos’u ayrıntılı olarak incelemeden önce, tipik anahtar değişiminin nasıl çalıştığını anlamak önemlidir.

Kerberos, iki sistem arasında paylaşılan gizli bir anahtarı kullanma esasına dayalı bir protokoldür. Temel amacı basittir: “Eğer gizli bir sır iki kişi tarafından biliniyorsa, bu iki kişi de karşısındakinin kim olduğunu, bu anahtar sayesinde bilebilir.” Örneğin askerlik yapanlar bilir, nöbetçilere bir parola bilgisi verilir. Karşıdan gelen birini gören nöbetçi , dost ya da düşman ayrımı yapmak için, parola diye sorduğunda, karşıdaki de parolaya karşılık gelen bilgiyi seslenir. Böylece aralarında bir güven ilişkisi olduğu düşünülür. Peki ya düşman, parola bilgisini etkisiz hale getirdiği askerden almayı başarmışsa? 🙂 Sadece gizli bir şifreyi aralarında paylaşmak yeterli olabiliyor mu bu durumda?

İşte bu noktada Kerberos protokolü, bahsettiğim bu problemi, gizli anahtarların şifrelenmesi tekniği ile çözmektedir. Gizli bir şifreyi paylaşmak yerine, şifrelenmiş bir anahtarı aralarında paylaşırlar ve bu anahtar sayesinde birbirlerine güvenirler. Askerlik örneğine geri dönersek, parolayı öğrenen herhangi biri, kendini dost gibi gösterebilir. İşte bu problemin aşılması için, bir tane daha bilgiye ihtiyaç vardı : “işaret”. Nöbetçilere, parola bilgisinin yanında bir de işaret bilgisi verilir. “Parola” diye soran nöbetçiye karşı taraf parolayı söyler, parola bilgisini söyleyen kişi ise “işaret” diye sorar ve nöbetçi de işaret bilgisini paylaşır. Karşılıklı ortak bir anahtar sayesinde (ki bu anahtar “işaret” olarak verilen bilgidir) güven ilişsini kurulur. Günlük bir hayattan örnekle kısaca bu şekilde açıklamak istedim…

Key Distribution Center nedir?

Yukarıda da bahsettiğimiz gibi, şifrelenmiş anahtarları dağıtan, güvenilir merkezi otoritedir. Bu anahtarlar (ticket), sistemlerin haberleşmesinin temelinde olan kriptolama fonksiyonları için önemli değişkenler olarak kullanılır. Böylece bir ağ üzerinden, şifrelenmiş mesajlaşma yapılabilir.

KDC, iki ana işlevden sorumludur.

Authentication Service (AS)
Ticket Granting Service (TGS)

Kriptolama için, tek bir paylaşılan anahtar kullanan Kerberos ile, ağa atılan kriptolanmış mesajların nasıl hazırlandığını ve alıcı tarafından bu mesajların nasıl okunabildiğini, basit şekilde aşağıdaki gibi matematiksel kavramlarla açıklayabiliriz.

Kriptolama : f (Veri, Ticket)= Kriptolanmış veri
Kriptoyu açma : f^-1 (Kriptolanmış veri, Ticket) = Veri

Windows server ağlarında, hangi hedef bilgisayara Kerberos paketi gönderilecekse, KDC’den o bilgisayar için bir ticket alır ve yukarıdaki gibi kullanırız. Böylece ağ üzerinden gönderilen veriler kriptolanmış olduğu için, sistem güvenli kabul edilir.

Güvenlik protokülünün tanımına göre KDC, fiziksel olarak güvenliği sağlanmış bir sunucu üzerinde çalışır. Burada kısaca iki temel kavramdan bahsetmek istiyorum.

REALM : Windows domainin Kerberos karşılığıdır.

PRINCIPAL : Windows domaninin’deki kullanıcıların Kerberos karşılığıdır.

KDC, kendi REALM’ındaki tüm PRICIPAL’lara ait bilgileri, kendi veritabanında tutar. Ayrıca kullanıcı kimlik bilgilerine ek olarak, sadece kullanıcının bilgisayarı ve KDC tarafından bilinen özel bir anahtarı da yaratır ve saklar. Bu anahtar, kullanıcı bilgisayarı ile KDC arasında yapılacak mesajlaşmaların güvenli şekilde kriptolanması için kullanılır.

Esasen KDC, her bir windows bilgisayarına kriptolu bağlantı kurulabilmesi için kullanılacak olan anahtarları (service ticket’ları) yaratır ve saklar. Kerberos uygulamasında, bu özel anahtarlar, kullanıcının bilgisayarının şifresinden üretilir. Şimdi bu bağlantı trafiğinin nasıl gerçekleştiğini anlatayım…

Windows Ağlarında Oturum Açma İşlemi Nasıl Gerçekleşir?

Buraya kadar anlattığım tüm bilgilerin, sistem tarafına nasıl yansıdığını bu adımda özetleyeyim. Zaten bu özetlemeyi de yaptığımızda, makalemizin konusu olan kimlik doğrulama işlemlerinin nasıl yapıldığı da iyice anlaşılmış olacaktır.

Client (İstemci), herhangi bir sunucuyla iletişime geçmek istedğinde, KDC’ye bir istek gelir ve bu ikilinin, kendi aralarında konuşabilmesi için gerekli olan anahtarlar (service ticket) elde edilir. Client’ın bu isteğine karşı getirilen iki oturum anahtarı da KDC’den client’a gönderilir. Bu işlem sırasında, client’ın oturum anahtarı, client’ın KDC ile paylaştığı özel anahtar ile kriptolanır. Sunucuya ait oturum anahtarı (service ticket) ise, client’a giden paket içerisine client’a ait bilgilerle birlikte yerleştirilir. İlgili sunucunun KDC ile paylaştığı özel anahtarı ile kriptolanan ve içinde client’a ait bilgilerin de olduğu sunucuya ait olan bu bilgiler, en son aşamada client’ın KDC ile paylaştığı özel anahtarı ile kriptolanıp KDC tarafından gönderilir.

Client, KDC’den cevap aldığında, kendine ait olan anahtarla verileri okuyabilir. Sunucuya bağlanmak istediğinde ise sunucuya, içinde sunucunun KDC ile paylaşmış olduğu anahtar ile kriptolanmış olan oturum anahtarının da bulunduğu bağlantı isteğini gönderir.

Sunucu, client’dan gelen bu isteği aldığında, kendi özel anahtarı ile kimlik bilgilerinin olduğu bölümü çözer. Client, iletişim için gerekli olan kimlik ispatlanmasının da sunucu tarafından yapılmasını istemişse, bu sefer sunucumuz client’ın gönderdiği istek içerisinden, bu isteğin oluştuğu sistem saat bilgisini de çözüp kriptolayarak client’a gönderir. Eğer problem görülmezse sunucu, client’ın güvenilir bir KDC’den kimlik bilgilerini aldığını anlar ve client da sunucuya güvenmiş olur. Böylece, bu isteğin içinden elde edilmiş olan oturum anahtarı da kullanılarak, client ile sunucu arasında bir oturum açılmış olur.

Sunucu ile client arasında gerçekleşecek haberleşmede kullanılacak bu oturum anahtarı, genellikle en fazla 10 saat boyunca bilgisayarların hafızalarında durur. Bu süre içinde bir client kapatılırsa, anahtar hafızadan silinir. Süre bittiğinde ise, aynı işlemler en baştan yapılarak yenilenir. Bu süreler group policy ayarları ile değiştirilebilir.

ÖNEMLİ NOTLAR:

Burada hemen bazı önemli notlar eklemek istyorum.

Bu yüzden, iletişime ihtiyacınız olmadığı durumlarda, sunucu üzerinden bağlantınızı, logoff dışında bir yöntemle kapatmayınız. Logoff olmadığınız sürece, arka planda oturumunuz açık kalabilir. GPO ile, max session süresini ayarlayıp, bu süre dolduktan sonra, sunucu üzerindeki tüm oturumları otomatik kapatan bir policy yazmanızı da öneriyorum.
Sistem saat bilgisinin de işleme alındığını ve Client ile sunucu arasındaki haberleşmede, sistem saat bilgisinin de kullanıldığını söyledik. Bu süre en fazla 5 dk olabilir. Eğer sunucu ile client arasındaki saat farkı 5 dk’dan fazlaysa, bağlantı açılamaz.

Kullanıcı, windows domain’ine login olduğunda da, kullanıcı bilgisayarındaki kerberos yazılımı şifresinden, kriptolu bir paket üretilir ve client’a özel bir kriptolama algoritması ile şifrelenerek gönderilir. Bu bilgi KDC’ye ulaştığında, KDC hali hazırda zaten client şifresini biliyordur. Kendinin bildiği şifre ile client’dan gelen şifreyi karşılaştırır ve kullanıcının login isteğini onaylar.

Kısacası, client ile sunucu arasında bir authentication yapılacaksa, client’ın sunucuya kriptolu olarak iletişim haline geçmesi için, öncelikle o sunucuya ait ticket’ı, KDC’den alması gerekmektedir. Buna kısaca service ticket denir.

Ticket Granting Ticket (TGT) nedir?

Domain logon işlemlerinde, client tarafından DC’nin logon servisi kullanılır. Dolayısıyla, logon işlemleri için öncelikle client tarafından DC’nin ticket’ının elde edilmesi gerekir. İşte daha ileriki safhalarda kullanılacak service ticket’ları alma sırasındaki bağlantılarda kullanılmak üzere, en başta alınan bu ilk ticket’a TGT (Ticket Granting Ticket) denir.

TGT’nin bu tanımını, aşağıdaki gibi şematize edebiliriz.

Yukarıdaki şemaya göre, domain login işlemleri şu şekilde yapılır:

Kullanıcı login isteği gönderir
Yerel Güvenlik Alt Sistemi (LSA), bu kullanıcı için bir TGT-Ticket Granting Ticket alır
Client, hangi sunucuya bağlanmak istiyorsa, Yerel Gücenlik Alt Sistemi, o sunucuya ait ticket’ı ister.
DC sunucuda çalışan Kerberos servisi, o sunucunun ticket’ının gönderir
Yerel Güvenlik Alt Sistemi, bir Access Token oluşturur ve bu token’ı, kullanıcının işlemlerine ekler

Tüm teknik işlemler kısaca bu şekilde gerçekleşir.

Şimdi ilk örneğimize geri dönelim ve ortamımıza bir de KDC sunucu eklendiğinde işlemlerin nasıl olduğunu da kısaca inceleyelim.

Senaryomuzu tekrar gözden geçirirsek, şimdi ortamda bir KDC’miz olsun. A sunucusuyla doğrudan iletişim kurmak yerine, Yusuf şimdi öncelikle KDC’ye gidiyor ve A sunucusuna erişmesi gerektiğini söylüyor. Şimdi Sunucu A ile iletişimi başlatmak için simetrik bir anahtara ihtiyacı var. Bu anahtar yalnızca Yusuf ve Sunucu A tarafından kullanılacak olan anahtardır. KDC isteği kabul eder ve bir anahtar (Key Yusuf+Server) oluşturur ve daha sonra bunu Yusuf ve Sunucu A’ya dağıtır. Oldukça basit görünebilir, ancak sunucu açısından birkaç zorluk vardır. Yusuf’dan gelen bağlantıyı kabul etmek için Key Y+S‘yi bilmesi gerekir, bu nedenle bu anahtarı Sunucu A’da saklaması gerekir, burada belki sadece bir bağlantı hakkında düşünüyoruz. Ancak, örneğin yüz kullanıcı bağlantısı varsa, içerdiği tüm anahtarları saklaması gerekir. Bu, sunucu A için kaynak kullanımının da artmasına mal olacaktır. Ancak, gerçek Kerberos protokolü işlemi bundan daha verimlidir. Active Directory ortamında KDC, etki alanı denetleyicisinin bir parçası olarak yüklenir.

Yusuf sisteme giriş yaptığında, KDC’nin tam olarak iddia ettiği kişi olduğunu kanıtlaması gerekir. Oturum açtığında kullanıcı adını “uzun zaman anahtarı” ile birlikte KDC’ye gönderir. Uzun süreli anahtar, Yusuf’in şifresine göre oluşturulur. Yusuf’in bilgisayarındaki Kerberos istemcisi şifresini kabul eder ve şifreleme anahtarı oluşturur. KDC ayrıca bu anahtarın bir kopyasını veritabanında tutar. KDC talebi aldıktan sonra kullanıcı adını ve uzun sireli anahtarını, kayıtlarıyla kontrol eder. Her şey yolundaysa KDC, Yusuf’a bir oturum anahtarıyla yanıt verir. Buna Ticket Granting Ticket (TGT) denir. (Yukarıda açıklamıştım)

Bu TGT iki şey içerir,

KDC’nin Yusuf ile iletişim kurmak için kullandığı oturum anahtarının kopyası. Bu, KDC’nin uzun vadeli anahtarıyla şifrelenmiştir.
Yusuf’un, KDC ile iletişim kurmak için kullanabileceği oturum anahtarının kopyası. Bu, Yusuf’un uzun vadeli anahtarıyla şifrelenmiştir, bu nedenle yalnızca Yusuf bunun şifresini çözebilir.

Yusuf bu anahtarı aldıktan sonra, uzun vadeli anahtarını, oturum anahtarının şifresini çözmek için kullanabilir. Bundan sonra, KDC ile gelecekteki tüm iletişim bu oturum anahtarına dayalı olacaktır. Bu oturum anahtarı geçicidir ve TTL (Yaşam Süresi) değerine sahiptir.

Bu oturum anahtarı, Yusuf’un bilgisayarının geçici belleğine kaydedilir. Şimdi Sunucu A’ya erişim talep ettiğini düşünelim. Yusuf’un KDC ile tekrar iletişime geçmesi gerekir, ancak bu sefer KDC tarafından sağlanan oturum anahtarını kullanması gerek. Bu istek, teorik konularda bahsettiğim gibi, oturum anahtarı ile şifrelenen zaman damgası olan TGT’yi ve hizmet kimliğini (sunucu A üzerinde çalışan hizmet) içeriyordu. KDC bunu aldıktan sonra, TGT’nin şifresini çözmek ve oturum anahtarını almak için uzun vadeli anahtarını kullanır. daha sonra oturum anahtarını kullanarak zaman damgasının şifresini çözer.

Değişikliği 5 dakikadan azsa, Yusuf’dan geldiğini kanıtlar ve önceki zamandan aynı istek değildir. KDC meşru bir istek olarak onayladığında, başka bir bilet oluşturur ve buna hizmet bileti (service ticket) denir. İki anahtar içermektedir; Yusuf için bir ve Sunucu A için bir tane.

Her iki anahtar da istek sahibinin adı (Yusuf), alıcı, zaman damgası, TTL değeri, yeni bir oturum anahtarı (Yusuf ve Sunucu A arasında paylaşılacan) içeriyordu. Bunun bir anahtarı Yusuf’un uzun vadeli anahtarı kullanılarak şifrelenmiştir. Diğer anahtar, Sunucu A’nın uzun vadeli anahtarı kullanılarak şifrelenir. sonunda ikisi birlikte KDC ve Yusuf arasında oturum anahtarı kullanılarak şifrelenir. En son aşamada, hazırlanan bu paket, Yusuf’a gönderilir. Yusuf, biletin şifresini oturum anahtarını kullanarak çözer. Kendisiyle, Sunucu A arasında paylaşılması gereken yeni oturum anahtarını açığa çıkarır. Ardından, KDC tarafından oluşturulan yeni oturum anahtarını kullanarak, şifrelenmiş zaman damgası olan hizmet biletinden alınan Sunucu A’nın anahtarını içeren yeni bir istek oluşturur. Yusuf, bunu Sunucu A’ya gönderdikten sonra, uzun vadeli anahtarını kullanarak anahtarının şifresini çözer ve oturum anahtarını alır. Oturum anahtarını kullanarak, isteğin gerçekliğini doğrulamak için zaman damgasının şifresini çözebilir. Gördüğümüz gibi, bu süreçte, istemcinin anahtar kullanımını takip etmek sunucu A’nın sorumluluğu ve ilgili anahtarları saklamak istemcisinin sorumluluğu değildir.

Son olarak, anlattığım tüm teorik bilgileri ve Kerberos hakkında öğrendiklerimizi, bu örneğimiz üzerinden özetleyelim.

Yusuf, kullanıcı adını ve uzun vadeli anahtarını KDC’ye (Etki Alanı Denetleyicisi) gönderir.
KDC, veritabanıyla kullanıcı adını ve uzun vadeli anahtarı kontrol eder ve kimliği doğrular. Daha sonra TGT oluşturur. KDC’nin Yusuf ile iletişim kurmak için kullandığı oturum anahtarının kopyasını içerir. KDC’nin uzun vadeli anahtarıyla bu anahtar şifrelenmiştir. Ayrıca, Yusuf’un KDC ile iletişim kurmak için kullanabileceği oturum anahtarının kopyasını da içerir.
Yusuf’a TGT ile yanıt dönülür.
Yusuf, uzun vadeli anahtarını kullanarak anahtarının şifresini çözer ve oturum anahtarını alır. Sistemi, TGT, oturum anahtarı ile şifrelenmiş zaman damgası ve hizmet kimliği dahil olmak üzere yeni istek oluşturur. Talep oluşturulduktan sonra KDC’ye gönderilir.
KDC, TGT’nin şifresini çözmek ve oturum anahtarını almak için uzun vadeli anahtarını kullanır. Daha sonra zaman damgasının şifresini çözmek için oturum anahtarı kullanılabilir. Ardından bir service ticket oluşturur. Bu bilet iki anahtar içerir. Biri sunucu A ve diğeri Yusuf için. Yusuf’un anahtarı, uzun vadeli anahtarı kullanılarak şifrelenir ve Sunucu A’nın anahtarı, Sunucu A’nın uzun vadeli anahtarı kullanılarak şifrelenir. Sonunda, her ikisi de KDC ve Yusuf tarafından kullanılan, oturum anahtarı kullanılarak şifrelenir.
Yusuf’a Service ticket gönderilir.
Yusuf, oturum anahtarını kullanarak biletin şifresini çözer ve anahtarını alır. Sonra A sunucusuyla bağlantı kurmak için kullanılabilecek yeni anahtarı almak için şifresini çözer. Sonunda, Sunucu A’nın anahtarı (5. adımda oluşturulan), Yusuf’un şifresini çözdüğü oturum anahtarıyla şifrelenen zaman damgası dahil olmak üzere başka bir istek oluşturur. Her şey hazır olduğunda, sistem onu Sunucu A’ya gönderir.
Sunucu A bağlantısına yönlendiriliriz ve uzun vadeli anahtarımızı kullanarak ve anahtarın şifresini çözerek, oturum anahtarını alırız. Daha sonra bunu kullanarak, sunucu A, isteğin gerçekliğini doğrulamak için zaman damgasının şifresini çözer. Her şey uygun olduğunda, Yusuf ve Sunucu A arasında bağlantıya izin verilir.

Yukarıdaki işlemlerin sağlıklı olarak yerine getirilebilmesi için bazı koşulların sağlanması gerekmektedir.

Connectivity – Sunucu, İstemci ve KDC’nin, istekleri ve yanıtları işlemek için kendi aralarında güvenilir bağlantıya sahip olması gerekir.

DNS – İstemciler, KDC ve Sunucuları bulmak için DNS kullanır. DNS’in düzgün çalışıyor olması ve kayıtların tam olması gerekir.

Time Synchronization (Zaman Senkronizasyonu) – Gördüğümüz gibi süreç, isteklerin gerçekliğini doğrulamak için zaman damgası kullanır. Yalnızca 5 dakikalık zaman farkına izin verir. PDC veya başka bir zaman kaynağı ile doğru zaman senkronizasyonuna sahip olması gerekir.

Service Principle Names (SPN) (Hizmet İlkesi Adları) – İstemciler, AD ortamındaki hizmetleri bulmak için SPN’yi kullanır. Hizmetler için SPN yoksa, istemciler ve KDC, gerektiğinde bunları bulamazlar. Hizmetleri kurarken, SPN’leri de kurduğunuzdan emin olun.

Çok daha detaylı olabilecek bir konu olan kimlik doğrulama konusunu, mümkün olduğunca özetlemeye ve çok fazla teoriye boğmadan aktarmaya çalıştım.

Yararlı olması dileğiyle.

Yusuf İşleyen