HTTP - Nass oluyor da oluyor? HTTP Windows Authentication

Mümkün olduğunca yaygın olarak bahsedilmeyen , bilinmeyen,detay verilmeyen konuları yazmaya çalışıyorum.Gelelim en karmaşık IIS kimlik doğrulama (authentication) yöntemine. Windows Authentication, Integrated Windows Authentication, NTLM Authentication, Kerberos Authentication gibi isimlerle anılır kendisi. IIS'in domain ortamında bulunması ve çalışıyor olmasını gerektirir,burası önemli. IIS web sunucusunun veya istemcinin domainde olup olmaması çok da önemli değil ama kimlik doğrulaması Active Directory'den yapılacağı için zırt pırt ortaya çıkan kullanıcı adı/parola pencereleriyle boğuşmak istemiyorsanız ( bu bilgileri kaydetmek te mümkün ama önerilmez ) hem sunucuyu hem istemciyi paşa paşa domaine dahil ederek kullanın. Avantajı ne bu yöntemin ? Basic ve digest authentication yöntemlerinde olduğu gibi kullanıcıya kullanıcı adı/parola penceresi sunmadan kullanıcı kimlik bilgilerini NTLM ya da Kerberos protokolleriyle alırsınız. Ayrıca bu yöntemle kullanıcı parolası değil de parolanın hash i yine kodlanarak gönderilir, bu da oldukça güvenli, açıkları yok mu var ama şimdilik dijital sertifikalardan sonraki en güvenli kimlik doğrulama yöntemlerinden biri. NTLM bildiğiniz gibi yerini Kerberos'a bıraktı ama Kerberos protokolü desteklenmediği durumlarda hala kullanılıyor. NTLM kısaltmasından bir dönem nefret etmiştim, kendisini güvenlik konusunda çok bilgili sanan ve bir bankanın güvenlik bölümün müdürlüğünü yapan ismi ve cismi lazım olmayan bir şahsın ağzından çıkan her cümlede kullanıldığı için :D ( en-ti-el-em otantıkeyşıın şeklinde)

Derin bir nefes alın, çayınızı kahvenizi hazırlayın, bu yazı çok uzun ve sıkıcı olacak, kafalarımız da allak bullak. Örneklendireceğim HTTP trafikleri yine 2 sanal makine (biri Windows 2008 diğer XP Pro) arasındaki iletişimi gösteriyor.
Önce IIS tarafında eksik bileşenleri yükleyelim

ve Default Web Site'ı "Windows Authentication" ile kimlik doğrulaması yapılacak şekilde yapılandıralım

IIS hazır. Şimdi IIS sunucu ile aynı domaindeki XP istemci bilgisayardan default web site'a erişip trafiği inceleme zamanı. Eğer web sitesini sunucunun hostname'i ya da FQDN dediğimiz domaindeki tam adıyla çağırmazsanız, bu IP'nin Active Directory'de kayıtlı SPN'i olmadığı için aşağıdaki ekran görüntüsündeki gibi kullanıcı adı/parola kutucuğuyla karşılaşırsınız -ki bu da istemediğimiz birşey- ve Kerberos Authentication kullanılmaz,onun yerine NTLM Authentication kullanılır.

Bizim istediğimiz ise şu; web sunucusunun korumalı alanına ulaşmaya çalışalım ama web sunucu kullanıcı bilgilerimizi arka tarafta browser'dan alsın, bizi böyle kutucuklarla uğraştırmasın. Bunun için web sitesine, siteyi barındıran sunucu ismiyle ve Kerberos Authentication protokolüyle erişiyoruz

Sıra arka tarafta cereyan eden trafiği incelemeye geldi.

192.168.227.133 istemci (XP Pro)

192.168.227.128 sunucu (Windows 2008) IP adresleri

Kerberos

Klasik 3-way handshake'den sonra istemci XP bilgisayardan ilk HTTP GET Request sunucuya gönderiliyor

