Sistem & Network Yönetim Merkezi

Windows Server 2008 Üzerinde GPO incelenmesi

2007-09-04T09:19:00.000+03:00

Microsoft’un yeni işletim sistemlerinde sürekli olarak güvenlik seviyesini arttırdığını biliyoruz, Vista ve Server 2008 işletim sistemlerinde de güvenliğin son derece ön planda olduğunu söylemek mümkün. Özellikle Group Policy lerde olağanüstü bir genişleme ve yenilik ilk bakışta göze çarpıyor.
Ben de bu yazımda yeni versiyon işletim sistemlerindeki Group Policy dosyalarının farklarını ve olası hataların önlenmesi için neler yapılması gerektiğinden bahsedeceğim.

Daha önceleri .adm formatında olup sadece kendi platformunda çalışabilen Group Policy dosyaları ( En fazla notepad ile açabiliyorduk ki bu bizim düzenlememiz için düşünülmemiş.) artık .admx formatında ve xml programlarıyla görüntülenebiliyor.

Dosyaların arasında ki en büyük ve en önemli farklardan biri ise şu; önceki işletim sistemlerinin kullandığı Group Policy dosyalarında sadece işletim sisteminin kendi varsayılan dili kullanırken yeni Group Policy dosyaları belirtebileceğimiz farklı dillerde güncellenebiliyor. Bu da .admx uzantılı dosyaların çoklu dil desteği sağlaması anlamına geliyor.

Bununla beraber Group Policy dosyalarının yerinin de değiştiğini belirtmekte fayda var. Daha önce %systemroot%\inf konumunda bulunan dosyalar artık %systemroot%\policyDefinitions klasöründe bulunmaktadır ve varsayılan dil altında bütün Group Policy dosyalarının bir kopyası bulunmaktadır.

Dosyaların içerik farklılıkları hakkında bir ön bilgi sahibi olduktan sonra eski Group Policy dosyalarının yenilerine uyarlamasına geçebiliriz. Tabi ki yeni kuracağımız sistemde tam manasıyla bir alt yapı değişikliği yapacak olursak dosyaları da uyarlamaya ihtiyaç duymayız. Fakat eski işletim sistemleriyle beraber çalışacağımızı varsayıyorum. Açıkçası yeni sürüm işletim sistemine sahip server ve client ları eklemeden önce eski server ve client larımızın burada bahsettiğim yeni ayarlar ve dosya türlerinden etkilenmemesini düşünmek olanaksızdır.

Bu noktada .adm dosyalarının uzantılarını .admx olarak mı dönüştürmemiz gerekecek diye düşünülebilir. Elbette kesinlikle hayır, tahmin ettiğiniz gibi Server 2008 ve Vista da bulunan Group Policy Editor , Vista, Server 2003, 2000 ve Xp de kullanılan .adm dosyalarını düzenleyebilecek şekilde tasarlanmıştır. Adm şablonunun düzenlemenin açıklaması ise şu; Group Policy objelerini ara yüzden düzenlerken bu dosyaların üzerine yazıyorsunuz demek oluyor, örnek olarak domain ortamında ki kullanıcıların Windows Movie Maker ı kullanmalarını yasaklamak için Group Policy ayarlarını yapılandırdınızda sonuç olarak ilgili .adm dosyasını aşağıdaki gibi yapılandırmış olursunuz.

CATEGORY !!MovieMaker
POLICY !!MovieMaker_Disable
#if version >= 4
SUPPORTED !!SUPPORTED_WindowsXPSP2
#endif
EXPLAIN !!MovieMaker_Disable_Help
KEYNAME "Software\Policies\Microsoft\WindowsMovieMaker"
VALUENAME "MovieMaker"
VALUEON NUMERIC 1
VALUEOFF NUMERIC 0
END POLICY
END CATEGORY

Şimdi örnek bir yapı oluşturalım, yalnız ondan önce eğer “file replication" servisinin transfer zamanını beklemek istemiyorsanız bu yapıyı PDC üzerinde oluşturmanızı tavsiye ederim.

Yapıyı oluşturmaktaki amaç Server 2008 ve Vista nın 2000–2003 ve Xp de ki gibi her bir Group Policy için ayrı klasörler açmaması ve dosyaları tek bir merkezi klasörde toplaması. Merkezi klasörler grubu oluşturarak aynı domain yapısındaki Domain Controller ların da kendi içinde dosya oluşturması yerine aynı merkezi kullanması ve dosyaları bu dizinden almasını sağlamış oluyoruz.

belirttiğimiz gibi İlk önce klasörleri oluşturalım.
%systemroot%\sysvol\domain\policies\PolicyDefinitions%systemroot%\sysvol\domain\policies\PolicyDefinitions\EN-US

Daha sonra varsayılan klasördeki dosyaları almanız için önceden hazırlanmış Xcopy komutunu kullanabilirsiniz.

( Bat olarak kaydedebilir ya da direk komut satırına kopyalayabilirsiniz. )

CD C:\Xcopy %systemroot%\PolicyDefinitions\* %systemroot%\sysvol\domain\policies\PolicyDefinitions\Xcopy %systemroot%\PolicyDefinitions\en-us\* %systemroot%\sysvol\domain\policies\PolicyDefinitions\en-us

Daha sonra gpmc.msc komutu ile Group Policy Object Editor u açın ve yeni bir Group Policy oluşturun, objeyi modifiye edip kapatın ve dosyanın yeni formatta modifiye edildiğini kontrol edin.

Ve herhangi bir member server üzerinde dosyaların doğru dizinde konumlandırıldığını kontrol edin.

Böylece eski sistem Group Policy dosyalarınızı kaybetmeden veya yeni dosyalarla çakışmaya uğramadan kullanabilirsiniz.

Exchange Server Üzerinde ESEUTIL Kullanımı

2007-09-04T08:54:00.000+03:00

Sahip olduğumuz Exchange Server üzerindeki mail trafiği her zaman sorunsuz işlemeye devam etmeyebilir. Olası kötü durumlara karşı kendimizi hazırlamamız gerekmektedir. İyi bir sistem yöneticisi olarak her zaman düzenli yedeklerimizi alsak ta bazı sorunlar yedek ile çözümlenemez. Servisin yavaşlaması ,gönderilen maillerin kuyrukta beklemesi , mail alma ve gönderme işleminin çok geç gerçekleşmesi , istemci mail alma programlarında ki tutarsızlık , servislerin çok fazla kaynak tüketmesi gibi durumlar bize Exchange Server’ın sorun çıkarmak üzere olduğunu ve bunun için yedekten fazlasını yapmamız gerektiğini göstermektedir .

Bu gibi durumlarda Microsoft un bize sunduğu “ESEUTIL” aracını iyi bir şekilde kullanabilmemiz gerekmektedir. Ben de bu yazımda bu komut seti ile neler yapabileceğimizi anlatacağım

ESEUTIL komut seti, ek bir yardımcı program yüklemeye gerek kalmadan Exchange Server yüklemesi ile beraber gelmektedir. Bu komut setini iyi derecede kullanabilmek için öncelikle Exchange Server ın veri dosyalarını nerede ve ne şekilde sakladığını bilmek gerekmektedir. Exchange Server standart olarak veri dosyalarını aşağıdaki dizine kurulmaktadır;

C:\Program Files\Exchsrvr\MDBDATA”

Bu dizinde aşağıdaki dosyalar bulunmaktadır.

Bu dosyaları sırası ile incelemek gerekirse;

EDB ve STM = Exchange Server 2003 üzerinde bir depolama birimine ait veri tabanı dosyalarıdır ( priv1 = depolama birimi için, pub1 = ortak klasörler için ) . Bu depolama birimi üzerindeki mailler ve bunlara ait olan ekler bu iki veri tabanı dosyasında tutulmaktadır. Bu her iki dosya farklı istemci tiplerine göre kullanılmaktadır. Yani bir MAPI client eğer Exchange Server üzerinden bir mail almak isterse bu bilgi ona “edb” veri tabanından verilirken, internet tabanlı bir protokol ile Exchange Server dan mail alan istemci “ stm ( Streaming) “ dosyasından bilgi almaktadır. “Edb” dosyasında maillere ait başlıklar, maillerin metinleri ve ekleri bulunmaktadır. “Stm” dosyasında ise; ses, görüntü ve benzeri multimedya öğeler yer almaktadır.

E00, Exx = Bu dosyalar Exchange Server ın “Transaction Log” dosyalarıdır. Her depolama grubu için oluşturulan bu log dosyaları yeni açılan her depolama biriminde numarası bir artarak oluşturulur; E00, E01, E02 vb. Bu dosyaların kullanım amacı ise Exchange Server ın hızlı çalışmasını sağlamaktır. Exchange üzerinde yapılan mail gönderimi ve mail düzenleme gibi işlemler direk olarak veritabanına yazılmaz, bu değişiklikler bilgisayarınızın fiziksel RAM i ile log dosyalarında tutulur. Bu Exchange Server ın daha hızlı çalışmasını sağlamaktadır, ancak olası log dosyası silinmesi veya zarar görmesi durumunda veri kaybı kaçınılmazdır. Çünkü çalışmakta olan bir Exchange Server ın sunduğu hizmet; veri tabanı dosyaları, RAM ve log dosyalarının oluşturduğu bir bütündür. Bu nedenle bu bütüne ait bir parçada olan sorunlar bütüne yansımaktadır. Bu log dosyalarının her biri beş’er MB ile sınırlandırılmıştır. Yani her 5mb tan sonra yeni bir log dosyası açılmaktadır. Birinci depolama grubu için artış;

E0000001, E0000002, E0000003 şeklinde ilerlemektedir.

Res1.log, Res2.log = Exchange Server ın kullandığı fiziksel diskte yer kalmaması durumunda loglama işlemi yapılamaz. Bu da olası veri kayıplarına yol açacağı için böyle bir durumda kullanılmak üzere iki adet beş er mb lık iki dosya rezerve için kullanılmaktadır.

E00.chk , Exx.chk = Chk dosyası kontrol dosyası olarak görev yapmaktadır . Bildiğimiz üzere işlemler öncelikle RAM ve log dosyaları üzerine yazılmaktadır . Kontrol dosyası da verilerin veri tabanı üzerine kayıt edilmesini kontrol etmektir.

E00.tmp, tmp.edb = Her depolama birimi için kullanılmak üzere geçici dosyaları temsil ederler. E00.tmp ilk depolama birimi için geçici log dosyasıdır. Exchange üzerinde çalışan “Extensible Storage Engine” servisi üzerinde gerçekleşen işlemler bu log dosyasında tutulur. Veri tabanı üzerinde gerçekleşen “full-text index” gibi işlemlerde ise verilerin geçici olarak tutulduğu dizin ise “temp.edb” dir.

Exchange veri tabanı dosyalarını ve bunların görevlerini anladıktan sonra artık komut setinin kullanımına geçebiliriz. Bu komut setini çalıştırmak için DOS ortamında aşağıdaki dizine kadar gitmeliyiz veya bu dizini path olarak tanımlayabiliriz.

“C:\Program Files\Exchsrvr\bin>” Bu dizinde “ESUTIL” yazarak komut setine ait parametreleri görebiliyoruz.

Yoğun çalışan bir Exchange Server ın zamanla veritabanı şişecek ve çok fazla yer kaplamaya başlayacaktır. Bunun sonucu olarak ise aldığınız yedeklerin boyutu büyüyecek , veritabanının bulunduğu diskteki yer azalacak , Exchange server ın çalışma performansı kötü yönde etkilenecektir . Exchange Server üzerinde Günlük bakım işlemleri ile beraber online bir defrag yapılmakta ancak bu çok ta yeterli olmamaktadır . ESEUTIL ile yapacağımız defrag ise offline defrag tır ve veritabanı üzerinde son derece etkilidir. Defrag işlemi sırasında Eseutil, veritabanın yapısını inceler ve veri tabanı üzerinde ; tarama , okuma , onarım ve birleştirme yapar.

Defrag yapmak için öncelikle Mailbox Store u Dismount etmemiz gerekmektedir.

Bu işlem için ESM üzerinden şekilde gösterildiği gibi Store un üzerine gelerek “Dismount Store” seçeneğini seçiyoruz.

( Not : Eğer bu işlemi unutur ve komut satırında işlemi yaparsanız Operation terminated with error -550

” şeklinde bir hata alacaksınız )

Bu işlemin ardından komut satırınsa aşağıdaki komutu çalıştırıyoruz ;

eseutil /d "c:\program files\exchsrvr\mdbdata\priv1.edb"

Burada önemli bir nokta ya dikkat çekmek istiyorum . Offline defrag yapmak için diskinizin veritabanını barındıran bölümünde veritabanı boyutunun %110 u kadar bir boş alan olmak zorundadır .

İşlem başarı ile sonuçlandıktan sonra artık Mailbox Store u tekrar mount edebiliriz

Bu işlem sayesinde artık veri tabanı gözle görülür bir şekilde küçülmektedir.

( Eğer veri tabanı parçalanmamış ise zaten defrag sonucu da boyut pek değişmeyecektir . )

Dğer defrag işlemi sırasında veritabanı birleştirme yanında diğer ek özelliklerinde kullanılmasını istiyorsanız ,

Defrag parametrelerinin switchlerini kullanabilirsiniz

Örneğin Defrag işlemi sonucu olası sorunlara karşılık veritabanının bir kopyasını almak isteyebilirsiniz .

Bunun için aşağıdaki komutu kullanabiliriz

eseutil /d "c:\program files\exchsrvr\mdbdata\priv1.edb" /b c:\deneme

Eğer farkında olmadan Exchange Server şişmiş ve veritabanının bulunduğu diskte yer kalmamış ise Exchange Server çalışmaya devam edemeyecektir. Bu durumda en iyi çözüm hızlı bir şekilde defrag yapmak ve yer açmaktır . Ancak sorun ise defrag için gerekli olan %110 boş alanın zaten elinizde olmaması . Böyle bir durumda ise yine kullanacağınız bir ESEUTIL switch i ile bu sorunu aşabilirsiniz.
Defrag sırasında “t” switch i kullanılmaz ise eğer veritabanının bulunduğu dizinde “Tempdfrgxxx.edb” isminde geçici veritabanı dosyası oluşturulur .

Eğer veritabanının bulunduğu disk üzerinde yeriniz yok ise geçici veri tabanı dosyasını isterseniz “t” komutu ile başka bir dizin üzerine alabilirsiniz . Örneğin aşağıdaki komut ile geçici veri tabanı ismini ve konumunu değiştirmiş oluyorum . Bu komuta göre geçici veri tabanı bilgisayarımın “D” dizininde “temp.edb” isminde olacaktır .

eseutil /d "c:\program files\exchsrvr\mdbdata\priv1.edb" /t d:\temp.edb

Kullandığım “t” komutu ile defrag için gerekli olan geçici veritabanı dosyası artık belirtilen dizine alınabilir . ( not : eğer tek disk var ise map network drive üzerinde de sorunsuz çalışmaktadır. )
ESEUTIL ile aynı zamanda bozulmuş data dosyalarını da düzeltme şansınız bulunmaktadır .
Örneğin virüs programları sonucu zarar görmüş ve mount olmayan db yi /P komutu ile onarabiliriz.
eseutil /p "c:\program files\exchsrvr\mdbdata\priv1.edb"

Komutu çalıştırdığımızda karşımıza bir uyarı ekranı gelecektir.

Bu ekranda bize Repair işleminin loglara yansımayacağı bildirilmektedir.

İşlemin sonucunda veritabanının bütünlüğünü kontrol etmek ve olası sorunları düzeltmek için aşağıdaki komutu kullanıyoruz.

isinteg –s kayro –test folder
( kayro = server ismi , folder ise test dosyasının ismi , -fix komutunu da kullanarak sorunları düzeltebilirsiniz )
bu komut hakkında daha fazla bilgi için http://support.microsoft.com/kb/182081/tr

Bu işlemin ardından sorunlu veritabanı sorunsuz bir şekilde mount olacaktır . ( not : bu işlemin %100 kurtarma ve onarma garantisi yoktur. )

Bu işlemlere rağmen veritabanı mount olmuyor ve sorunlar devam ediyor ise “/g” komutunu kullanabiliriz .

Bu komut veritabanının bütünlüğünü kontrol eder ve eğer sorunlar var ise artık “/r” parametresini kullanabileceğimizi gösterir.

Eğer veri tabanı hala sorunlu ise “/r” parametresi ile “Soft Recovery” işlemi yapılabilir . Microsoft ; eğer Exchange Server ın veri dosyaları duruyor ancak mount işlemi gerçekleşmiyor ise bu işlemi öneriyor . Ancak veri dosyaları yok olmuş ve online olarak yedekten geri dönülmüş ise o zaman “Hard Recovery” yani “/c” parametresini önermektedir.

Eseutil Recovery faklı bir lokasyona taşınmış veritabanını kurtarabilir, bu özellik yalnızca Exchange 2003 le beraber kullanılabilir. Hard recovery "veritabanı back up alındıktan sonra bile" farklı lokasyona taşınmış olsa dahi geri kurtarma işlemini başarı ile tanımlar. Exchange 2003 öncesine kadar ise Veritabanını kurtarmak için Transaction Log files ın bulunduğu konumda olması gerekirdi. Exchange 2003 de /D switch’i kurtarma moduna eklenmiştir ve böylece transaction log files ın bulunduğu konuma da transaction logları tarafından yazılmış bilgilere rağmen geri yüklemeyi başarır. Bu yeni özellik çevrimdışı veritabanlarını " Recovery Storage Groups" a yazarken ve ya yukarıda ki senaryoda gibi bozulmuş veritabanlarını kurtarırken son derece kullanışlıdır.

Veritabanını ve transaction log dosya gruplarını istediğiniz klasöre kopyalayabilir ve başarılı bir şekilde normal geri kurtarma işlemi yapabilirsiniz. Veritabanı bir kez doğrulandığında ( Consistence ) daha sonra veritabanını istediğiniz lokasyona taşıyabilirsiniz ve farklı log larla ilişkilendirebilirsiniz.
eseutil /r e00 /i ( veritabanının olduğu dizinde çalıştırın )

Komutun çalıştırılmış şekli yukarıdaki gibidir . Bu uygulama ile beraber sorunlu olan veritabanı dosyaları düzelecektir. ( yine bu konuda da Microsoft bir garanti vermemektedir. )
Eğer ESEUTIL aracını Exchange üzerinde değil de bir başka makinede çalıştırmak istiyorsanız Exchange server dan aşağıdaki dosyaları kopyalamanız gerekmektedir

Eseutil.exe, Ese.dll, Jcb.dll, Exosal.dll, Exchmem.dll

“C:\Program Files\Exchsrvr\bin” dizininde bulunmaktadır .

ESEUTIL ile yapılacaklar bunlarında ötesindedir , ancak her bir komutu ve bu komutların switchleri ayrı bir makale konusu olduğundan en önemli ve en çok kullanılan komutların üzerinde durmaya çalıştım.

Secure E-Mail

2007-09-04T08:33:00.000+03:00

Günümüzde mail trafiğinin önemi gittikçe artmaktadır. Gerek kurumsal alanda gerekse bireysel alanda işlerin pek çoğu artık yazılı kültüre dayanmaktadır . Böylesi bir öneme sahip olan mail trafiğinin güvenliğini artırmak için biz sistem yöneticilerine düşen görevler de artmaktadır . Bu yazıda yöneticilerimizden birinin isteği üzerine araştırdığım, güvenli mail trafiği oluşturmak için sertifikaların nasıl kullanılacağını anlatacağım.

Kısaca Dijital İmza Nedir?

Bugün yazılı dökümanlarda kullandığınız imzalar gibi, e-mail veya elektronik datanın yazarının/diğer imzalayıcılarının tanımlanması için dijital platformda kullanılan imzalardır. Dijital imzalar, Dijital Sertifikalar kullanılarak yaratılır ve onaylanır. Bugün, hukuk kurumları dijital imzaların yazılı olanlar gibi yasal bağlayıcı ve uluslararası kabul edilir olması için hukuki altyapıyı hazırlamaktadır. Bilgiyi imzalamak ve güvenli bir işlem gerçekleştirmek için kendi özel Dijital Sertifikanıza ihtiyacınız vardır.

Dijital imzalar aşağıda belirtilen önemli fonksiyonları sağlarlar:

- Tanılama
- Gizlilik & data bütünlüğü
- İnkar-edememe

5070 Sayili Elektronik İmza Kanunu madde 4’e göre Güvenli elektronik imza;

- Münhasıran imza sahibine bağlı olan,
- Sadece imza sahibinin tasarrufunda bulunan güvenli elektronik imza oluşturma aracı ile oluşturulan,
- Nitelikli elektronik sertifikaya dayanarak imza sahibinin kimliğinin tespitini sağlayan,
- İmzalanmış elektronik veride sonradan herhangi bir değişiklik yapılıp yapılmadığının tespitini sağlayan,
dijital bir anahtardır.

23 Ocak 2004 tarih ve 25355 sayılı Resmi Gazetede yayınlanan ilgili mevzuatı aşağıdaki linkten takip edebilirsiniz: http://www.dijital-imza.com/mevzuat/kanun.htm

Makalenin bu kısmında dijital bir anahtarı kullanarak karşı taraf için kimliğimizi ispatlamayı, ve aynı anahtarı kullanarak maillerimizi encryptleyerek göndermeyi göreceğiz.

Öncelikle bu anahtarı verecek, herkes tarafından güvenilir sertifika dağıtan CA (Certification Authority) 'lere ihtiyaç duyulur. Ticari olarak bu işi yapan firmalardan kullanım amacına uygun sertifikalar ücret karşılığı alınabilir.

Lokal kullanım için Windows 2000/2003 sunucu ailesi işletim sistemleri CA servisi sağlayabilir.

Yalnız lokal CA kullanmanız durumunda sertifkanızın güvenilirliği sadece lokaliniz için geçerli olacaktır.

Bu sebep ile Web sitelerinin SSL sertifikaları, mail için kullanılan Secure Email sertifikaları Ticari CA (Commercial CA)'lerden alınmalıdır.

Bu yazıdaki uygulamada bir mail hesabı için sertifika talep edeceğiz.

Sertifika alabileceğiniz CA sitelerine örnek olarak

http://www.globalsign.com veya http://www.thawte.com

web adresleri verilebilir.

Global Sign web adresini kullanarak devam edeceğiz.

Sol üst linkte Certificates – Client Certificates bölümünden talep sayfasına girerek; aşamaları talip edeceğiz.

Kişisel Sertifikamızı talep ediyoruz

Karşımıza çıkan ekranda istekte bulunulan sertifika için prosedür gereği hangi aşamalardan geçileceği belirtiliyor.

Step1: İşletim sistemimizin globalsign’a güvenip güvenmediğinin kontrolü yapılır;
Step2: Sertifikayı kullanmak istediğimiz mail hesabını yazılır;
Step3: Yazdığımız mail hesabına gelen mail’i kontrol edip, linke tıklanır;
Step4: Aşama 2 de yazdığımız password girilir;
Step5: Kişisel bilgilerimiz girilir;
Step6: Anlaşmayı kabul ederiz;
Step7: Mailimize gelen son link ile, yükleme yapacağımız yere yönlendiriliriz;
Step8: Sertifikayı install ederiz.

Tüm aşamalar sonunda bizim için hazırlanan sertifikayı sistemimize yükleyebiliriz.

Install edilmiş sertifikayı görmek ve herkes tarafından güvenilir sertifika dağıtan CA (Certification Authority) ler arasında bizim tercih ettiğimiz CA (Certification Authority), yer alıyor mu kontrol edelim;

Sertifikalar

Güvenilen CA (Certification Authority) listesi

Bu sertifikayı başka makinada kullanmak ya da yedeklemek isterseniz, export edebiliriz. Bilindiği üzere Dijital sertifika iki anahtardan oluşuyor; Public Key ve Private Key'dir. Veriyi encrypt hale dönüştüren public key, encrypt edilmiş veriyi açan public key dir. Uygulamamıza Private Key’ i de export ederek yedekleme işlemini başlatıyoruz.

Eğer birileri size özel bu private key'i ele geçirirse, encrypt hale dönüştürülmüş verileri açma olasılığını engellemek amacıyla bu sertifikayı kendine yükleyememesi için password verilmesi ve kimseye söylenmemesi gerekir.

Güvenlik amacıyla sertifikayı ele geçirebilecek kişler için parola zorunluluğu bulunmaktadır.

Yedekleme işlemini de böylece tamamlamış oluyoruz.

Zaten yüklü olan sertifikamızı Microsoft Outlook programında nasıl kullanacağımıza bakalım.. .

Tools – Options açılan pencerede Security sekmesine gelirsek yüklü olan sertifikayı outlook programımızın zaten kullanmaya hazır olduğunu, ya da import edebileceğimiz yeri görebiliyoruz. Karşı tarafa attığımız maillerde dijital kimliğimizi de göndermek istiyorsak “Add digital signature to outgoing messages” kutucuğunu işaretleyebiliriz

Gönderdiğiniz maillerde kırmızı kurdele eklentimiz geliyor ve karşı tarafta kendi kimliğimiz ispatlanmış oluyor.

Maili alan kişi, sertifikalı mail atan kişinin sertifikayı aldığı siteye güveniyorsa, o an için iletişim kurabiliyorsa ve kişinin bilgileri doğrulanıyorsa kurdele kırmızı olacaktır; herhangi bir gereklilik eksikse kurdelemiz renksiz olacaktır.

Maili okumadan önce kurdeleye tıklayarak, kullanıcının, sertifika dağıtan server ın ve sertifikanın bilgilerini görebiliriz.

