Geçmişte Executive i kernel in dış katmanı olarak tanımlamıştık. Bu aslında ntoskrnl.exe in dış katmanıdır. Gerçi sadece iç katmanına Kernel denir, ama günlük hayatımızda ntoskrnl.exe in hepsine Kernel deriz. Bu yanlış değil, ama farkı da unutmamak lazım. Executive de temel işletim sisteminin hizmet sağlayıcıları yer almaktadır. Burada örneğin process ve thread yönetimi, bellek yönetimi ve güvenlik açısından WD206 da söz edilen security reference monitör çalışır. Cacheleme yönetimi ve I/O sisteminin de kodlarını bu tarafta bulabiliriz. Kolaylık açısından kitapta sayfa 50 deki detaylı grafik bu yapıyı özlemektedir. Fark edeceksinizdir, burada sadece I/O manager diye bir yapı gösterilmektedir,


I/O system diye bir bölüm yoktur. Bunun nedeni I/O sisteminin executive ve usermode tarafında çalışan farklı bileşenlerden oluşmasıdır: WDM WMI rutinlerine ihtiyacımız olur ve burada user mode tarafındaki WMI servisi de bunun bir parçasıdır. Ayrıca PnP manager bir bileşendir ve bunun da user mode tarafında çalışan komponentleri vardır. I/O sistemi ayrıca kernel mode ve user mode da çalışan komponentlerden oluşan power manager dan ve son olarak sadece executive de implemente edilmiş olan merkezi I/O manager dan oluşur.

Genişletilmiş bakış açısında I/O manager ında usermode komponentleri olabilir. Bunlar örneğin bir IO aygıt sürücüsü yüklenirken kullanılan user modedaki setup ile ilgili bileşenler olabilir. Yani genişletilmiş bakış açısından örneğin bu tarz kurulumlarda kullanılan .inf ve .cat dosyaları da I/O sisteminin yapısal ihtiyaçları için gereklidir ve kendisini bütünleyen parçaları olarak görülebilir. O zaman registry de dahil olur ve tabii ki aygıt sürücülerin kendileri de burada yer alır.

Son olarak işletim sisteminin bütün donanım ile ilgili yapısının altında duran ve işletim sisteminin geniş çaplı donanımsal uyumluluğunu sağlayabilmek için ‘donanımsal abstraksiyon’ yapan HAL da bunun bir parçasıdır. Bunun sayesinde bütün donanımsal detayları bilmeden Windows API leri kullanarak aygıt sürücüsü yazma imkânımız oluşur. Bu yapı sayfa 539 da bir grafik aracılığı ile özetlenmektedir.

Şimdi, executive yapısının içindeki I/O system in bileşenlerini çıkardık. Konsepti biraz daha genel anlayabilmek için bileşenlerin görevlerini tanımlayabiliriz.

Burada bütün IO interaksiyonların merkezinde I/O Manager yer alır. Yüklenen aygıt sürücüleri kendilerini burada kayıt ederler. Burası her şeyin birleştiği noktadır ve bütün işlemler nereden gelip nereye gitse de, bu noktaya dokunmak zorundadırlar. Çünkü, buradaki çevirmeler sayesinde yazımlar ve sistem parçaları sanal, mantıksal ve fiziki aygıtlar ile buluşurlar. Burası Windows I/O frameworkün çekirdeğidir ve aygıt sürücülerin en temel I/O gereksinimlerinin uyarlandığı bölgedir.
Aygıtların güç seviye işlemlerinden sorumlu Power Manager dır. PnP Manager aygıtların sisteme eklenme ve çıkartılmalarını algılamaktan ve gerekli sürücülerin yüklenilmesinden sorumludur. Örneğin bir aygıtın uygun sürücüsü bulunamadığında, user mode tarafındaki PnP Manager servisini devreye alır ve otomatik sürücü yüklenmesi gerçekleşebilir. PnP Manager ın özelliği Bus tipi aygıt sürücüleri ile çalışmasıdır. Bus tipi sürücüsünün farkı kitabın 2ci bölümünden ve WD202 den hatırlayabileceğiniz gibi, aygıt sürücünün çalıştığı aygıtın altında, PCMCIA veya USB de olduğu gibi, çocuk aygıtı olmasıdır. Örneğin bir USB port una bağlı olan harici diskiniz gibi. Bus, port ve disk sürücüleri ayrıdır. Aygıt sürücü tiplerinin temel özetini sayfa 69 da ve daha detaylı bir özetini sayfa 542 de bulabilirsiniz.

WDM WMI yapısının temel görevi, sürücülerin WMI üzerinden user mode tarafındaki WMI servisi ile görüşebilmelerini sağlamaktır. Böylece sürücüler kendilerini WMI frameworküne WMI provider olarak dâhil edebilirler.

Son olarak aygıt sürücüsü de aslında sadece aygıt ile I/O manager arasındaki ara yüzdür. I/O manager sayesinde gerekli bütün aygıt sürücüler bir IO ya dâhil edilir. Bunlar IO komutlarını aygıta aktarırlar ve bitişinde yine I/O manager a geri bildirimde bulunurlar.


IO un kendisine baktığımızda: Windows un uyarladığı çoğu IO, IRP (I/O request packet) yapısı kullanılarak yapılmaktadır. IRP yapısı bir IO un başarılı sonuçlanabilmesi için gerekli tüm bilgileri içerir. I/O manager bu yapıyı oluşturduktan sonra basitçe ilişkin sürücüye bir pointer ı pass eder. Bu pointer ı referans noktası olarak kullanan sürücünün kodu, işlemlerini bitirdikten sonra yine durmun yönetimi I/O manager a aktarılır. Bu aşamada IRP sonlandırılabilir veya I/O manager gerekli bir sonraki sürücüyü dâhil edebilir. IRP bir alış veriş listesine, bir yemek tarifine benzetilebilir. Belli bir yemeği yapmak istiyorsanız, belli içeriklere ve bunların işlemelerini tarif eden belli izleklere ihtiyacınız olur. Bir IO yapıyorsanız da bütün ilgili sürücüleri dâhil etmeniz gerekir.
Bir alışveriş listesi, kendilerini belli bir IO türü için IO manager a register etmiş olan sürücü listesine benzetilebilir. Bunların hepsini dahil etmeden IO yu yapamayız. Yemek tarifini de sürücülere bölünmüş olarak düşünebiliriz. Her sürücü sıra kendisine geldiğinde kendisine düşen izlekleri tamamlar. Burada örneğin tarama yapmak isteyen antivirüsün sürücüsü ve storage sürücüsü devreye girebilir. Sırayla bütün sürücüler IO paketine erişirler ve istedikleri değişiklikleri yaparlar. IO manager a sürücüler kendilerini register ederken, zaten hangi senaryolarda işletim sisteminin kendilerinin hangi kodunu çalıştıracağını belirlerler.

Bu belli kod ofsetlerine routine denilir. Örneğin kullanıcı kopyalama işleminde cancel de edebilir. Her sürücüsünün bir cancel routine i vardır ve sürücü kendisini IO manager a kayıt ederken bu bilgiye de kayıt eder. Kısaca: cancel durumunda bu offsetimindeki bu fonksiyonuma pointer ı pass et. WD203 de Interrupt Service routine den söz edilmişti. Bir aygıt processörü interrupt ettiğinde kerneldeki interrupt dispatcherı ilgili sürücünün bu ISR ını devreye alır. Yani, senin aygıtından, deviceobjectinden interrupt geldi, sen devicedriverı sın ve bu durumumda senin interrupt service routinine ine bu pointerı pass ediyorum. Bu durumda yapılacakların kodu bana daha önce bildirdiğin gibi burada. Yani genel olarak bir sürücü kernelde ‘serbest gezmez’, ne zaman nasıl devreye alınmasını kurulurken bildirir ve bu belli kodlar istenilen durumlarda kernel tarafından devreye alınır. Yani bu kodlar, sürücünün kendisi kernelin bir parçası olur.
Ve önceki bölümlerden hatırlamıyorsanız, neden pointer? Windows un çoğu C de yazılmıştır. Teoride bir sürücü kendisini her türlü IO a dâhil ettirebilir ve IO paketine değişiklik yapabilir.


