Windows Server 2008 Üzerinde GPO incelenmesi

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ı

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

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 ?

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.