Bir önceki bölümde NAP Clinet ayarlarıiçin GPO yapılandırmasınıyapmıştık. Bu noktadan sonra NAP ortamıhazır sayılır. Artık Client üzerindeki ayarlara geçebiliriz.
Bu Bölümde Client üzerindeki testlere başlıyoruz. NPS01 üzerindeki yapılandırmalar esnasında bazınoktalarıbilerek atlamıştım. Bu ayarlarıclient testleri sırasında yapacağız. Böylece kilit noktalarıdaha iyi kavrayabileceksiniz.
Yeni kurulmuş bir Windows Vista Business Edition ile testlere başlıyoruz.
Vista kurulumundan sonra ilk kez oturum açtığımızda, “Select your computer’s current location†penceresinde “Work†seçeneği ile devam etmeyi unutmayın.
Bu, bilgisayarımızıiş ortamında kullanacağımız anlamına geliyor ve Work ortamına uygun profili almayısağlıyor (güvenlik duvarıvs.. ayarlarıiçin.)
Öncelikle Local Area Connection özelliklerine geliyoruz ve IPv6 öğesini devre dışıbırakıyoruz.
Ayrıca IPv4 için Obtain an IP address automatically ve Obtain DNS server address automatically seçili olduğundan emin oluyoruz.
Bu ayarlar doğrultusunda ve normal bir network yapısında, client-130 bilgisayarının DHCP den TCP/IP ayarlarınıalmış olmasıve network’teki kaynaklara erişebilir durumda olmasıgerekirdi.
En azından PING isteği gönderebiliyor olmasıgerekirdi (yanıt dönmese bile)
Çünkü Windows server 2003 üzerinde hizmet veren DHCP servisi, kendisinden IP isteyen clinet’ların kim olduğunu kontrol etme yeteneğine sahip değildi. Her gelen yeni bilgisayara, aynıdoğrultuda TCP/IP bilgisi atar, gerisine karışmazdı.
Windows Server 2008 üzerinde çalışan ve NAP kontrolü için yapılandırdığımız DHCP servisi ise, çok daha yetenekli ve kontrolcü bir kimlik kazanmış durumda.
şimdi Client-130 bilgisayarının ağa erişim durumunu kontrol edelim.
Öncelikle main-dc yani 192.168.5.10 server’ımıza ping atarak sonucu izliyoruz.
Start> Run> cmd ile açılan pencerede ping 192.168.5.10 yazıyoruz ve enter yapıyoruz.
Dönen yanıt aşağıdaki gibi olacaktır.
PING: transmit failed, error code 1231.
Gördüğünüz gibi main-dc server’ına ping atamıyoruz. Bunun nedeni main-dc üzerindeki bir güvenlik önlemi yada benzer bir durum değil, tamamen NAP ortamının sağlamış olduğu bir kontroldür.Â
Bu durum, network içerisindeki diğer IP adresleri ve sistemlere erişmek isteyince de aynıdır.
Peki Clinet-130 bilgisayarının IP adresi nedir? Acaba doğru IP adresini almışımıdır?
Hemen Clinet-130 IP bilgisine bakıyoruz.
AynıCMD ekranında IPCONFIG yazıyoruz ve enter yapıyoruz. Çıktıaşağıdaki gibi olacaktır.
Gördüğünüz gibi 192.168.5.100 olarak DHCP den IP adresi almış ama alt ağ maskesi 255.255.255.255 . Yani herhangi bir network ü temsil etmiyor. Bu nedenle 192.168.5.10 server’ınıpingleyemedi.
IPCONFIG çıktısında bir başka dikkat çeken nokta ise, Connection-specific DNS Suffix olarak restricted-zone.test.local yazıyor olması. Hatırlarsanız bu DNS Suffix’i, ağımıza kısıtlışekilde erişecek client’lara atanmasıiçin belirlemiştik.
Toparlarsak; Client-130 bilgisayarıDHCP sunucumuzdan IP adresi almış ama şu an kısıtlıalanda bulunuyor ve ağ kaynaklarına hiçbir şekilde erişemiyor.
Client-130’u ağımıza erişmek isteyen herhangi bir bilgisayar gibi düşünebilirsiniz. Bu, misafirlerimizin notebook’larıolabileceği gibi ağa yetkisiz olarak erişmek isteyen birileri de olabilir.
Peki Client-130 bilgisayarıneden şu an kısıtlıalanda bulunuyor? Ve nasıl ağımıza erişmesini sağlayacağız?
Clinet-130’un kısıtlıalanda bulunmasının temel nedeni, henüz NAP kontrolüne tabi tutulamamış olması.
Dikkat edin NAP kontrolünden başarılışekilde geçemediği için demiyorum. NAP kontrolüne tabi tutulmadığıiçin diyorum çünkü henüz tam anlamıyla NAP kontrolü yapılmadı.
Hatırlarsanız NAP gerekliliklerinin (SHVs yapılandırmasında belirlediğimiz) kontrolünün yapılmasıiçin, Clientt üzerinde çalışmasıve tanımlanmış olmasıgereken 3 temel nokta vardı.
ï‚·Â Â Â Â Â Â Â Â NAP enforcement clients
ï‚·Â Â Â Â Â Â Â Â NAP Agent service
ï‚·Â Â Â Â Â Â Â Â Security Center user interface
Öncelikle bu 3 ayarın Client-130 üzerinde tanımlıolmasıgerekiyor ki NAP kontrolü yapılabilsin. Bu 3 ayar tanımlandıktan sonra; bu seferde diğer gerekliliklerin uygunluğu kontrol edilecek (SHVs tanımları) ve uygunsa tam erişim verilecek, değilse kısıtlıalanda kalmaya devam edecek.
Peki Client üzerinde bu tanımlarınasıl yapacağız?
NAP kontrolü için gerekli bu ayarları, Client üzerinde, local policy ayarlarıile yapabiliriz. Ama örneğin 50 client’ımız varsa, local policy ile uğraşmak çok anlamsız olur. Ä°şte tam bu noktada devreye Remediation Server lar giriyor. Bu gurupta tanımlayacağımız serverlar, ağa erişmek isteyen client’lara yardımcıolacak.
(Hatırlarsanız NAP yapılandırmasısırasında Remediation Server yapılandırmasınıatlamıştık. Remediation Server ‘ıaz sonra yapılandıracağız ve ne işe yaradığınıdaha iyi kavrayacaksınız.)
Örnek yapımızdaki Client-130 üzerinden gidersek; bu Client’a, ağa erişmesi için nasıl yardımcıolabiliriz bir bakalım.
Hatırlarsanız NAP Clinet Ayarları isimli bir policy oluşturmuştuk. Bu policy NAP kontrolü için gerekli olan 3 temel özelliği aktif yapıyordu (NAP Client Settings).
Eğer ki bu policy ayarınıağa erişmek isteyen clinet’a uygulayabilirsek, gerekli olan 3 temel özelliği aktif yapmış oluruz ve client’ın NAP kontrolüne girmesini sağlayabiliriz.
Biliyorsunuz ki GPO ayarlarıdomain’e dahil olan bilgisayarlara uygulanabilir. Bu nedenle, öncelikle Client-130 bilgisayarınıdomain’e almamız gerekiyor. Bunun için de, öncelikle DNS ve DC hizmeti veren, yani main-dc server’ına erişmesini sağlamamız gerekiyor.
Bu noktada main-dc server’ınıRemediation Server olarak tanımlayacağız. Clinet’ların bu gurup altındaki serverlara yada makinelere (NAP kontrolünden geçememiş olsalar dahi) erişimleri olacak.
Client-130’u, Main-dc’e eriştikten sonra domain’e join edebileceğiz. Böylece GPO ayarlarınıalmasınıve NAP kontrolüne girmesini sağlayacağız.
dc-main server’ınıRemediation Server olarak tanımlamak için aşağıdaki adımlarıizliyoruz.
NPS01 üzerinde start> run> nps.msc konsolunu açıyoruz.
Policies altında Network Policies ‘e geliyoruz ve NAP DHCP Non NAP-Capable ‘a çift tıklıyoruz.
Açılan pencerede Setings tabına geçiyoruz ve NAP Enforcement ‘a gelip Remediation Server Group and Troubleshooting URL altında Configure diyoruz.
Gelen pencerede New Group tıklıyoruz.
Gelen pencerede guruba bir isim veriyoruz ve Add diyoruz. Bu gurup altında birçok Remediation Server toplayabiliriz.
Add dedikten sonra gelen pencerede, Remediation Server olarak görev yapacak serverlarıgiriyoruz.
Bizim yapımızda main-dc olacak. Remediation server’ın Windows Server 2008 çalıştırmasıgibi bir gereklilik yok.
Ok dedikten sonra Remediation Servers and Troubleshooting URL penceresine geri dönüyoruz ve oluşturduğumuz gurubun Remediation Servers Group altında seçili olduğundan emin olduktan sonra OK diyerek pencereleri kapatıyoruz.
Aynıişlemi NAP DHCP Noncompliant için de yapıyoruz. Tekrar Policies altında Network Policies ‘e geliyoruz ve NAP DHCP Noncompliant ‘a çift tıklayarak açıyoruz.
Açılan pencerede Setings tabına geçiyoruz ve Configure butonuna tıklıyoruz.
Gelen pencerede; Remediation Server Group olarak açılır listeden RS-Group1 seçiyoruz ve OK ile onaylayarak pencereleri kapatıyoruz. (RS-Group1 ‘i önceden tanımladığımız için tekrar tanımlamıyoruz, sadece listeden seçiyoruz.)
Böylece her iki durumdaki (Non NAP-Capable ve Noncompliant) client’lar içinde Remediation Server tanımlamış olduk. şimdi tekrar Client-130 bilgisayarına geliyoruz ve
start> run> cmd aracınıaçıp ipconfig /renew diyerek DHCP ye bir IP isteği gönderiyoruz.
Ardından Remediation Server olarak tanımladığımız main-dc makinesine ping atmayıdeniyoruz.
Ping 192.168.5.10
Ping cevabıaşağıdaki gibi olacaktır.
Gördüğünüz gibi artık 192.168.5.10 server’ınıpingleyebiliyoruz. ipconfig komutu ile IP yapılandırma bilgisini alalım ve bir değişiklik var mıgöz atalım. Çıktıaşağıdaki gibi olacaktır.
Gördüğünüz gibi değişen bir şey yok. Client-130 hala kısıtlıalanda bulunuyor. Main-dc’ye erişebilmesinin nedeni, bu server’ıRemediation Server olarak belirlememizdir. Client-130, ağ içerisindeki diğer kaynaklara hala erişemiyor.
Evet, artık main-dc ye erişebildiğimize göre Client-130 bilgisayarınıdomain’e join edebiliriz.
Normal bir join işlemi ile Clinet-130’u test.local domain’ine alıyoruz. Domain join işleminden ayrıca bahsetmiyorum.
Client-130’u domain’e aldıktan sonra, main-dc üzerinde active directory yönetim konsolunu açıyoruz ve Client-130 bilgisayar hesabını, NAP Computers gurubuna üye yapıyoruz.
Hatırlarsanız oluşturmuş olduğumuz NAP Client Ayarları isimli GPO yu, gereksiz makinelere etki etmemesi için, yalnızca NAP Computers gurubuna üye bilgisayarlara etki edecek şekilde filtrelemiştik. Bu nedenle Client-130 bilgisayar hesabını, Active Directory içinde NAP Computers gurubuna üye yapıyoruz ve Client-130’u restart ediyoruz. Clinet-130 açıldıktan sonra, domain’de yetkili bir hesap ile oturum açıyoruz.
Biraz beklerseniz ilk olarak aşağıdaki gibi bir uyarıgöreceksiniz.
Bu noktada GPO ayarlarının başarılıbir şekilde uygulandığınıkabul edebiliriz çünkü NAP kontrolü yapılmış ve uygun olmadığıbilgisi verilmiş. Hemen arkasından aşağıdaki gibi bir uyarıgelecektir.
Bu uyarıgeldiğinde, NAP kontrolünde başarılıolamayan Client-130 üzerinde otomatik iyileştirme işlemi yapıldığınıve uyumlu hale getirildiğini anlayabiliriz. Biz yinede GPO ayarlarınıbir kontrol edelim.
Start> run> cmd ile komut satırınıaçıyoruz ve aşağıdaki komutu giriyoruz.
netsh nap client show grouppolicyÂ
Çıktıaşağıdaki gibi olacaktır.
Gördüğünüz gibi DHCP Quarantine Enforcement Client için belirlemiş olduğumuz Enable ayarı, doğru şekilde uygulanmış. Yine CMD komut satırında aşağıdaki komutu giriyoruz.
netsh nap client show state
Çıktıaşağıdaki gibi olacaktır.
DHCP Quarantine Enforcement Client altında Initialized durumunun Yes olduğunu görüyoruz. Evet sonuçlar bu şekilde ise, GPO ayarıbaşarıile uygulanmıştır.
GPO ayarlarıbaşarılıbir şekilde uygulandığına göre, artık Clinet-130 bilgisayarıNAP kontrolü için uygun hala gelmiş demektir ki bu kontrol GPO ayarlarıuygulandıktan hemen sonra yapıldıbile.
Toparlarsak; NAP kontrolü için gerekli olan tanımlarıGPO üzerinden Clinet-130’a uyguladık. Bu GPO ayarlarıClinet-130 üzerinde aktif olduktan sonra sistem NAP kontrolüne girdi. NAP kontrolünde zorunlu koştuğumuz güvenlik duvarının açık olması koşulu kontrol edildi ve Clinet-130 ağa tam erişim hakkıkazandı. Çünkü üzerinde güvenlik duvarıaçık durumda.
Ipconfig ile IP yapılandırmasınıkontrol ediyoruz. Çıktıaşağıdaki gibi olacak.
Gördüğünüz gibi Clinet-130, artık kısıtlıalanda değil ve 255.255.255.0 subnet mask’ına sahip. Yani artık ağımıza tam olarak erişebilir ve kaynaklarıkullanabilir durumda.
Peki çalışma anında kullanıcıgüvenlik duvarınıkapatırsa ne olacak? Bu durum bizim politikamıza aykırıbir durum.
Hemen test ediyoruz.
Client-130 üzerinde güvenlik duvarınıkapatıyoruz.
Control Panel> Security altında Windows Firewall ayarına geliyoruz ve Off konumuna getiriyoruz.
OK ile onayladığımızda Windows güvenlik duvarıkapanacak ve sistem uyumsuz duruma düşecektir. Ama hemen ardından Windows Güvenlik Duvarıotomatik olarak açılacak ve Client tekrar uyumlu hale gelecektir. Yani güvenlik duvarının kapatılmasısöz konu değil.
Makalemizde Windows Güvenlik Duvarı’nın açık olmasınızorunlu koştuğumuz için, sadece bu ayarıtest etme şansımız oldu. Ä°lerleyen günlerde farklızorunluluklara da değiniyor olacağız.
Son olarak NAP konusunda yardımcıolacağınıdüşündüğüm ve sorun giderme işlemleri sırasında kullanabileceğiniz olay kayıtlarının tutulduğu yer konusunda bilgi vermek istiyorum.
Bu kayıtlar;
Client üzerinde: eventvwr.msc konsolu içinde,
Event Viewer(Local)\ Applications and Services Logs\ Microsoft\ Windows\ Network Access Protection\ Operational.
Altında tutuluyor.
NAP Server üzerinde ise: yine eventvwr.msc konsolu içinde,
Event Viewer(Local)\ Custom Views\ Server Roles\ Network Policy and Access Services.
Altında tutuluyor.
Problem oluştuğunda buradaki kayıtlarıinceleyebilirsiniz.
NAP konusunu mümkün olduğunca özetleyerek anlatmaya çalıştım ancak gördüğünüz gibi çok derin bir konu. Ä°lerleyen günlerde farklıNAP teknikleri ve özelliklerine değiniyor olacağız.
Çalışmalarınızda başarılar.
Serhat AKINCI – IT Professional
Powered by MightyAdsense