Böylece işletim sistemi açısından bütün IO detaylarını bilmemize gerek kalmaz. İşletim sistemi I/O sistemi sayesinde sadece bir aygıta IO yapmak isteyen yazılım ile ilgili aygıtı ve sürücülerini birleştirir (device object ve driver object s. 554). Bunu yaparken kullandığı paket yapısı sayesinde de bir threadin birçok IO yu simultane yapabilmesini mümkün kılar.


I/O Sistemi ne kadar geniş kapsamlı olsa da, illa sadece tek başına bir IO esnasında gerekli bütün işlemleri yapamaz. Örneğin WD206 da güvenlik için dediğimiz gibi, güvenlik yapısı sürekli her işlemde çalışan bir yapıdır. Bu bir hizmettir ve sistemdeki her şey bundan faydalanabilir ve buna tabi tutulur. Ondan da executive bulabildiğimiz bu yapılara ‘işletim sisteminin hizmet sağlayıcıları’ diyebiliriz. Yaygın olarak bunlara rutin de demekteyiz. Güvenlik için security reference monitör örneğin file IO sunda ACL lerin kontrolü için dâhil olur. I/O sistemi de işletim sisteminin sadece bir parçası olduğundan, izole çalışamaz ve diğer executive rutinleri kullanır.

I/O system in konseptini ve çalışma temellerini özetledikten sonra değişik IO türevlerine bakabiliriz.

Örneğin işletim sistemi mapped file I/O özelliğini sunar. Bu IRP yapısını kullanmaz. Burada disk de duran bir dosya bir processin sanal adres bölgesine maplenir. Diskde duran dosya RAM de durabildiği için, bunun avantajı elbet hızdır ve bu şekilde işletim sistemi cacheleme özelliğini de kazanmış olur. Bunu I/O systemi memory manager ın yardımı ile gerçekleştirir.


IO genel olarak Synchronous ve Asynchronous olarak bölünür. Synchronous ReadFile ve WriteFile gibi kernel fonksiyonlarda yapılan IO dur. Yani yazılım eşleme gereği IO un bitmesini bekler. Asynchronous da yazılım akışı devam eder ve IO un bitmesi beklenmez.
Bütün bu sistemin çalışabilmesi için de bir aygıt sürücüsüne yönelik temel gereksinimler mevcuttur. Bunların detaylı listesini sayfa 548 de bulabilirsiniz.


Genel olarak bir buffer bir işlem esnasında bir veri için geçici kullanılan bir bellek alanıdır. Örneğin eskiden arabalardaki CD playerlar media oynatırken aracın sallanmasında ses gidebiliyordu. Laser titreşimden dolayı optic mediumdaki pathini kaybedebiliyordu ve yine mediumdan okunabildiğinde ses geri geliyordu. Buradaki çözüm bir buffer. Yani mediumdan okunan verilerin ses aygıtına aktarılmadan bir ara bellek de depolanması. Böylece mediumdan okuyamayınca sadece belleğe depolama işlemi geçici durdurulmuş oluyor, bellekten ama veriler hala ses aygıtına iletilebiliyor.

IO verisinin IRP oluştururken işletim sistemi nasıl buffer layacağını bilmeli. Buffered I/O da, çağıranın bufferından veri kernelin non paged pool da bu IO için oluşturulan eşit boyutlu bir buffer a kopyalanır. Okumada da veri (aygıttan) non paged pool daki buffer üzerinden çağıranın bufferına kopyalanır. IRP sonlandığında non paged pool daki buffer alanı da serbest bırakılır. Direct I/O da callerın bufferını kilitleyip bunu RAM e mapleriz. Örneğin DMA, direct memory Access yapabilen sürücüler ile bu şekilde çalışılır: RAMe yüklenmiş buffer alanı MDL, memory desriptor list ile tarif edilir ve sürücü bu bilgileri aygıta yönlendirir. Böylece donanımsal altyapının sunduğu imkân ile DMA ın en büyük özelliği mümkün olur: CPU devreye alınmadan, aygıt direk bellek ile çalışabilir. İşletim sistemi iki buffer türünü de yapmamaya karar verebilir. Örneğin aygıt sürücüsü buffer lamayı kendisi yönetiyor olabilir.


Kendi IO aygıt sürücünüzü yazacaksanız kitabın 7 bölümü çok daha derin kavram ve gereksinimleri özetliyor. İşletim sisteminin IO altyapısı Windows Internals 5th ed. Chapter 7 ‘I/O System’ de anlatılmaktadır: http://technet.microsoft.com/en-us/sysinternals/bb963901

Ayrıca Windows internals ın 6^th ed. ilk bölümü de piyasaya sunuldu:
http://technet.microsoft.com/en-us/sysinternals/bb963901

Başar Güner
Sr. Support Engineer, Microsoft

Merhaba,

Bir Windows işletim sistemine bir kullanıcı ile ilk defa logon olduğunuzda, yani diğer bir deyişle o işletim sistemi üzerinde logon olan kullanıcının profili daha önce oluşturulmamışsa (tabii roaming profile kullanıcılarını buna katmıyoruz), işletim sistemi üzerinde bulunan default profile kullanılarak kullanıcının profili oluşturulur. Bu yeni oluşturulan profil üzerinde bazı ayarların önceden tanımlı olmasını isteyebilirsiniz. Örneğin bir dosya tipini belirli bir program ile açmak olabilir. Bir diğer ihtiyaç ise Roaming profile kullanıcılarının logon olduğu işletim sistemlerinde yaptıkları bazı değişikliklerin profile ile birlikte taşınmaması. Örneğin, yine dosya tipi ile ilgili örnek vereceğim, bir dosya tipinin farklı bir program ile açılmasını sağladınız. Kullanıcı logoff olduğunda Roaming profile bilgisi, profilin tutulduğu sunucuya kopyalandı. Eğer logoff olduğumuz sunucuda profillerin silinmesi için bir policy’si bulunuyorsa, genellikle Terminal Server’lar üzerinde bu tercih edilir, kullanıcı o sunucuya tekrar logon olduğunda file association tanımı kaybolacaktır. Bunun nedeni, File association tanımlarının tutulduğu HKEY_CLASSES_ROOT hive’ının %userprofile%\Appdata\Local altında bulunan usrclass.dat ile yüklenmesi ve bu dosyanın logoff sonrası roaming profile ile birlikte kopyalanmamasıdır. Bu nedenle siz Roaming profile ile logon olduğunuzda, usrclass.dat dosyası logon olduğunuz sunucu üzerindeki Default Profile’a ait Appdata\Local klasöründen kopyalanmaktadır. Dilerseniz ExcludeProfileDirs registry anahtarında bir değişiklik yaparak kopyalanmasını sağlayabilirsiniz ancak bu yazının amacı diğer opsiyon yani default profile’ın kişiselleştirilmesidir.