Encryptli mailleşme olabilmesi için öncelikli olarak tarafların birbirlerine public keylerini göndermeleri gerekmektedir. Public Key ler dijital imzalarımızla karşı tarafa ulaşıyor, Uygulamamızda Türker’ den Volkan’ a ve Volkan’dan da Türker’e karşılıklı olarak mailleşme olduğundan ve public key ler paylaşıldığından (Volkan’ın public key i Türker’ de; Türker’in public key i de Volkan da) olduğu için artık encryptli mailleşebiliriz. Sonuç olarak İlgili programımızın security sekmesinde “Encrypt contents and attachments for outgoing messages” kutucuğunu doldurarak tüm içerik ve eklerin encyrptlenmesini sağlayabiliriz.

Maili alan kişi artık kırmızı kurdelenin yanında asma kilit işaretini de görmektedir. Kırmızı kurdelede söylediklerimize ek olarak bu maili açabilmemiz için private key imizi hiç bir zaman kaybetmemiz gerekiyor. Diğer bilgiler için ilgili simgelere tıklamamız gerekiyor.

Hem yasanın gerekliliklerini yerine getirmiş :), kimliğimizi ispatlamış tüm bunlara ek olarak maillerimizi mail sahibinden başka hiçkimsenin okuyamaz hale gitirmiş olduk.

Kerberos Nedir, Nasıl Çalışır ?

2007-09-04T08:20:00.000+03:00

Bilgisayar ağlarının yaygınlaşması ile birlikte, bilgisayarlar arası kimlik doğrulama önem kazanmıştır.

Burada çeşitli kimlik doğrulama (authentication) protokolleri vardır.
Bunlardan en önemlisi Kerberos protokolüdür.

Kerberos Athena Projesinin bir parçası olarak MIT (Massachusetts Institute of Technology) tarafından geliştirilmiştir.

Kerberos açık bir ağda güvenli kimlik denetimini sağlamak için şifreleme teknolojisini ve hakem olarak üçüncü bir taraf kullanır (KDC).

Kerberos’un kullanımda olan iki sürümü vardır; sürüm 4 ve sürüm 5. Sürüm 1’ den sürüm 3’e kadar olan sürümler iç geliştirme sürümleri olup hiçbir zaman yayınlanmamıştır. Sürüm 4’ ün ise bir çok zayıf yönü bulunduğundan kullanılması uygun değildir.

Biz sadece sürüm 5’ den bahsedeceğiz. Kerberos 5 RFC 1510’ da tanımlanmıştır.

