Anasayfa » DHCP Uzerinde Network Access Protection – Bolum4 (Client Testleri ve Remediation Server Yapılandırması)

Makaleyi Paylaş

Windows Server

DHCP Uzerinde Network Access Protection – Bolum4 (Client Testleri ve Remediation Server Yapılandırması)

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.

Sponsor

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.)

Client’ın ismi Client-130

Ö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.

clip_image002

 

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.

clip_image004

 

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.

clip_image006

 

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.

clip_image008

 

Açılan pencerede Setings tabına geçiyoruz ve NAP Enforcement ‘a gelip Remediation Server Group and Troubleshooting URL altında Configure diyoruz.

clip_image010

 

Gelen pencerede New Group tıklıyoruz.

clip_image012

 

 

Gelen pencerede guruba bir isim veriyoruz ve Add diyoruz. Bu gurup altında birçok Remediation Server toplayabiliriz.

clip_image014

 

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.

clip_image016

 


 

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.

clip_image018

 

Aynı işlemi NAP DHCP Noncompliant için de yapıyoruz.

 

Tekrar Policies altında Network Policies ‘e geliyoruz ve NAP DHCP Noncomplianta çift tıklayarak açıyoruz.

clip_image020

 

Açılan pencerede Setings tabına geçiyoruz ve Configure butonuna tıklıyoruz.

clip_image022

 

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.)

clip_image024

 

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.

clip_image026

 

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.

clip_image028

 

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.

clip_image030

 

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.

clip_image031

 

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.

clip_image032

 

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.

clip_image034

 

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.

clip_image036

 

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.

clip_image038

 

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.

clip_image040

 

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

 

Makaleyi Paylaş

Cevap bırakın