Default profile ile logon olup değişikleri yapmak mümkün olmadığından bunun için farklı bir yöntem izlememiz gerekecek. Bunun için test amaçlı kullanıcığımız bir şablon Windows kurulumuna ihtiyacımız vardır. Ben örneğimi Windows Server 2008 R2 referans alarak veriyorum, siz Windows 7 üzerinde de uygulayabilirsiniz.

1. Öncelikle Windows Server 2008 R2 için image dosyasına ihtiyacınız olacak. Bu image dosyasını DVD/ISO içerisinden “source” klasörü altında bulabilirsiniz.
2. Şablon olarak kullanacığımız Windows kurulumunda (Virtual ortamda olabilir) unattend.xml kullanarak sistemi sysprep’leyebiliriz. Burada ki amacımız sysprep işlemi sırasında CopyProfile yöntemiyle makinada logon olan kullanıcıya ait tüm profil bilgisini Default Profile’a yazmaktır.
3. Bunun için önemli olan şablon olarak kullanacağımız sistemde sadece bir kullanıcı olması ve o kullanıcının (tercihen administrator) üzerinde değişikliklerin yapılıp sysprep yapılması gerekmektedir.
4. Şablon olarak kullanacağımız kurulum üzerinde dosya tiplerini değiştirmeyi planladığınız programların yüklü olması gerekmektedir.
5. Yine şablon olarak kullanacağımız sistemin WORKGROUP olarak çalışması ve sadece bir profile olmasıni öneririm.
6. Bunun için administrator ile logon olduktan sonra Control Panel > User Accounts > User Accounts > Configure advanced user profile properties altında Administrator (ve Default profile) dışında, eğer varsa, tüm profilleri silelim.
7. DVD/ISO’da bulunan /sources/install.wim dosyasını Sysprep yapacağımız sunucu üzerine kopyalayalım. Örnek: C:\Sources\Install.wim
8. Aşağıdaki kodu kullanarak bir XML dosyasını taratıp, adını unattend.xml olarak verebilirsiniz.
9. Eğer yukarıda belirttiğimden farklı bir path yazdıysanız, xml dosyasında ki satırı düzenlemek gerekecektir. Install.wim’den sonraki komutlar aynen görüldüğü gibidir.

<?xml version="1.0" encoding="UTF-8"?>
-<unattend xmlns="urn:schemas-microsoft-com:unattend">
    -<settings pass="specialize">
        -<component language="neutral" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" versionScope="nonSxS" publicKeyToken="31bf3856ad364e35" processorArchitecture="x86" name="Microsoft-Windows-Shell-Setup">
            <CopyProfile>true</CopyProfile>
        </component>
    </settings>
<cpi:offlineImage xmlns:cpi="urn:schemas-microsoft-com:cpi" cpi:source="wim:C:\Sources\install.wim#Windows Server 2008 R2 SERVERENTERPRISE"/> </unattend>

• %systemroot%\system32\sysprep\sysprep.exe /oobe /reboot /generalize /unattend:c:\sources\unattend.xml

[shell unattend] CopyProfileDirectory from C:\Users\Administrator succeeded.
[shell unattend] CopyProfile succeeded.

Okan ÇETİNİM

Merhaba,

Windows 8 Consumer ve Developer Preview olarak “beta” sürümlerini yayınladığımız sürümlere artık resmi olarak Windows 8 diyebiliriz!

Windows 8 “Client” sürümleri, Windows 8, Windows 8 Pro ve Windows RT olarak adlandırılacak. Ayrıca Software Assurance hakkıyla satın alacak Kurumsal müşterilerimiz için Windows 8 Enterprise sürümü de bulunuyor. Sürümlerin içeriğinde yer alacak özelliklerin tam listesine buradan ulaşabilirsiniz.

Windows 8 “Server” sürümü ise geleneksel olarak yayınlanacağı yıl ile biliniyor olacak: Windows Server 2012.

Okan ÇETİNİM

Merhaba,

Çok sık karşılaşılmayan ama zamanla her sistemde ortaya çıkabilecek ve nedeni kolay kolay bulunamayacak bir cluster kurulum hatası hakkında sizleri bilgilendirmek istiyorum. Yeni projeler, ya da yeni istekler geldikçe ortamlarımızda yeni cluster sistemleri kuruyoruz. Çoğu kişinin devamlı yaptığı bu işlem aslında büyük bir projenin ilk adımı olabiliyor. Yine 2 node’lu bir Windows Server 2008 R2 cluster bir ortam oluşturulması ve istendi, gerekli komponentleri kurduk, validation raporlarını kontrol ettik herhangi bir sorun görünmüyor, donanımı da zaten tanıyoruz daha önce bir çok kere bu işlem yapıldı ve cluster’ı yapılandırmaya başladık. “Create cluster” dedik, node’larımızı seçtik ve kurulum başladı. Ama o da ne? Karşımıza aşağıdaki hata geldi:

An error occurred while creating the cluster.

An error occurred creating cluster "xxxxx".

The parameter is incorrect

Unable to successfully cleanup.

Çok fazla bilgi yok, “View Report…” a bastık ve aşağıdaki gibi bir bilgi geldi:

Buradan da çok fazla bilgi edinemedik. Node’un birinde “cluster log /g” komutunu çalıştırdık, “cluster.log” dosyalarını inceledik, “Event Viewer” ı inceledik. Bazı hatalar var ama hiç birisi bu duruma çare olmadı.

Bu cluster name için yeni yarattığımız obje üzerinde cluster’ın 2 node’u için de “Full Control” hakkı verdik hala aynı hatayı alıyoruz.

İşte bu noktada genelde gözden kaçan ve bu gibi durumlarda hiç aklımıza gelmeyen bir limitasyona takılıyoruz demektir:

Maximum number of ACEs in an ACL
http://support.microsoft.com/kb/166348/en-us

Bu durumda her iki node üzerinde de clean up işlemini (cluster node computername /forcecleanup) yapıp, Active Directory Users and Computers snap-in’ini açıyoruz:

- Burada kuracağımız cluster name için önceden yaratılmış bir CNO (Computer Name Object) varsa onu siliyoruz.

- Yeni bir CNO yaratıyoruz.

- Yeni yarattığımız computer objesini disable ediyoruz.

- Bu cluster name için yeni yarattığımız obje üzerinde cluster’ın 2 node’u için de “Full Control” hakkı veriyoruz.

Buraya kadar normal ama bunu yaparken “Security” tab’ında dikkatimizi bir şey çekiyor olmalı, buradaki ACL (Access Control List) biraz uzun mu?

İşte burada yukarıdaki makale devreye giriyor, ACL (Access Control List) içerisindeki ACE (Access Control Entry) lerin bir limiti var. Bu objeyi yarattığımız OU ile de ilgili olabilir ya da daha üst seviyeden inherit eden haklar dolayısı ile bu liste, bu objenin gerçekten ihtiyacı olmadığı ACE’lere sahip olabilir, bunun için:

- Cluster name için olan computer objesinin özelliklerindeki “Security” tab’inda “Advanced” tuşuna basalım ve “include inheritable permissions from this object's parents” seçeneğinin işaretini kaldıralım.

- OK tuşuna bastığımızda bir onay penceresi gelecek ve “Remove” tuşuna bastığımızda artık o uzun listenin olmadığını göreceğiz. Burada bütün node’ların ve “self” objesinin “full control” hakkı olduğundan emin olalım ve yoksa bunları tekrar ekleyelim.

Artık her zaman yaptığımız gibi cluster kurulumumuzu sorunsuz tamamlayabiliriz.

Ozan Köksal

Merhaba,

