Windows Server 2003’ e giriş

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

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ı

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

Ç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ı

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

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ı

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ı

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

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ı

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

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.