(http://www.ietf.org/rfc/rfc1510.txt).

Windows 2000, Windows XP , Windows Server 2003 ve Windows Server Core varsayılan kimlik doğrulama protokolü olarak Kerberos kullanır. Ayrıca açık kaynak kodlu sistemlerde de Kerberos kullanılmaktadır.

Kerberos Needham-Schroeder protokolünü temel alır.
Burada KDC (Key Distribution Center) olarak isimlendirilen güvenilen üçüncü bir taraf kullanılır.

KDC iki kısımdan oluşur; Authentication Server (AS) ve Ticket Granting Server. Kerberos kullanıcıların kimliklerini doğrulamak için bilet (ticket) kullanır. KDC networkdeki her bir istemci yada sunucu için gizli anahtarları tutan bir veritabanına sahiptir. Bu gizli anahtarlar sadece KDC ve ait olduğu istemci tarafından bilinir.

Kerberos’un çalışma şekli ise aşağıdaki gibidir;

1- Kullanıcı istemci üzerinde kullanıcı ismini ve şifresini girer

2- İstemci kullanıcı şifresi üzerinde tek yönlü bir hash algoritması uygular ve bu istemcinin gizli anahtarı olur.

3- İstemci Authentication Server’a oturum açma bilgilerini gönderir. Oturum açma bilgileri kullanıcı adı ve domain bilgilerini içerir. Dikkat edilirse burada kullanıcının şifresi yada gizli anahtarı Authentication Server’a gönderilmez.

4- Authentication Server istemcinin kendi veritabanında bulunup bulunmadığını kontrol eder, eğer mevcutsa, istemciye iki adet mesaj gönderir.

Mesaj

A: İstemci/TGS oturum anahtarı (session key), bu kullanıcının gizli anahtarı ile şifrelenir.
(Bu gizli anahtarı sadece KDC ve istemci biliyor. Bu yüzden bu oturum anahtarını sadece istemci açabilir)

B. Mesaj B: Ticket-Granting Ticket. Bu bilet kullanıcı ismi ve biletin kullanım süresi gibi bilgileri içerir ve TGS’ nin kendi gizli anahtarı ile şifrelenir.

5- İstemci bu iki mesajı aldıktan sonra İstemci/TGS oturum anahtarını almak için Mesaj A’ yı açar. Mesaj A kullanıcının kendi şifresinden üretilen gizli anahtarı ile şifrelendiğinden kullanıcı bu mesajı açabilir. Bu gizli anahtar TGS ile daha sonra yapılacak olan iletişimde kullanılacaktır. Burada istemci Mesaj B’ yi açamaz. Çünkü Mesaj B sadece KDC tarafından bilinen KDC’ nin kendi gizli anahtarı ile şifrelenmiştir. Bu işlemin sonucunda istemci kimlik doğrulamasını başarıyla yapmıştır Kerberos protokolünü kullanarak domaindeki diğer kaynaklara erişmeye hazırdır.

Buraya kadarki adımlar kullanıcının oturum açmasına kadar olan kısımdı. Şimdide istemcinin bir sunucuya erişimi sırasındaki adımları inceleyelim;

1- İstemci aynı domain’deki bir sunucuya erişmek istediğinde TGS’ ye şu iki mesajı gönderir;

a- Mesaj C: Mesaj B’ de aldığı TGT ve erişilmek istenilen sunucu ID’si

b- Mesaj D: İstemci ID’ si ve Zaman bilgisi (TimeStamp) istemci/TGS oturum anahtarı ile şifrelenir

2- TGS bu iki mesajı aldıktan sonra, Mesaj D’ yi istemci/TGS oturum anahtarı ile açar ve sonrasında istemciye şu iki mesajı gönderir;

a- Mesaj E: İstemci-Sunucu bileti. Bu bilet İstemci ID, istemci network adresi, geçerlilik süresi ve İstemci/Sunucu oturum (session) anahtarı bilgilerini içerir. Bu mesaj sunucunun gizli anahtarı ile şifrelenir.

b- Mesaj F: İstemci/Sunucu oturum (session) anahtarı, İstemci/TGS oturum anahtarı ile şifrelenmiştir.

3- Mesaj E ve F’ yi istemci aldıktan sonra, istemci artık sunucuya bağlanmak için gerekli bilgilere sahiptir. Ve istemci sunucuya bağlanıp şu iki mesajı gönderir;

a- Mesaj E: Bir önceki adımdaki Mesaj E’ yi gönderir.

b- Mesaj G: İstemci ID’ si ve Timestamp bilgisini gönderir. Bu mesajıda İstemci/Sunucu oturum anahtarı ile şifreler.

4- Sunucu kendi gizli anahtarı ile Mesaj E’ yi açar. Ve bu mesajın içerisinden İstemci/Sunucu oturum anahtarını alır. (Burada dikkat edilmesi gereken husus Mesaj E’ yi sadece bağlanılan sunucunun açabilmesidir. Sunucu bu mesajı açtığı zaman bunun güvenilen bir kaynaktan geldiğini bilir. Çünkü bu mesaj sunucunun gizli anahtarı ile şifrelenmiştir ve bu anahtar sadece kendisinde ve KDC’ de mevcuttur.) Bu anahtarlada Mesaj G’ yi açar. Daha sonra İstemciye kimlik doğrulamasını onaylamak için şu mesajı gönderir;

a- Mesaj H: Mesaj G’ deki Timestamp değerini bir artırır. Bu mesajı istemci/sunucu oturum anahtarı ile şifreler.

5- İstemci mesajı aldıktan sonra timestamp’ in doğru olarak güncellendiğini kontrol eder. Eğer bu işlem doğru olarak yapıldıysa istemci artık sunucuya güvenebilir ve sunucuya istenen servisler için bağlantı kurar.
Burada dikkat edilirse şifreler hiç bir zaman networkde dağıtılmıyor. Bağlanılan sunucuda bağlantı isteğini sadece kendi gili anahtarını kullanarak onaylıyor. KDC’ ye bağlanmaya hiç bir şekilde ihtiyaç duymuyor.
Tüm bunların yanında Kerberos protokolü kullanıldığında şu durumlara dikkat etmek gerekir;

a- Eğer Kerberos sunucusu bir adet ise bu sunucu da oluşacak bir problem sonrasında kullanıcılar hiç bir şekilde kimlik doğrulaması yapamayacaklar ve kaynaklara erişemeyeceklerdir. Bu problemi aşmak için birden fazla Kerberos sunucusu kullanmak gerekir.

b- Kerberos protokolünde kimlik doğrulama esnasında Timestampler kullanıldığından dolayı zaman ayarı önemli. Varsayılan ayarlarda en fazla 5 dakikalık bir zaman sapması olabilir. Zamanın tüm host’ larda aynı olması için NTP sunucusu kullanılabilir.

Server Core - Kurulum & Temel Yapılandırma

2007-07-30T13:41:00.000+03:00

Microsoft Windows Server serisinin son ürünü Windows Server 2008 yakında kullanıma sunulacak.
Birçok yeniliği beraberinde getiren bu ürünle birlikte yeni tanıştığımız “Core” kavramı da dikkat çekmeye başladı.
Server Core olarak duyurulan bu ürüne “Windows without Windows” yakıştırması yapılıyor. Grafik arayüzü bulunmayan, komut satırından yönetilebilecek bir Windows Server kurulum seçeneği olarak karşımıza çıkıyor.

Bu makalede Server Core ‘u yakından inceleyeceğiz.

Windows yöneticilerinin alışık olduğu grafik arabirim (GUI) olmadan server yönetmek çok kolay olmayacak. Artık tüm yönetimsel görevlerin bir parçası haline gelmiş olan wizard’ları kullanmadan, çoğu yöneticinin tercih etmediği bir şekilde, tüm idari işlerin komut satırından yapılması gereken bir işletim sistemine neden ihtiyaç duyarız, bu sorunun da cevabını vermek lazım. Server Core’un sağladığı avantajlardan birkaçı şunlardır ;

- Daha az bakım gerektirmesi
- Daha az yönetimsel efor gerektirmesi
- Daha az servis çalıştırarak atak alanının azaltılmasıyla gelen ekstra güvenlik
- Daha az sistem kaynağı kullanması
- Kısa kurulum süresi
- Server Core ile kullanılabilecek olan sunucu rolleri şunlardır.
- Active Directory Domain Services (AD DS)
- Active Directory Lightweight Directory Services (AD LDS)
- DHCP Server
- DNS Server
- File Services
- Print Server
- Streaming Media Services
- IIS 7.0

Bunların dışında şu an için .Net Framework desteği Server Core içinde gelmiyor ve yüklenemiyor. Burada birkaç detay dikkatimizi çekiyor. .Net Framework olmadığı için IIS kursak da Asp.NET sitelerini yayınlayamıyoruz. Bir handikap da PowerShell tarafında. Biliyoruz ki Microsoft yeni komut konsolu olarak PowerShell’i geliştirdi ve günden güne kullanımı artıyor.

Fakat Server Core da .Net Framework desteği olmadığından PowerShell kullanamıyoruz. Sadece komut satırından yönetilecek bir işletim sistemi için, devrim niteliğindeki komut satırı aracı olan PowerShell’den mahrum bırakılmadı bence doğru olmamış. Umarım ürün release olmadan bu konuya bir çözüm getirilecektir. Sitede PowerShell ile ilgili bir makalemi bulabilirsiniz.

Server Core Kurulumu

Server Core kurulumunu yine Windows Server 2008 kurulum dvd’sinden gerçekleştiriyoruz. Vista’da olduğu gibi Windows Server 2008’de de tüm sürümler tek dvd’de geliyor. Kurulum sırasında satın aldığımız sürümü seçmemiz gerekiyor. Bu yüzden Kurulum sürecinde sorun yaşanacağını düşünmediğimden bu kısmı geçiyorum.

Kurulum sonrası tüm işlemlerimizi gerçekleştireceğimiz yönetim konsoluna ulaşabiliriz.

Kısa kurulum sürecinin ardından bizi karşılayan ekranın çok gösterişli olduğu söylenemez.

Windows yöneticileri için ilk başta alışmak zor olabilir ama kısa bir ısınma turu ardından temel komutları ve işlevleri öğrenerek her türlü yönetimsel görevi yerine getirebiliriz.

Server Core’u yönetmek için birkaç seçeneğimiz var.

- Konsoldan logon olarak makine başından yönetebileceğimiz gibi, uzak bir makinadan Remote Desktop bağlantısı da yapabiliriz. Fakat bu Remote Desktop bağlantısının da yine sadece komut konsoluna olacağını unutmayalım.

- Server Core’da karşımıza başlat butonu asla gelmeyecek . Ayrıca yine uzak bir bilgisayardan mmc konsoluyla da bağlanıp yönetmek mümkün.

Şimdi asıl Server Core’u yönetme ve rollerin kurulumu ile ilgili işlemleri gerçekleştirip bu yeni sistemi efektif bir şekilde kullanabilmek için nasıl konfigüre etmeliyiz buna bakalım.

İlk olarak temel işlemlerle başlıyoruz.

Server Core’u açtıktan sonra karşımıza gelen komut konsolundan istediğimiz işlemleri yapabiliriz.

Server Core ile beraber Windows Explorer yazılımı gelmiyor fakat bu hiçbir grafiksel arayüzü olan programın çalışmayacağı anlamına gelmiyor.

Örneğin notepad, regedit gibi araçları kullanabiliriz. Bu programları çalıştırmak için komut konsolundan çağırmamız yeterli.

Ayrıca Task Manager’a da erişim mümkün.

Komut konsoluna “taskmgr” yazarak yada ctrl+shift+esc tuş kombinasyonunu kullanarak Task Manager’a ulaşabiliriz.

Buradan “Run” aracına da yine erişmemiz mümkün. Task Manager’ın çalışan hali resimde görülmekte.

Task Manager sayesinde çalışan uygulamalar ve process’ler hakkında bilgi alabilir ve bunları sonlandırabiliriz.

Ayrıca bağlı userları görebilir, sistem performansını anlık denetleyebiliriz.

Önceki Windows sürümlerinin aksine bu sürümün task manager’ında ekstradan çalışan servislerle ilgili de bilgi alabiliyoruz. Komut konsolunu yanlışlıkla kapatırsak yapmamız gereken şey ctrl+shift+esc tuşlarına basarak

Task Manager’ı açmak ve File menüsünden Run’a gelip cmd yazmak. Bu sayede yeni bir komut konsolu açılacaktır.

Problemlerimizden bir tanesi driver yüklemek. Eğer Server Core’un driverını yükleyemediği bir aygıtımız varsa bunun yüklemek için yine basit bir komut satırı aracımız var.

Makinamıza yüklenmiş driverların bir listesini almak için; “sc query type= driver”
Komutunu kullanıyoruz. Bu komutun çıktısı çok uzun olacağından tamamını ekranda görmemiz mümkün değil. Önce çıktıyı bir dosyaya kaydedip daha sonra dosyanın içeriğini notepad ile inceleyebiliriz.

Yada sadece aygıtların ismini görüntülemek için komutu şu şekilde uygulayabiliriz.

Eğer driverı yüklenmemiş bir aygıtımız varsa Microsoft PNP Utility aracını kullanarak driverı yükleyebiliriz.

Gerekli komut şu; “Pnputil -i -a driverdosyasi.inf”

Bu işlemden sonra eğer gerekirse restart etmemiz için bizi uyaracak.

Bilgisayarımızı yeniden başlattıktan sonra driverın yüklenmiş olduğunu yine üstteki komutları kullanarak denetleyebiliriz.

Kurum sırasında bize bilgisayar adı ve administrator parolası sorulmamıştı.

Şimdi bunları ayarlayalım. Makinamızda var olan kullanıcıları görmek için; “net users”
Komutunu kullanabiliriz. Resimde komutun çıktısı görülmektedir.

Default olarak administrator kullanıcısının şifresi yoktur.

Güvenliğimiz için sistemi kullanmaya başlamadan önce, ilk olarak bir yönetici parolası belirlemeliyiz. Komut satırından herhangi bir kullanıcıya şifre belirlemek için; “net user administrator *” Komutunu çalıştırıyoruz.

Bizde vermek istediğimiz şifreyi girmemizi ve onaylamamızı isteyecektir.

Resimde bu komutun çıktısı görülmektedir.

Ayrıca bir kullanıcıyla ilgili (örn. Administrator) detaylı bilgi almak için “net user administrator” komutunu verebilirsiniz.

Eğer istersek yeni bir kullanıcı oluşturup bunu local administrators grubuna ekleyebiliriz.

Bunun için aşağıdaki komutları çalıştırmamız gerek. “net user /add Cem *”
Bu komut bilgisayarımıza Cem isimli bir kullanıcı ekleyecek.

Sonunda ki * koymazsak kullanıcımıza bir şifre atanmaz. Ben * koyarak bir şifre belirlemeyi seçtim.

Ayrıca bu kullanıcıyı local administrators grubuna dahil etmek için şu komutu çalıştırmalıyız.
“net localgroup administrators /add Cem”

Sonucu görmek için ise; “net localgroup administrators” Komutunu çalıştıralım.

Makine adı olarak rasgele bir isim belirlenmişti.

Şimdi onu istediğimiz bir isimle değiştirelim.

Makina adını görüntülemek için aşağıdaki komutu kullanalım. “hostname”

Daha sonra makine adımızı istediğimiz bir isimler değiştirelim.

Makinanın adını değiştirmek için “netdom” komutunu kullanıyorum.

Komutun yazımı şu şekilde.
“netdom renamecomputer makinanın_eski_adı /newname:makinanın_yeni_adı”

Eğer makinamız domaine üye olsaydı, makine adını değiştirmek için;

“netdom renamecomputer makinanın_eski_adı /newname:makinanın_yeni_adı /userd:DOMAINADI \USERNAME /password:*”

şeklinde bir komut kullanmamız gerekirdi.

Bu işlemi yaptıktan sonra bilgisayarı yeniden başlatmamız gerekli.

Bilgisayarı yeniden başlatmak için veya kapatmak için “shutdown” komutunu kullanıyoruz.

Bu komutun çok kullanılan parametrelerini alttaki listede bulabilirsiniz.

- Shutdown /s è Makinayı Kapatır (30 saniye sonra)

- Shutdown /r è Makinayı Yeniden Başlatır (30 saniye sonra)

- Shutdown /s /t 10 è /t Parametresiyle makinayı kapatmak istediğimiz süreyi belirleyebiliriz. /r ve /s ile kullanılabilir.

Default olarak komut verildikten 30sn sonra kapanır.

Ben burada değiştirerek 10sn verdim.

- Shutdown /i è Shutdown komutunun grafik arabirimini açar.

- Shutdown /m è /m Parametresiyle uzaktaki bir bilgisayarı kapatabiliriz.

- Shutdown /a è Gerçekleşmemiş shutdown veya restart komutunu iptal eder. /t ile belirtilen zaman ( Default 30 sn) geçmeden işlemi iptal edebilmemizi sağlar.

- Shutdown /l è Kullanıcının oturumu kapatır.

Şimdi bilgisayar adını da değiştirdiğimize göre artık sıra makinamıza ip vermeye geldi.

Komut satırından makinamızın ip konfigürasyonunu değiştirmek için “netsh” komutunu kullanabiliriz.

Netsh komutu gerçekten büyük ve faydalı bir araçtır. Server Core ‘da çok işimize yarayacak bir komut.

Makinaya ip atamadan önce kurulu network bağlantılarını görmek için komutu aşağıdaki şekilde kullanıyoruz.
“netsh interface ipv4 show interfaces”

Burada karşımıza gelen listeden işlem yapmak istediğimiz bağlantının “Idx” numarasını diğer komutlarımızda kullanacağız.

İp atamak için kullacağımız komut ise şu şekilde.
“netsh interface ipv4 set address name="" source=static address= mask= gateway=”

Burada olan yere işlem yapmak istediğimiz bağlantının “Idx” numarasını giriyoruz.

Komutların çıktıları şu şekilde;

Sıra geldi dns server ip’si eklemeye.

Yine netsh komutunu kullanacağız. Komutun kullanımı aşağıdaki gibi.

“netsh interface ipv4 add dnsserver name="" address= index=1”

Yine bölümüne bağlantının id numarasını yazıyoruz. bölümüne de dns server’ın ip adresini yazıyoruz.

Eğer aynı yöntemle birden fazla dns server eklersek, index değeriyle bunların sırasını belirleyebiliriz.

İhtiyaca göre wins server adresi de girebiliriz. Yöntem ve komut neredeyse aynı.
“netsh interface ipv4 add winsserver name="" address= index=1”

Bu komutlarla dns ve wins serverları da ekledik.

Eğer bunlardan herhangi birini silmek istersek şu komutları vermeliyiz.

“netsh interface ipv4 delete dnsserver name="" address= index=1”
“netsh interface ipv4 delete winsserver name="" address= index=1”

İp verme ile ilgili son örneğimizde dhcp hakkında. İstersek makinamızı bir dhcp serverdan otomatik olarak ip alacak şekilde yapılandırabiliriz. Örnek komut şu şekilde olmalı.

“netsh interface ipv4 set address name="" source=dhcp”

Yine bölümüne bağlantının id numarasını yazıyoruz. Artık bilgisayarımız dhcp sunucudan ip alacak.

Artık dns ve wins server ip’lerini de girdiğimize göre makinamızı domain’e katabiliriz.

Domain’e katmak için kullanacağımız komut ise “netdom”. Altta nasıl kullanmanız gerektiğini görebilirsiniz.

“netdom join MAKINAADI /domain:domainadi.com /userD:DOMAINADI\USERNAME /passwordD:*”

Bu aşamada bize belirttiğimiz kullanıcının şifresini soruyor.

Bu kullanıcının domain’e makine katmaya yetkisi olmalıdır.

Burada /userD ve /passwordD komutlarının sonundaki D harflerine dikkat etmek gerek.

Sıra geldi activasyon işlemlerini yapmaya.

Diğer windows ürünlerinde olduğu gibi Server Core’u da aktive etmemiz gerek.

Bunun için kullanmamız gereken komut; “slmgr.vbs –ato”

Bu komut Windows Software Licensing Management Tool’u aktivasyon için çalıştıracak.

Bu tool ile birlikte kullanacağınız diğer parametreleri resimden görebilirsiniz.

Şimdi uzaktan bağlantı ayarlarını yapalım.

Grafik ekranımız olmadığı için Remote Desktop bağlantılarını da yine komutla aktif edeceğiz.

Bunun için hazırlanmış bir script mevcut.

Bu scripti kullanarak uzak bağlantıyı çok kolay bir şekilde konfigüre edebiliriz.

Scriptin kullanımı şu şekilde olmalı;
“Cscript %windir%\system32\SCRegEdit.wsf /ar 0” è Windows Server 2008 ve Vista’dan bağlamak için
“Cscript %windir%\system32\SCRegEdit.wsf /cs 0” è Windows 2000, XP veya 2003’den bağlanmak için

Bu komutların ikisini de çalıştırabiliriz. Script bizim için gerekli registry değişikliklerini yapacak.

Şu anda Remote Desktop açık olmasına rağmen bağlantı sağlamamız mümkün değil.

Çünkü default olarak Windows firewall açık geliyor.

Bağlantı kurabilmek için ya firewall’da port açmalı ya da ihtiyaç yoksa firewallı komple kapatmalıyız.

İlerleyen bölümde firewall konfigürasyonundan bahsedeceğiz.

Yine aynı scripti çalıştırarak Windows Update ayarlarını da yapabiliriz.

Windows Update default olarak konfigüre edilmemiştir.

Açmak veya kapatmak için şu komutları kullanmalıyız.
“Cscript %windir%\system32\SCRegEdit.wsf /au 4” è Automaitic Update’i açar.
“Cscript %windir%\system32\SCRegEdit.wsf /au 1” è Automaitic Update’i kapatır.
“Cscript %windir%\system32\SCRegEdit.wsf /au /v” è Automaitic Update’in durumunu gösterir.

Ayrıca çektiğimiz herhangi bir update’i manual yüklemek istersek “wusa” komut satırı aracını kullanabiliriz.

Windows Update Standalone Installer programının kullanım şekli aşağıdaki gibidir.
“wusa updatedosyasi.msu /quiet”

Komutun tüm parametrelerini şekilde görebiliriz.

“SCRegEdit.wsf” scripti ile kullanılabilecek komutların tam listesine /? Parametresiyle ulaşabilriz.

Şimdi sıra geldi firewall konfigürasyonuna. Bu iş için yine netsh aracını kullanıyoruz.

Firewall default olarak açık geliyor. Bu durumu değiştirmek için şu komutları kullanabiliriz.
“netsh firewall set opmode enable” è Firewall’u aktif hale getirir.
“netsh firewall set opmode disable” è Firewall’u kapatır.

Firewall’dan port açmak için ise şöyle bir komut çalıştırılmalıdır.

Örnek olarak Remote Desktop portunu açıyorum.
“netsh advfirewall firewall add rule name=”Remote Desktop” dir=in Protocol=TCP localport=3389 action=allow”

Firewall konfigürasyonunu da yaptıktan sonra sıra bölgesel ayarlara ve zaman ayarlarına geldi.

Standart olarak komut satırından “time” ve “date” komutlarını kullanarak saat ve tarih bilgisini görüntüleyebilir, ihtiyaca göre de değiştirebiliriz.

Fakat komut satırından bölgesel ayarlar, klavye ayarları ve zaman dilimi ayarlarını yapmamız mümkün değil.

Bunun için Server Core ile birlikte yüklü gelen iki adet control panel öğesini kullanacağız.

Bunları açmak için gerekli komutlar şunlardır.
“control intl.cpl” è Regional and Language Options’ı açar.
“control timedate.cpl è Date and Time’ı açar.

Son olarak sistem özelliklerine söyle bir göz atalım.

Bunun için komut satırına girmemiz gereken komut;
“systeminfo”

Bu komut sayesinde sistemimiz hakkında birçok bilgi edinebiliriz. Komutun çıktısı şu şekilde.

Exchange Server 2007

2007-02-04T20:09:00.000+02:00

Beraberinde getirdiği yenilikler ile heyecan verici yeni bir dönem açacağa benzeyen Exchange 2007 ‘nin kurulumunun aşamalarına ve yeni gelen bazı özelliklerini şöyle bir inceleyelim.

Henüz Beta 2 versiyonuna sahip olduğumuz (code name Exchange12) Exchange 2007 mail hizmetini daha güvenli ve daha esnek bir yapıya kavuşturacağa benziyor. Saha uygulamalarında şirket mail sunucu yapısı artık rol bazlı tasarlanabilecek böylelikle çok katmanlı güvenli mail yapılarına sahip olabileceğiz.

Exchange 2007 64 bit yapısı ile hayatımıza girdiğinde donanımsal olarak da yapımızı yenilememizi gerektirecek .

Öncelik ile Exchange 2007 kurulum öncesi ihtiyaçlara göz atalım.

Donanımsal İhtiyaçları;

İşlemciler

Intel Pentium veya uyumlu 800 megahertz (MHz) veya daha hızlı 32-bit işlemci (Beta için)
x64 mimarisi tabanlı Intel Xeon veya Intel Pentium ailesi işlemciler (Intel® Extended Memory 64 Technology (Intel® EM64T) destekleyen)
x64 mimarisi tabanlı AMD Opteron veya AMD Athlon 64-bit işlemci

UYARI!: Intel Itanium IA64 işlemciler desteklenmiyor.

Memory

Minimum: 1 gigabyte (GB) RAM (buna ilave olarak her mailbox için 7 MB )
Önerilen : 2 gigabyte (GB) RAM (buna ilave olarak her mailbox için 10 MB )
Paging File boyutu sunucunun RAM ‘inden fazla olması önerilir.

Harddisk

En az 1.2 GB boş alana ihtiyacınız olacak yükleme yapılacak disk üzerinde.Buna artı olarak da 500 MB alana ihtiyacınız olacak yükleyeceğiniz her Unified Messaging (UM) dil paketi için. 200 MB sistem sürücüsünde boş alanınız olmalı.

Yazılımsal İhtiyaçlar;

İşletim Sistemi

32-bit Beta 2 Exchange Server 2007 için Microsoft Windows Server 2003 Service Pack (SP) 1 veya Windows Server 2003 R2. Enterprise Edition cluster continuous replication ve single copy cluster özelliği kullanılacak ise gerekli.

UYARI!: 32 bit desteği sadece Exchange 2007 beta sürümleri için vardır.

64-bit Beta 2 Exchange Server 2007 için Windows Server 2003 x64 veya Windows Server 2003 R2 x64. Enterprise Edition cluster continuous replication ve single copy cluster özelliği kullanılacak ise gerekli.

Microsoft .NET Framework 2.0: http://msdn.microsoft.com/netframework/downloads/updates/default.aspx

NET Frameworkunuzu update edebilirsiniz.

Windows PowerShell

Bu eklentinin yüklenmesi mecburi öngörülmüştür.

Kurulum sihirbazı size yükleme için gerekli linki sağlayacak

Internet Information Service (IIS) World Wide Web Publishing servisi (W3SVC) Client Access Server (CAS) ve Mailbox server rolleri için gerekli. İlave olarak Client Access server rolü ASP.NET yüklemenizi de gerektirecektir.

Microsoft Management Console(MMC) 3.0 MMC3.0 yüklenmesi mecburidir.

Aşağıdaki linkten edinebilirsiniz.

http://www.microsoft.com/downloads/details.aspx?FamilyId=4C84F80B-908D-4B5D-8AA8-27B962566D9F

Active Directory Domain Functional Level Windows 2000 Native veya daha üstüne yükseltilmelidir. Bu operasyon yeni Exchange Servers universal grouplarının kurulum aşamasında oluşturulabilmesi için mecburidir.

Exchange Server 5.5 sunucular forest içinde bulunmamalıdır.
Exchange 2003 sunucular Exchange Server 2003 Service Pack 2 yüklü olmalılar
Exchange 2000 sunucular Exchange 2000 Server Service Pack 3 yüklü olmalılar.

Exchange 2007 ve Yeni Gelenler

Elbette köklü değişiklikleri gelen Exchange 2007’in bildiğimiz bir çok özelliğin de geliştirilmiş olduğunu söyleyebiliriz. Dikkat çekici bellibaşlı özellikleri sıralayalım .Exchange Management Console Exchange Management Console sayesinde bütün Exchange organizasyonunu bir arayüz içerisinden öncekilere nazaran daha basit bir şekilde yönetmemiz mümkün .MMC 3.0 tabanlı geliştirildiği için Exchange 2007 yüklemenin şartlarından biri de MM3.0 güncellemesidir .

Bu güncellemeyi aşağıdaki linkten alabilirsiniz.

http://www.microsoft.com/downloads/details.aspx?FamilyId=4C84F80B-908D-4B5D-8AA8-27B962566D9F

Exchange Management Shell Exchange Management Shell sayesinde artık biz yöneticiler Exchange ile ilgili işlerimizi komut satırından veya scriptler ile yapabileceğiz. Hatta öyleki konsoldan yaptığımız işlemlerin komut satırından yapılışınıda görüp daha sonra bunları batch file haline getirip uygulama kolaylığına kavuşacağız. Unified Messaging Exchange 2007 Unified Messaging (UM) desteği ile çok farklı iletişim yöntemlerini kullanıcının mailbox’ında birleştirerek çeşitli platformlardan postakutularına ulaşıp kullanabilmelerini sağlayabilecek. Bu sayede Exchange 2007 içerisinde UM-enabled kullanıcılar sesli-posta, e-mail fax mesajlarına mobil cihazlar analog veya dijital telefonlar ile ulaşabilecekler. “Text to Speech özelliği” ile email lerini dinleyebilecek Calendar’larına ulaşabilecekler.

Performans Gelişimi Exchange 2007 64-bit mimarisi üzerine tasarlanıp geliştirildiği için performans ve kapasitesi de buna bağlı olarak artmış oldu.

Buna ilave olarak da

Exchange Server 2007 daha fazla sayıda storage grup ve database desteğine sahip oldu.

Availability Exchange 2007 ile gelen kurulum rolleri sayesinde artık çok sunuculu ortamlarda Hub Transport server rolu yüklü bir site da mail akışı load balancing sayesinde daha efektif hale getirilebilecek ve hatta Hub Transport sunucunuzun devredışı kalması durumunda bir diğeri otomatik olarak görevlenecek.

High availability Exchange Server 2007 Continuous Replication özelliği ile Mailbox sunucularının High Availbility ‘sini sağlamaktadır. Bu özelliğin kullanımının üç çeşidi vardır bunlar; Local Continuous Replication (LCR), Cluster Continuous Replication (CCR), ve Single Copy Clusters (SCC). Continuous replication özelliği log shipping mantığı ile kullanımdaki storage group’un bir kopyasının alınmasıdır. LCR tipinde kopya aynı sunucuda konuşlanırken CCR ortamında, cluster içinde passive node üzerinde tutulur.(Exchange 2007 ‘nin Active-Active cluster desteği yok) WebReady Document Viewing OWA kullanırken mailiniz ile gelmiş ekli dosyaların HTML olarak görüntülenmesi için dokumanın oluşturulduğu programın makinanızda yüklü olmasına gerek olmaması özelliği (Word, Microsoft Excel, Microsoft PowerPoint ve PDF dosyaları için). Örneğin attachment olarak yollanmış bir word dökümanın açılması için client makinada Ofisin kurulu olması gerekmeyecek. Auto-discover Outlook 2007 clientlarınızın exchange ayarlarını yaparken sunucu ismini bilmelerine gerek kalmadan sunucuya ulaşmaları mümkün hale geldi. IIS eklenmiş yeni bir virtual directory ve DNS’ eklenecek bir A record sayesinde sayesinde kullanıcılarımız domaine üye olsun veya olmasın email adres ve parolalarını kullanarak Exchange sunucu ayarlarını yapabiliceklerIntra-Org Encryption Exchange 2007 organizasyon içerisindeki mail akışını default olarak encrypt eder. SSL ve TLS gibi güvenlik önlemleri için gerekli sertifikalar kurulum sırasında oluşturulur . Bu sayede güvenli iletişim için gerekli altyapı sağlanmış olur.

Exchange 2007 Rolleri

Client Access

İstemcilerinizin POP3 ,IMAP ActiveSync OWA kullanmaları için gerekli roldür.Bir başka deyiş ile client makinalar Outlook harici bir yöntem ile mailbox larına ulaşacaklar ise yüklenmesi mecbur bir roldür. Autodiscover özelliği için de gerekli roldür.

Edge Transport

Daha evvelki dökümanlarda gateway server olarak da adlandırılan bu rolün amacı perimeter networke kurularak olası atak yapılabilecek alanın daraltılmasıdır. Bu rol bize Smart Host ve SMTP Relay olanağı sağlayacaktır. Üzerine kurulu ADAM sayesinde bütün recipient ve ayar bilgisi kendi üzerinde depolanır. EdgeSync sayesinde tek yönlü bir replikasyon yapabilir. Virüs ve AntiSpam kontrolü de bu rolün görevidir.

Hub Transport

Edge Transport rolüne sahip serverdan email leri alıp şirket içi ulaştırılmasından sorumlu bir başka deyişle de mail akışından sorumlu rolümüzdür. Bazı durumlarda Edge Transport rolü kurulumu yapılmadı ise direk olarak internet ile ilişkili olacak roldür. Hub Transport rolü de istenirse antivrüs ve spam kontrolü yapabilir. Transport ,Journaling kurallarının uygulanmasından da sorumludur. Ayar bilgileri Active Directory içerisinde tutulur.

Mailbox

Kullanıcı mailbox’larını Public Folder’ları tutan roldür.

Unified Messaging

Exchange 2007 ile gelen en dikkat çekici yeniliklerden biri olan Unified Messaging sayesinde SesliPosta Fax gibi iletişim yöntemleri ve bu bilgilere Speech to Text gibi teknolojiler ile herhangibir yerden herhangibir telefon ile ulaşabileceğiz. Bu özelliklerin kullanılabilmesi için gerekli rolümüz de Unified Messaging rolüdür.

Exchange Server 2007 Kurulumu

Kurulumdan önce domain seviyesini Native Mode veya Windows 2003 seviyesine yükseltelim . Önceki sürümlerde IIS bileşenlerinden SMTP NNTP servislerini kurmamız kurulumun şartlarından idi. Artık Exchange Server 2007 kendisi bunu builtin olarak sağlıyor.

UYARI! : Bu işlem geri dönüşü olmayan bir işlemdir.

Kurulum son derece basitleştirilmiş bir arayüz ile başlıyor.

Arayüzde belirtilen bileşenler bilgisayarınızda yüklü değil ise size linki sağlanarak kolayca indirmeniz mümkün hale getiriliyor.

Bu pencerede oluşan hataların Microsoft’a yollanmasını sağlayabliiyoruz. Böylelik ile oluşan hatanın bilinen biz çözümü olması durumunda size yollanan feedback içinde sağlanan link sayesinde problemi çözmeniz mümkün olacak. Bu özelliği kullanabilmek için burada Yes seçeneği işaretlenmeli.

Typical seçeneği bize tipik bir şirket profili için gerekli rollerin yüklenmesini sağlar. Eğer Çok sunuculu bir kurulum düşünülüyor ise Custom seçeneği ile seçimimizi özelleştirebiliriz. Bu sayede farklı sunuculara farklı rollerde kurulumlar yapmak da mümkün

Şirket bünyesindeki kullanıcılarımızın Outlook 2007 öncesi sürümlere sahip olup olmadıklarını belirtmeliyiz. Belirtmeyip No dersek Public Folder’lar oluşturulmayacaktır.

Son kontrol işlemleri bittikten sonra kurulum işlemleri başlayacaktır. Kurulum sihirbazı Exchange Best Practices Analyzer (ExBPA) ile tümleşik çalışması sayesinde olası uygulama problemlerini göstererek kurulumun daha efektif yapılabilmesini sağlıyor. Kurulumdan bittikten sonra Exchange yönetim konsolunu açtığımızda gayet sade olarak dizayn edilmiş MM3.0 tabanlı bir arayüz bizi karşılıyor. Exchange 2007 konsolunun diğer sürümlerden en ayırıcı farkı derinlik olarak artık yapmak istediğimiz işlem için alt alta açılan düğümlerin olmaması. Ve elbet herkesin dikkatini çekecek olan bir başka özellik de konsoldan mailbox oluşturabilmemiz gibi işlemlerimizi kolaylaştıran eklemeler. Yaptığımız işlemden sonra komut bazlı yapılışının gösterilmesi istenildiğinde sistem yöneticilerini bunları kullanarak batch dosyalar oluşturabilmesini sağlayacak.

Exchange 2007 Beta 2 Download

http://www.microsoft.com/technet/prodtechnol/exchange/2007/downloads/beta.mspx?wt.mc_ID=PreviewHero

Group Policy Management Console

2007-02-04T19:23:00.000+02:00

Sistem yöneticilerinin Group Policy yönetiminde işlerini bir hayli kolaylaştıracak bir eklenti olan Group Policy Management Consol u ele alacağız.

Bu eklentiden önce sistemimizdeki Group Policy Object’lerini yönetmek için Active Directory Users and Computers ve Active Directory Sites and Services gibi asıl amacı Group Policy Object’lerinin yönetimi olmayan birden fazla eklentiyi kullanıyorduk.

Bu eklenti sayesinde sistem yöneticileri tüm Group Policy yönetimini tek bir arayüz kullanarak gerçekleştirebilecekler ve bunun yanında, mevcut Group Policy Object’lerinin yedeğinin alınması, yedeklerden geri yüklenmesi vb. gibi önceden üçüncü parti yazılımlar kullanarak gerçekleştirilebilen yeni özellikleri de kullanabilecekler.

Group Policy Management Console ile gelen yeni özelliklere değinmeden önce Group Policy Management Console (GPMC) ile neler yapılabildiğine göz atalım.

Öncelikle Group Policy Management Console’u http://www.microsoft.com/windowsserver2003/gpmc/default.mspx adresinden indirmeniz gerekiyor.

Bunun yanında Group Policy Management Console’u sadece Windows XP ve Windows 2003 yüklü işletim sistemlerine kurabilirsiniz. Eğer kurulumu Windows XP yüklü bir bilgisayara yapacaksanız bu bilgisayarda Windows XP Service Pack 1, Microsoft .NET Framework ve KB 326469’daki post-SP1’in yüklü olması gerekiyor.

Group Policy Management Console’u kullanarak Windows 2003 ve Windows 2000 (Service Pack 2 ve daha yukarı bir service pack yüklü olmalı) Active directory domainlerindeki Group Policy Onject’lerini yönetebilirsiniz.

Group Policy Management Console’u açtığınızda karşınıza Şekil-1’de gösterildiği gibi bir konsol çıkacaktır.

Şekil-1: Group Policy Management Console

Group Policy Management Console’unun sol tarafındaki kısmında dört temel node bulunur.

Bunlar sırasıyla :

· Domains
· Sites
· Group Policy Modeling
· Group Policy Result

Varsayılan olarak Group Policy Management Console’un çalıştırıldığı bilgisayarın ait olduğu forest ve domain listelenir. Bu listeye başka domainler ve forest’lar da ekleyebilirsiniz. Yalnız eğer ekleyeceğiniz forest bir Windows 2000 forest’ı ise bu durumda o forest’a ait Group Policy Modeling node’u görülmeyecektir.

Domain node’unu genişlettiğinizde bu domain’deki Domain Controllers konteynırı ile sizin sonradan oluşturduğunuz Organizational Unit (OU)’lerin yanında, Group Policy Objects ve WMI Filters adlı iki tane daha node bulunur. Active Directory’de oluşturduğunuz GPO’ları Group Policy Objects kısmında görebilirsiniz.

İlgili GPO’ya tıkladığınızda Group Policy Management Console’un sol tarafında bu GPO üzerinde Group Policy Management Console ile yapabileceğiniz ayarlardan bazıları listelenecektir. Sol taraftaki pencerede Scope, Detail, Settings ve Delegation olmak üzere dört tane sekme bulunur. Scope sekmesinde oluşturduğunuz bu GPO’nun etkileyeceği alanı belirleyeceğiniz ayarlar bulunuyor. Bu sekmedeki Links kısmında GPO’nun hangi site, domain yada OU’ya bağlandığını görebiliyorsunuz. Ayrıca bu bağlantıların Enable ve Enforce özelliklerinin ne durumda olduğunu yani aktif mi yoksa pasif mi olduğunu da görebilirsiniz. Security Filtering kısmında bu GPO’nun kimlere uygulanacağını belirleyebiliyorsunuz. Hatırlatma yapmak gerekirse, bir GPO’nun bir kullanıcı yada bilgisayara uygulanabilmesi için o kullanıcının yada bilgisayarın veya bunların dahil oldukları gruplardan herhangi birisinin o GPO üzerinde Read ve Apply Group Policy izinlerinin olması gerekiyor. Sizin Security Filtering kısmına ekleyeceğiniz her kullanıcı, bilgisayar yada gruba bu GPO üzerinde Read ve Apply Group Policy izinleri verilecektir. Son olarak bu sekmenin alt kısmında bulunan WMI filtering kısmını kullanarak önceden oluşturmuş olduğunuz WMI filtrelerinden birisini bu GPO’ya bağlayabiliyorsunuz. WMI filtering konusunda detaylı bilgiyi yazının ilerleyen kısımlarında bulabilirsiniz.

Details tabına tıkladığınızda ise karşınıza Şekil-2’deki gibi bir ekran çıkacaktır. Bu ekranda GPO’nun bulunduğu domain, GPO’nun sahibi (owner), ne zaman oluşturulduğu ve en son ne zaman bu GPO’da bir değişiklik yapıldığı gibi bilgilerin yanında versiyon bilgileri ile bu GPO’nun Unique ID’si bulunur. Son olarak GPO Status kısmında ise bu GPO’nun o anki durumu ile alakalı bilgiler bulunur ve GPO’nun durumunda herhangi bir değişiklik yapılacaksa buradan yapılır. Bir GPO’nu durumu, All settings disabled (GPO’yu pasif yapar), Computer configuration settings disabled (GPO’nun sadece User Configuration kısmı aktif olur ve işlenir), User configuration settings disabled (GPO’nun sadece Computer Configuration kısmı aktif olur ve işlenir) ve Enabled (GPO’yu aktif yapar) olmak üzere dört farklı durumda olabilir. Buradaki Computer configuration settings disabled ve User configuration settings disabled ayarları bazı durumlarda işinize arayabilir. Örneğin oluşturduğunuz GPO’da sadece User Configuration kısmındaki policy’lerde tanımlama yaptıysanız bu GPO’nun Computer Configuration kısmını disabled ederek bu GPO’nun işlenme süresini hızlandırabilirsiniz.

Şekil-2: Oluşturduğunuz bir GPO’nun detaylı bilgilerine Details tabından ulaşabilirsiniz.

Settings tabına tıkladığınızda ise belirli bir süre bekledikten sonra (Bu süre zarfında ekranda Genereting report… yazısı görünür) o GPO’da tanımlı policy’lerin listelendiği ve Şekil-3’de bir benzerini görebileceğiniz bir rapor gösterilir. Bu rapor sayesinde GPO’da tanımladığınız policy’lerin hepsini tek bir pencerede görebilirsiniz. Bu raporda GPO’daki tanımlanmamış policy’ler yani Not Configured olarak kalan policy’ler listelenmez.

Şekil-3: Bir GPO’da tanımlı bulunan policy’lerin listesini almak için Settings tabını kullanabilirsiniz.

Delegation tabına tıkladığınızda ise bu GPO üzerinde kimlerin hangi haklara sahip olduğunu görebileceğiniz Şekil-4’deki gibi bir pencere çıkacaktır. Eğer bu GPO üzerinde birilerine hak vermek istiyorsanız yada verilmiş bir hakkı geri almak istiyorsanız Add yada Remove butonlarını kullanabilirsiniz. Bir GPO üzerinde buradan verebileceğiniz haklar Read, Edit Settings ve Edit Settings, delete, modify security olmak üzere üç tanedeir. Read hakkına sahip kullanıcılar bu GPO’da tanımlı policy’lerin neler olduğuna bakabilir, Edit Settings hakkına sahip kullanıcılar bu GO’daki policy’leri değiştirebilir ve son olarak Edit Settings, delete, modify security hakkına sahip kullanıcılar ise bu GPO’daki policy’leri değiştirebilir, bu GPO’yu silebilir ve bu GPO’nun izinleri üzerinde değişiklik yapabilir.

Şekil-4: GPO üzerinde kimlerin hangi haklara sahip olduğunu görmek istiyorsanız Delegation tabını kullanabilirsiniz.

Oluşturduğunuz GPO’ları GPMC’deki site, domain yada OU’lardan istediğinize bağlayabilirsiniz. Bunun için yapmanız gereken ilgili site, domain yada OU üzerinde mouse ile sağ tıklamak ve Şekil-5’de gösterilen menüden Link an Existing GPO... seçeneğini seçerek karşınıza gelecek Select GPO başlıklı pencereden ilgili GPO’yu seçmek olacaktır. Burada açılan menüdeki Create and Link a GPO Here... seçeneğini seçerseniz seçtiğiniz yere bağlanmak üzere yeni bir GPO oluşturulacak ve buraya bağlanacaktır.

Şekil-5:Oluşturduğuz GPO’ları site, domain yada OU’lara bağlayabilirsiniz.

Group Policy’nin etki alanını (scope) belirleyen bir diğer unsur ise WMI filtreleridir. Örneğin oluşturacağınız WMI filtreleri sayesinde GPO’nun sadece Windows XP yüklü bilgisayarları etkilemesini yada RAM miktarı belirli bir değerin üzerinde olan bilgisayarlara uygulanmasını sağlayabilirsiniz. WMI filtreleri WQL (WMI Query Language) olarak adlandırılan ve SQL dili ile benzerlik gösteren sorgu dili ile yazılırlar. Şekil-6’da görülen örnek WMI sorgusunda bu WMI filtresinin bağlandığı GPO’nun sadece Windows XP yüklü bilgisayarlara uygulanmasını sağladık.

Şekil-6:WMI filtrelerini kullanarak GPO’nun etki alanına çok daha fazla esneklik kazandırabilirsiniz.

Group Policy Modeling kısmında ise çalıştıracağınız Group Policy Wizard sayesinde Active directory objelerinin konteynırlar arasında taşınması durumunda bu objelere etki edecek Group Policy ayarlarının ne olacağını önceden öğrenebilirsiniz. Örneğin Satış adlı OU’daki bir kullanıcıyı Pazarlama adlı OU’ya taşımanız durumunda bu kullanıcıya etki edecek GPO ayarlarının neler olacağını önceden öğrenebilirsiniz.

Group Policy Result kısmında çalıştıracağınız Group Policy Result Wizard sayesinde bir kullanıcıyı yada bilgisayarı etkileyen GPO ayarlarının o an için neler olduğunu görebilirsiniz. Bu sayede eğer kullanıcının yada bilgisayarın bulunduğu site, domain yada OU’ya bağlanan GPO’ların tamamının bu kullanıcı yada bilgisayar üzerindeki en son etkisinin ne olduğunu görebilirsiniz.

Group Policy Management Console ile birlikte gelen en güzel özelliklerden birisi de GPO’ların yedeğini alınması işlemini gerçekleştirebilmemiz. Eğer tek bir GPO’nun yedeğini almak istiyor yada yedekten geri yüklemek istiyorsanız bu GP’nun üzerine mouse ise sağ tıklayıp açılan menüden Back Up yada Restore from Backup seçeneğini seçmeniz gerekiyor. Eğer mevcut GPO’ların tamamını yedek almak istiyorsanız bu durumda Group Policy Objects üzerine mouse ile sağ tıklayıp Back Up All seçeneğini seçmelisiniz. Önceden almış olduğunuz yedekleri görmek ve bu yedekleri yönetmek istiyorsanız açılan menüden Manage Backups seçeneğini seçerek Şekil-7’deki pencereyi açmanız gerekiyor. Bu pencere sayesinde sisteminizde önceden almış olduğunuz GPO yedeklerini görebilir, bu yedekleri geri yükleyebilir, silebilir ve View Settings butonuna basarak bu GPO yedeğindeki ayarları bir rapor halinde görebilirsiniz.

Şekil-7: GPO yedeklerinizi Manage Backups penceresi yardımıyla kolayca yönetebilirsiniz.

Longhorn Release Öncesi

2007-02-03T17:15:00.000+02:00

Microsftun son server işletim sistemi olan Longhorn'un release edilmeden önceki son halinin nasıl olduğunu ve nelere dikkat etmemiz gerektiğini şöyle bir inceleyelim.

Windows Longhorn kurulum öncesi dikkat edilecek hususlar aşağıdaki gibidir;

Yedek

Windows 2003 yüklü bir bilgisayara longhorn yüklemeden önce yapılması gereken en önemli şey yedeğinin alınmasıdır. Boot olan bölüm yedeğinin alınacağı disk alanının en az 1GB olması lazım. Backup öncesi gizli olan dosyaların normal hale döndürüldüğünden emin olun. Bazı 3. parti yazılımlar ile alınan systemstate yedeklerin çalışması garanti değildir. Dolayısıyla bu tür yazılımlar için dikkat edilmesi gerekmektedir. Gerekirse ASR backup yapılabilir. Windows system recovery ile alınan yedekler distributed file system replication restore işlemi authoritative dir. Restore işleminin non-authoritative olması için aşağıdaki komutu girmek gerekmektedir.

WBADMIN START BMR otheroptions –nonauth

Windows Network Load Balancing

Bu özelliğin silinmesi veya kurulması işlemi server manager üzerinden gerçekleşmektedir. Bu işlemi ipv4 sistemler tarafından desteklenir. Bu işlem ipv6 da hata vermektedir.

Sql Server Cluster

Sql server'ı cluster üzerine kurmaya çalıştığınız zaman cluster kaynakları görmeyecektir. Bunu önlemek için yapılması gereken şey diskleri kendi gruplarına taşımak olacaktır.

Zamanlanmış Görevler

Daha önceden At.exe ile alınan hazırlanmış olan önceki versiyon işletim sistemlerindeki görevler bu sistemlerde etkileşimli bir şekilde çalışmayacklardır. Bunların etkileşimli bir şekilde çalışması için yeni versiyon schtask.exe komutunun kullanılmasını sağlamaktır. Bu komutu kullanırken yönetimsel hak isteyen işlemler olduğunda administrator haklarına sahip komut satırı açıp, onun üzerinden bu işlemleri gerçekleştirebiliriz.

Dizin Servisi

Windows 2000 server veya Windows server 2003 olan domain ortamlarına eklenecek olan Longhorn için daha önceden şemayı güncellemek gerekmektedir. Bu işlemler esnasında Schema master ve Infrastructer master rollerinin güncellenmesi gerekmektedir. Eğer bu işlem katılımsız kurulum ile gerçekleşiyorsa daha önceden bu masterların güncellenmesini yapmak gerekiyor. Bu işlemlerden sonra ancak kurulum başlar.

Forest’ı Hazırlamak

öncelikle schema master rolü olan makineden enterprise admin, schema admin, domain admin gruplarından biriyle logon olunur. Daha sonra Longhorn dvdsinde \source\adprep klasörü kopyalanır.
Komut satırından kopyaladığımız klasöre kadar erişim yapıyoruz.

komut satırında adprep /forestprep çalıştırılır.

eğer read-only domain controller kurulacaksa o zaman adprep /rodcprep komutu çalıştırılır.
değişikliklerin olmasını sağlamak için replikasyon yapılmalıdır.

Domaini Hazırlamak

Infrastructure master rolü olan bilgisayardan domain admin accountu ile logon olunur. Daha sonra Longhorn dvdsinde \source\adprep klasörü kopyalanır.

komut satırından kopyaladığımız klasöre kadar erişim yapıyoruz

komut satırında
Windows 2000 domaini için adprep /domainprep/gpprep
Windows 2003 domaini için adprep /domainprep komutu çalıştırılır.

değişikliklerin olmasını sağlamak için replikasyon yapılmalıdır.

Dosya Sistemi

NFS (Network File System): Bu servis varsayılan olarak tanımlı olmayan kullanıcıların erişimine kapalıdır. Bunu kullanmak için manuel olarak müdahale etmek gerekmektedir. Aşağıdaki adımları izleyerek bunu gerçekleştirebiliriz.

Lokal veya domain user hesabı oluşturulur.
Bu hesap lokal hesaba eklenir.
Regedit.exe başlatılıp aşağıdaki anahtar eklenir.
Hkey_local_machine\system\currentcontrolset\services\nfsvr\parameters anahtarı içerisinde yeni string değeri oluşturulur ve
UnmappedUnixUserUsername ismi verilir. Bu değer için ilgili hesabın buraya izni ayarlanır.

Shadow Copy

Daha önceden oluşturulmuş olan volume shadow copy ve restore noktaları silineceklerdir. Yapılması gereken şey kurulum işleminden hemen sonra bu noktaları tekrar oluşturmak olacaktır.

Oyunlar

Direct3D mode ile çalışan oyunlar çalışmayacaklardır. Bu oyunları çalıştırmak için üretici firmalardan opengl sürücüleri yüklemek gerekmektedir.

Grup İlkeleri

Upgrade işleminden sonra yerel ilke ayarlarının yeniden düzenlemesi gerekecektir.

Microsoft Exchange

Exchange 2003 sp2 versiyonu bu bu sürümde desteklenmemektedir. Bunun yerine 2003 server üzerinde çalıştırmak gerekmektedir. Fakat posta istemcileri desteklenmektedirler.

2007 Office

Sadece ofis 2007 release öncesi Longhorn un beta2 versiyonunda desteklenmektedir, öncesi desteklenmemektedir. Bu sürümden öncekiler desteklenmemektedir. Ofis 2007 kurulumu gerçekleştikten sonra geri dönüş noktası oluşturulmamaktadır. Bunun için yapılması gereken şey daha önceden manuel olarak bu noktaları oluşturmaktır.

Microsoft Operations Manager (MOM)

MOM 2005 SP1 li bu versiyonda desteklenmemektedir. Yapılması gereken şey 2003 server üzerine bunu kurmak olacaktır. Fakat MOM agent longhorn tarafından desteklenmektedir.

Network ve İletişim

telnet client ve telnet server default olarak kurulu gelmemektedir. Bu servisleri daha sonradan özelliklerden ekleyebilirsiniz.

WINS servisini komut satırından kurmamız gerekecektir. Bunun için yapılması gereken şey administrator hesabı ile %systemroot%\system32 klasörüne komut satırından erişmek olacaktır.

Aşağıdaki komut ile wins servisini kurmuş olacağız
Wins_b2install /install

İnternet connection sharing açıksa DNS sorguları aniden başarısız olabilir.
İnternet connection servisini yeniden başlatmak gerekebilir.

Encrypting File System

Eğer çöp kutusunda daha önceden sildiğiniz şifreli dosyalar varsa bilgisayarın açılması işlemi beş dakika kadar olabilir. Bunu önlemenin yolu dataları silmeden önce şifrelerini çözüp ondan sonra silme işlemini yapmak olacaktır.

Active Directory Rights Management Services

Daha önceden kurulu olan Rms server rolü için aşağıdaki komut satırı yazılarak uninstall edilebilir.
\rms\Microsoft.RightsManagementsServices.Provision.exe –u parametresi ile bunu yapabilirsiniz.

Security Configuration Wizard

Bu sihirbaz ile çeşitli server rollerini etkinleştirmek mümkün olacaktır.
Bunun için yapılması gereken şey aşağıdaki adımlar gibi olacaktır.
Eğer scw çalışıyorsa bunu kapat
Systemroot\security\msscs\kbs
Lokalde oluşturulan xml dosyası üzerinde istenilen şey aktifleşmektedir.

Smtp

Smtp server özelliği bir kere yüklendikten sonra onu direkt olarak kaldıramazsınız. Smtp server özelliğini kurduğunuz anda bazı dosyaların manuel olarak güncellenmesi gerekmektedir.

1. Server yönetim konsolundan IIS özelliği işaretlenir. Eş zamanlı olarak FTP publishing servisininde işaretli olduğundan emin olun.

2. Komut satırında %windir%\inetsvr dizinine ulaşılır ve
Regsvr32 smtpsnap.dll Komutu çalıştırılır.

3. Mmc konsolu kapatılıp restart edilir.

System Management Server

Sp2 li system management server (SMS with SP2) şu anki Longhorn versiyonunda desteklenmemektedir. Sms sp2 de agent Longhorn'un bu sürümünde desteklenmektedir.

SQL Server 2005

SQL Server 2005 SP1 in tüm sürümleri Longhorn'un bu sürümünde desteklenmektedir.
Tavsiye edilen kurulumun bir test makinesi üzerine yapılmasıdır.
SQL server kurulum işlemi yapılırken öncelikle SQL server 2005 in full versiyonu kurulup ondan sonra SP1 kurulur.

Unix Bazlı Uygulama Altsistemleri

Unix bazlı uygulamaların hiçbiri Longhornun itanium tabanlı sistemlerinde desteklenmemektedir.

Terminal Services

Bundan önceki işletim sistemlerinde hem terminal server hemde terminal server lisans rolleri beraber yüklenebiliyordu. Longhorn'un bu sürümünde ikisini aynı anda yükleyemiyorsunuz. Yapılacak olan önce birini sonra diğerini yüklemek olacaktır.
Terminal server kurulumu yapılırken per device yada per user seçilirken henüz konfigürasyon bitmediği için hata mesajı ile karşılaşırsınız.

Windows Media Server

Windows media server kurulduktan sonra server manager da görünmeyecektir. Kurulum işleminden hemen sonra server manager rolünü restart etmek gerekir.

2007-02-03T15:42:00.000+02:00

Active Directory © Directory Services çalışma prensipleri, veritabanı üstünde gerçekleştirilen değişikliklerin nasıl kaydedildiği, ve bu kayıt işlemlerinin performans üzerindeki etkisi, servisin sağlıklı yönetilebilmesi için gereklidir.

Active Directory (AD) © dizin hizmeti, ağa hizmet verirken, elinde bulundurduğu bilgiyi bir veritabanında tutar. Bu veritabanının tuttuğu bilgi, Active Directory Domain’ i seviyesindedir. Forest’ ta bulunan –varsa- diğer AD domain’ leri ile ilgili bilgi ise, ilgili AD domain’ inin Domain Controller (DC) ismi verilen ve AD servislerinin çalıştığı sunucular tarafından tutulur.

Active Directory, veritabanını kendi veritabanı motoru ile çalıştırır. Tüm sorgulama, ekleme, silme ve modifikasyon işlemleri, veritabanının korunması, yönetimi, saklanması, güvenliğe alınması; ESE (Extensible Storage Engine) isimli ve Active Directory © directory services’ a ait veritabanı motoru tarafından yürütülür.

Bu serideki konularımız, Active Directory veritabanının temelde nasıl çalıştığı, data modifikasyonlarının nasıl meydana geldiği, bu modifikasyonların veritabanı üstündeki performans etkileri ve ortaya çıkabilecek performans sorunlarının çözümü olacaktır.

Active Directory veritabanı, Domain Controller (DC) olarak adlandırılan, ve AD Domain’ inin yönetiminden sorumlu olan sunucu veya sunucuların yerel diskinde tutulur. Veritabanının fiziksel lokasyonu, varsayılan kurulum sonucu olarak %windir%\NTDS\‘dir. Veritabanı dosya ismi ise, yine varsayılan olarak, ntds.dit ‘tir. Bunlarla beraber, veritabanı sistemi, sadece veritabanı dosyası ile çalışamaz. Tüm işlemlerin geçici olarak yer aldığı, değişikliklerin veritabanına yazılmadan once çeşitli sebeplerden (ilerleyen kısımlarda açıklanacaktır) ötürü saklandığı ve transaction log olarak adlandırılan edb.log isimli dosya da, Active Directory dizin hizmetinin çalışmasında kritik rol oynar. Üçüncü kritik veritabanı bileşeni ise kontrol noktası olarak çalışan ve ESE checkpoint olarak adlandırabileceğimiz ebd.chk dosyasıdır. Bu dosyanın görevi ise, öncelikle transaction log’ u olan edb.log a yazılan modifikasyon bilgisinin - ki bundan sonra bu modifikasyon işlemlerini transaction olarak adlandıracağız – veritabanı olan ntds.dit içine, düzgün ve tutarlı olarak yazılıp yazılamadığını konrol etmektir.

Bunlardan başka, veritabanı sistemine hizmet eden, ve disk üzerinde boş alan kalmama ihtimaline karşılık, sadece alan işgal etmek üzere bulunan, ve acil durumlarda (disk’ in dolması) silinerek, servisin kullanımına alan yaratan reserved log dosyaları vardır. Iki tane olmak üzere, 10’ ar MB boyuta sahip olan bu dosyaların ismi ise res1.log ve res2.log’ dur.

Veritabanına Yazma İşlemi (Transaction)

Şimdi Active Directory veritabanı sisteminin nasıl çalıştığını, sıradan bir transaction işleminin nasıl gerçekleştiğini inceleyeceğiz.

Bir administrator, veritabanı üzerinde bir değişiklik yaptığı zaman, mesela bir kullanıcı hesabı yaratıldığı, silindiği ya da modifiye edildiği zaman; bir yazma isteği (write request) oluşur. Bu yazma talebi bir işlem, yani teknik adıyla da bir transaction olarak yakalanır. Bu transaction, ilgili değişim bilgisi ve ilgili metadata (versiyon sekans numarası, değişikliğin yapıldığı tarihi ve saati belirten time stamp ve ilgili değişikliği kaydeden domain controller sunucunun globally unique identifier (GUID) ‘ i) dan oluşur. Örnek olarak bir objenin bir attribute’ u değiştirildiği zaman, değişim bilgisi; ve versiyon sekans numarası, değişikliğin yapıldığı tarihi belirten time stamp ve ilgili değişikliği kaydeden domain controller sunucunun globally unique identifier (GUID) ‘ ını belirten bir metadata, bu değişimin transaction’ ını oluşturur.

Bir transaction, Active Directory’ ye bir yazma isteği (write request) oluşunca başlar. Transaction; içinde, ilgili değişiklik bilgisini ve ilgili metadata’ yı barındırır ve AD bu transaction’ ı, hafızada bulunan transaction buffer’ a yerleştirir. Bundan sonra ESE, buffer’ a yerleştirdiği bu transaction’ ı, transaction log’ una yazar (ebd.log). Bu, transaction’ un sağlıklı birr şekilde kaydedilmesini sağlamış olur. Transaction, log dosyasına güvenle yerleştirildikten sonra; ESE, bu transaction’ u, hafızadaki transaction buffer’ dan, DC’ nin yerel sabit diskinde bulunan, AD veritabanı dosyası olan ndts.dit içine de yerleştirir. Veritabanına işlenmemiş transaction’ lar, log dosyasında kalırsa, hatalar oluşabilir. Bunun için ESE, checkpoint dosyası olan edb.chk kontrol ederek, log dosyasında bulunan ve henuz veritabanına aktarılmamış, veritabanına yazılması gereken transaction bulunup bulunmadığına baker. AD, her transaction’ un, veritabanına başarıyla aktardığını onaylamak için, ntds.dit ile edb.log dosyalarını karşılaştırır. Daha sonra ise, edb.chk dosyası, ilgili transaction’ un, veritanabına yazıldığına dair, güncellenir. Eski log dosyalarındaki tüm transaction’ lar veritabanına yazıldıktan sonra; AD, eski dosyalarını siler.

Transaction’ ların Etkisi ve Performans Sorunu

Diske data yazılırken, devamlı sektorlere yazılır ve data silindikçe, disk üzerinde boş alanlar bırakır. Buna fragmentation denir. Data silinip de yeni data yazılırken de, bu dağınık şekilde duran ve devamsız sektorlere yazılır.

Data, bu dağınık alanlara yazılırsa da, datanın okunma performansı, ve dolayısıyla da, veritabanı performansı düşer. Garbage Collection (ilerki konulda değinilecektir) sürecinde; -varsayılan olarak 12 saatte bir- Active Directory, online defragmentation işlemi gerçekleştirir. Bu işlem sırasında, veritabanının fragmentasyona bağlı performans kaybı ortadan kalkar ve online defragmentation işlemi sırasında, Active Directory Directory Service domain controller sunucu, hizmet vermeye devam edebilir.

Bununla birlikte, online defragmentation, performans sorununu giderirken, veritabanının boyutunu optimize etmez ve dosya boyutu büyümeye devam eder. Veritabanı boyutunu azaltmak için, offline defragmentation yapılması gerekmektedir. Bu işlem, original veritabanı dosyasının içindeki bilgiyi kullanarak; yeni, düzenli bir veritabanı dosyası yatatır (compact). Offline defragmentation sırasında, transaction log’ unda bulunan ve henuz veritabanına aktarılmamış tüm transaction’ lard a, bu yeni yaratılan compact veritabanına yazılır. Ancak unutmamak gereken bir durum vardır; bud a, offline defragmentation işlemi sırasında, domain controller, sisteme hizmet vermeyecektir. Dolayısıyla, bu işlem sırasında kaybolan zamanın, iş planına uygun olması, örneğin, mesai saatleri dışında uygulanması tercih edilebilir. Online defragmentation, zaten performans sorununu çözdüğü için; offline defragmentation; sadece, veritabanı boyutunun küçültülmesi için kullanılmalıdır.

Daha önceki kısımlarda da bahsettiğimiz gibi, transaction log ve checkpoint sistemi, tek bir veritabanı altında tutulan bilginin tutarlılığını sağlar (data integrity). Ancak aynı replica’ yı tutan birden fazla Domain Controller sunucumuz varsa, veritabanının replikaları arasında da veri tutarlılığını düşünmek zorundayız.

Replikalar arası Veritabanı Tutarlılığı

Düşündüğümüzde, eğer değişiklik bir modifikasyon ya da ekleme ise; data, replikalar arası senkronize edilebilir. Ama ya eğer değişiklik bir silme işlemi olursa? Eğer silme işlemi sırasında obje tamamen silinirse, değişikliği kaydeden replica dışında kalan diğer sunucular, bu silme işlemi nasıl anlayabilecekler ve kendi replikalarını güncelleyecekler? İşte bunun için, eğer bir obje silinirse, aslında veritabanından düşürülmez (purge), bunun yerine, özel bir container olan, deleted items container’ ına taşınırlar. Bu işlemin amacı ise, diğer replikaların, bu silme işlemini güncelleyebilmelerinin sağlanması için yeterli sürenin oluşturulmasıdır. Objenin silinmesi ile veritabanından düşürülmesi arasında geçen sure, diğer replikaların, silme işlemine dair bilginin, kaynak replikadan diğer replikalara aktarılmasını garanti etmek içindir. Bu surenin sonunda, obje expired olarak işaretlenir, ve bir sonraki garbage collection sürecinde, veritabanından purge edilir. Objenin silinmesi komutunun işlenmesi ile veritabanından düşürülmesi arasında geçen sure, varsayılan olarak 60 gündür, ve yapılandırılabilir. Ancak; bu sure, sistemdeki, en uzun replikasyon süresinden daha uzun olmalıdır. Aksi takdirde, bazı replikalar, silme isteğini kaydedemez, ve silinmiş ojbe, sisteme yeniden geri gelmek durumunda kalır. Çünkü; diğer replikalar objeyi çoktan veritabanından düşürmüş olduğu için, aslında silinmiş olması gereken ama silinemeyen bu obje, diğer replikalara, yeni bir obje olarak görünebilir.

Windows Server 2003’ e giriş

2006-07-13T14:44:00.000+03:00

W2K3 ‘ ün 4 farklı sürümü bulunmakta :

Web Edition
Standart Edition
Enterprise Edition
Datacenter Edition

Web Edition
Web edition, tamamiyle kurumların web sunucusu olarak çalışacak şekilde tasarlanmıştır. Sınırsız anonim web bağlantısı kabul eder ama ancak 10 adet SMB bağlantısı kabul etmektedir. 2GB RAM ve 2 SMP CPU desteklemektedir. Fax server ve Internet Gateway olarak kullanılamaz. Terminal Server olarak kullanılamaz. Etki alanına dahil olabilir ancak etki alanı denetleyicisi olamaz. İçinde bulunan MSDE eşzamanlı 25 bağlantıyı kabul eder.

Standart Edition
4 SMP CPU ve 4 GB RAM desteklemektedir. POP3 ve SMTP sunucusu içermektedir. Network Load Balancing servisi bulunmaktadır. Cluster ve Itanium (64 bit) işlemci desteği bulunmamaktadır.

Enterprise Edition
Enterprise edition, standart edition ın özelliklerine ek olarak 8 SMP CPU ve 64 GB RAM desteklemektedir. 8 yollu kümelemeyi (Clustering) destekler. Ayrıca 64 Bit işlemcileri de desteklemektedir.
Microsoft Metadirectory Services (MMS) : AD ile dizinler, dosyaların entegre edilmesini sağlar.
Hot Add Memory : Sistem çalışırken bellek takılıp çıkartılmasına izin verir.
Windows System Resource Manager : Uygulamalara özel bellek tahsisi yapılmasına izin verir.

Datacenter Edition
Sadece üreticilerin OEM yazılımı olarak dağıtılır. 32 bit sürümü için 32 SMP CPU ve 64 GB RAM destekler.

DİKKAT ! Windows 2003 kurulum disketlerini desteklememektedir.

Sistem güncellemesi yapılırken her majör sürüm ancak kendi eş sürümüne veya üstüne yükseltilebilir.

Alt seviyedeki bir sürüme güncellemek mümkün değildir.

Nt 4.0’ dan W2K3’ e sistem güncellemesi yaparken minimum SP5 yüklenmiş olmalıdır.

Sistem güncellemesi sırasında donanım uyumluluğunu kontrol etmek için kullanılabilecek en

iyi araçlardan biri : D:\i386\winnt32.exe /checkupgradeonly

MMC konsolları oluştururken, diğer kullanıcıların MMC konsollarını kısıtlamalar dahilinde kullanabilmeleri için Author Mode dışında bir de User Mode bulunmaktadır.

Domain, tek başına bir yetki ve güvenlik sınırıdır.
Tree, aynı root namespace’ i paylaşan etki alanları tarafından oluşturulur.
Forest, aynı root namespace’ i paylaşan veya paylaşmayan domain ve treeler tarafından oluşturulur.

Group Policy’ nin kullanıcı üzerindeki etkilerini ölçmek ve incelemek için Resultant Set of Group Policy adında yeni bir GUI aracı oluşturulmuştur. Ayrıca gpresult.exe de komut satırından aynı görevi görmektedir.

Secedit.exe komutu yerine artık gpupdate.exe komutu GP ayarlarının elle güncellenmesi için kullanılmaktadır.

ASR (Automatic System Recovery) özelliği veri dosyalarının yedeğini almamaktadır. ASR bu amaçla kullanılabilecek bir yedekleme aracı değildir.

W2K’ da GC’ nin mevcut olmaması halinde Universal Gruplara üyelik denetlemesi yapılamıyor ve UPN kullanarak logon işlemi tamamlanamıyordu. Bu nedenle her siteye bir GC konulması zorunlu hale gelmişti. Ancak W2K3’ de Universal Group Membership Cachig denen uygulamayla bu durum ortadan kaldırılmıştır.

Active Directory

2006-07-13T14:14:00.000+03:00

AD Yapısını Kurmak

Active Directory kurulumu yaparken AD veritabanı ve log dosyalarının farklı fiziksel disk gruplarına yerleştirilmesi tavsiye edilmektedir.

AD kurulumunu bir cevap dosyası (answer file) ile yapmak için dcpromo /answer:answerfile komutu ile çalıştırılması gereklidir.

AD kurulumunun daha once yedeği alınmış bir AD veritabanı dosyası yardımıyla yapmak da mümkündür. Bu dosya ağ üzerinden veya bir paylaştırılmış dizinden okunabilir. Böylece replikasyonun büyük kısmının ağ üzerinden yapılması engellenmiş olur ve işlem hızlandırılabilir. Ancak alınmış yedek AD etki alanının varsayılan tombstone lifetime değerinden (60 gün) geç olmamalıdır.

Eğer yedeği alınan DC de AD, Application Directory Partition ile oluşturulmuşsa, bu yedeğin yeni bir DC ye kopyalanması mümkün değildir.

Bu modda yükleme yapmak için dcpromo /adv komutu kullanılmalıdır.

Etki alanına ilk katılan DC aynı zamanda otomatik olarak GC olarak da görevlendirilir.
Universal Group membership Caching, WAN sitelerinin bulunduğu AD ortamlarında kullanılabilir. WAN sitesinde GC bulunmadığı hallerde UPN ile logon işlemi GC den kontrol edilmesi nedeniyle uzun sürebilir. Cachin ile bu şekilde ilk logon olan kullanıcı ile yapılan kontrol sonrasında elde edilen üyelik bilgileri 8 saat süreyle site DC sinde saklı kalacaktır. Daha sonra 8 saat aralıklarla bu bilgi yenilenir.

Caching ayarları site seviyesinde gerçekleştirilir. Yani yapılan bir değişiklik sitedeki tüm sunucuları etkiler. Buna karşılık GC ayarları sunucusu seviyesinde yapılmaktadır. Yapılacak değişiklikler bu duruma gore değerlendirilmelidir.

Domain Functional Levels
W2K3’ de, etki alanlarının fonksiyonları işletme amaçlarına gore farklı olarak düzenlenebilmektedir. Böylece aynı forest içindeki farklı etki alanlarına farklı ayarlar sağlamak mümkün olmaktadır.

W2K Mixed Mode
W2K Native Mode
W2K3 Interim Mode
W2K3 Mode

W2K Mixed Mode
W2K Mixed Mode, W2K3 AD etki alanları kurulurken oluşturulan varsayılan moddur. Bu modda W2K ve W2K3 DC lerinin, daha önceki sistemlerle ( NT 4.0 DC ) konuşmaları mümkündür. Ancak bu mod, AD ile gelen bazı özelliklerin kullanılmasını kısıtlamaktadır. Örneğin ;

- Universal group membership
- Security group nesting
- Domain renaming
- Group converting

W2K3 Interim Mode
Interim Mode, doğrudan NT 4.0’dan W2K3’ e yükseltilen etki alanları için kullanılan bir moddur. Sadece NT 4.0 ve W2K3 DC lerini destekler. Interim mode W2K DC lerini desteklemez.
W2K Mixed mode ile aynı kısıtlamalara tabidir.

DOMAIN’ LERİN ÖZELLİKLERİ VE SINIRLARI

W2K Native Mode’da çalışan bir etki alanının DC si W2K3 e yükseltilirse, Domain Functional Level hala W2K Native olarak kalacaktır.

W2K etki alanına W2K3 DC eklerken ya da W2K etki alanını W2K3’ e yükseltirken öncelikle aşağıdaki işlemlerin uygulanması gereklidir :
- Forest Schema Master DC de adprep /forestprep komutu çalıştırılmalıdır.
- Domain Infrastructure Master DC’ de adprep /domain prep çalıştırılmalıdır.

Forest Functional Levels
Üç farklı mode vardır. W2K Mode, W2K3 Interim Mode, W2K3 Mode

W2K Mode

Bu forest fonksiyon seviyesinde, Forest içinde NT 4.0, W2K ve W2K3 DC lerinin varlığına izin verilmektedir. Ancak, W2K3 ile gelen tüm yeni özellikler yaklaşık olarak devre dışıdır. Sadece W2K3 GC leri replication partner olarak çalışıyorlarsa, bunlarda şema genişlemesi sonucu elde edilen yeni Attribute ların replikasyonunda optimizasyon sağlanmıştır.

W2K3 Interim Mode
NT 4.0 etki alanının ilk DC si W2K3’e yükseltildiğinde forest mode Interim’ e geçer. Ancak forest mode daha once W2K3’ e yükseltilmişse, NT 4.0 etki alanları desteklenmeyecektir. Zaten domain veya forest mode lar geriye çekilemezler. Sadece yükseltilebilirler. W2K Mixed > W2K Native > W2K3 veya W2K3 Interim > W2K3

W2K3 Mode
W2K3 mode, tüm W2K3 özelliklerini desteklemektedir. Bu moda geçiş için tüm etki alanlarının DC leri W2K3 yüklenmiş olmalıdır. Ayrıca tüm etki alanları en az W2K Native Modda çalışıyor olmalıdırlar. Bu moda geçiş sağlandıktan sonra NT 4.0 ve W2K DC leri sisteme dahil edilemezler.

Forest Özelliği W2K Native ModeW2K3 Mode
GC replication improvements - Enabled

Defunct schema objects Disabled Enabled
Forest Trust Disabled Enabled
Linked Value Replication Disabled Enabled
Domain Rename Disabled Enabled
Improved AD replication algorithms Disabled Enabled
Dynamic Auxilary Classes Disabled Enabled
InetOrgPerson objectClass change Disabled Enabled

Application Directory Partition

W2K3 Active Directory daha once W2K’da bulunan 4 AD bölmesini aynen desteklemektedir.

Domain Partition : Bir etki alanı ile ilgili tüm nesneler bulunmaktadır. Etki alanındaki tüm DC lere replike edilir.

Schema Partition : Bir forest’ın Active Directory şeması ile ilgili tüm bilgiler bulunmaktadır. Forest içindeki tüm DC lere replike edilir.

Configuration Partition : Siteler ve servisler ile ilgili tüm bilgileri içerir. Forest içindeki tüm DC lere replike edilir.

Global Catalog Partition : AD içindeki bazı belirli nesneler ile ilgili tüm bilgileri içerir. Forest içinde GC rolü alan tüm DC lere replike edilir.

W2K3 ile birlikte tüm bunlara ek olarak Application Directory Partition da eklenmiştir. Anck bu tamamiyle W2K3’e özel bir durum olduğundan sadece W2K3 DC lerine replike edilmektedir.

Ancak etki alanının veya forest ‘ın mutlaka W2K3 mode da olması şart değildir. İçinde NT 4.0 veya W2K DC ler bulunan ortamlarda da W2K3 DC lerine replike edilmektedir.

Application Partition’ dan AD özelliği olan uygulamalar yararlanabilir. Örneğin TAPI veya DNS. Bu özellik sayesinde aşağıdaki avantajlar elde edilebilir :

- AD içindeki bilgi replikasyonundan kaynaklanan trafiğin azaltılması.
- Bazı özel DC lere bilgi replike edebilme imkanı nedeniyle hata toleransının sağlanması.
- Uygulamaların LDAP ile AD’ ye erişimlerinin sağlanması.

Application Directory Partition ortamında security principal (kullanıcı , bilgisayar hesabı ve security groups) dışında tüm nesneler tutulabilir.

Bir ADP forest içinde aşağıdaki noktalara yerleştirilebilir :

- Domain partition child
- Application Directory Partition child
- Forest içinde yeni bir Tree

ADP bilgileri, Global Catalog lara replike edilmez. Ancak GC özelliği olan DC ler ADP bulundurabilirler.

Eğer bir uygulama LDAP portundan ( 3268 / 3269 ) bilgi sorgularsa, sorgulanan DC aynı zamanda bir GC ise, ADP ile ilgili bilgileri göndermez. Bu, karışıklıklara yol açmaması için alınmış bir önlemdir.

Eğer bir DC denote edilecekse, üzerinde ADP varsa aşağıdaki yollar takip edilmelidir :

- ADP yi kullanan uygulama tespit edilerek, ADP yi bu uygulamanın kaldırması tercih edilebilir.
- Eğer silinecek olan son replika ise durum dikkatli değerlendirilmelidir. Son replika silindikten sonra geriye dönüş olmayacaktır.
- Replikayı kaldıracak uygulama bilinmiyorsa, ntdsutil.exe kullanılarak ADP elle kaldırılabilir.

Security Descriptor Reference Domain

AD deki her bölme ve nesnenin bir yetki ve erişim seti vardır. Buna Security Descriptor denir. Bu set içinde kullanıcı, bilgisayar ve gruplar yer alır. Eğer nesneye bir SD tanımlanmamışsa, bu nesne bağlı olduğu Class’ ın varsayılan SD sini alır.

ADP farklı etki alanlarındaki DC lere replike edilebileceğinden durum daha da karışmasın diye ADP için ön tanımlı bir SD Reference Domain tanımlanır. Eğer ;
- ADP bir child domain ise, üst etki alanı SD Reference Domain dir.
- ADP başka bir ADP’ nin altındaysa, SD Reference Domain üstteki etki alanının SD Reference Domain’idir.
- ADP rootda tanımlıysa, SD Reference Domain ; Forest Root Domain dir.

Active Directory' i Yönetmek

W2K3’ de güven ilişkileri aşağıdaki gibi kurulabilir :

Tek yönlü veya çift yönlü
Otomatik veya elle
Geçiken veya geçişsiz

W2K3’ ün varsılan güvenlik protokolu Kerberos V5 vey NTLM’ dir. Kerberos’un kullanılamadığı durumlarda NTLM’ in kullanılmasına izin verilir.

Kerberos V5 ile kimlik doğrulama aşağıdaki şekilde yapılmaktadır :

Kullanıcı logon işlemi sırasında KDC (Key Distrubution Center)’ dan TGT (Ticket for Granting Ticket) alır. Varsayılan değer olarak tüm DC ler birer KDC’ dir.

Kullanıcı bir kaynağa erişmek istediğinde, aldığı TGT’ yi KDC’ ye gösterir ve kaynak için bir servis bileti ister.

KDC de etki alanı veritabanından istenen kaynak için Service Principal Name’ I kontrol eder. Erişilmesi istenen kaynak KDC ile aynı etki alanında olduğundan kontrol sonrası bilet istemciye verilir.

Kullanıcı aldığı bilet ile sunucuya başvurur ve kaynağa erişir.

Eğer kaynak farklı bir etki alanında ise aşağıdaki işlemler gerçekleşir : Örneğin, domain1.contoso.com’ dan domain2.contoso.com’ a erişmeye çalışılıyor olsun.

Kullanıcı, kendi etki alanı olan domain1.contoso.com KDC’ ye başvurarak bir TGT alır.
Kullanıcı, domain2.contoso.com’ daki kaynağa erişmek için elindeki TGT ile yerel KDC’ ye başvurur.
KDC, SPN’ de kontrollerini yapar ve kaynağın kendi etki alanında olmadığını görünce , GC (Global Catalog) üzerinden kaynağın nerede olduğuna dair bir araştırma yapar. GC gerekli bilgiyi KDC’ ye gönderir.
KDC, aldığı bilgiyi kullanıcıya verir ve contoso.com etki alanına başvurmasını söyler.
Kullanıcı, contoso.com’ dan bir KDC ile görüşerek, domain2.contoso.com için bir KDC bilgisi ister. KDC, bu KDC bilgisini gönderir.
Kullanıcı, domain2.contoso.com KDC ile görüşür ve kaynağa erişim yetkisi ister.
domain2.contoso.com KDC, SPN’ I kontrol eder ve kullanıcının kaynağa erişim yetkisi varsa kendisine bir bilet verir.
Kullanıcı, kaynağa erişir.

Güven türleri

Tree-root trust : Mevcut forest’da yeni bir root domain oluşturulduğunda otomatik olarak gerçekleşir. Geçişken ve çift yönlü güven ilişkisidir.

Parent-child trust : Bir etki alanına child olarak eklenen başka bir etki alanı ile oluşan güven ilişkisidir. Bu da çift yönlü ve geçişkendir.

Shortcut trust : Birbirinden çok uzak olan etki alanları arasında normal yollardan kimlik doğrulamanın çok uzun sürdüğü hallerde elle oluşturulan bir güven ilişkisi türüdür. Adından da anlaşıldığı gibi güven ilişkisine kısayol sağlamak kurulur. İsteğe gore tek veya çift yönlü olabilir. Geçişkendir.

Realm trust : Genelde UNIX Kerberos 5 türevi kaynaklar ile elle kurulan bir ilişki türüdür. Geçişken veya geçişsiz, tek veya çift yönlü olabilir.

External trust : Farklı forestlerin etki alanları arasında veya W2K3 etki alanı ile NT 4.0 etki alanı arasında kurulabilir. Geçişsizdir ve tek veya çift yönlü olabilir. Forest Trust kurulması için gerekli şart sağlanamadığında ancak bu yöntemle ilişki kurulabilir.

External trust iki şekilde ; kısıtlı veya genişletilmiş olarak tasarlanabilir. Trusting domain kaynaklarının tamamına erişim yetkisi verilebileceği gibi, Selective Authentication da uygulanarak sadece belirli bilgisayar hesaplarına belirli kullanıcıların erişimi de sağlanabilir. Bunun için kaynağın yetki setinde Allowed to Authenticate adında yeni bir yetki tanımı oluşturulmuştur.

Forest Trust : Farklı W2K3 forestleri arasında bağlantı kurmayı sağlar. Sadece iki forest arasında geçişkendir ve tek veya çift yönlü olabilir.

W2K3 Trust Wizard bu geçiş ilişkilerini ayarlamak için kullanılabilir. Wizard, mevcut jargona iki yeni tanımlama eklemiştir :

Incoming trust : Güvenilen (Trusted ) etki alanındaki bir kullanıcı, güvenen (trusting) alandaki kaynaklara ulaşmak istediğinde bu ; Incoming Trust olarak adlandırılır. Yani kullanıcıi kaynağa erişmeden once güvenilen etki alanında kimlik doğrulatmak zorundadır.

Outgoing trust : Güvenen (Trusting) etki alanındaki Administrator güven ilişkisi kurmak istedğinde bu Outgoing Trust olarak adlandırılır.

Forest Trust
Forest Trust W2K sistemlerinde farklı forestlerin etki alanları arasında güven ilişkisi kurmak için kullanılan external trust’ ın getirdiği kısıtlamaları gidermek için oluşturulmuştur.
- İki forest arasında geçişkendir. Ancak 3ncü forest’a geçişken değildir. A>B , B>C, A >C’ye yok.
- Yönetim kolaylığı sağlar.
- Her iki forestın tüm etki alanlarına erişimi sağlar.
- UPN kullanımına izin verir.

Uygulanabilmesi için her iki W2K3 etki alanı da W2K3 forest functional level da çalışmalıdır.

Netdom.exe ile Forest Trust kurulamaz !

Active Directory Schema
AD Şeması sadece Schema Master olarak belirlenen sunucu üzerinden değiştirilebilir. Şema, forest içindeki tüm DC lere kopyalanır. Şema değişikliği yapacak kullanıcı Forest Root Domain’ de Schema Admins grubu üyesi olmalıdır.

AD şema değişikliği için AD Schema Snap-in yüklenmelidir.

Regsvr32 schmmgmt.dll komutu ile gerekli düzenleme yapılabilir.

Backup & Restore
Ntbackup ile uzak sistemlerin System state yedeği alınamaz.

System State blgisi içinde aşağıdakiler yer almaktadır.

System Registry
COM+ class registration database
boot files, ntdetect.com, ntldr, boot.ini ve ntbootdd.sys
Windows File Protection sistemi ile korunan sistem dosyaları

Aşağıdaki bilgiler de ilgili sunucularda system state içine dahil olmaktadır.

- Sertifika servis veritabanı (sertifka sunucularında)
- Active Directory ve sysvol dizini (AD sunucularında)
- Cluster servis bilgisi (cluster sunucularında)
- IIS Metabase (IIS sunucularında)

Active Directory geri yüklenirken sistemin Directory Services Restore Mode’ a geçirilmesi gereklidir.

Yedekleme yöntemi ne olursa olsun (Incremental vs.) System State yedeği daima Full alınır.

Üç farklı Restore yöntemi vardır :

- Normal (Non-authoritative)
- Authoritative restore
- Primary restore

Normal Restore yapıldığında, geri yüklenen bilgiler replikasyon ile değişebilir. Yani geri yüklenen bilgiden daha yeni bilgi AD’ de mevcutsa ,bu bilgiler geri yüklenenlerin üzerine replikasyon sırasında yazılır. Normal restore için DC , Directory Services Restore Mode’ da çalıştırılmalıdır. Normal restore şu amaçlarla kullanılabilir.

- Çok sayıda DC olan bir ortamda bir DC yi geri yüklemek için
- Bir DC üzerindeki, replika setlerinden farklı FRS veya Sysvol dizinlerini geri yüklemek için

Authoritative Restore‘ un amacı bir sistemdeki veriyi tamamiyle geri yüklemektir. Bu yöntem ile geri yüklenen verinin diğer DC lerdeki veri tarafından değiştirilmesi engellenmiş olur.
Bu yöntemi uygulamak için sistem yine Directory Services Restore Mode’ da açılır ve geri yükleme yapılır. Daha sonra ntdsutil.exe çalıştırılarak yüklenen nesneler authoritative olarak işaretlenir. Bu işlem geri yüklenen nesnelerin Update Sequence Number (USN) lerini mevcut son numaradan yukarıya çeker ve replikasyon sırasında değişmelerini engeller.

Genelde aşağıdaki amaçlarla kullanılır :

- AD nesnelerini geri yüklemek için
- Sysvol dizinindeki veriyi resetlemek için.

Örnek :

ntdsutil.exe
Authoritative restore
Restore subtree OU=yeni,CN=contoso,CN=com

Primary restore, bir AD ortamındaki tüm DC ler (veya tek DC li ortamdaki tek DC) arızalandığında, mevcut bir yedekten AD ortamını yeniden oluşturmak amacıyla kullanılır. Ortamı oluşturmak için yüklenecek ilk DC Primary Restore ile, sonraki DC ler ise Normal Restore ile geri yüklenmelidir.

Genelde aşağıdaki amaçlarla kullanılır :

- Ortamda hiç DC kalmamışsa sistemi yeniden oluşturmak için

System State verisinin bir kısmı sabit disk üzerinde orijinal yerinden farklı bir yere geri yüklenebilir. AD veritabanı, COM+ bilgileri ve Sertifika veritabanı farklı yere geri yüklenemez.

Advanced Restore Settings

Original Location

Bozuk veya sorunlu bilginin geri yüklenmesi için kullanılır. AD geri yüklemesinde bu seçenek seçilmelidir.

Alternate location

Seçilen bir dizine dosyanın eski bir sürümünün geri yüklenmesi sağlanır.

Single Folder

Dosyaları bir ağaç yapısından tek bir dizin içindeki dosyalar haline döndürerek geri yükler.

Sunucu Sistemlerinin Yönetim ve Bakımı

2006-07-12T18:30:00.000+03:00

Windows Server 2003 sistemlerinin yönetimi için kullanılan araçların organize edildiği ortam Microsoft Management Console (MMC)dir. MMC, sunucu yönetimi için kullanılan eklentilerin (snap-in) ilave edilmesiyle esnek ve güçlü bir yönetim aracına dönüşür.

Birden fazla eklentinin bulunduğu ve kişiselleştirilmiş konsollar, sunucu yönetimini çok kolaylaştırmakta ve her eylem için ayrı programın açılıp kapatılmasını engellemektedir.

MMC’nin farklı kullanım modları bulunmaktadır

Tam Mod (Full Mode) : Kullanıcıların konsol ağacının tamamına erişmesine izin verir, farklı pencereler açabilirler.

Sınırlı Erişim, Çoklu Pencere (Limited Access, Multiple Windows) : Kullanıcılar konsolda birden fazla pencere görebilir ama konsol ağacının izin verilen kısmına erişebilirler.

MMC konsolonun web arayüzü sadece Windows 2003 Web Edition’da kullanılabilir. http://sunucuadı:8098

Terminal Servisleri Hata Ayıklama Metotları

Ağ problemleri : Eğer ağ ortamındaki DNS isim çözümlemesinde sorun varsa TS bağlantısı gerçekleşmeyebilir. Bağlanılacak sunucunun 3389 portu açık ve erişilebilir olmalıdır.

Yetkili hesaplar : Kullanıcı Administrators veya Remote Desktop Users grubunun üyesi olmalıdır.

Group Policy : GPOlar DC’lere sadece Adminlerin bağlanmasına izin verir. Diğer kullanıcılar için GPO’larda elle ayarlamalar yapmak gerekir.

Bağlantı sayısı : Windows 2003 sunucuları eş zamanlı olarak sadece 2 TS bağlantısına izin verir. Bu sayı arttırılamaz.

Remote Assistance

Remote Assistance servisi küçük ağ ortamlarında çalışabilmek ve NAT cihazlarını aşabilmek için UPnP (Universal Plug and Play) protokolünü kullanır. Windows XP ICS (Internet Connection Sharing) UPnP’yi desteklemektedir. Ancak Windows 2000 ICS UPnP’yi desteklemez.

Bağlanacak cihazlardan her ikisi de UPnP desteklemeyen NAT cihazları arkasındaysa bağlantı gerçekleşmez. Ancak cihazlardan birinin önünde böyle bir cihaz yoksa Windows veya MSN Messenger ile bağlantı sağlamak mümkün olur.

Terminal Server ortamının yönetilmesi

TS üzerinde çalışacak uygulamalar çok sayıda kullanıcıyı destekleyecek şekilde yapılandırılması gerektiğinden özel bir yöntemle kurulmalıdır. TS’e kurulacak yazılımlar daima Add / Remove Programs seçeneği ile kurulmalıdır. Bu eklenti sunucu TS kurulum moduna geçirecektir. Bazı yazılımların güncelleme paketleri veya yamalar bu şekilde kuruluma izin vermezler. Bu durumda komut satırından change user /install yazarak mode değişikliği yapılabilir. Kurulum tamamlandığında ise change user /execute yazarak normal moda dönülebilir.

TS’e yeni bağlantı yapılması change logon /disable veya /enable komutları ile engellenebilir.

TS kurulumu sırasında tam güvenlik (full security) veya esnek güvenlik (Relaxed security) arasında seçim yapılmalıdır. Tam güvenlik modunda bazı registry ayarları kayıt edilmez ve eski yazılımlar genellikle çalışamazlar.

TS Home Folder seçeneği genelde sistem yöneticileri tarafından yanlış anlaşılan bir özelliktir. Bu özellik ile TS sunucusunda kurulan uygulamaların kullanıcıya özel ayar dosyalarının saklanacağı yer belirtilmektedir. Kullanıcının kişisel klasörleri kastedilmemektedir.

TS lisans sunucusunun kendi üzerine kurulmaması tercih edilmesi gereken bir yöntemdir. İki çeşit lisanslama vardır. Enterprise ve Domain Level.

TS sunucusunda belirlenen kullanıcı bağlantı ayarları, kullanıcının bireysel olarak yaptığı bağlantıdaki ayarların daima üstündedir.

Bir TS’e bağlantı sağlanabilmesi için aşağıdaki şartlar gerçekleşmelidir :

- Sunucunun ağdan ulaşılabilir olması.

- Sunucunun TS bağlantısını 3389 portundan desteklemesi

- Remote Desktop aktif olmalı. change logon /enable

- Sunucu ile istemcinin şifreleme seviyeleri eşit olmalı.

- Kullanıcı Remote Desktop Users grubunda olmalı.

- Kullanıcının Allow log on through Terminal Services yetkisi olmalı

- Allow Logon to Terminal Server ayarı aktif olmalı.

Windows 2003 Enterprise ve Datacenter sürümleri ile TS Load Balancing özelliği eski sürümlere göre daha rahat kullanılabilmektedir.

Bir TS kümesi kurmak için aşağıdakilere ihtiyaç vardır :

- NLB veya DNS Round Robin ile çalışan TS sunucuları

- TS Session Directory Servisi : Servis her kullanıcının TS sunucuları üzerinde oturumlarını bir veritabanında tutar.

- TS bağlantı ayarları : Küme sunucuları, Session Directory’e yönlendirilmelidir.

IIS ile Web Sunucularının Yönetilmesi

W2K3 sunucularına yapılabilecek saldırı imkanlarını azaltmak amacıyla IIS varsayılan kurulumda yüklü gelmez. Daha sonradan elle yüklenmelidir.

SUS (Software Update Services) sunucusunu yönetmek

SUS sunucusu Microsoft yamalarının dağıtılması için efektif bir yol olarak kullanılabilir.

http://sus_server/SUSAdmin adresinden sunucunun konsoluna erişim sağlanabilir.

Windows güncelleme istemcisi (Windows Update Client) Group Policy ile SUS sunucusunu kullanacak şekilde yönlendirilebilir ve istemcilerin Internet yerine SUS’dan güncelleme yapmaları sağlanabilir.

Windows 2000 sunucularında ilgili GPO ayarları bulunmamamaktadır. Bu durumda wuau.inf şablon dosyası yüklenerek Windows Update Client ayarlarının GPO ile yapılması sağlanabilir. Wuau.inf dosyası %windir%\inf klasörü altında bulunmaktadır.

SUS ve otomatik güncelleme servisi aşağıdaki log dosyalarını kullanır :

- Senkronizasyon logu : Geçmiş senkronizasyonlar hakkındaki bilgiler burada tutulur. History-sync.xml dosyası IIS içinde \autoupdate\administration klasöründe bulunur.

- Onay logu : History-Approve.xml dosyası IIS içinde \autoupdate\administration klasöründe bulunur.

- Windows Update Log : otomatik güncelleme istemcisi logu. %windir%\window supdate.log dosyasıdır ve istemcinin diskinde bulunur.

- Wutrack.bin : Şifrelenmiş log dosyasıdır.

SUS sunucusunun yedeklenmesi için aşağıdaki işlemler yapılmalıdır :

- IIS konsolu içinden metabase yedeklemesi yapılır.

- NTbackup ile c:\inetpub\wwwroot klasörü yedeklenir. Daha önceden alınan metabase yedeği de NTbackup yedeğine ilave edilir.

- Metabase yedek dizini. %windir%\system32\inetsrv\metaback klasörü yedeklenir

- SUS güncelleme içeriğinin tutulduğu klasör.

SUS sunucusunun geri yükleme prosedürü aşağıdaki gibidir :

- Sunucu virüs bulaşma ihtimaline karşın ağdan çıkartılır.

- Windows 2003 sunucusu yüklenir.

- IIS aynı özelliklerle ve modüllerle yüklenir.

- Güncel SP ve paketler yüklenir.

- SUS daha önceden yüklendiği klasöre yüklenir.

- NTbackup ile alınan yedek geri yüklenir. Yedek, default web site, SUSAdmin ve AutoUpdate Virtual Directoriesi ve metabase yedeğini içermelidir.

- IIS Manager açılır ve metabase yedeği geri yüklenir

Masaüstünü ve kullanıcıları kontrol altına almak

2006-07-12T18:21:00.000+03:00

Çok sayıda kullanıcının çalıştığı ortamlarda rahatı yerinde, her an sürpriz sorunlarla , günde en az bir virüs atağı , ısrarlı kullanıcılar ve bıktırıcı Help Desk telefonları ile uğraşmadan çalışabilmenin temel koşulu nedir diye sorarsanız, ilk yapmanız gereken masaüstünü ve kullanıcıyı kontrol altına almaktır derim.

Öyle bir şirket düşünün ki toplam bilgisayar sayısının yarısı dizüstü bilgisayarlardan oluşsun. (ki şu an çalıştığım kurumda 500 'den fazla bilgisayardan bahsediyorum.) Üstelik kurumsal IT politikaları ve prosedürleri hazır olmadığından ve istekleri nedenlerine göre analiz ederek yeri geldiğinde hayır ! diyebilecek Sistem Yöneticileri bulunmadığından dolayı kavramsal olarak sistemlerin egemenliği yazılım ekiplerinin elinde olsun ve yazılım geliştirirken güvenlik en son düşünülen şey olarak görülsün. Hatta kullanılan yazılımların gereği (!) kullanıcılara yerel Administrator yetkileri de verilsin ve tüm PC ve dizüstü bilgisayarlar tamamiyle son kullanıcının hakimiyetinde olsun. Canı isteyen herkesin istediği yazılımı kurabildiğini söylememe gerek yok sanırım.

Üstelik kurulum prosedürleri ve klonlama teknikleri mevcut olmadığı için her bilgisayar, işletim sisteminin ve diğer yazılımların kurulum varyasyonlarının sonsuz aritmetiği içinde her biri nev-i şahsına münhasır olarak hazırlansınlar ve destek için başına oturduğunuz her PC'de yeni sürprizlerle karşılaşın.

Elbette bu kadar şenliğin olduğu bir ortamda anti-virüs yazılımlarının da standart ve her bilgisayarda kurulu olduğunu söylemeyeceğim tabi ki. O kadar da uçuk senaryolar yazmak istemiyorum :)

Böyle bir ortamı islah etmek mümkün olur mu diye sormayın. "ettik" Bu yazı dizisinde anlatmaya çalışacağım şey de bu. Ancak en baştan söylemeliyim ki, eğer üst yönetimi bu çalışmanın yapılmasına ikna ederek yazılı ve sözlü desteğini alamazsanız işiniz gerçekten zor olacaktır. Bunu unutmayın. Ne yaparsanız yapın, Genel Müdür ve yardımcılarını bu projenin içine çekin. Yeri geldiğinde çok tepki çeken bir uygulamanız için "Genel Müdürümüzün onayı ile yapılmıştır." diyerek ikinci bir itiraza fırsat vermeden kapatabileceğiniz çene sayısına siz bile şaşırabilirsiniz.

Ayrıca bu konuda yazan herkesin bildiği ama çoğunlukla akademik dilde yazmaya gayret edildiği için atladığı bir kaç konu daha var. Bence bunlar "edinilen tecrübeler" başlığı altında toplanabilecek kadar önemli konular.

1- Herkesi memnun edemezsiniz. Daima sızlanan birileri olacaktır. Unutmayın ki birilerinin daha önceden edindiği bazı hakları (!) geri alıyorsunuz. Büyük düşünmeye gayret edin. Esas amacınızı unutmayın. Sonuçta elde edeceğiniz masaüstü ortamı ve kontrol şu anki çatlak seslere değecektir. Durumunu zamanın padişahları ile karıştırarak "bu kısıtlamalar kaldırılsın" diyen kendini bilmez müdürleri de pek önemsemeyin.

2- Bu projeyi yaparsanız sonunda IT kökenli kişiler (bazen onlar bile karşınızda olacaktır) ve vizyon sahibi yöneticiler (Olanla olmayanı nasıl ayıracaksınız ?) dışında kimsenin sizi anlamasını ve sevmesini beklemeyin. Alkışlanmayacaksınız. 100 tane satış personelinin dizüstü bilgisayarlarında ne yapıp ne yapamayacaklarını "siz" söylediğiniz zaman arkanızdan hayır duası okuyacaklarını zannedecek kadar saf olamazsıınz. Bu projeyi, iyi polis-kötü polis oyununundaki kötü polis rolünü oynamaktan korkmayacak kadar dirençli sistem yöneticileri dışında kimseye tavsiye etmiyorum.

3- Sıkı durun. Taviz vermeyin. Yumuşamayın. Daima birileri sizden kısıtlamalarda kendisi için küçük delikler açmanızı isteyecektir. Eğer satış ekibindeki o hep beğendiğiniz sarışın satış personeli göz süzüp ağzını büzerek "ben kendi duvar kağıdımı kullanmak istiyorum" dediğinde yelkenleri suya indirecekseniz ya bu işe hiç kalkışmayın ya da toz duman yatışana kadar ortalıkta gözükmeyin. Bir kere taviz vermeye başlarsanız emin olun ki arkası gelir.

Kullanıcıları kontrol altına alabilmek için katedilmesi gereken yol ve geçilmesi gereken köprü sayısı çok da olabilir az da. Bu çoğunlukla projeyi yapacağınız kurumun yapısına, kurum kültürüne, projenize ayıracağı bütçeye ve diğer yönetimsel faktörlere bağlıyken biraz da şansla ilgisi olduğunu düşünüyorum. Zira işe ta en başından başlamanız gerekebilir; masaüstünü kontrole almadan önce PC ve dizüstü bilgisayarları yeniden kurmanız ve proje zeminini bu noktada oluşturmanız gerekebilir. Hatta tüm bölge müdürlükleri veya şubelerdekileri de... Böyle bir durumda proje bir kaç ay da sürebilir, bir kaç yılda.

Diyorum ya, projenin süresi çoğunlukla içinde bulunduğunuz ortamın size baştan hazırladığı şartlara bağlı. Söylediğim şeyin soyut bir tanım olarak kalmaması için şöyle iki örnek verebilirim. Daha önce çalıştığım şirkette 400 tane Genel Müdürlük PC'sinin klonlanması 15 gün sürmüştü. Çünkü devraldığımız bir bankadan biz Pentium II'lerle çalışırken aynı sayıda IBM ve Compaq Pentium III 500 PC gelmişti. Dolayısıyla kullanıcıların PC'lerini onlar çalışırken sırayla alıp klonlamak gibi usandırıcı ve zaman kaybettiren bir işle uğraşmamıştık. Günde 50-75 arası PC klonlayarak hazırlıyor ve her gün bir kat dolusu insanın PC'sini değiştirebiliyorduk. Şu an çalıştığım sigorta şirketinde ise aktif olarak kullanılan 500 tane dizüstü bilgisayarı ancak 7 ayda tamamlayabildik. Üstelik PC'lere henüz sıra gelmedi. (Bellek ve disk yükseltme işlemleri için bütçe henüz onaylanmadı.). Bir önceki yazımdaki tespitime atfen o 500 tane dizüstü bilgisayarı kullanan satış personelinin artık benden nefret ettiğini de belirtmek isterim (!).

Aslına bakarsanız böyle bir projeye gireceksem, bunu güvendiğim ve nasıl kurulduğunu bildiğim masaüstü sistemlerinde uygulamaktan yanayım. Eğer hazırda PC ve dizüstü bilgisayarın kurulumuna ilişkin bir prosedürler dizisi yoksa ya da o belgeler varsa bile sağlıklı ve disiplinli olarak uygulandığından emin değilsem, ilgili kişileri ikna edip projeye yolun en başından başlamayı tercih ederim. Bazı durumlarda delice, hatta zaman kaybı gibi görünebilir, hatta bazen uygulaması imkansız olabilir ama yapabiliyorsanız böyle yapın derim. En azından neyin üzerinde çalıştığınızdan ve X, Y veya Z fazında nasıl tepki vereceğinden emin olursunuz.

Şimdi gelin senaryomuzu yazalım ve projeyi başlatalım :

Durum : Yurt genelinde birden fazla yerleşime yayılmış bir finans şirketinde masaüstünün kontrol altına alınması ve kullanıcıların sistemler üzerindeki yetkilerinin kısıtlanması isteniyor. Sistemlerde oluşan arızalar ve bilgisayarların kullanımındaki verimsizlik yönetimi bir çalışma yapılması konusunda karar almaya yöneltmiş.

Dizüstü bilgisayarlar çoğunlukla aynı marka ve model. Ancak PC'lerde marka / model farklılıkları ciddiye alınması gereken derecede yüksek. Geçmişteki yanlış uygulamalar nedeniyle kullanıcılar genelde bilgisayarlarında Local Admin yetkilerine sahipler. Kullanıcılar tarafından yetkisiz yüklenen yazılımlar ve sistem ayarlarının sıkça değiştirilmesi nedeniyle Yardım Masası ve PC Destek ekibine yüksek oranda PC kaynaklı çağrılar geliyor. Yüklenen yazılımlar nedeniyle oluşan virüs saldırılarından kurum genelinde etkilenmeler görülüyor.

Farklı departmanlar tarafından kullanılan bir çok uygulama ve yazılım olması nedeniyle PC'lerde farklı kurulum yöntemleri uygulanmış. Aynı yazılımı kullanan iki PC'de bile farklılıklar mevcut.

İstenenler :
- Kurum genelinde kullanılan PC ve dizüstü bilgisayarların standart şekilde kurulması ve her bilgisayarda sadece kullanıcının işini sürdürebilmesi için gerekli yazılımların yüklü olması.

- Bilgisayarların kullanımında "kurcalama" veya yetkisiz yazılım yükleme sonucu oluşan arızaların en aza indirilmesi, verimsizliğin azaltılması.

- Kullanıcıların bilgisayarları üzerindeki Local Admin yetkilerinin kaldırılması. Hakimiyetin, kullanıcılardan alınıp sistem yöneticilerine verilmesi (!).

- Active Directory ve Group Policy'nin etkin şekilde kullanılması.

- Yardım Masası'na gelen PC kaynaklı çağrılarda azalma sağlanması. PC ve dizsütü bilgisayarlara uzaktan müdahale edilebilmesi imkanının YM' na verilmesi.

İşimiz hiç de kolay değil. Kurum yöneticilerinin doğrudan desteği dışında neredeyse hiç bir faktör uygulamada kolaylık sağlamıyor.

Oluşturduğum senaryo geçirdiğim iki büyük deneyimin en kötü yanlarını toplayarak kurguladığım sanal bir şirket ve ortama ait. Unutmayın ki projemiz ilerledikçe değişen etkenler de olabilir. Bazıları yolumuza çıkacak, bazıları ise kolaylıklar sağlayacaktır. Her şeye hazırlıklı olmak elbette mümkün değil ancak değişen şartların getirdiği baskıdan en az zararla çıkmanın yolu sanırım şartların değişmesinden daha normal bir şey olmadığına kendimizi ikna etmek ve rahat olmak olacaktır. Geriye dönüp baktığımda proje yönetimine dair aldığım en büyük derslerden birinin de bu olduğunu söyleyebilirim.

Biraz durumumuzu analiz edelim : Bu kurumda uygulama sırasında ciddi zorluklar yaşayacağımızı şimdiden söyleyebiliriz. Bu kadar heterojen bir ortamda mutlaka iyi analiz ve planlama yapılmalı ve uygulamaya geçilmeden önce hazırlık aşamasına yeterince vakit ayrılmalıdır. Mevcut sistemleri rehabilite etmeye çalıştığımıza ve bir seferde kurup kullanıcının önüne koyabileceğimiz sayıda yedek PClerimiz olmadığına göre mevcut PCler üzerinde projeyi sürdürürken kullanıcıları en az düzeyde rahatsız edecek bir plan yapmalıyız. Bu bize projeye karşıt propaganda yapabilecek kişilerin sayısını lüzumsuz yere arttırmamak konusunda yardımcı olacaktır. Organizasyonun yapısını iyi tanımak ve genel süreçler hakkında bilgi toplamak da yararlı olacaktır. Bir proje tanıtım dokümanı hazırlamak ve bunu kilit noktalardaki kişiler ve departman yöneticileriyle paylaşmak işlerimizi kolaylaştırabilir.

Genel prensipler halinde verilmiş olan istekleri detaylandırmalı ve teknik bir dile çevirmeliyiz. Talepleri ve bunlara karşılık yapmamız gerekenleri IT dilinde bir şartname haline getirmek, uygulama seçenekleri arasından en iyi yöntemleri bulmak için gereken mesaiyi harcamak tüm proje süresi içinde en fazla zaman harcadığımız "hazırlık" dönemi olabilir. Ama bu projenin "olmazsa olmazı"dır. Şirket genelinde kullanılan yazılımları tanımalı ve her bir yazılımın oluşturduğumuz projeye (düzenlemeler ve kısıtlamalar) nasıl tepki verdiğini incelemeliyiz. Oluşturduğumuz teknik planı gerçek ortamı yansıtacak kadar detaylandırılmış bir test ortamında tekrar tekrar denemeli ve yeterince olgunlaşmış sonuçlarını ilgili kişilerle paylaşmalıyız. Sonuçların onaylanması halinde de bir proje takvimi oluşturarak uygulamaya geçmeli ve projeyi tamamlamalıyız.

İleri düzey DNS ayarları

2006-07-12T18:11:00.000+03:00

DNS sunucusu kurulduğunda ileri düzey ayarlar aşağıdaki gibidir :

Disable recursion : off
BIND Secondaries : On
Fail on load if bad zone data : off
Enable round robin : on
Enable netmask ordering : on
Secure Cache against pollution : on
Name checking : Multibyte (UTF8)
Load zone data on startup : From active directory and registry
Enable automatic scanvenging of stale records : off (requiers configuration)

Disable Recursion (özyineleme)
Bu seçenek varsayılan değer olarak kapalıdır. Bir DNS sunucusu istemciden gelen sorguyu, yineleme (iteration) yoluyla FQDN sorgusunun tam cevabını alana kadar diğer sunuculara sormaya devam eder. Cevabı alınca da istemciye bildirir.

Disable recursion seçildiğinde sunucu istemcinin sorgusunu cevaplamak için araştırmak yerine istemcinin kendi cevabını araştırabilmesi için refererans kayıtları istemciye gönderir (referral). Bu durumun geçerli olabileceği hallere örnek vermek gerekirse ; istemcinin bir internet adresini çözmek istemesi ancak yerel DNS sunucusunun sadece kendi alanına ait kayıtları bulundurması olabilir.

Disable Recursion aktif hale getirildiğinde, DNS sunucusunda forwarders sekmesi pasif hale gelir.

BIND Secondaries
Windows 2003 DNS sunucuları BIND DNS kullanan ikincil sunuculara alan transferi yaparken fast transfer format denen hızlı veri aktarım yöntemini kullanmazlar. Bu özellik, 4.9.4’den eski BIND sürümleri ile uyumluluk sağlamak içindir. Bu seçenek varsayılan değer olarak açıktır. Eğer ortamdaki tüm BIND DNS sunucularının sürümleri 4.9.4’den büyükse bu seçenek kapatılabilir.
Şu anki mevcut BIND sürümü 9.2.2’dir.

Fail on load if bad zone data
Windows 2003 DNS sunucusu alanı yüklerken eğer kayıtlarda hata tespit etmişse bunu loglar ancak alanı yüklemeye devam eder. Bu seçenek varsayılan değer olarak kapalıdır. Aktif hale getirilirse, DNS sunucusu kayıtlarda bozukluk tespit ettiğinde alanı yüklemeyi durdurur.

Enable Netmask Ordering
Çok sayıda ağ kartı ve IP adresi bulunan (Multihomed) bir istemcinin birden fazla (A) kaydının olması halinde DNS sunucusu sorguyu yapan istemciye ilk olarak, sorguyu yapan istemcinin bulunduğu subnete uyan (A) kaydını gösterecektir. Varsayılan değer olarak bu özellik aktiftir.
Ortada birden fazla IP adresi ve (A) kaydı varsa DNS sunucusu istemciye hosta ait tüm (A) kayıtlarını belirlenen sırada gönderecektir. İstemci ilk gelen kayda erişim sağlamaya çalışacak, başaramazsa ikinciyi deneyecektir.

MCSE sınavlarında Enable Netmask Ordering, LocalNetPriority olarak adlandırılmaktadır.

Enable Round Robin
Bu özellik multihomed bir hotsu sorgulayan istemcilere, uygun (A) kayıtlarının belirli bir sıra dahilinde değiştirilerek her seferinde farklı bir kayıt sunulmasını sağlar. Çok temel olarak bu yöntem hotsun ağ kartları arasında bir yük dengeleme (load balancing) yöntemi sağlamakta ve yükün teorik olarak tüm ağ kartlarına eşit şekilde dağıtılmasını sağlamaktadır. Aynı içeriği sunan birden çok sunucunun olduğu web sitelerinde sıkça kullanılan bir yöntemdir.Varsayılan değer olarak aktiftir.

Secure Cache against pollution
Bu özelliğin aktif hale getirilmesi ile DNS sunucusu kayıtlarını yanlış kayıtlar ile doldurma ve bir anlamda kirlenmeden korumaktadır. Özellik aktifken DNS sunucusu sadece sorgunun yapıldığı etki alanı adı ile tamamiyle uyan alan adlarına ilişkin sonuçları saklar. Örneğin, Microsoft.com adresine yapılan bir sorgu için msn.com’dan bir kayıt sonuç olarak alınmışsa, bu özellik açıkken bu kayıt saklanmaz. Böylece yetkisiz sunucuların ve kişilerin DNS sorgularını yanıltmaları önlenebilir.

Alanların Yetki Devirlerinin Yapılması (Zone Delegation)
Internet kadar büyük bir isim uzayı (namespace) , eğer etki alanlarının daha küçük parçalara bölünerek yönetiminin farklı kişilere devri imkanı olmasaydı yönetilemezdi. Bu nedenle DNS isimuzayı içindeki bir alt-etki alanı (subdomain) devredilmek istendiğinde yeni bir alan (zone) yaratılır ve yetki ilgili yöneticiye devredilir.

Bir alanın yetki devrini yapmak demek, bu DNS isimuzayını küçük alt-etki alanlarına bölerek yetkiyi devretmek demektir. Örnekte Microsoft.com etki alanının devir modeli görülmektedir.

Ne zaman yetki devri gerekir ?
- DNS etki alanının organizasyon içindeki bir şube ya da bölüm tarafından yönetilmesi gerektiğinde.
- Kurumun çok büyük bir DNS sistemi varsa ve birden fazla DNS sunucusu üzerinde yönetiliyorsa, bu ortamda hata toleransı ve performans artışı sağlanması istendiğinde

Yetki devrinin yapılabilmesi için ana alanın (parent zone) devredilecek etki alanını yöneten yetkili DNS sunucusuna ait A ve NS kayıtlarına sahip olması gereklidir. Bu kayıtlar alanın istemcilerinin iteratif sorgularına cevap bulabilmelerini sağlar.

Not : Yetki devri yapılırken A ve NS kayıtları otomatik olarak oluşturulur.

Yukarıdaki örnekte, yeni oluşturulan example.microsoft.com etki alanının yetkili DNS sunucusu ns1.us.example.microsoft.com olarak belirtilmiştir. Bu sunucunun yetki ataması yapılan yeni alanın dışındaki hostlar tarafından da tanınması için bir NS ve A kaydı otomatik olarak ana alanda (Microsoft.com) oluşturulur.

NS kaydı yeni alan için yetkili isim sunucusunun ns1.us.example.microsoft.com olduğunu belirtir ve alana dair sorguların bu sunucuya yönlendirilmesini sağlar.

A kaydı (glue record olarak da tanınır) ise NS kaydında ismi belirtilen sunucunun IP adresinin çözümlenmesini sağlar. Eğer yetkili sunucu yeni yetki devri yapılmış alanın bir üyesiyse, daha üst seviyedeki tüm hostlar tarafından isim-IP çözümlemesinin sağlıklı olarak yapılabilmesi için gereklidir.

Örneğin bir DNS sunucusu box.example.microsoft.com adresini çözümlemek istiyor : İlk olarak sorguyu Microsoft.com alanının yetkili DNS sunucusuna gönderecektir. Bu sunucudaki yetki transferi nedeniyle sunucu cevap olarak sorgulanan alanın (example.microsoft.com) yetkili sunucusunun adını ve IP adresini istemciye gönderecek ve buraya sormasını isteyecektir. İstemci de aynı sorguyu bu sefer bu sunucuya soracak (ns1.us.example.microsoft.com) ve sonucunda istediği cevabı alacaktır.

Stub Zone
Stub Zone, ana alanın (master zone) kısaltılmış ancak düzenli olarak güncellenen ve içeriğinde sadece ana alana ait NS kayıtlarını bulunduran bir kopyasıdır. Stub zone barındıran bir sunucu sorgulara doğrudan cevap vermek yerine onları stub zone kayıtlarında bulunan NS kaynaklarına yönlendirir.

Stub zone oluşturmak için değişmez IP adresi olan bir isim sunucusunu alana eklemek yeterlidir. Alan, daha sonra eklenecek veya çıkartılacak isim sunucularını kendisi otomatik olarak güncelleyecektir.
Stub zone kayıtları elle değiştirilemez.

Faydaları
- İsim çözümlemesini geliştirir Stub zone bir DNS sunucusunun alanda kayıtlı isim sunucularını sorgulayarak özyineleme (recursion) yapmasını sağlar ve her seferinde kök DNS sunucusunu sorgulamasını engeller.

- Uzak alanlara dair güncel bilgi sağlar Stub zone otomatik olarak güncellendiği için farklı bir alana ait DNS sunucularının güncel listesi daima kayıtlıdır. Örneğin; farklı bir DNS sunucusunda yetki devri yapılmış bir alan.

- DNS yönetimini kolaylaştırır İkincil alanlar kullanmaya gerek kalmadan alan bilgisi (zone information) dağıtımı sağlanır.

Stub zone, ikincil alanların hata toleransı ve yük paylaşımı gibi faydalarını sağlayamaz ve bu amaçlarla kullanılamaz.

Stub Zone ne zaman kullanılır
Yukarıdaki örnekte, widgets.microsoft.com alanı için yetki devri yapılmış ve bu alana iki NS kaydı ve DNS sunucusu eklenmiştir. Sistem yöneticisi bir süre sonra alana iki DNS sunucusu daha eklemiş ama ana alanı (parent zone) bu durumdan haberdar etmemiştir. Bu nedenle de widgets.microsoft.com alanına gelen sorgular halen ilk iki sunucu tarafından karşılanmaktadır.

Bu durum bir stub zone kurulmasıyla giderilebilirdi. Widgets.microsoft.com alanına ait Stub zone Microsoft.com alanının yöneticisi tarafından ana alanda kurulduğunda, widgets.microsoft.com alanının baş NS sunucusu sorgulanacak ve tüm NS kayıtları elde edilecektir. Bu alana yapılacak her türlü ekleme ve çıkarma işlemleri de otomatik olarak güncellenebilecektir.

Dikkat : Bir stub zone, aynı alanı yönetmeye yetkili DNS sunucusu üzerine kurulamaz. Örneğin, widgets.microsoft.com alanının stub zonu bu alanın yetkili DNS sunucusunda kurulamazdı. Bu alanın stub zonu ancak farklı bir alanın yetkili DNS sunucusunda kurulabilirdi. Örneğimizde bu sunucu Microsoft.com alanının yetkili DNS sunucusu olabilirdi.

Farklı kullanım metotları
Yukarıdaki örnekte farklı iki istemci ns.mgmt.ldn.microsoft.com kaynağını çözümlemek için kendi DNS sunucularına sorgu gönderiyorlar. Soldaki klasik DNS hiyerarşisi içinde uzun bir yoldan bu çözümlemeyi yapmak zorunda kalırken, sağdaki istemci ise, actg.wa.microsoft.com alanında oluşturulan stub zone sayesinde çözümlemek istediği kaynağın bulunduğu alana ait NS kayıtlarına tek hamlede ulaşmakta ve çözümlemeyi çok daha kısa yoldan yapmaktadır.

Önemli : Stub zone glue records DNS konsolundan görülememektedir.

Ağ İstemci Servisleri

2006-07-12T18:05:00.000+03:00

Apache

RHL tarafından kullanılan Apache web sunucusu sürümünde bazı önemli değişiklikler bulunmaktadır.

· Yeni paketler RHL içeriğinde bulunan Apache 2.0’ da tüm paket isimleri değişmiştir. Çoğu isim httpd ile başlamaktadır.

· Farklı direktifler Perl veya php tabanlı direktifler artık birbirinden bağımsız olarak /etc/httpd/conf.d dizininde konfigüre edilmektedir.

· Gözden geçirilmiş değişkenler Bazı değişkenler değişmiştir. Örneğin Apache’ ın web servisini 80 no.lu porttan dinlemesini sağlayan değişken adı Listen olmuştur.

· Sanal Hostlar Apache birden fazla web sitesinin tek bir IP adresi kullanarak aynı sunucu üzerinde bulundurulmasına sanal hostlar vasıtasıyla izin vermektedir.

Kurulum türlerinden Server veya özel kurulumda (Custom) Web Server paketinin seçilmesi halinde Apache otomatik olarak kurulmaktadır.

Apache yüklendikten sonra chkconfig programı ile Apache’ ın belirlenen runlevellarda otomatik olarak çalışacak şekilde konfigüre edilmesi sağlanmalıdır :

[client@host] /sbin/chkconfig -–level 35 httpd on

Aşağıdaki komut ile konfigürasyon kontrol edilebilir :

[client@host] /sbin/chkconfig -–list httpd

Basit Web Sunucusu Kurulumu için Temel Apache Ayarları :

Web sunucusunu doğru ayarlayabilmek için 3 tane ayar dosyası kullanılmaktadır. Apache web sunucusunun genel ayarları /etc/httpd/conf/httpd.conf dosyasından yapılmaktadır.

BİLGİ !
Apache 1.3.x ve öncesindeki sürümlerde aynı dizin içinde bulunan access.conf ve srm.conf dosyaları da kullanılmaktaydı. Apache 2.x ve sonrasında bu dosyalar kullanılmamaktadır.

Bu ayarlar dosyasında bazı temel yazım kuralları uygulanmaktadır. İlk olarak; dizin, modül ve dosyalar için ayarlamalar yapılırken, yapı kutuları (container) içine alınmaktadır. Bu kutular da (<> ) işaretleri ile ayrılır.

Örneğin ;

Kutu sonları ise bir düz kesme işareti ile gösterilir.

Örneğin ;

Erişim Kısıtlamaları
httpd.conf dosyası hangi servislerin kullanılacağına dair izinleri kontrol etmekte ve bu izinler her dizin için belirlemektedir. Bu kontroller sunucu tarafından doğrudan erişilen dizinler ve Apache web sunucusu üzerinden dizinlere erişen kullanıcılar için geçerlidir. Ancak Linux’ a normal olarak bağlanan kullanıcıları kapsamamaktadır.
Bu yetki ve kısıtlamalar üst dizinlerden geçişlidir. İlk olarak yetkilendirme yapılması gereken dizin (/) kök dizindir. Kök dizine erişim en üst düzeyde kısıtlanmalıdır.

Options FollowSymLinks
AllowOverride None

Bir başka kısıtlanması gereken dizin de web sayfalarının bulunduğu dizindir. Normal olarak bu dizin /var/www/html dizinidir. Örnek bir kısıtlama aşağıda gösterilmiştir :

Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all

.htaccess ile dizin kontrolü
Alt dizinlerdeki kısıtlamaları geçersiz kılmanın yolları bulunmaktadır. .htaccess adında gizli bir dosyayı ilgili dizinde oluşturup gerekli komutları bu dosya içine yazarak kısıtlamaları kaldırmak mümkündür. Bu yöntem httpd.conf dosyasında “AllowOverride Options” komutu bulunmadığı sürece geçerlidir. Her alt dizine farklı bir .htaccess dosyası oluşturarak tüm dizinler için esnek bir yetki tanımlaması mümkündür.
“Options” komutunun seçenekleri aşağıdaki tabloda gösterilmiştir :

None For no custom options in force
All To allow all options except MultiViews
ExecCGI Permits Web pages to run CGI scripts
FollowSymLinks Permits symbolic links to directories outside of DocumentRoot
Includes Allows server-side includes
Indexes To permit FTP-style directory indexing

RHCE302 Notları

2006-07-12T17:50:00.000+03:00

zX Window oturumunu özelleştirmek için kullanılabilecek bir çok ayar dosyası vardır. Bu dosyalar oturum açan kullanıcının ev dizininde bulunan gizli script dosyalarıdır ve X Windows başlangıç rutinleri tarafından kullanılmaktadırlar. X eğer bu dosyaları kullanıcının ev dizininde bulamazsa varsayılan dizindekileri kullanacaktır.

userclientrc=$HOME/.xinitrc
sysclientrc=/etc/X11/xinit/xinitrc

Yukarıdaki satırlar /usr/X11R6/bin dizininde bulunan startx dosyasından alınmıştır.

X Window sistemi startx komutu ile başlatıldığında xinit programı yukarıdaki satırlarda yazılı olan yollarda sırayla .xinitrc dosyasını arayacaktır. .xinitrc dosyası farklı X istemcilerini çalıştıracak bir seri komut içermektedir. İlk satır Linux’ un scripti işletmek için hangi kabuğu kullanacağını göstermektedir.

#! /bin/bash
xterm &
xclock –geometry 200x200-20+20 &
xcalc –geometry 300x300-20-20
exec twm

.xinitrc dosyası herhangi bir kelime işlemci işe oluşturulabilir ve daha sonra gerekli çalıştırma izni verilerek X Window tarafından kullanılması sağlanabilir. Ör :

chmod a+x ~/.xinitrc

Yukarıdaki komuta “a” parametresinin eklenmesinin nedeni, bu script dosyasının sistem tarafından tüm oturum açan kullanıcılar için işletilecek olmasıdır ve bu nedenle gerekli çalıştırma izni “all” için verilir.

Text ve Grafik Login Modları
Linux’ ta text ve grafik modlar arasında geçiş yapmak veya login modunu textten grafiğe çevirmek çok kolaydır. /etc/inittab dosyası içinde yapılacak küçük bir değişiklikle bu geçiş sağlanabilir :

id:3:initdefault:

yerine

id:5:initdefault:

yazarak açılışta sistemin grafik modda açılması sağlanabilir. Oturum açıldıktan sonra da modlar arasındaki geçiş aşağıdaki komutla yapılır :

/sbin/init 3

veya

/sbin/init 5

Gösterim Yöneticileri (Display Managers) xdm, gdm, kdm
Linux GUI’ yi kullanarak login olduğumuzda, login işlemi özel bir X istemcisi olan gösterim yöneticisi (display manager) tarafından gerçekleştirilir. Bu son derece basit bir programdır ve tek yaptığı ekranda kullanıcı adı ve şifreyi soran bir diyalog kutusu göstermektir. Belli başlı üç tane gösterim yöneticisi vardır ve /etc/X11 altındaki prefdm scriptinde “prefferred=” satırı değiştirilerek istenen yönetici kullanılabilir.
X Window sisteminin nasıl başlatıldığı ,nasıl bitirileceğini ve sonrasını da belirlemektedir. Örneğin, X Window saydığımız bu gösterim yöneticilerinden biri ile başlatılırsa, X Window kapatıldığında sistem tekrar gösterim yöneticisini kullanarak login penceresine dönecektir.

Bir gösterim yöneticisi kullanılarak login olunduğunda X Window ,startx kullanılarak başlatılan oturuma göre biraz daha farklı şekilde açılacaktır. startx çalıştırıldığında X Window oturumu, text tabanlı login kabuğunun alt süreci (child process) olarak çalışacaktır. Bu durumu runlevel komutunu çalıştırarak test etmek ve doğrulamak mümkündür. X Window’un çalıştığı zamanlarda bile Linux hala runlevel 3’ de çalışıyor olacaktır. X Window sonlandırıldığında oturum kapanmış olmayacağından, gerçek oturumu kapatmak için kabukta gerekli komutlar çalıştırılmalıdır.

Eğer bir GY (gösterim yöneticisi) kullanılarak logon olunuyorsa, Linux etkileşimli bir kabuk (shell) başlatmayacaktır. Onun yerine GY ,X Window login sürecini kontrol eden oturum yöneticisi (session manager) adında bir programı çalıştıracaktır. GNOME’ da bu programın adı /usr/bin/gnome-session, KDE’ de ise /usr/bin/kwin ‘dir.

Açılan X Windows oturumunda çalıştırılan tüm X istemcileri OY (oturum yöneticisi)’ nin alt süreçleridir. OY kapandığında tüm süreçlerde otomatik olarak sonlandırılırlar. Bir GY üzerinden login olunduğunda OY, ~/.xinitrc ayar dosyasını kullanmayacaktır.

X Uygulamalarının Uzaktan Görüntülenmesi
X Window sisteminin en güçlü yanlarından biri X uygulamalarını uzak sistemlerden çalıştırmaya izin vermesidir. Bu sayede birçok RHL sunucu sistemini uzaktan kendi bilgisayarımızdan yönetmemiz mümkün olabilmektedir.

Güvenlik
Güvenlik kontrolünü sağlamanın en kolay yolu xhost komutunu kullanmaktır. xhost komutu yerel sistemdeki X sunucusuna erişimi bir listeye bakarak teker teker kontrol eder.

Komut Tanımı
xhost Mevcut güvenlik ayarlarını gösterir
xhost + Güvenliği kaldırır. Tüm sistemlerin erişimine izin verir.
xhost - Güvenliği aktive eder.
xhost +host.xyz.com host.xyz.com’ dan erişime izin verir.
xhost - host.xyz.com host.xyz.com’ dan erişimi engeller.

BİLGİ !
Bu komuta daha gelişmiş bir alternatif ise xauth komutudur. Bu komut sadece hostların değil, kullanıcıların da erişimlerini kontrol edebilmekte ve kimlik doğrulama sırasında trafiği şifreleyebilmektedir. Tüm ayarları ~/.Xauthority dosyasında tutmaktadır.

DISPLAY değişkeni yazılı olmadığı sürece xhost çalışmakta sorun çıkartacaktır. Bu durumda basit bir değişken tanımlaması yazarak (DISPLAY=localhost:0.0) ve bunu ihraç ederek (export DISPLAY) xhost çalıştırılabilir.

Uzak X İstemcileri
Bir X istemcisini uzak bir sistemde çalıştırmak ve ekran çıktısını kendi yerel sistemimizde görüntüleyebilmek için bazı şartların yerine gelmiş olması ve bazı adımların takip edilmesi gereklidir.
İlk olarak uzak sisteme ,kendi yerel sistemimizde yetki vererek başlarız :

xhost +host.xyz.com

Sonraki adımda uzak sisteme logon olmamız gereklidir. Bunu telnet, rsh, rlogin vb. programlarla yapabiliriz.

telnet host.xyz.com

X Window uygulaması çalıştırılacağı için path tanımlarında X Window dizininin kayıtlı olup olmadığını kontrol etmek faydalı bir davranıştır. Yoksa , echo $PATH komutu ile görüntüler, eğer yoksa aşağıdaki komut ile ekleriz :

[client@host] $ PATH=$PATH:/usr/X11R6/bin

Çalıştırılması istenen X istemcisi aşağıdaki komutla çalıştırılır :

[client@host]xclock –display benimbilgs.xyz.com:0.0 &

Diğer bir yöntem de yukarıdaki komuttaki display parametresini bir değişkene atamak yoluyla istemcinin çalıştırılmasıdır :

[client@host]export DISPLAY=benimbilgs.xyz.com:0.0
[client@host]xclock

Hata giderme

OY ler kullanıcının ev dizininde ~/.xsession-errors adında log dosyaları oluştururlar. /var/log/messages ve /var/log/XFree86.0.log dosyaları ile birlikte bu log dosyasının da kontrol edilmesi gereklidir.
.xinitrc veya .Xclients kabuk scriptleri sorunlara yol açabilirler. Bunların silinmesi ya da adının değiştirilmesi denenebilir.

DISPLAY çevre değişkeni kontrol edilmelidir.
/usr/X11R6/bin dizininin $PATH değişkeninde kayıtlı olduğu kontrol edilmelidir.
X Window sisteminin uzak bağlantı yapmasını engelleyebilecek ağ ve sistem problemleri giderilmelidir.
X Font Sunucusu ,daha önceki bölümlerde anlatıldığı gibi kontrol edilmelidir.
X sunucusu kilitlenmiş olsa bile farklı bir text konsol ekranı açmak mümkündür.

DNS Alan ayarlarının yapılması

2006-07-12T17:43:00.000+03:00

DNS Alan ayarlarının düzenlenmesi için DNS Konsolu kullanılabilir. Bu konsolda aşağıdaki sekmeler bulunur : General, SOA, Name Servers, WINS, Zone Transfers.

General

Zone Status : Pause düğmesi ile alanın isim çözümlemesi geçici olarak durdurulup başlatılabilir. Ancak bu düğme DNS servisini durdurmaz.

Zone Type : Alanın Birincil, İkincil veya Stub Zone olarak yeniden tanımlanması için kullanılır. “Store the zone in the Active Directory” düğmesi seçilerek alanın C:\windows \system32\dns içinde saklanması yerine AD’ye entegre hale gelmesi sağlanabilir.

Zone Replication : Alanın AD içinde saklanması ile bu düğme aktif hale gelir. Alan bilgilerinin ne şekilde replike edileceğini ayarlamayı sağlar.

To all DNS servers in the Active Directory forest
Forest içinde yer alan tüm AD DNS sunucularına bilginin kopyalanmasını sağlar.
To all DNS Servers in the Active Directory Domain
Etki alanında yer alan tüm AD DNS sunucularına bilginin kopyalanmasını sağlar.
To all domain controllers in the Active Directory Domain
AD içindeki tüm etki alanı sunucularına bilginin kopyalanmasını sağlar.
Windows 2000 DNS sunucularının bilgileri alması için bu seçenek seçilmelidir.

Application Directory Partition ve DNS replikasyonu
Active Directory’de DNS için iki ADP bulunur. DomainDnsZones ve ForestDnsZones. DomainDnsZones AD içinde aynı zamanda DNS sunucusu olan tüm DC’lere kopyalanır. ForestDnsZones ise Forest içinde aynı zamanda DNS sunucusu olan tüm DC’lere kopyalanır.Her ADP bir alt etki alanı ve FQDN ile tanımlanmıştır. Örneğin, Yenibir.com etki alanının ADP’leri şöyle isimlendirilir : DomainDnsZone.yenibir.com.

Önemli : Eğer varsayılan DNS ADP’leri zarar görmüş veya silinmişse, DNS konsolunda sunucu üzerine sağ klik yapılarak Create Default Application Directory Partitions ile yeniden oluşturulabilir. ADP’ler mevcutsa bu seçenek seçilebilir durumda değildir.

Özel ADP’ler oluşturmak için aşağıdaki komutlar kullanılabilir.

Dnscmd servername /createdirectorypartition FQDN
Dnscmd servername /enlistdirectorypartition FQDN

Bu işlemi yapacak kullanıcının Enterprise Administrators grubuna üye olması gereklidir.

Yukardaki bilgiler ışığında Change Zone Replication Scope düğmesine basılarak “To all DNS servers in the Active Directory forest” seçildiğinde DNS alanı bilgileri aslında ForestDnsZones ADP’si içinde saklanmış olacaktır. Aynı şekilde “To all DNS Servers in the Active Directory Domain” seçildiğinde ise DNS alanı bilgileri DomainDnsZones ADP’si içinde saklanacaktır.

Dynamic Updates
Dinamik güncelleme özelliği DNS alanlarının bilgilerinin otomatik veya elle transfer edilebilmesi için gereken ayarları sağlamaktadır. AD’ye entegre alanlar için yok, güvenli ve güvensiz, güvenli aktarım seçenekleri bulunmaktadır. Standart alanlar için bu seçenekler yok, güvenli ve güvensiz olarak belirlenmiştir.

Aşağıdaki şartlardan birinin gerçekleşmesi halinde DNS dinamik güncelleme işlemi gerçekleşir.

- DNS istemcisinin açılması.
- DNS istemcisi olan bilgisayarda IP adresi değişikliği olması.
- İstemcinin ağ bağlantılarından herhangi birinde IP adresi eklenmesi, kaldırılması veya değiştirilmesi.
- Alandaki üye sunuculardan herhangi birinin terfi ettirilerek DC haline dönüştürülmesi.
- İstemcide IPconfig /registerdns komutunun kullanılması.

Güvenli Dinamik Güncelleme GDG işlemleri sadece AD-entegre alanlarda yapılabilir. İstemciler sunucu ile görüşmek için Kerberos protokolunu kullanırlar. GDG işlemlerini sadece Windows 2000, Xp veya 2003 sistemleri gerçekleştirebilir. Windows NT, Win9x ve WinME bilgisayarları GDG gerçekleştiremezler.

GDG ve DnsUpdateProxy grubu
GDG’nin geçerli olduğu bir DNS alanında host kayıtlarını sadece o kaydın sahibi olan bilgisayar güncelleyebilir. Bu durum, bir DHCP sunucusunun, kendi adına kayıt düzenleyemeyen istemciler için A kayıtlarını değiştirme yetkisine sahip olduğu ortamlarda sorun yaratabilir. Benzer bir ortamda kaydın sahibi DHCP sunucusu olacaktır. İstemcinin Windows 2000 ve üstü bir işletim sistemine terfi ettirilmesi ve kendi kaydını düzenlemeyi istemesi halinde sistem istemciyi kaydın sahibi olarak tanımayacağından soruna yol açabilir. Benzer bir durum DHCP sunucusunun arızalanması halinde yedek DCHP sunucusu dahil kimsenin yerine kayıt güncellemesi yapamaması olarak da karşımıza çıkabilir.

Böyle bir problemden kaçınmak için kayıt güncellemesi yapan tüm DHCP sunucularını DnsUpdateProxy grubuna eklemek gereklidir. Bu gruba dahil olan sunucuların kayıtları sahiplenmesine izin verilmez.

Kayıt Yaşı (Aging)
Kayıt yaşı özelliği ile dinamik olarak güncellenen DNS kayıtlarına bir zaman damgası vurulur ve kayıtların güncelliği bu damga ile takip edilir. Eski kayıtların zamanının dolması sonucunda bu kayıtlar otomatik olarak temizlenirler (Scavenging). Bu özelliğin aktif olması için kayıt yaşı (aging) özelliğinin aktif olması zorunludur.

Kayıt yaşı ve silme özellikleri aktif edildiğinde, DNS kayıtları Windows 2000 öncesi DNS sunucuları tarafından artık okunamazlar.

Start of Authority (SOA)
SOA sekmesi tüm alan için SOA kayıtlarının oluşturulmasını sağlar. DNS sunucusu alanı yüklediğinde yetkili bilgilerini bulmak için SOA kayıtlarına başvurur. Bu kayıt aynı zamanda birincil ve ikincil DNS sunucuları arasında alan transferlerinin hangi sıklıkta yapılacağını da tespit etmeye yarar.

Seri No (Serial Number ) : Seri no, alanın güncelleme kayıt numarasını belirler. Alanda bir kayıt değiştiğinde veya Increment tuşuna basarak elle yükseltildiğinde seri no artar. Bu sıra numarası alan transferi yapılırken de kullanılır. Ana alanın (master zone) seri numarası transfer edilecek alanınkinden büyükse transfer gerçekleşir, aynıysa alanların birbirinin eşi olduğu düşünülerek transfer yapılmaz.

Birincil sunucu (Primary server) : Alanın birincil DNS sunucusuna işaret eder. Sunucunun adı mutlaka bir nokta (.) işareti ile bitmelidir.

Güncelleme Aralığı (Refresh Interval) : Birincil alan sunucusundan ne sıklıkta alan transferi isteneceğini belirler. Buradaki değere göre alandan sorumlu diğer DNS sunucuları birincil sunucuya bağlanarak alan transferi başlatırlar. Varsayılan değeri 15 dk.dır

Tekrar Deneme Aralığı (Retry Interval) : Başarısız olmuş bir alan transferinden ne kadar sonra tekrar deneneceğini belirler. Varsayılan değeri 10 dk.dır.

Geçersizleşme Zamanı (Expires After) : İkincil DNS sunucusunun ana sunucusu ile hiç bağlantı kurmadan, gelen sorgulara ne kadar süreyle cevap verebileceğini belirler. Sürenin dolmasından itibaren sunucudaki kayıtlar güvenilmez kabul edilir. Varsayılan değeri 1 gündür.

Minimum (Default) TTL: Bu değerin ayarlanması ile alandaki tüm kayıtların maksimum yaşam süresi (Time to live :TTL) belirlenmiş olur. Varsayılan değer 1 saattir.

TTL değeri kendi yetkili sunucusunda tutulan kayıtlar ile ilgili değildir. Daha çok yetkisiz ve cache belleğinde kaydı tutan sunucuları ilgilendirir. Bir sorgu sırasında kaydı belleğine alan bir DNS sunucusunun kaydı ne kadar süre ile tutacağını gösterir.

Eğer ağ ortamında caching-only DNS sunucusu varsa, kayıtların TTL değerlerini arttırmak ana DNS sunucusu ile caching-only sunucu arasındaki trafiği azaltacaktır.

Tam olarak kayıt edildiğinde bir SOA kaydı aşağıdaki gibi olacaktır.

@IN SOA server01.contoso.com. hostmaster.contoso.com. (
5099 :serial number
3600 : refresh (1 hour)
600 : retry (10 mins)
86400 : expire (1 day)
60 ) : minimum TTL (1 min)

İsim Çözümlemesinin Yönetilmesi

2006-07-12T17:23:00.000+03:00

DNS sunucuları iki çeşit alan destekler. Forward Lookup Zone ve Reverse Lookup Zone. Sunucunun her bir alan türü için üstleneceği rol ise aşağıdaki seçeneklerden biri veya birden fazlası seçilerek tespit edilebilir.

- Birincil alan
- İkincil alan
- Stub Zone

En çok kullanılan DNS kayıt tipleri aşağıda listelenmiştir :

- Host (A)
- Alias (CNAME)
- Mail Exchanger (MX)
- Pointer (PTR)
- Service Location (SRV)

Host (A)
Host kayıtları alan veritabanında en çok karşılaşılan kayıt türüdür. DNS alanı içindeki sistemlerin veya hostların alan adlarının IP adresleri ile eşleştirilmesi için kullanılır. Elle, DNS dinamik kayıt yöntemi veya DHCP yoluyla A kayıtları oluşturulabilir.

IPconfig / registerdns komutu ile A kaydı bulunmayan host için DNS alanında kayıt oluşturulabilir.

Alias (CNAME)
Canoncial Names olarak da adlandırılır. Bir hostu birden fazla isimle adlandırmak ve işaretlemek için kullanılır. Örneğin, ftp ve www birer CNAME’dir.

Mail Exchanger (MX)
MX kayıtları e-posta uygulamalarının bir alan içindeki e-posta sunucusunu bulabilmelerini sağlayan kayıt türüdür. Birden fazla MX kaydı olması halinde, ilk sunucunun bulunamaması durumunda ikincisine yönlendirme ve dolayısıyla hata toleransı sağlamak mümkündür.

Pointer (PTR)
PTR kayıtları Reverse Lookup Zone içinde reverse lookup sorgularının yapılabilmesi için kullanılır.

Service Location (SRV)
SRV kayıtları etki alanında bir servisin hangi hostlar tarafından sağlandığını bulmak için kullanılır. SRV tanıyan uygulamalar DNS sunucusunun SRV kayıtlarından faydalanabilirler.

Active Directory’de kullanılan tüm servislerin SRV kayıtları Windows\System32\Config klasöründeki netlogon.dns dosyası içinde bulunmaktadır. Eğer DNS’te SRV kayıtları eksikse netdiag /fix komutu kullanılarak bu dosyadan yüklenebilirler.

Eğer bir bilgisayar yenibir.com etki alanındaki bir LDAP sunucusuna ulaşmak isterse istemci DNS sunucusuna aşağıdaki sorguyu gönderir :

_ldap._tcp.yenibir.com

Aşağıdakine benzer bir cevap alınır : (Kayıtlar çoğunlukla otomatik yaratılıyor olsa da aşağıdaki örnekte otomatik kayıda ek olarak hata toleransı sağlamak için elle oluşturulmuş ikinci bir kayıt bulunmaktadır.)

_ldap._tcp SRV 0 0 389 dc1.yenibir.com (0 öncelik değeri, 0 Load Balance)
SRV 10 0 389 dc2.yenibir.com (10 öncelik değeridir)

DNS Sunucusunun Cache temizlemesi için servis yeniden başlatılabilir veya dnscmd.exe /clearcache komutu çalıştırılabilir.

DNS Sunucu konsolunun kullanılması
DNS Sunucusu üzerinde sağ klik yapıldığında Properties seçilerek gelen sekmeklerin kullanımı aşağıda anlatılmıştır.

Interfaces
Bu sekme, sunucunun ağ kartlarından hangilerinin DNS taleplerini dinleyeceğini belirler. Örneğin iki ağ kartı olan bir sistemde, biri iç ağa diğeri dış ağa bakan iki bağlantı oluşturulabilir ve sadece iç ağa servis veren tarafın DNS isteklerini dinlemesine izin verilebilir.

Forwarders
Bu sekme ile DNS sunucusunun kendine gelen istekleri hangi DNS forwarder sunucularına ileteceği ve hangi etki alanlarına dair istekleri dışarı yönlendireceğini belirlemek mümkündür. Örneğin, yenibir.com etki alanına ait tüm çözümleme istekleri cevaplanması için 80.1.22.55 sunucusuna yönlendirilebilir. Buna şartlı yönlendirme (Conditional Forwarding) denir.

Aşağıdaki durumda ise iç ağ ile dış ağları (Internet) buluşturmadan, arada bir güvenlik duvarı varken Internet’ten nasıl isim çözümlemesi yapılabileceğini dair bir forwarder örneği verilmiştir.
Disable Recursion özelliği forwarder DNS sunucu tarafından çözülemeyen bir isim sorgusunun, soruyu soran DNS sunucusu tarafından kendi başına çözmeye çalışmak için yapacağı eylemi engelleyecektir. Bu özelliğin aktif hale getirilmesi hata toleransını ortadan kaldırmakla birlikte olumsuz cevapların istemciyi fazla bekletmeden verilebilmesini sağlayacaktır.
Disable Recursion bu sekmeden çalıştırılabileceği gibi Advanced sekmesinden de tüm DNS sunucusu için kullanılabilir. Ancak bu noktadan çalıştırılması halinde sunucuya forwarder tanımlamaya izin vermeyecektir.

Root Hints
C:\Windows\System32\Dns\Cache\cache.dns dosyasının bir kopyasını gösterir. Internet’teki kök DNS sunucularının listesini içermektedir. DNS sunucusu Internet ile isim çözümleme işlemleri yapacaksa bu dosya ve Root Hints kalmalıdır. Ancak sunucu iç ağda bir kök sunucu (.) olarak çalışacaksa bu dosya silinmelidir.
Benzer bir şekilde, iç ağ çok büyükse ve birden çok kök sunucu varsa, bu dosyanın içeriği değiştirilerek kendi DNS sunucularınızı yazabilirsiniz.

Monitoring
Temel DNS fonksiyonlarının çalışmasına ilişkin testlerin yapılmasını sağlar.

İlk test sunucunun kendisine sorgu gönderip alabilmesini kontrol eder. Testin başarılı olması için sunucu kendisine gönderilen forward ve reverse queryleri alabilmelidir.

İkinci test ise kök DNS sunucularına recursive query yapılmasına yöneliktir. Testin başarılı olabilmesi için sunucu Internet’e bağlı olmalı ve kök DNS sunucuları ile görüşebilmelidir.

Sunucu Rolleri ve Güvenliğinin Planlanması

2006-07-12T17:09:00.000+03:00

Windows 2003 işletim sisteminin güvenli çalıştırılabilmesi için düzenlenmesi gereken bir çok ayar bulunmaktadır. Bu ayarların sağlıklı ve verimli olarak düzenlenebilmesi için bir çok yardımcı araç sunulmuştur. İyi bir planlama ve araçların yerinde kullanımı ile güçlü bir güvenlik altyapısı oluşturmak mümkün olabilir.

Windows 2003 güvenlik ayarları birden fazla araç, bunların konsol ekranları veya Group Policy ile yönetilebilmektedir.

Denetim Kuralları
Denetim Kuralları ve buna bağlı olarak oluşturulan log kayıtları sistem olaylarını incelemek için kullanılan en önemli kaynaklardandır. Ancak kullanımı son derece hassastır. Zira gereğinden fazla log kaydı üreten bir denetim kuralı, güvenlik olaylarını izlemeyi güçleştireceğinden yarardan çok zarar getirebilir.

Audit Account Logon Events : Bir bilgisayara logon olan her kullanıcı için kullanılır. Bu ayar genelde DC’ler için kullanılmakta olup üye sunucular için açılmasına gerek yoktur.

Audit Account Management : Bir bilgisayar üzerinde bulunan tüm hesapların yönetimine ilişkin eylemler loglanır. Kullanıcı oluşturma, değiştirme, silme hatta şifre değişikliği bile bu ayarın aktif hale getirilmesi ile loglanabilir. DC’ler dışındaki diğer sunucularda bu ayar ile sunucunun yerel SAM veritabanına ilişkin eylemler loglanır.

Audit Directory Service Access : Bir AD nesnesine erişmeye çalışan kullanıcıya ilişkin eylemler loglanır. Sadece DC’lerde açılması yeterlidir.

Audit Logon Events : Bilgisayara logon ve logoff olan tüm kullanıcılara ilişkin eylemler loglanır.

Audit Object Access : Bir dosya, klasör veya registry gibi sistem elemanlarına ulaşmaya çalışan kullanıcıların eylemlerinin loglanabilmesi için bu kaydın açılması ve loglanması istenen nesnenin üzerinde de denetim özelliğinin aktif hale getirilmesi gereklidir.

Audit Policy Change : Bilgisayardaki denetim ayarlarının, kullanıcı hakları atamalarının veya güven kurallarının (trust policy) değişmesi halinde loglama yapılır.

Audit System Events : Sistemin yeniden başlatılma ve kapanma gibi eylemleri ve güvenlik kayıtlarını etkileyen olaylar loglanır.

Olay Kayıtları Kuralları (Event Log Policies) : Her log türü için 4 kural kaydı tanımlanabilir.

Maksimum Log Büyüklüğü : Log dosyasının fiziksel olarak ne kadar büyüyebileceğini belirtir. 64 KB’lik adımlar halinde en fazla 4 GB’a kadar büyüyebilir.

Yerel ziyaretçi hesabının loglara erişmesini engelle : Local Guest grubu üyeleri log kayıtlarına erişemezler.

Logları sakla (Retain Log) : Logların kaç gün saklanacağını belirtir.

Logların Saklanma Metodu : Log kayıtları belirtiklen gün sayısı kadar saklanır ve gün sayısı aşıldığında, en eski günden başlamak itibariyle silinebilir. Gerektikçe silinmesi özelliği kullanılarak belirli kayıt büyüklüğüne erişildiğinde otomatik silinmesi sağlanabilir. Ya da yerel yönetici tarafından elle silinmesi sağlanabilir. Bu durumda log dosyası maksimum büyüklüğe ulaştığında yazmayı durduracaktır.

Sistem Servisleri ilkeleri
Windows 2003 Server servislerinin Group Policy ile otomatik veya elle başlatılması veya durdurulması sağlanabilir.

Kayıt Defteri (Registry ) İlkeleri
Kayıt defteri üzerinde ACL’ler oluşturmayı sağlar. Bu ilkeler Registrye yeni kayıtlar eklemez. Sadece registrynin güvenliğini düzenler.

Dosya Sistemi
Kayıt defteri ilkeleri gibi GPO’nun uygulandığı bilgisayardaki dosya sistemi üzerinde ACL’ler ile erişim yetkilerini tanımlamaya yarar.

Kullanıcı Hakları
Kullanıcıların sahip olduğu bazı hakları düzenler.

Hesap İlkeleri
Şifre ilkeleri, hesap kilitleme ve Kerberos ilkeleri gibi güvenlik ayarlarının düzenlenmesini sağlar.

DC’lerin güvenliğinin sağlanması
DC’ler etki alanı ve içinde çalışan tüm sistemlerin yönetiminde en büyük role sahip olduklarından güvenliğinin sağlanması diğer sistemlere göre çok daha büyük önem arzetmektedir.
DC’lerin fiziksel olarak güvenli ortamlarda tutulması, konsol ekranlarının şifre ile korunması ve hatta ağ ortamında DC’lerin tüm portlardan erişimine izin verilmemesi güvenlik yöntemleri arasında sayılabilir.

Yine Olay kayıtlarının (Event Log) aktif hale getirilmesi ve denetim özelliğinin (Audit Policy) çalıştırılması da önemlidir. DC’lerde bazı denetim ayarları açıktır ancak varsayılan değer olarak sadece başarılı eylemler loglanır. Başarısız eylemlerin loglanması için düzenleme yapılması gereklidir.

Kullanıcı yetkilerinin atanması
Güvenli bir çalışma ortamı oluşturulması için aşağıdaki bazı önerilerin uygulanmasında fayda vardır. Aşağıdaki ayarlar Domain Controller Security Policy içinde uygulanması halinde DC’lerin daha güvenli çalışmasını sağlayacaklardır.

Debug Programs
Bu yetkiye sahip kullanıcılar hata ayıklama araçları kullanarak işletim sistemi hatta kernel seviyesinde inceleme ve değişiklikler yapabilirler. Bu tarz uygulamaların kullanılmasına gerek yoksa veya yazılım geliştiriciler sistemde çalışmıyorsa Administrators grubundan bu yetki geri alınabilir.

Add Workstations to Domain
Varsayılan değer olarak tüm tanımlanmış kullanıcıların (Authenticated Users) etki alanına 10 adete kadar PC’yi dahil etme yetkileri vardır. Bu sayede AD’de Computers bölümü altında bilgisayar nesneleri oluşturabilirler. Eğer sistem IT personeli tarafından yönetiliyorsa kullanıcılardan (Authenticated Users) bu yetki geri alınabilir.

Allow Log On Locally
Bu yetki varsayılan ayar olarak aşağıdaki kullanıcı gruplarına bilgisayarın konsol ekranından logon olabilme imkanını tanır.
- Account Operators
- Administrators
- Backup operators
- Print operators
- Server operators

Shut Down the System
Bu yetki varsayılan ayar olarak aşağıdaki kullanıcı gruplarına sistemin kapatılabilme yetkisini verir.
- Administrators
- Backup Operators
- Print Operators
- Server operators

Servislerin Ayarlanması
Daha önceki tabloda yer alan servislere ek olarak DC’lerde aşağıdaki servislerin de başlama şeklinin otomatik olması gereklidir.
- Distributed File System
- File Replication Service
- Intersite messaging
- Kerberos Key Distribution Center
- Remote Procedure Call (RPC)

Bir sistemde güvenliğin sağlanabilmesi için uyulması gereken en önemli kurallardan biri de “Gereken en az yetkiyi verme prensibiyle çalışmak”tır. Bu prensibin başarıyla uygulanabilmesi için aşağıdaki detaylara dikkat etmek gerekir :

- Güçlü bir şifre politikası uygulamak
- Yetkileri kısıtlamak (özellikle logon yetkilerini).
- Yetkisiz erişimleri engellemek için güvenlik ayarlarını kullanmak.
- Dosya ve kayıt defterleri için Access Control Lists (ACL)’ ler oluşturmak.
- Önemli grupların üyeliklerini Group Policy ile düzenlemek.
- Kullanılmayan tüm servisleri kapatmak ve hangi servisi kimin kullanabileceğini tespit etmek.
- Her bilgisayar rolü için br güvenlik şablonu tespit etmek ve uygulamak.
- Anlaşılabilir ve takip edilebilir düzeyde bir denetim stratejisi uygulamak.

Güvenli ayarlarının GPO ile düzenlenmesi
Güvenlik ayarlarının her sunucu ve PC için teker teker elle uygulanmaya çalışılması pratik bir yöntem değildir. Bu durumda Group Policy’nin yeteneklerinden faydalanmak ve merkezi bir uygulama en doğrusudur.

Windows 2003 server tüm bilgisayar nesnelerini AD’de Computers Container (Konteyner) altına yerleştirir. Konteyner özel bir AD nesnesidir. AD’de Computers dışında, Users, Builtin ve ForeignSecurityPrincipals adında üç özel nesne daha bulunur. Bu nesneler silinemez ve benzer özelliklerde konteynerler oluşturulamaz.

Group Policy nesneleri Site, domain veya OU’ lara bağlanabilir ancak Konteynerlerle ilişkilendirilemezler.

Tüm sunucuları bağlayacak bir temel GP ayarlar seti oluşturmak için yapılabilecek en iyi hareketlerden biri, kök AD dizininde bir sunucu OU’ su oluşturmak ve sunucuları bu OU altına kaydırmaktır. Daha spesifik hareket etmek isteyen sistem yöneticileri, farklı rollerdeki sunucular için farklı OU’ lar ve GP setleri oluşturabilirler.

Özellikle aynı ayar setlerine sahip olduklarından emin olmadıkça PC’ler ve sunucuları aynı OU altında toplamak doğru olmayacaktır.

Bir GPO’ nun birden fazla OU’ ya bağlanması (link) sonucunda GPO’ nun birden çok kopyası oluşturulmaz. Hala tek bir kopyası vardır ancak GPO da yapılan değişiklikler bağlı olduğu tüm OU’lardaki tüm nesneleri eşit derecede etkileyecektir.

GPO Link listesinde birden fazla GPO görülüyorsa sıralama olarak daha üstte olan GPO daha etkindir ve ayarları baskın olacaktır.

GPO ayarlarının uygulama öncelikleri aşağıdaki açıklamaya göre hesaplanabilir.

- Eğer üst seviye OU’ daki GPO ayarı tanımlanmamış ve altındaki OU’ daki aynı ayar tanımlanmış ise, geçerli ayar alt OU’ daki olacaktır.
- Eğer üst seviye OU’ daki GPO ayarı tanımlı ve altındaki OU’ daki aynı ayar tanımlanmamış ise, geçerli ayar üst OU’ daki olacaktır.
- Eğer üst ve alt seviye OU’ ların her ikisinde de aynı ayar tanımlanmış ise, geçerli ayar alt OU’ daki olacaktır.

Güvenlik ayarlarının şablon dosyalar ile yapılması
Windows 2003, güvenlik ayarlarının tek elden yapılabilmesi için daha önceden tanımlı ayarların bulunduğu şablon (template) dosyalarına sahiptir. Şablon dosyaları (.inf) uzantılı metin dosyalarıdır.

Şablon dosyaları ile aşağıdaki güvenlik ayarları düzenlenebilir :

- Hesap yönetim kuralları (Account policies)
- Yerel Kurallar (Local Policies)
- Olay Günlüğü Kuralları (Event Log Policies)
- Kısıtlı Gruplar (Restricted Groups)
- Sistem servisleri
- Kayıt defteri yetkileri (Registry permissions)
- Dosya sistemi yetkileri (File System permissions)

Şablon dosyaları Group Policy, GP Security Configuration and Analysis MMC veya secedit.exe ile uygulanabilir.

Metin tabanlı şablon dosyaları ile çalışmanın en büyük avantajlarından biri, sisteme yapılan düzenlemelerin geri alınması istendiğinde, yapılan tüm ayarları hatırlamanın zor olacağı varsayılarak bir dosya kullanarak geri dönmenin daha basit olacağının varsayılmasıdır.

Şablon dosyaları Windows\Security\templates klasörü altında bulunmaktadır.

Setup Security.inf : Bilgisayarı Windows 2003 setup programının hazırladığı temel güvenlik ayarlarına döndürür. Bu ayarlar, daha sonradan yüklenen tüm yazılımların hazırladığı güvenlik ayarlarını ezebileceğinden, bu yazılımların yeniden yüklenmesi gerekebilir.

DC Security.inf : Bu ayarlar dosyası, bir W2K3 sunucusu DC’ye dönüştürüldüğünde ortaya çıkar. DC’ lerin varsayılan dizin ve kayıt defteri güvenlik ayarları bulunmaktadır.

Securedc.inf : DC’ nin güvenlik seviyesini yükseltecek ayarlar içerir. Anonim hesaplar ve LAN Manager sistemleri için yüksek güvenlik ayarları bulunur.

Hisecdc.inf : Securedc.inf’den daha da yüksek seviye güvenlik ayarları içerir. Sayısal olarak işaretlenmiş iletişim (digitally signed communication) ve şifrelenmiş güvenli kanal iletişimi (encrypted secure channel communication) ayarlarının zorunlu uygulanmasını sağlar. Bazı servisleri pasif hale getirir ve Power Users grubunu boşaltır.

Compatws.inf : Varsayılan ayar olarak yerel Users grubunun üyeleri sadece Windows uyumluluğu test edilip onaylanmış yazılımları çalıştırabilirler. Uyumsuz yazılımları sadece Power Users grubu üyeleri çalıştırabilir. Bazı durumlarda kullanıcılara bu yazılımları kullanabilmeleri için Power users grubu yetkileri verilir. Compatws.inf ayarları uygulandığında Power users grubu boşaltılır ve Users grubu için bazı dizin ve kayıt defteri yetki değişiklikleri yapılır. Bu şablon DC’lerde kullanılmaz.

Securews.inf : Üye sunucular veya PC’ler için güvenlik ayarları içerir. Anonim hesapların erişimine dair yetki kısıtlamaları ve Sayısal olarak işaretlenmiş iletişim (digitally signed communication) ayarları içerir.

Hisecws.inf : Daha yüksek derecede güvenlik ayarları içerir. Local Administrators grubu üyeleri sadece Domain Admins ve yerel Administrator hesabı olur. NTLM güvenlik seviyesini arttırır.

Rootsec.inf : Windows 2003 işletim sistemi kullanan sistemler için varsayılan dosya sistemi güvenlik ayarlarını içerir. Bir sistem sürücüsüne (C:, D: vb.) varsayılan yetkileri geri yüklemek için kullanılabilir.

Şablon dosyaları metin tabanlı olduklarından üzerlerinde kolayca değişiklik yapmaya uygundurlar. Ancak değiştirmeden önce yedeklerinin alınmasında fayda vardır.

Security Configuration and Analysis aracı, şablon ayarlarının uygulanmasına imkan sağladığı gibi mevcut ayarlarla bir şablon dosyasını karşılaştırmayı ve o anki ayarların üzerinde değişiklik yapılıp yapılmadığını öğrenmeyi sağlar.

Bir sistemin analiz edilebilmesi için araç ile öncelikle bir veritabanı oluşturulmalıdır. Bu veritabanına bir şablon dosyası aktarılır ve bilgisayardaki aktif ayarlar ile aralarındaki farklılıklar analiz edilir.

Farklılıklar bazı özel işaretlerle belirtilir :

- Kırmızı daire içindeki X : Ayarın hem veritabanı hem de bilgisayarda olduğunu ancak değerlerin aynı olmadığını gösterir.
- Beyaz daire içindeki yeşil işaret : Ayarın hem veritabanı hem de bilgisayarda olduğunu ve değerlerin aynı olduğunu gösterir.
- Beyaz daire içindeki soru işareti : Ayarın veritabanında bulunmadığını ya da yetki kısıtlamaları nedeniyle aracın ayarları sorgulayamadığını gösterir.
- Beyaz daire içindeki ünlem işareti : Ayarın veritabanında bulunduğunu ancak bilgisayar ayarlarında bulunmadığını gösterir.
- İşaret yok : Ne bilgisayarda ne de veritabanında ayarın bulunmadığını gösterir.

Ayarlar incelendikten sonra istenirse değişiklik yapılıp bilgisayara uygulanabilir ya da bu ayarlardan yeni bir şablon dosyası oluşması sağlanabilir.

Oluşturulan şablon dosyası, mevcut veritabanı içindeki değiştirilmiş şablondan üretilir. Aktif bilgisayar ayarlarından üretilmez.

Secedit.exe
Bu araç ile Security Configuration and Analysis aracının yaptıklarının tamamı ve hatta daha fazlası komut satırından yapılabilir. En büyük avantajlarından biri de bir şablonun sadece bir kısmını uygulamak gibi bir esnekliğe sahip olmasıdır. Tıpkı grafik tabanlı diğer araç gibi bir veritabanı oluşturur, karşılaştırır, analiz eder ve ayarları uygulayabilir. Ayrıca uygulanan ayarların geriye alınabilmesi için bir “Rollback” şablonu da oluşturabilir.

Ağ İletişimini Güvenli Hale Getirmek

2006-07-12T15:05:00.000+03:00

Ağ ortamında birbirleriyle iletişim kuran sunucu sistemleri ve uygulamaların aralarındaki veri değiş tokuşu güvenli metotlarla yapılmıyorsa yabancı kişiler tarafından dinlenebilir ve gizli bilgiler fark edilmeden ele geçirilebilir. Aşağıdaki örnekte FTP uygulamasına şifresini giren kullanıcının şifresinin Network Monitor yazılımı ile yakalanması buna gösterilebilecek en basit örneklerdendir:

IPsec

protokolü veriyi gönderilmeden önce sayısal olarak imzalamak ve şifrelemek esasına dayanır. IPsec protokolü IP datagramlarını şifreler ve iletişimin herhangi bir noktasında paketlerin incelenerek çözülmesi olasılığını ortadan kaldırır. IPsec OSI modeline göre Network katmanında çalışır ve uçtan uca şifreleme –paketin çıkış noktasında şifrelenmesi ve varış noktasına kadar şifresinin çözülmemesi prensibi- yapar. Ağ ortamında trafiği yönlendiren routerlar için şifrelenmiş içerik payload olarak algılandığından routerlar bu paketlerin şifresini çözmeye gerek duymadan olduğu gibi iletirler.
SSL gibi diğer şifreleme protokolleri OSI modeline göre Application katmanında çalıştıklarından uygulamaların seçtikleri trafik türlerini şifrelerler (web trafiği gibi).

IPsec protokolünün sağladığı birden fazla güvenlik özelliği vardır :

Anahtar Üretimi (Key Generation)

Ağ üzerinden şifrelenmiş paketler gönderip alan iki bilgisayarın gelen paketleri çözmeleri için ortak paylaşılan bir anahtara ihtiyaçları vardır. Ancak bu anahtarın ağ üzerinden gönderilmesi ele geçirilmesi ihtimalini ortaya koymaktadır. Bu nedenle, ağ üzerinden IPsec ile haberleşecek bilgisayarlar Diffie-Helmann algoritması denilen, her bilgisayarda uygulanıp aynı sonucu elde eden hesaplama teknikleri sayesinde anahtarlarını paylaşmadan aralarında veri değiş tokuşu yapabilirler.

Şifrelenmiş Dip toplam (Cryptographic checksum)

Ağ üzerinden gönderilen trafiği şifrelemeye ek olarak, IPsec her pakette HMAC (Hash message authentication code) denen dip toplam hesaplamaya yarayan anahtarı da gönderir. Böylece paket yolda birileri tarafından değiştirilse bile alıcı paketi değiştirilmiş olduğunu anlayabilir. IPsec Message Digest 5 (MD5) ve Secure hash algoritm (SHA-1) fonksiyonlarını kullanabilir. SHA-1 160 bittir ve MD5 (128 bit) e göre daha güvenlidir.

Mutual Authentication

Windows 2003 IPsec, Kerberos, sayısal sertifikalar veya önceden paylaşılan anahtar uygulamaları ile aralarında IPsec kullanacak bilgisayarların birbirlerini tanımlamalarına imkan sağlar. Dolayısıyla her iki tarafın da sayısal imzasının karmaşıklıklığı ve diptoplamı yanlış veya hatalı bilgisayarın tanınmasını engeller.

Paket tekrarlamanın engellenmesi (Replay prevention) : IPsec her pakete bir numara atadığından paketlerin tekrarlanması veya dışarıdan üretilerek araya karıştırılarak gönderilmesi mümkün değildir.

IPsec Protokolleri

IPsec standartını aşağıdaki iki farklı protokol sağlar. IP Authentication Header -AH- ve IP Encapsulating Security Payload –ESP- :

IP Kimlik Doğrulama Başlığı (IP Authentication Header -AH-)

IP authentication header protokolü IP paketleri içindeki veriyi şifrelemez, ancak kimlik doğrulama, paket tekrarının engellenmesi ve bütünlük fonksiyonlarını sağlar. AH kendi başına veya ESP ile kullanılabilir. AH, kendi başına yetkisiz kullanıcıların paket içeriğini okumalarını engelleyemez ancak AH kullanmak paketlerin yolda değiştirilmemesini ve paketin gerçekten de kaynak IP’ye sahip sistemden çıktığını garantiler.

İletişimde AH kullanan bir sistem IP paketinin içine AH başlığını yerleştirir.

AH başlığının içinde aşağıdaki bilgiler yer alır.

Next header : IANA (Internet Assigned Numbers Authority) tarafından belirlenen spesifik protokol kodunu içerir. IPsec AH protokolünü tek başına kullanıyorsa bu alan, datagram payloadu oluşturan protokol tarafından üretilen kodla doldurulur. Genelde TCP, UDP veya ICMP dir.
Standart IP paket başlığında aslında bir Protokol kodu alanı vardır. Normalde bu alana TCP için 6, UDP için 17 ve ICMP için 1 yazılır. Ancak AH kullanan bir pakette bu alanın kodu 51dir. Çünkü AH başlığı hemen IP başlığının ardına yazılır. AH başlığının içinde bulunan Next Header alanında TCP, UDP veya ICMP’ye ait kod bulunur.

Payload Length : AH başlığının uzunluğunu belirler.

Reserved : Kullanılmamaktadır.

Security Parameters Index : Paketin hedef IP adresi ve güvenlik protokolünün (AH) kombinasyonundan oluşan bir değer içerir (SA - Security Association). Paketin gönderileceği bilgisayara iletişimin güvenliği için kullanılacak tüm ayarları içeren bilgileri gönderir.

Sequence Number : Aynı SA’ya sahip her paket gönderildikçe 1er sayı artan sıra numarasıdır. Bu sayede paketlerin yeniden tekrarlanmasını engeller (anti replay)

Authentication Data : Gönderici bilgisayarın hesapladığı bir ICV (Integrity check value) değeridir ve paketin değiştirilmeden alıcıya iletildiğini doğrular. Alıcı bilgisayar da kendi hesaplaması sonucunda aynı ICV değerini buluyorsa paket değişmemiştir.

IPsec Transport mode veya Tunnel Mode denilen iki farklı modda çalışabilir.

Transport modda çalışırken IPsec protokolü, iletişim kuran her iki bilgisayarın da IPsec paketlerini algılayabilmesini ve şifreleme / deşifreleme işlemlerini yapabilmesini bekler. Ancak routerlar ve diğer ara cihazların IPsec algılama yeteneğine sahip olması gerekli değildir.

Tunnel Mode ise genelde VPN gibi Internet tabanlı iletişim yöntemlerinde sıkça kullanılan bir yoldur. Tunnel Modunda alıcı ve gönderici bilgisayarlar yerine her iki uçtaki routerlar IPsec kullanırlar. Tunnel modunda routerlar paketleri Transport moddakinin yerine tamamını başka bir IPsec paketi ile enkapsüle ederek gönderirler.

Windows 2003 IPsec uygulaması aşağıdaki bileşenlerden oluşur :

IPsec Policy Agent : Her Windows 2003 bilgisayarında bulunan, AD veya kayıt defterinden (registry) IP ayarlarını okuyan servistir. IPSEC Services

Internet Key Exchange (IKE) : IKE, IPsec bilgisayarlarının Diffie-Hellman anahtarları üretmek ve Security Association (SA) oluşturmak için kullandıkları protokoldür. IKE iletişimi iki fazda gerçekleşir. Birinci fazda hangi kimlik doğrulama, hashing ve şifreleme algoritmalarının kullanılacağına dair pazarlık yapılır. İkinci faz her bilgisayarda ayrı ayrı uygulanır. Bu fazda da hangi IPsec protokolünün, şifreleme metodunun kullanılacağına dair pazarlıklar yapılır.

IPsec sürücüsü (driver) : İletilecek verinin şifrelenmesi, dip toplamların (checksum) oluşturulması ve güvenli iletişimin başlatılmasını sağlar. Sürücü sistemdeki IPsec kurallarından (policy) bir filtre listesi oluşturur ve giden her paketi bu filtre ile kontrol eder. Bir paket eğer filtrenin kriterlerine uyuyorsa, sürücü hedef sistemle IKE iletişimini başlatır, giden pakete AH ve ESP başlıklarını ekler ve gerekiyorsa içeriği şifreler. Gelen paketler içinse diptoplam ve hash değerlerini hesaplar ve bunları doğrulama için gelen paketlerle karşılaştırır.

IPsec kullanımının planlanması

IPsec protokolünün ağınızda kullanılması göreceli olarak Windows 2003 işletim sistemleri için basit bir işlemdir. Ancak gerçekte iyi hesaplanması gereken bir davranıştır. Zira, AH ve ESP başlıkları mevcut ağ trafiğine belirgin bir yük getirecektir. Ayrıca giden gelen paketlerin şifrelenmesi ve deşifre edilmesi işlemleri de bu işleri yapacak bilgisayarlarda bir veri işleme gücü ve zamanı gerektirecektir. Yeterince güçlü olmayan bilgisayarlarda veri şifreleme / deşifre işlemlerinin gecikmelere yol açması muhtemeldir.
Buna karşılık IPsec bu konuda da esneklik getirmiş ve ağ yöneticilerine istedikleri sistemler veya protokol türleri için IPsec kullanabilme imkanını tanımıştır.

IPsec kurallarını yönetmek için IPsec MMC konsolu kullanılır. IPsec kuralları da tıpkı diğer Group Policy öğeleri gibi Site, domain veya OU’lara uygulanabilir.

Windows 2003 Server tarafından varsayılan değer olarak üretilen ve konsolda görülebilen 3 IPsec kuralı vardır :

Client (Respond only ) : Bilgisayarı sadece IPsec kullanımını talep eden bir paket geldiğinde IPsec kullanmaya yönlendirir. Bilgisayar kendisi asla IPsec iletişimi başlatmaz.

Server (Request security) : Bilgisayarı, başka bir sistemle iletişim kurarken IPsec kullanmaya zorlar. Eğer diğer sistem IPsec destekliyorsa güvenli iletişim başlar. Desteklemiyorsa standart IP iletişimi kurulur.

Secure Server (Require Security) : Bilgisayarı iletişim kurarken sadece IPsec kullanacak şekilde ayarlar. IPsec kullanmadan iletişim kurmaya kalkan sistemlerle bağlantı otomatik olarak kesilir.

Genel kural olarak mevcut IPsec kurallarını değiştirmeye çalışmak yerine isteğe göre yenilerini oluşturmak, bir hata anında geri dönüşü kolaylaştıracaktır.