Windows kullanıcılarının sorun yaşamadıkça sadece “Windows Update” kullanarak sistemleri güncelleştirmelerini öneriyoruz. Bu güncelleştirmeler genellikle security güncelleştirmeleridir. Bazı aralıklarla rollup packages adıyla da güncelleştirmeler yayınlanmaktadır. Bu güncelleştirmeler GDR (General Distribution Release) olarak adlandırılmakta ve yayınlanmadan önce farklı ve çok sayıda test yapılmaktadır.

Windows ile ilgili problemler üzerinde çalışırken, yaptığımız analizler sonucunda bir sistem sürücüsünün veya bileşeninin davranışının değiştirilmesi gerektiğini düşünürsek bunu bir kod değişikliği ile hotfix adı altında bir KB makalesi ile birlikte yayınlamaktayız. Burada spesifik olarak bir sorunu gidermeye yönelik değişiklikler yer almaktadır ve bu nedenle daha limitli sayıda test edilmektedir ve biz sadece KB makalesinde belirtilen sorunu yaşayan kullanıcıların güncelleştirmesini isteriz. Bu güncelleştirmeler  LDR (Limited Distribution Release) olarak adlandırılmaktadır. (Önceki Windows sürümlerinde QFE (Quick Fix Engineering)) Eğer aynı sürücü veya bileşene ait yeni bir değişikliğe gidilecekse, bir önceki değişiklikte bu yeni pakette yer alır; yani hotfixler kümülatiftir.

Destek uzmanı olarak, yaptığımız sorun giderme adımlarında sorun yaşadığımız sistem sürücülerinin yayınlanmış en son sürümü ile problemi tekrar repro etmeyi denediğimiz durumlar olmaktadır. Windows için yayınlanan hotfix’ler kümülatiftir yani bir sorun için değiştirilmiş olan kod, daha sonra yayınlanan yeni hotfix’ler içerisinde de yer almaktadır. Bu nedenle benzer sorunlar için yayınlanmış kod değişikliklerinin son sürümü ile deneyip sonucuna göre bir aksiyon alabiliyoruz.

Aşağıda Core, Networking ve Domains problemleri ile ilgili sistem sürücülerinin son sürümlerinin bir listesini bulabilirsiniz. Bu listeyi yeni güncelleştirmeler ile birlikte hep güncel tutmayı planlıyoruz.

CORE

NTFS.SYS

Significantly slower directory tree replication performance when you use the Robocopy command in Windows 7 or in Windows Server 2008 R2
http://support.microsoft.com/kb/2646535

STORPORT.SYS

The startup process stops responding on a Windows Server 2008 R2-based computer that has many processors and Fibre Channel adapters installed
http://support.microsoft.com/kb/2646761

MPIO.SYS

MPIO does not remove a disk that is on a failed path in Windows Server 2008 R2
http://support.microsoft.com/kb/2661794

MSDSM.SYS

MPIO failover fails on a computer that is running Windows Server 2008 R2
http://support.microsoft.com/kb/2460971

CLUSRES.DLL

CAP does not come online in a Windows Server 2008 R2-based failover cluster
http://support.microsoft.com/kb/2685891

CLUSSVC.EXE

A LUN that is registered to a cluster shared volume is invisible and inaccessible in a Windows Server 2008 R2
http://support.microsoft.com/kb/2687646

CSVFILTER.SYS

"0x0000003B," "0x00000027," and "0x0000007e" Stop errors when a connection to a CSV is lost on a Windows Server 2008 R2-based failover cluster
http://support.microsoft.com/kb/2639032

VOLSNAP.SYS

"fvevol!FveFilterDeviceControl+1d0" Stop error when you create a VSS snapshot backup in Windows Server 2008 R2 SP1
http://support.microsoft.com/kb/2632149

HVBOOT.SYS

A saved virtual machine crashes on resume when it hits a debugging breakpoint in Windows Server 2008 R2
http://support.microsoft.com/kb/2586470

MOUNTMGR.SYS + MSMMSP.DLL

A computer stops responding because of a deadlock situation in the Mountmgr.sys driver in running Windows 7 or in Windows Server 2008 R2
http://support.microsoft.com/kb/2614892

WIN32.SYS

MS11-054: Vulnerabilities in Windows kernel-mode drivers could allow elevation of privilege: July 12, 2011
http://support.microsoft.com/kb/2555917

FLTMGR.SYS

Computer randomly stops responding because of a deadlock situation in Windows Server 2008 R2 or in Windows 7
http://support.microsoft.com/kb/2575077

UMPO.DLL

Windows 7 or Windows Server 2008 R2 stops responding when an application performs many I/O operations to a network share
http://support.microsoft.com/kb/2582112

NETWORKING

TCPIP.SYS

Data transfer speed is slow in Windows 7 or in Windows Server 2008 R2
http://support.microsoft.com/kb/2675785

MRXSMB.SYS

SMB connection is reset if you cancel a file operation over a network connection in Windows 7 or in Windows Server 2008 R2
http://support.microsoft.com/kb/2563210

NDIS.SYS

A computer that is connected to an IEEE 802.1X-authenticated network via another 802.1x enabled device does not connect to the correct network
http://support.microsoft.com/kb/976373

RDBSS.SYS

"File not found" error message when you change an open file on a network share from a computer that is running Window 7 or Windows Server 2008 R2
http://support.microsoft.com/kb/2687753

SRV.SYS

You cannot access a shared file by using the SMB Version 2 protocol because of a race condition in Windows Server 2008 R2 or in Windows 7
http://support.microsoft.com/kb/2618190

SRV2.SYS

You cannot access a shared file by using the SMB Version 2 protocol because of a race condition in Windows Server 2008 R2 or in Windows 7
http://support.microsoft.com/kb/2618190

AFD.SYS

"0x0000007E" Stop error message when a connection is reset on a computer that is running Windows 7 or Windows Server 2008 R2
http://support.microsoft.com/kb/2579274

IPSEC

IPsec connection that uses IKEv2 tunnel mode fails on a computer that is running Windows 7 or Windows Server 2008 R2
http://support.microsoft.com/kb/2686921

DNS.EXE

DNS server stops responding to DNS queries from client computers in in Windows Server 2003, in Windows Server 2008 or in Windows Server 2008 R2
http://support.microsoft.com/kb/2655960

DOMAINS

NETLOGON.DLL

The Lsass.exe process crashes on Windows Server 2008 R2-based domain controllers
http://support.microsoft.com/kb/2684982

Client computer uses site-less SRV records after you restart the computer in Windows 7 or in Windows Server 2008 R2
http://support.microsoft.com/kb/2666938

KERBEROS.DLL

A Windows Server 2008 or Windows Server 2008 R2-based domain controller does not function correctly after restart
http://support.microsoft.com/kb/2615570

Remote Assistance invitation fails in an Active Directory environment in Windows 7 or in Windows Server 2008 R2
http://support.microsoft.com/kb/2678068

DFSR.EXE

DFSR fails from a computer that is running Windows Server 2008 R2 to a computer that is running Windows Server 2003 R2
http://support.microsoft.com/kb/2462352

Okan ÇETİNİM

Merhaba,

Windows ve Auditing ile ilgili genel bilgiler ve DNS kayıtlarının silinmesi takip edilmesi ile ilgili yazımdan sonra, inceleme yaparken işinize yarayacağını düşündüğüm event ID’leri ile ilgili referansları paylaşmak istedim.