Sunucu, istemciye gönderdiği HTTP Response'da "güzel kardeşim bu sayfaya elini kolunu sallayan erişemez, authentication diye birşey var ayıp oluyor, Kerberos destekliyorsan devam edelim, NTLM destekliyorsan bana bi zahmet kullanıcı adı/parola gönder ( 1 Numara ) , ikisini de yapmam diyorsan ya da vazgeçtiysen bu sayfayı gösterebilirsin ( 2 Numara) " der. "WWW-Authentication" header'daki "Negotiate" terimi NTLM ve Kerberos'u kapsayan bir protokol olarak düşünülebilir.

Bunun üzerine istemci aynı web sitesine erişme isteğini tekrarlar ama bu defa InitializeSecurityContext() fonksiyonuyla NegTokenInit (istemciden sunucuya gönderilen negotiation token) denen bir initialization token oluşturur,bu tokenı base64 ile kodlanmış şekilde "Authorization" header'ı içinde gönderir. 

Bu HTTP Request'i taşıyan pakete Wireshark ile daha detaylı bakarsak ( aynı bilgiyi Fiddler da gösterir ), Authorization Header'da Kerberos-5 kullanıldığını görebiliriz. Ayrıca token içinde istemcinin desteklediği güvenlik mekanizmaları,domain adı, sunucu adı gibi bilgiler de bulunur.

NegTokenInit tokenını Authorization header içinde alan web sunucu Authorization Header'daki NegTokenInit tokenini decode eder (base64 decode), güvenlik mekanizmalarını kontrol eder ( MechType) daha sonra MechToken verisini paketten çıkarır ve gss_accept_security_context() fonksiyonu ile bu token'i doğrulamaya çalışır. gss_accept_security_context() foniksiyonu "GSS_S_COMPLETE" değeri döndürürse ne ala, sunucu istemciye HTTP 200 koduyla istediği sayfanın kodlarını iletir, ama fonksiyon "GSS_S_CONTINUE_NEEDED" sonucu verirse sunucu, istemciden doğrulamayı yapmak için gerekli tüm veriyi alana kadar istemciye 401 Unauthorized koduyla cevap gönderir. Bu Kerberos Authentication'da pek rastlanmayan bir durum. İstemci de, sunucunun 401 koduyla gönderdiği cevabın "WWW-Authenticate" header'ındaki negTokenTarg (negotiation Token returned by target) 'ı alır sunucu "GSS_S_COMPLETE" sonucu gönderene kadar eksik veriyle birlikte "Authorization" header'da gönderir. Aşağıdaki ekran görüntüsü sunucunun cevabını gösteriyor

Fonksiyon, yukarda belirtilen iki sonuç dışında sonuç verirse - ki bu yüksek ihtimalle hata anlamına gelir - istemciye erişimin engellendiğine dair bir cevap döndürür. Bu karman çorman hadisenin adı ise "SPNEGO Token Handshake".

 Kerberos'la NTLM arasındaki bir fark da şu, Kerberos ihtiyacı olan bilgiyi tek seferde bu yukardaki ekran görüntüsünde görülebileceği gibi uzunca bir tokenla alırken NTLM bu bilgileri alana kadar istemciye 401 Unauthorized cevabı gönderir. Yani Kerberos'da trafik

istemci -- (HTTP Request) --> sunucu

istemci <-- ( 401 Unauthorized ) -- sunucu

istemci -- (HTTP Request / Authorization Header ) -->sunucu

istemci <-- (HTTP Response 200 OK) -- sunucu

şeklinde cereyan eder.

İncelemek isteyenler Pcap (Packet Capture) dosyasını buradan indirebilir, wireshark'la inceleyebilir.

NTLM

Kerberos'u yazarken dağıldım, NTLM'i bir başka gün anlatacağım.

İlgili Yazılarım
HTTP - Nass oluyor da oluyor? 3-way-handshake
HTTP - Nass oluyor da oluyor? HTTP Headerlar ve HTTP Mesaj Yapısı
HTTP - Nass oluyor da oluyor? HTTP Basic Authentication
HTTP - Nass oluyor da oluyor? HTTP Digest Authentication
HTTP - Nass oluyor da oluyor? HTTPS - HTTP over SSL