Özetle, Auditing için ilk olarak yapılması gereken Policy üzerinden veya Auditpol kullanarak Auditing’in etkinleştirilmesi gerekmektedir. Sonrasında ise izlenecek olan her ne ise (file access, directory service access etc.) o object üzerinde System Access Control List (SACL) ayarlanması gerekmektedir.

Windows Server 2003 üzerinde Auditing sadece “genel” olarak açılabiliyordu. Bu durumda örneğin siz sadece computer hesapları ile ilgili bir izleme yapmak istediyseniz de diğer “Account Management” ile ilgili olayları da takip etmek durumunda kalıyordunuz. EventViewer üzerinde veya SCOM ile filtreleyerek istediğinizi alabiliyordunuz. Windows Server 2008 ve sonrasında Auditpol kullanarak alt kategorilerde sadece istediğimiz olayları izlememiz mümkün. Ayrıca Event Forwarding/Collector özelliğini kullanarak birkaç sunucudan aldığınız eventleri bir başka sistem üzerinde toplayabilirsiniz.

  Auditpol /get /category:*

  Bu komut yardımıyla tüm genel ve alt kategorilerin bir listesini görebilirsiniz.

  Eğer genel kategoride bir değişiklik yaparsanız, tüm alt kategorilerde aynı şekilde değiştirilecektir. Bu durumda alt kategorilerin kullanılmasının bir anlamı kalmayacaktır. Varsayılan olarak bu şekilde çalışmaktadır. Bunu değiştirmek için ise daha önce bahsettiğimiz policy’nin değiştirilmesi gerekmektedir:

Policies > Windows Settings > Security Settings >Local Policies >Security Options

 

Artık alt kategorileri sadece Auditpol kullanarak etkinleştirmek zorunda değilsiniz!

Advanced Audit Policy Configuration ile birlikte bunu GPO üzerinden de yapmanız mümkündür. Ancak dikkat etmeniz gereken bu ayarların kalıcı olacağıdır. Yani policy devre dışı bırakıldığında dahi yerel ayarlar kalacaktır.

Windows Server 2008 ile birlikte Audit event ID’leri değişmiştir. Tüm event ID referanslarına aşağıdaki TechNet makalelerinden ulaşabilirsiniz.

Description of security events in Windows Vista and in Windows Server 2008
http://support.microsoft.com/kb/947226

Description of security events in Windows 7 and in Windows Server 2008 R2
http://support.microsoft.com/kb/977519

IT Admin olarak en çok kullandığımız iki policy herhalde “Account Management” ve “Directory Service Access” dir. Her iki policy’de default olarak etkindir. Ancak mutlaka hangi objenin ve hangi aksiyonların izlenmesi gerekiyorsa, SACL ayarları yapılmalıdır. Directory Service Access için Configuration, Schema ve Domain gibi bazı önemli objeler için SACL ayarlanması varsayılan olarak yapılmıştır. Ancak siz sadece değişiklikleri izlemek isterseniz, Delete ve Write All Properties access entry’lerini eklemeniz yeterli olacaktır.

Event ID’ler bize KIM, HANGİ obje üzerinde NEYİ değiştirdiğini söyleyecektir.

Event açıklamaları size Account Name ile KİM, Object Distinguished Name ile HANGİ obje ve Attribute + Operation bilgileri ile ise NEYİ bilgisini verecektir.

Yukarıda belirttiğim makaleler ile daha birçok event için referans bulabilirsiniz. Burada amacınız mümkün olduğu kadar aradığınız, izlemek istediğiniz objeleri, özellikleri azaltmanızdır. Aksi halde Security eventlerinin birbirinin üzerine yazılmasını engellemeli yani boyutunu arttırmal��sınız.

Misal Directory Service için alt kategorilerde sadece değişiklikleri izlemek isterseniz:

AUDITPOL /set /subcategory:"directory service changes" /success:enable /failure:enable

Daha fazlası için…

Advanced Security Audit Policy Step-by-Step Guide
http://technet.microsoft.com/en-us/library/dd408940(WS.10).aspx

Okan ÇETİNİM.

Merhaba,

Birkaç ay önce Auditing ile ilgili yazdığım yazıda genel itibariyle nasıl ayarlanması gerektiği, Auditing Policy’lerinin nasıl kullanılması gerektiği, Auditpol ile nasıl ayarlamalar yapabileceğimizden bahsetmiştim. Bu yazımda ise Auditing kullanılarak silinen bazı DNS adreslerinin peşine düşeceğiz.

Her ay mutlaka birkaç tane DNS kaydı silinen sunucu veya istemciler ile ilgili problemler üzerinde müşterilerim ile birlikte çalışmalar yapıyorum. Genelde bu tür problemler, çokça kullanılan sunuculara yapılan isteklerin cevaplanamıyor olması ile birlikte ortaya çıkmaktadır. Aksi halde sistemler üzerinde çalışan DNS Client servisi her açılışta veya 24 saatte bir kayıtları yenilemektedir. Siz farketmeden kayıt yeniden oluşabilir. Peki neden siliniyor? Auditing olmadan buna kesin bir cevap vermek mümkün değildir.

Kimler şüpheli?

1. Administrator: Evet, ortamın hakimi Domain Admin’lerden bir tanesi “yanlışlıkla” silmiş olabilir.
2. Scavenging: Doğru ayarlanmamış bir scavenging, bir anda birçok kaydın silinmesine sebep olabilir.
3. Kaydın sahibi: Evet. Ama burada bir suçlama yok! Çünkü sistemi shutdown ederek, eğer DHCP opsiyonlarında tanımlıysa, kaydın silinmesi için istek göndermiş olabilir.
4. Replikasyon: Burada asıl şüpheli başkası olmalı. Replikasyon ona söyleneni yapar ve silinmiş kaydı replike eder. Gerçekten öyle mi? Replikasyon o kadar masum değildir!
5. Hiç update edemedim ki! Evet bu da mümkün, kaydın daha önce var olduğundan emin misiniz? Bunu anlamanın en kolay yolu kaydı silinmiş bir sistem üzerinde ipconfig /registerdns çalıştırmaktır. Eğer kayıt oluşmuyorsa, hedefteki DNS Zone’un güvenlik ayarlarını kontrol etmek de fayda var.
6. Uşak: Kastım servisin kendisinin buna sebep olması :) Bilinen iki problem için kod güncelleştirmesi bulunuyor:
   • KB953317
   • KB2520155

Bilinen problemler giderildikten sonra problem devam ediyorsa, IT Admin olarak bizim yapmamız gereken şüphelinin peşine düşmektir.

ÖNEMLİ!!! Auditing etkin olduğu müddetçe size yararlı olacaktır. Kayıt silindikten sonra etkinleştirip izlemenin, bir önceki silinme işlemi için bir yararı yoktur. Etkinleştirildikten sonra ki hareketleri izleyebilirsiniz.

Bir önceki Auditing yazısında belirttiğim gibi Directory Services Access Auditing UI veya Auditpol kullanılarak etkinleştirilebilir. Yalnız bu yeterli değildir. Yine daha önce belirttiğim gibi izlenecek olan kayıt ve/veya zone seviyesinde SACL belirlenmelidir.

Peki SACL nedir?

Açılımı System Access Control List olan SACL, dosya ve klasör seviyesinde object access kontrolü yapma yetkisidir. ACE (Access Control Entries) den farklı olarak kullanıcı veya gruba sadece Auditing yetkisi verilmesidir. Auditing hakkı olan bir kullanıcının, ACE hakkı olmayabilir. Tıpkı ACE ile yaptığınız gibi dosya veya klasör özelliklerinden Auditing üzerinden hakları verebilirsiniz. Daha fazla bilgi için tıklayabilirsiniz.

Eğer bir zone altındaki tüm kayıtları izlemek istiyorsak, DNS konsolu üzerinden zone seviyesinde önce özellikler sonrasında ise Auditing sekmesine ulaşmak için Security sekmesine tıklamalı ve sonrasında Advanced ile devam etmelisiniz. Everyone için Delete, Delete Subtree ve Write All Properties haklarını “Success” için vermelisiniz. Eğer silmeye çalışıp, silemeyen hesapları da izlemek isterseniz “Failure” tanımı da yapmalısınız. Neleri Audit edeceğimiz (Delete, Write) önemlidir çünkü ne kadar fazla SACL girilirse, Security event’leri bir o kadar artar ve işimize yarayacak bilgilerin event dosya boyutunu büyüklüğünün çabuk dolmasıyla silinmesini istemeyiz.

Artık yapmamız gereken izlemek olacaktır. Akla gelen soru belli: Hangi eventleri izleyeceğiz?

2003 sunucu üzerinde izleme yapıyorsanız, 566; 2008 sunucu üzerinde izleme yapıyorsanız 4662 ID numaralı eventleri takip etmeniz gerekiyor. Örnek bir Audit event’I aşağıda bulabilirsiniz.

Subject :

  Security ID:   S-1-5-21-2344108740-3013817150-2900169035-16685

  Account Name:  (Sistem Adı veya Kullanıcı Adı)

  Account Domain:  <DomainName>

Object:

  Object Server:   DS

  Object Type:  dnsNode

  Object Name:  DC=test,DC=domain.com,CN=MicrosoftDNS,DC=DomainDnsZones,DC=domain,DC=com

  or the GUID = {38173e3c-1083-4871-9f95-301f120a2a61}

Operation:

             Operation Type:                   Object Access

             Accesses:                              Write Property

             Access Mask:                       0x20

             Properties:                            Write Property

               {e0fa1e69-9b45-11d0-afdd-00c04fd930c9}    dnsRecord attribute ait GUID

               {d5eb2eb7-be4e-463b-a214-634a44d7392e} dnsTombstoned attribute ait GUID

               {e0fa1e8c-9b45-11d0-afdd-00c04fd930c9}    dnsNode attribute ait GUID

Bizi ilgilendiren 3 şey:

1. Kim = Account Name
2. Silinen DNS Node = Object Name
3. Hangi operasyon = Write Property = TombStoned attribute

Yukarıda ki örnekte görüldüğü gibi Account Name bize kimin sildiğini söyleyecek. Burada bir kullanıcı hesabı görüyorsanız, bu muhtemelen “elle” silinmeyi işaret etmektedir. Çünkü genelde birçok servis Local System account ile çalışmaktadır ve Vista sonrasında Network üzerinden görüşme yapan Local System account bilgisayar adı ile authenticate olmaktadır.

Eğer DC adını görüyorsanız, muhtemelen ya scavenging ya da replication’dır. Scavenging ayarlarını kontrol ederek hangi DNS sunucusunun scavenger olduğunu bulmalı ve değerleri kontrol etmelisiniz. Üzerinde scavenging etkinleştirilen tüm DNS sunucuları scavenger’dır. Bizim tavsiyemiz aynı domain altında sadece bir sunucunun scavenger olarak çalışmasıdır. Aging ve scavenging birkaç cümle ile anlatılacak bir özellik değildir; sanırım o konuyu başka bir yazıya bırakacağım. Ama bilmeniz gereken varsayılan değerleri ile 8 günlük IP kiralamanın sağlandğı bir ortamda 7’şer günlük no refresh ve refresh zamanları yeterli olacaktır. Daha fazla bilgi için bakınız.

Makinenin kendi adını görüyorsanız, bu tamamen normal olabilir. Sistem kapanıp adresi siliyor olabilir. Sistem kapalı iken DNS/IP eşleştirmesinin çalışmaması en son üzüleceğiniz şey olacaktır. Ancak bunun böyle olup, olmadığını ya da olmasını isteyip istemediğinizi daha fazla araştırmanız gerekir. Tabii KB2520155 makalesinde belirtilen kod güncelleştirmesinin yapıldığını varsayıyorum.

Örnekte gördüğünüz gibi Attribute isimleri yerine GUID’leri yer almaktadır. Bizi ilgilendiren dNSTombstoned attribute’dur. DNS kayıtlarının silinmesi Active Directory’de yer alan diğer kayıtların silinmesinden biraz farklıdır. AD’de bir obje silindiğinde isDeleted attribute’un değeri TRUE olarak değiştirilir. Sonrasında objenin birçok diğer attribute’u silinir ve adı değiştirilerek Deleted Objects container’in altına taşınır. Bu objeye tombstone denmektedir ve amaç replikasyon ile bu objenin tüm DC’lere dağıtılması ve DC’lerin kendi veritabanlarında bu objenin silmesini sağlanmasıdır. Tombstone lifetime (2008, 180 gün) sonrasında bu obje tamamen silinir. Silinememesi halinde ise hayatına lingering object olarak devam eder. Bu da ayrı bir yazının konusu olabilir.

AD-Integrated bir zone altında bulunan DNS kayıtlarının silinmesi ise bu prosesden önce farklı bir proses izler. Her DNS objesinin artık dnsTombstoned attribute’u vardır. Eğer elle konsol üzerinden veya sistemin kendisi TTL=0 olan bir update gönderirse veya scavenging kaydın silinmesine karar verirse bu attribute’un değeri TRUE olarak değiştirilir. Bu durumda obke diğer AD objeleri gibi “silinmiş” olarak düşünülmez. Ancak DNS konsolu bu kayıtları yüklemeyecektir. Eğer aynı kayıt “elle” tekrar yaratılırsa veya sistemin kendisi (ya da DHCP) bir güncelleştirme gönderirse, sadece bu attribute değiştirilerek kaydın yeniden DNS’e yüklenmesi sağlanabilir. Eğer kayıt 7 gün boyunca dnsTombstoned değeri TRUE olarak kalırsa, sonrasında diğer AD objelerinin silinmesinde izlenen yol izlenecektir. Bu nedenle event’I izlerken DELETED property’si yerine Write Property değerine bakmaktayız. Zaten properties altında da dnsTombstoned ‘un GUID’ini görmeniz gerekir. Aksi halde IP adres veya timestamp değişikliği gibi değişiklikler sizi yanıltabilir. Hepsi event 4662’dir ancak önemli olan hangi attribute’un güncellendiğidir.

Replikasyonun her zaman masum olmadığından bahsetmiştim. Bunun nedeni SRV gibi DNS kayıtlarının birden fazla dnsRecord içeren tek bir DNS Node altında tutuluyor olmasıdır. Yani 10 tane DC’ye ait bir Kerberos SRV kaydı aslında AD üzerinde sadece bir kayıttır. Eğer bu dnsRecord’lardan bir tanesi güncellenirse, tüm objenin versiyon numarası değişir. Bu durumda, bir DC’nin SRV kaydını bulundurmayan başka bir DC, üçüncü bir DC’nin SRV kayıt değişikliğini daha yeni olmasıyla, replikasyon sonucunda SRV kaydını silebilir. Bunu farketmeyebilirsiniz çünkü NetLogon servisi her 24 saatte bir kayıtları yenilemektedir.

Umarım bu bilgiler silinen kayıtların takibi için size yol gösterecektir. İyi avlanmalar…

Okan ÇETİNİM

Güvenlik her sistemin önemli bir bakış açısıdır. Güvenlik tasarımın alt katmanlarından itibaren farklı noktalarda uyarlanmak zorundadır ve çok sayıda imkân ve zorunluluklar getirir. Kitabın ilk bölümü birçok konu arasında güvenlikten de söz ediyordu ve özetleyecek olursak: Güvenlik de işletim sisteminin temel sütunlarından biridir. Objeler üzerinde üç farklı güvenlik konsepti uyarlanır.

İlki discretionary dir. Bu hepimizin kullandığı haklar ve paylaşım haklarıdır. Yani bir kullanıcı, kullanıcı adı ve şifresi ile logon şeklinde authenticated olduktan sonra farklı kaynaklara authorized olur. Bu authentication ve authorization Windows güvenliğinin temelidir. Yani şahıs tanıma ve şahısın haklarına göre kendisinin sistemde hareket kabiliyetini sağlamak. Korunan kaynakların listesini sayfa 458 de bulabilirsiniz.

Priviledged acess control, discretionary in üstüne gelen yapıdır. Örneğin artık kullanılmayan bir kullanıcı hesabın sadece onun hakkı olan dosyalarının kurtarılması gibi durumlarda devreye girer. Yani, admin o dosyaların ownership liğini üstüne alabilir ve sonra hakları istediği gibi değiştirebilir.

Objeleri son koruyan katman da mandatory integrity control dur. Bu da örneğin User Account Control, UAC dir.

Burada özel durumlar da mevcuttur. Örneğin kitabın beşinci bölümü protected process lerden söz eder. Debug priviledge ı olan herhangi bir process diğer processlere tamamen erişebilir ve değişiklikler yapabilir. Kısaca admin hakkı olan bir kullanıcıya sistemde çalışan bütün processlere hak vermiş oluruz. Bu ancak mesela protected media rights ile çakışır. Media Foundation API sini kullanarak Windows Media sertifikası olan dosyalar ile çalışan processler bu şekilde korunabilir. Yani protected processlere admin in erişimide böylece kısıtlanmaktadır. Burada örneğin audiodg.exe bir protected process dir. Böylece korunan media ların örneğin riplenmesi önlenir.
System processi de kernel ile farklı işlemler yaptığından dolayı ve integrity si korunması gerektiğinden dolayı bir protected process dir. Bir process i protected yapmak aslında sadece kendi Eprocess bloğunda bir flag i set etmektir. Bu flag kernel de olduğu için, diğer aygıt sürücülerin erişimine açıktır. Ancak bu yönde ilerlemek o sürücünün ‘malicious’ algılanmasını sağlayacaktır. Burada o sürücünün yüklenmesi engellenebilir veya durum o sistemde örneğin ses sorunlarına kadar gidebilir. Basitçe, korunmakta olan bir medyayı sadece güvenilir sürücüler oynatabilir. Örneğin bir debugger ile o sürücüye bağlanırsanız sistemin ses oynatma kabiliyetini geçici durdurmuş olabilirsiniz. Digital medya korunması kanuni bir gereksinimidir ve en temelinde digital millenium copyright act ine dayanır.


Bilgisayar sistemlerin güvenliğinin standardize edilmesi trusted computer evaluation criteria ile başlamıştır. Burada sistemler yerine getirdikleri gereksinimlere göre sınıflandırılırlar. Windows çoğu sistem gibi C2 seviyesindedir. Bu normal kullanım için en uygun güvenlik seviyesidir ve genel işletim sistemlerin çoğu C seviyesindedir, B ve A seviyesindeki sistemler sadece savuma sanayisinde bulunabilir.


Windows da authentication (secure logon facility) ve authorization (discretionary access control) vardır. Yani kullanıcı login olur ve login olduğu kullanıcının hakları bazında sistemde hareket eder. Ayrıca farklı kaynaklar için Security Auditing açılabilir. Object reuse protection ile bu ilk dört nokta ile Windows C2 seviyesine gelir. Sonuncusu örneğin A kullanıcısının silmiş olduğu bir dosyanın B kullanıcısı tarafından herhangi bir şekilde erişebilmesini engeller.

Windows ayrıca B seviyesinden de iki noktayı tam yerine getirir. İlki Trusted Path Functionality dir. Secure attention sequence, SAS (ctrl+alt+delete) sayesinde hep Windows un kendi logon ekranı, Winlogon.exe in logonUI si gelir ve burada başka bir user mode process in araya girmesi imkansızdır. Ayrıca SAS zaten yüksek keyboard IRQL seviyesinde gelir. Yani burada başkasının kernel seviyesinde araya girmesi de imkânsızdır. SAS ın amacı budur. Ancak sisteme sürücü kurma yetkisi olan bir kullanıcı değişik sürücüleri bilinçli veya bilinçsiz kurabilir ve böylece malicious bir filter sürücüsü kendisini sistemde daha farklı yerlere de attach edebilir.
Genuine bir işletim sisteminde, örneğin Windows Defender artı antivirüs de çalıştığında, sistemi bu tarz threat lere karşı çok iyi koruyabiliriz.

Kısaca güvenlik altyapısı sistemi dış etkenlerden çok iyi koruyabilir, ama eğer kullanıcı/admin kernelde çalışacak bir tehlikeli sürücü kurarsa, sistemin yapabileceği çok şey kalmayabilir. Bir aşamadan sonra sistem admin e güvenmek zorundadır. Burada güvenlik yazılımları bu tarz kullanıcı hatalarından koruyabilirler.

İşletim istemi güvenlik ile ilgili kullanıcı yanılmaları ve hatalarından integrity mekanizmaları ile korunur: UAC, İnternet explorer protected mode (PMIE) ve User Interface Privilege Isolation (UIPI). Burada bir integrity level değeri kullanılır ve aşağıda sözü geçen Security Reference Monitör, bir erişim isteğinin nereden geldiğini belirleyebilir.
Böylece discretionary yapının üstünde mandatory yapının nasıl çalıştığını anlayabiliriz. Yani bir güvenlik katmanı daha getirerek burada da hak bilgileri tutabiliriz. Örneğin kurulum hakkına sahip bir kullanıcı kurulum exe sini başlattığında UAC devereye girer, yani bir güvenlik katmanından daha geçeriz. Kurulum yapma hakkı sadece ilk katman için geçerlidir. UAC ayarları bundan bağımsızdır.

En nihayetinde ama güvenlik sunucunuzun bulunduğu ortam ile başlar. Temel bakış açıları için Enterprise Security Best Practices makalesini incelemenizi ve Microsoft Security Response Center sayfasını ziyaret etmenizi öneririm.

Diğer Windows un sunduğu B seviyesi gereksinimlerinden biri de Trusted facility management dir. Bu da print veya backup gibi farklı admin gruplarına admin kullanıcısının bölünebilmesini sağlar. Yani sadece bir her şeye tam hakkı olan bir admin kullanıcı tipi yoktur.


SAS ın çağırdığı Winlogon.exe ve logonUI ile logon oluruz ve bu kullanıcı kontekstinde çalışan ilk processi çalıştırır.
Buradan sonra biometric cihaz veya smartcard gibi farklı credential provider lar devreye giriyor olabilirler. Bunlar logonuı de çalışan COM objeleridir. Bunlar mesela authui.dll veya SmartcardCredentialProvider.dll lerdir.

Winlogon, interactive logon manager dır, ayrıca netlogon.dll, network logon servisimiz vardır. Kendisi ile DC ye secure channel bağlantı kurup, domaine logon olabiliriz veya farklı güvenlik ile ilgili isteklerde bulunabiliriz.

Lsass.exe lsasrv.dll beraberinde kullanıcılar ile ilgili tanımlanmış policy lerin uygulanmasını sağlar ve bunun ile ilgili auditleri iletir. Local security authority subsistemi bunun için HKLM\Security altındaki lsass policy veritabanını kullanır.

Lsass.exe ayrıca samsrv.dll i çağırır. Böylece SAM, security accounts manager ın lokaldeki kullanıcı adları/şifreleri ve gruplamaları ile ilgili gerekli kodlar çalıştırılabilir. Domain üyesi sunucularda SAM veri tabanı kullanılır ve bu HKLM\SAM altında tutulur. Domain controllerlarda SAM sadece sistem admin kullanıcısının recovery bilgisi ve şifresinden sorumludur. Bildiğiniz gibi DC de lokal kullanıcı aslında yoktur.

Domain controller larda lsass.exe ayrıca ntdsa.dll i de yükler. Bu active directory için temeldir; bütün domain in bilgilerinin tutulması gerekir. Active directory kitabın 12inci bölümünde detaylı tartışılmaktadır.

Kernel tarafındaki güvenlik yapıları ile lsass arasındaki LPC iletişimi kernel security device driver, ksecdd.sys ile yapılabilir. Örneğin kernelde çalışan encrypting file system, efs.sys bu sürücüyü kullanır.

En temel güvenlik de mimari olarak ntoskrnl.exe de security reference monitor, SRM ile uyarlanır.

Üçüncü bölümde sözü geçen object manager güvenlikte önemli bir rol üstlenir. Farklı kaynaklara kernelden user mode tarafına erişim sağlanır ve ondan object manager kernel tarafında güvenlik konusunda büyük önem taşır. Bir thread bir objeye erişmek istediğinde baştan yapılacak, işlemleri belirlemek zorundadır. Object manager SRM ı çağ��rır ve bu güvenlik ayarlarını kontrol ettikten sonra threade erişim hakkı processin handle tablosuna hak detayları ile beraber kayıt edilerek verilir.

Deafult güvenlik ayarları örneğin file objelerinde farklıdır. Burada file bazında güvenlik ayarları belirleyebiliriz ve erişimde bu detayları ntfs.sys den alırız. Yani örneğin mutex ve semaphore gibi objelerin default üstüne yazılamaz güvenlik yaraları vardır. Mesela bir objeye bir handle bir processe read olarak verilmişse, bu processin başka bir threadi bu handle ın hakkını tabloda write a çeviremez. Yeni handle istenilmesi gerekir. Ama overwrite edilebilen ntfs güvenlik ayarları gibi obje güvenlik ayarları da vardır. Kullanıcı objesinin de hakları değiştirilebilir örneğin.


Çok yardımcı olabilen bir mekanizma impersonation dir. Bir thread normalde bağlı oldu processin güvenlik konteksinde çalışır ve o da kendisinin veli processinkini almıştır vs. Impersonation ile bir thread farklı bir güvenlik konteksinde çalışabilir. Burada dikkat edilmesi nokta, burada hak yükseltmesi söz konusu olduğunda, bundan indirect diğer threadlerin de faydanabilmeleri. Process deki handle tablosuna bütün threadlerin erişim hakkı eşittir. Yani bir impersonating thread bir objeye erişim sağlarsa, bu handle tablosuna kayıt edilir ve aynı processin diğer handle ları da aynı objeye erişim hakkına sahip olurlar. Bu şekilde de ama bütün processin ve threadlerinin haklarını temelde düşük tutarak ve sadece bir threadin hak seviyesini bir işlem için geçici artırarak çalışmamız mümkün olur. Herkes ve her şey için ilgili hakları hep işlevsel engel olmayacak şekilde mümkün olduğunca düşük tutmak gerekir. İmpersonation burada çok kolay bir yardım aracıdır.

Güvenlik yapısında bilgisayar ve kullanıcılar gibi ayrı tutulması gereken farklı varlıklar, entity ler mevcuttur. Bunu her birine benzersiz security identifier, SID vererek yaparız. SID in uzunluğu farklı olabilir, ama örneğin bütün kullanıcıların, kullanıcı grupların ve bilgisayarların bir SID değeri vardır. Kullanıcı yaratıldığında veya bir sistem kurulduğunda hemen bir SID değeri de oluşturulur.

Duyacağınız İkinci temel güvenlik terimi de belirteç, Token dır. İşte bu da kullanıcının güvenlik ile ilgili bilgilerini tutuğumuz yapıdır. Tokenların da LUID, lokal ID leri vardır. Bu değerler hakkında bilgileri kitapta sayfa 461 inden itibaren bulabilirsiniz. Yani varlıkları belirleyen benzersiz ID leri vardır ve objelerin haklarını özetleyen yine benzersiz ID li belirteçleri vardır. Impersonation da tokenlar ile yapılır. Özellikle networksel işlemlerde daha düşük hak seviyesi istenildiğinde, istenilen seviyeye göre restricted veya filtered admin tokenları kullanılabilir.


Objelerin güvenlik ayarları security descriptor lar ile tutulur. Burada en bilinen herhalde discretionary access contol list, DACL lardır. Örneğin dosyalaın güvenlik yarları bu şekilde tutulur. Söz ettiğimiz gibi bir objeye erişebilmek için mandatory ve discretionary Access check leri geçmemiz gerekir.

Burada özel durum örneğin backupdır. Burada bütün dosyalara bir kullanıcının hakları eklenmez. Bir kullanıcıya bir priviledge, bir ayrıcalık verilir. Bazı super priviledge ların verilmesi bir kullanıcıyı bir ‘süper kullanıcısı’ yapabilir. Örneğin debug programs priviledge ı bunlardan biridir. Tam listeyi sayfa 510 da bulabilirsiniz.
Audit, security yapısının bir sütunudur. Geriye dönük işlemleri kontrol etmemizi mümkün kılar.

Bu sadece bir konsept özetiydi. Çok daha fazla güvenlik yapısı ile ilgili konuları ve detayları Windows Internals 5th ed. Chapter 6 ‘Security’ de bulabilirsiniz: http://technet.microsoft.com/en-us/sysinternals/bb963901

Eğer kendinizi Windows mimarisinde veya sistem/sürücü yazılımcısı yönünde geliştirmek istiyorsanız veya işletim sisteminin bir referans kitabına ihtiyacınız varsa bu kitabı incelemenizi öneririm.

http://en.wikipedia.org/wiki/Digital_Millennium_Copyright_Act Digital Millennium Copyright Act
http://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria Trusted Computer System Evaluation Criteria
http://technet.microsoft.com/en-us/library/dd277328.aspx Enterprise Security Best Practices
http://www.microsoft.com/security/msrc/default.aspx Microsoft Security Response Center

Başar Güner

Sr. Support Engineer, Microsoft

Merhaba,

Customer Support and Services ekibinde birlikte çalıştığımız Orkun Aksu’nun blog’unda PKI ve Sertifika hakkında çok yararlı olacağını düşündüğüm yazılar bulabilirsiniz. Örnek olarak bir kaç tane yazıya ait referansı burada paylaşmak istedim.

PKI yapılandırması için Active Directory Environment’ının hazırlanması –1

PKI yapılandırması için Active Directory Environment’ının hazırlanması –2

PKI ‘ın Temelleri-1

PKI ‘ın Temelleri–2 ( Certification Authorities, Certificate Revocation Lists )

PKI ‘ın Temelleri–3 ( Online Certificate Status Protocol {OCSP} )

Umarım faydalanacak kişiler çıkacaktır…

Okan Çetinim

test