İki bölümden oluşacak bu makale serimizde organizasyonlarda her geçen gün yaygınlaşan Microsoft Internet Information Server (IIS) web ve ftp sunucu sistemleri üzerinde yönetimsel ve güvenlik alanlarında uygulanan en iyi uygulama kriterleri hakkında bilgi sahibi olacaksınız. Genel olarak önerilerimizi Windows Server 2012 R2 ile gelen IIS 8.5 versiyon arayüzünde inceliyor olsak da aynı standartlar IIS 7.0 ve sonrası tüm versiyonlar için geçerli olacaktır. Güvenlik teknolojilerindeki yeniliklere göre makalemizde belli dönemlerde güncellemeyi hedefliyoruz. Bu makalede belirtilen yöntemler en iyi uygulama deneyimleri ve gerçek hayattan uygulamalardan elde edilen tecrübeleri paylaşmak amacına yönelik bir içeriktir. Bu öneriler oluşabilecek güvenlik riskleri ya da zaafiyetlerini en aza indirgemeyi amaçlamakla birlikte güvenlik açıkları ya da problemlerinizin tamamen yok olacağı garanti edilmemektedir.

Web sunucusu üzerindeki yönetimsel ve güvenlik alanındaki en iyi yapılandırma prensiplerini aşağıdaki şekilde de görüldüğü gibi fiziksel katmandan başlayarak ele alıp ağ katmanı, kullanıcı katmanı ve verinin korunması katmanı olarak farklı seviyelerde ele alıyor olacağız.

Böylece çok katmanlı bir savunma yaklaşımı ile web sunucular üzerindeki yönetimsel ve güvenlik standartlarını değişen teknoloji ve kullanıcı deneyimleri de göz önüne alınarak daha da iyileştirmenizi hedefliyoruz.

Makalemiz içerisinde en iyi yapılandırma adımlarını aşağıdaki alanlarda inceliyoruz:

Kurulum

Temel Yapılandırmalar

Güvenlik Yapılandırmaları

ASP.NET Yapılandırmaları

Günlük Dosyalarının Yapılandırılması

İçerik Yönetim Yapılandırmaları

Yük Dengeleme Yapılandırmaları

Web Sunuculara Özel İzole Active Directory Yapılandırmaları

Diğer Yapılandırmalar

Bu makalemizde bahsi geçen belirli ticari marka isimleri kendi özgün sahiplerine aittir.

Kısaltmalar

Kurulum

Bu başlıkta IIS 8.5 web sunucularda kurulum alanındaki en-iyi-yapılandırma deneyimleri (best-practice) paylaşılacaktır:

IIS rolünü domain controller ya da additional domain controller sunucular üzerinde aktifleştirmemelisiniz. Bunun birinci nedeni özellikle web sunucularda sıklıkla kullanılan yerel hesapların (local account) domain controller rolüne sahip sunucular üzerinde bulunmamasıdır.

IIS web sunucu rolü ile domain controller rolünün aynı sunucu üzerinde olması da güvenlik hesabı seçeneklerinizi önemli oranda sınırlandırmaktadır.

Web servislerinden dolayı web sunucu üzerinde oluşan bir güvenlik zaafiyet vakası tüm domain yapısını hatta tüm ağ yapınızı etkileyecektir.

Web sunucular üzerine sadece gerekli olan modülleri ve bileşenleri kurmalısınız. IIS 8.5 ile kırkın (40) üzerinde modül içermektedir. İhtiyacınız olan modülü kolaylıkla ilave edebilir, kullanılmayan modülleri de kaldırabilirsiniz. Sadece ihtiyacınız olan modülleri yükleyerek potansiyel saldırı ya da ataklara karşı saldırı gelebilecek yüzeyi de daraltmış olacaksınız.

Peryodik olarak IIS modüllerini gözden geçirerek kullanılmayan ya da istenmeyen modülleri kaldırın. Bu bir önceki maddede bahsettiğimiz gibi sizin saldırı gelme riski olan alanı mümkün olan en aza indirgeyecektir.

Yüksek hacimli IIS kurulumları için (özellikle çok katmanlı uygulamalarda) SQL Server, Exchange Server gibi yoğun kaynak ihtiyacı olan ürünleri IIS sunucular dışında ayrı sunucularda konumlandırın.

Antivirüs, antimalware gibi güvenlik yazılımlarınızı güncel tutun.

IIS kurulumu sonrasında sistem sürücüsü altında oluşan “Inetpub” klasörünü ve diğer web sitelerine ait içerik klasörlerini farklı bir sürücüye taşıyın. Böylece hem sistem diskinde oluşabilecek disk alanı darboğazlarının önüne geçmiş hem de güvenlik etkilerini en aza indirgemiş olacaksınız. Inetpub içeriğinin taşınması için APPCMD.exe ve XCOPY araçlarını kullanabilirsiniz. Bu konuyu ayrı bir makalede ele alıyor olacağız.

Temel Yapılandırmalar

Bu başlıkta IIS 8.5 web sunucularda en-iyi-yapılandırma deneyimleri (best-practice) referans alınarak uygulanan temel yapılandırma standartlarını bulacaksınız.

Web İçeriğinin Sistem Diski Haricinde Bir Konumda Saklanması

IIS üzerinden yayınlanan servislere ait içerikler sistem diski dışında bir disk bölümünde saklanmalıdır. Bu sayede :

Web içerikleri sistem bölümünden izole bir alanda saklanmış olur.

Web içeriğinin sistem alanındaki yer kullanması ya da tüketiminin önüne geçilmiş olur.

Web içeriğinden oluşan I/O yükünün sistem dosyalarının performansı ve veri bütünlüğü açısından oluşabilecek riskler de en aza indirgenmiş olacaktır.

Ayrıca web içeriğinden oluşabilecek gizlilik ve hassas durumlar da ortadan kaldırılmış olur.

Web Siteleri Üzerinde Host Header Tanımlama Standardı

IIS üzerinden yayınlanan tüm web siteleri üzerinde Host Header tanımlaması yapılmalıdır.

Bu sayede :

Aynı ip adresi ve port numarasından çoklu web site yayını yapılabilir.

DNS rebinding saldırılarına karşı koruma sağlanmış olmaktadır.

IP-tabanlı taramalarda IIS üzerinde host edilen uygulamanın tanımlanması da kolaylıkla sağlanmış olacaktır.

Web Siteleri Üzerinde Directory Browsing Kapatılması

IIS üzerinden yayınlanan site yapılandırmalarında “directory browsing” özelliği kapatılmalıdır.

Bu sayede :

Web site içeriklerinin browser tabanlı web istemcileri üzerinden görülmesi engellenmiş olacaktır.

Web site içerisindeki özel bir dosya içeriğine doküman listesinden erişim riski azaltılmış olacaktır.

Web site içeriğindeki hassas dökümanlara kontrolsüz erişim engellenmiş olacaktır.

Web Siteleri ve Uygulamaları Tarafından Bağımsız Application Pool Kullanımı

Application Pool kimlikleri (Identity) web sunucuları üzerindeki w3wp.exe isimli iş süreçlerini çalıştırmaya yetkili hesap ya da otoritelerdir. Web siteleri ve uygulamaları üzerinde application pool ataması yaparken her web site ya da uygulama için benzersiz, farklı application pool tanımlanmasına özen gösterilmelidir. Bu sayede :

Web site ya da uygulamalarının birbirlerinden farklı uygulama havuzları kullanmaları sağlanmış olacaktır.

Web site ya da uygulamada meydana gelecek bir kilitlenme, duraklama ya da kaynak problemi diğer web site ya da uygulamaları etkilemeyecektır.

Yoğun-kaynak ihtiyacı olan web site ya da uygulamalarının farklı uygulama havuzları kullanmalarıyla sunucu ve servisin performansı da artırılmış olacaktır.

Uygulamaların erişilebilirlik seviyesi de artırılmış olacaktır. Herhangi bir uygulama havuzunda oluşan bir sorundan sadece o uygulama havuzunu kullanan web sitesi ya da servisleri etkilemiş olacak, diğerleri hizmet kesintisi ya da duraklama yaşamayacaktır.

Web site ve uygulamaları farklı uygulama havuzlarında barındırıldıkları için uygulama seviyesinde yetkisiz erişim riski de azaltılmış olacaktır.

Web site ve uygulamaları farklı uygulama havuzlarında barındırıldıkları için kullanılmayan bir uygulama havuzunu istenildiği zaman durdurmak diğer servislerde kesintiye neden olmayacaktır.

Güvenlik Yapılandırmaları

Bu başlıkta IIS 8.5 web sunucularda en-iyi-yapılandırma deneyimleri (best-practice) referans alınarak uygulanan güvenlik yapılandırma standartlarını bulacaksınız.

Windows Kimlik Doğrulamasın Genişletilmiş Koruma Özelliği

IIS web sunucuları üzerinde Windows authentication kimlik doğrulaması aktif ise mutlaka genişletilmiş koruma özelliği olan “Extended Protection” da açmanızı öneriyoruz.

Windows Authentication kullanılabilmesi için Web Server rolü altındaki bileşenlerden kurulmuş olması gerekir. Aşağıda PowerShell ile bu gereksinim kontrol edip yüklüyoruz.

Anonim Kimlik Doğrulamasını Doğru Yapılandırın

IIS web sunucuları üzerinde Anonymous authentication kimlik doğrulaması ile birlikte diğer kimlik doğrulama yöntemlerini aktif etmemeye mümkün olduğunca dikkat edin. Çünkü çalıştığı modüle bağlı olarak çoğu durumda öncelikli olarak Anonymous authentication kimlik doğrulaması devreye gireceği için diğer kimlik doğrulamalarında sorunlara neden olacaktır.

Diğer yandan sunucu dizinlerine ve kaynaklarına anonim kimlik erişim hesabına yetki vermeyiniz. Sunucuya yapılacak dosya yükleme ya da yazma işlemleri için anonim hesabı dışındaki hesapları özellikle kullanmanızı tavsiye ediyoruz.

Default Application Pool Kimliğinin Minimum Yetkiye Sahip Principal Hesabına Atanması

Application Pool kimlikleri (Identity) web sunucuları üzerindeki w3wp.exe isimli iş süreçlerini çalıştırmaya yetkili hesap ya da otoritelerdir. Bu sayede :

Doğru ve geçerli kimlik bilgisinin tanımlanması web uygulaması ya da servisinin fonksiyonel olarak doğru çalışmasını da garanti altına almaktadır.

Aynı zamanda web uygulaması ya da servisinin gerekli en az yetkili hesapla çalıştırılarak, gereğinden fazla yetkili hesap kullandırmayarak oluşabilecek güvenlik riskleri ve zafiyetleri de en aza indirgenmiş olacaktır.

Bu aksiyon web site içeriğinde yapılabilecek zararları ya da manipülasyonları da engellemiş olacaktır.

Web Siteleri ve Uygulamaları Tarafından Kullanılan Application Pool Kimliğinin Benzersiz Olmasına Dikkat Edilmesi

Application Pool kimlikleri (Identity) web sunucuları üzerindeki w3wp.exe isimli iş süreçlerini çalıştırmaya yetkili hesap ya da otoritelerdir. Web siteleri ve uygulamaları üzerinde application pool kimlikleri tanımlanırken her web site ya da uygulama için benzersiz, farklı kimlikler tanımlanmasına özen gösterilmelidir. Bu sayede :

Doğru ve geçerli kimlik bilgisinin tanımlanması web uygulaması ya da servisinin fonksiyonel olarak doğru çalışmasını da garanti altına alınmaktadır.

Aynı zamanda web uygulaması ya da servisinin gerekli en az yetkili hesapla çalıştırılarak, gereğinden fazla yetkili hesap kullandırmayarak oluşabilecek güvenlik riskleri ve zafiyetleri de en aza indirgenmiş olacaktır.

Bu aksiyon web site içeriğinde yapılabilecek zararları ya da manipülasyonları da engellemiş olacaktır.

Web site ya da web uygulamasının ilgili alanına sadece ilgili kimlik bilgisi ile minimum yetki seviyesinde erişim sağlanması garanti altına alınmış olacaktır.

Bu sayede her uygulama havuzunun (application pool) benzersiz bir kimlikle çalışması sağlanmış olacaktır.

Anonymous User Kimliği Olarak Application Pool Kimliğinin Yapılandırılması

IIS sistemleri üzerinde uygulama havuzları için farklı uygulama kimlikleri kullanılabilir. IIS web site ya da uygulaması üzerindeki application pool kimlik yapılandırmasında anonymous kullanıcı hesabı tanımlanmamışsa application pool isimli kimliğini kullanması şeklinde yapılandırma yapılabilir. Bu durumda IIS üzerinde ihtiyaç duyulan hesap kimliği de minimum sayıya indirgenmiş olacak, hesap yönetimi de kolaylaşacaktır. Önerilen Application Pool Identity’nin Anonymous User Identity olarak yapılandırılmasıdır. Bu yapılandırma minimum yetki ile servislere erişimin yapılmasını sağlarken, site yönetimini de kolaylaştıracaktır.

Web Sitesi Dynamic IP Address Kısıtlanması

IIS web sunucular üzerinde ihtiyaca göre ip adresi, network adresi ya da domain bilgisine göre erişim kısıtlamaları yapılmalıdır. Bu sayede :

Yetkisiz kişi ve sistemlerin web sitesine erişimi engellenmiş olur.

Dinamik olarak tanımlanan kapsamda olan sistemler kısıtlama kapsamına girmektedir.

DDOS saldırıları engellenmiş olacaktır.

Dynamic ip kısıtlaması için web sunucu üzerinde Web-IP-Security isimli IP and Domain Restrictions bileşeninin  kurulu olması gerekir. Standart web server kurulumunda bu özellik kurulu gelmez. Yüklemek için aşağıdaki şekilde görülen PowerShell komutlarını işletmek gerekecektir.

Bu işlemden sonra IIS konsolu içerisinde IP and Domain Restrictions görünmüş olacaktır.

IP Address and Domain Restrictions kısıtlamaları aşağıdaki seviyelerde uygulanabilir:

IIS Sunucu seviyesinde

Web Site seviyesinde

Web Application seviyesinde

Üst seviyeden uygulanan kısıtlamalar miras yoluyla alt seviyelere geçmektedir.

IP Address and Domain Restrictions simgesi üzerine çift tıklayınca gelen aşağıdaki ekranda sağ kısımda gelen Actions menüsü kullanılarak izin verilecekler için Allow Entry, yasaklanacaklar için de Deny Entry seçenekleri kullanılır. Spesifik IP adresi için kısıtlama ya da izin verme uygulanabileceği gibi IP adres aralığı ya da IP Subnet tanımı da yapılabilir.

Bu ekranda tanımlanmamış diğer adresler için geçerli olacak aksiyon ayarını da Edit Feature Settings ile belirleyebilirsiniz:

Yukarıdaki şekilde de görülen ekranda “Access for unspecified clients” ile tanımlanmamış istemciler için erişim durumu izin verilsin derseniz Allow yasaklansın derseniz de Deny seçeneklerinden uygun olanı liste kutusundan seçebilirsiniz. Yine bu ekranda “Enable domain name restrictions” kutucuğu işaretlenerek domain bazında da Allow Entry ya da Deny Entry tanımlanabilir, ilgili seçenekler Add Allow Entry ya da Add Deny Entry seçeneklerinden uygun olana tıklayınca gelecektir.

FTP Sitesi Erişiminin Kısıtlanması

IIS web sunucular üzerinde FTP hizmetlerinde ihtiyaca göre ip adresi, network adresi ya da domain bilgisine göre erişim kısıtlamaları yapılmalıdır. Bu sayede :

Yetkisiz kişi ve sistemlerin ftp sitesine erişimi engellenmiş olacaktır.

Dinamik olarak tanımlanan kapsamda olan sistemler kısıtlama kapsamına girmiş olacaktır.

Yetkisiz kişiler tarafından FTP içeriği görüntülenmesi ya da içerik yüklenmesi engellenmiş olacaktır.

Brute force ataklar bloklanmış olacaktır. Böylece yerel Administrator hesabının ele geçirilip saldırı yapılmasının da önüne geçilmiş olacaktır.

Yetkisiz kullanıcıların web site içeriğini kapsayan ftp alanına zararlı yazılımlarla oluşturabileceği riskler engellenmiş olacaktır.

FTP User Isolation yöntemi kullanılarak kullanıcıların FTP alanında sadece kendilerine izin verilen klasör alanına erişmeleri, yetkisiz alanlara erişmeleri engellenmiş olacaktır.

FTP Sitesine erişimde kullanıcı hesabı seviyesinde filtreleme ve sınırlandırma yapılarak yetkisiz kullanıcıların ftp sitesine erişimleri yasaklanmış olacaktır.

FTP Request Filtering yeteneği ihtiyaca göre kullanılarak FTP alanında belirtilen uzantılar dışında içerik yüklenmesi engellenmiş olacaktır.

Web Sitesi Global Authorization Rule İle Erişim Kısıtlanması

IIS 7.0 ile gelen URL Authorization sayesinde dosya sistemi yerine URL-bazlı yetkilendirme kuralları ile web sitesi koruması sağlanmalıdır. Authorization kuralları sunucu, web sitesi, web application, virtual directory ya da dosya seviyesinde uygulanabilir. URL authorization kuralları .NET modülleri, statik sayfalar, ASP sayfaları gibi tüm içeriklere gelen istekler için etkilidir. Bu kapsamda web servisi ve uygulamasına göre sunucu seviyesinde URL Authorization kuralları uygulanarak içerikle beraber hedefe taşınmaktadır. Böylece :

İçeriğin konumu değişse de yukardan aşağıya yetkilendirme kuralları miras olarak aktarılarak sürekli etkinliğini korunacaktır. Bu sayede uygulanan kısıtlamalar konum-bağımsız etkinliğini koruyacaktır.

Şu anki ve gelecekteki web içeriğine erişimde belirlenen kurallar dışında erişimin yapılması engellenmiş olacaktır.

İstek dışı ve yetkisiz erişimlerin yapılması engellenmiş olacaktır.

Web Sitesi Form Kimlik Doğrulamasında SSL Zorlanması

IIS üzerinden yayınlanan web sitesi içeriğine göre form-tabanlı kimlik doğrulaması kullanılan site ya da sayfalar üzerinde SSL erişim zorunluluğu getirilmelidir. Böylece forma girilen bilgilerin kriptolanarak web sunucuya güvenli mimaride iletilmesi sağlanacaktır. SSL sonlandırması uygulamaya göre bazı senaryolarda Load-Balancer aygıtı üzerinde gerçekleştirilebilir. IIS sunucularda gerçekleşen SSL sonlandırmalarında da Load-balancer (yük dengeleme) cihazı gelen isteklere SSL optimizasyon uygulaması sağlanabilir.

ÖZETLE :

İki bölümden oluşan bu makale serimizin ilk bölümünün sonuna geldik. İkinci bölümde de IIS sunucularımız üzerinde aşağıdaki maddeler için yönetimsel ve güvenlik alanında en iyi uygulama standartlarını paylaşmaya devam edeceğiz:

ASP.NET Yapılandırmaları

Günlük Dosyalarının Yapılandırılması

İçerik Yönetim Yapılandırmaları

Yük Dengeleme Yapılandırmaları

Web Sunuculara Özel İzole Active Directory Yapılandırmaları

Diğer Yapılandırmalar

Hoşçakalın.

Mesut ALADAĞ.
Microsoft MVP, MCT, P-TSP
www.cozumpark.com | www.mesutaladag.com

IIS 8.5 ile web sunucularda yönetimsel ve güvenlik alanındaki en iyi uygulamalardan deneyimlerimizi paylaştığımız makale serimizin ikinci bölümünde de birlikteyiz. Bu ikinci bölümde de aşağıdaki kırmızı ile belirtilen maddeleri incelemeye devam edeceğiz :

Kurulum

Temel Yapılandırmalar

Güvenlik Yapılandırmaları

ASP.NET Yapılandırmaları

Günlük Dosyalarının Yapılandırılması

İçerik Yönetim Yapılandırmaları

Yük Dengeleme Yapılandırmaları

Web Sunuculara Özel İzole Active Directory Yapılandırmaları

Diğer Yapılandırmalar

Makalemin ilk bölümüne aşağıdaki link üzerinden erişebilirsiniz

https://www.cozumpark.com/blogs/windows_server/archive/2015/06/21/_31013101_s-8-5-yonetimsel-ve-guvenlik-yapilandirma-uygulamalari-bolum-1.aspx

İlk bölümde olduğu gibi önerilerimizi Windows Server 2012 R2 ile gelen IIS 8.5 versiyon arayüzünde inceliyor olsak da aynı standartlar IIS 7.0 ve sonrası tüm versiyonlar için geçerli olacaktır. Güvenlik teknolojilerindeki yeniliklere ve makale yayınlama takvimimize göre makalemizde belli dönemlerde güncellemeyi hedeflediğimiz tekrar vurgulamak istiyorum. İlk bölümde de belirttiğimiz gibi bu makalemizde belirtilen yöntemler en iyi uygulama deneyimleri ve gerçek hayattan uygulamalardan elde edilen tecrübeleri paylaşmak amacına yönelik bir içeriktir. Bu öneriler oluşabilecek güvenlik riskleri ya da zaafiyetlerini en aza indirgemeyi amaçlamakla birlikte güvenlik açıkları ya da problemlerinizin tamamen yok olacağı garanti edilmemektedir.

Web Sunucu Günlüklerinin Yapılandırılması

Bu başlıkta IIS 8.5 web sunucularda en-iyi-yapılandırma deneyimleri (best-practice) referans alınarak uygulanan web sunucu günlüklerinin yapılandırma standartlarını bulacaksınız.

Web Sunucularda Varsayılan IIS Logging Konumunun Taşınması

IIS web sunucular üzerinde ihtiyaca göre standart log kayıtlarının tutulması amaçlı Logging özelliği aktifleştirilmelidir. Bu sayede sunucu, web sitesi ve web uygulaması seviyesinde olay kayıtları alınarak ilgili sistem ya da servise yapılan bağlantılarla ilgili standart log günlükleri tutulmalıdır.

Oluşan log günlükleri yukarıdaki şekilde de görüldüğü gibi varsayılan konumlarından farklı bir disk sürücüsü üzerine taşınmalıdır. Böylece log büyümelerinde sistem diskinin performansa ya da disk alanına negatif etki edebilecek riskler minimuma indirgenmiş olacaktır.

Web Sunucularda Advanced Logging Etkinleştirilmesi

IIS web sunucular üzerinde ihtiyaca göre ileri seviye log kayıtlarının tutulması amaçlı Advanced Logging özelliği aktifleştirilmelidir. Advanced Logging IIS 8.5 ile gelen ve standart günlük kayıtları yerine ihtiyaca göre özel alanlara ait bilgileri de günlüklemeyi sağlayan bir yetenektir. Bu sayede sunucu, web sitesi ve web uygulaması seviyesinde log tutma aktifleştirilerek ilgili sistem ya da servise yapılan bağlantılarla ilgili detaylı log günlükleri tutulmaktadır. Log kayıtları içerisinde standart alanların dışında ihtiyaca göre özel alanlar da tanımlanabilir (örneğin istemcinin ip adresi gibi.).  İleri seviyede günlük tutma yapılandırması için IIS 8.5 web sunucular üzerinde “Logging” bileşeni kullanılarak ileri seviye günlükleme yetenekleri aktifleştirilebilir:

Yine yukarıdaki şekilde de görüldüğü üzere oluşan log kayıtları sistem diski dışında farklı bir disk sürücüsü üzerinde saklanmalıdır.

Böylece log büyümelerinde sistem diskinin performansına ya da disk alanına negatif etki edebilecek riskler minimuma indirgenmiş olacaktır.

Yukarıdaki gibi özel alanlar eklendikten sonra IIS günlük metin dosya isimlerinin sonuna “_x” ilavesini yapacaktır. “_x” ibaresi günlük dosyası içerisinde özel bir alana ait günlük bilgilerinin tutulduğunu gösterir.

ASP.NET Yapılandırmaları

IIS üzerinden yayınlanan web sitesi içeriğine göre ASP.NET yapılandırmalarında da belli standartlar uygulanmaktadır. ASP.NET yapılandırma standartlarının uygulanması için web sunucumuz üzerinde ASP.NET bileşeninin de kurulmuş olması gerekir. Aşağıda PowerShell cmdlet’ler ile bu bileşenin kurulu olup olmadığını sorgulayıp, sonrasında da kurulumunu yapıyoruz:

IIS konsolu içerisine ASP.NET yapılandırma ayarlarını içeren kategori gelmiş olacaktır.

Artık şimdi ASP.NET için gerekli en iyi yapılandırma deneyimlerini etkinleştirebiliriz.

Debug Yeteneğinin Kapatılması

Uygulama geliştiriciler kod geliştirme sürecinde debug özelliğini aktifleştirirler ve genelde bu özellik bu şekilde kalır. IIS sunucu üzerinde ASP.NET yapılandırma ayarlarında debug özelliği kapatılarak sunucu seviyesinde bu özellik kapatılmalıdır. Böylece:

Potansiyel tehlike olan son kullanıcılara detaylı debug çıktısı vererek uygulamalar hakkında bilgi sahibi olmaları engellenmiş olacaktır.

Kod-seviyesinde açılmış debug özellikleri için savunma mekanizması oluşturuyor.

Debug kapatılması önerilen bir en iyi uygulama yöntemlerindendir.

Bilgi sızmalarına karşı da önemli bir yapılandırmadır.

.NET Özel Hata Sayfalarının Açık Tutulması

ASP.NET uygulaması başarısız olursa “HTTP/1.x 500 Internal Server” hatasına neden olduğunda ya da IIS kategorisindeki “Request Filtering” kurallarına takıldığında bir hata mesajı üretilecektir. Bu durumda kullanıcıya anlaşılır bir hata mesajı sayfası üretmek ya da göstermek isterseniz bu ayar önemlidir. Bu özellik kapalı durumda ise kullanıcıya çok genelleyici bir mesaj görüntülenecektir. Bu özellik açıksa oluşan hataya göre özel mesajlar üretilebilir. IIS sunucular üzerinde bu özelliği açık tutmanızı da öneriyoruz.

Web Sunucu İçerik Yönetim Yapılandırmaları

IIS Web sunucular üzerinden yayınlanan içeriğin yönetimi için merkezi yönetim, otomatik senkronizasyon, güncelleme ve güvenlik standartlarının da mutlaka uygulanmasını öneriyoruz. Şimdi de bunları inceleyelim.

DFS(Distributed File System) İle Merkezi İçerik Dağıtımı

DFS (Distributed File System), Windows sunucu sistemlerinde dosya sunucular için içerik çoğaltmak amacıyla kullanılan bir servistir. Özellikle dosya sunucusu (file server) rolüne sahip sunucular üzerinde File Server rolü altından etkinleştirilebilen bir alt bileşendir. Windows 2000 işletim sisteminden bu yana Windows Server işletim sistemleri üzerinde aynı isimle gelen ve kullanılan bir bileşen. Windows 2008 domain fonksiyonel seviyesi ve sonrası active directory yapılarında da SYSVOL içeriğinin domain controller sunucular arasında replikasyonunu gerçekleştiren DFS Replication bileşeninin de altyapısını oluşturur. Web sunucular için içerik yönetimi de son derece önem arzeden ve sürekli güncel tutulması gereken bir konu. Sahip olduğunuz web sunucu altyapınızda da yük dengeleme mimarisinde yedekli olarak çalışan çok sayıda web sunucuya sahipseniz bunlar üzerinden yayınlanan içeriklerde herhangi bir değişiklik olduğunda bu değişikliğin tüm diğer web sunuculara da tek tek kopyalanması gerekir. Web sunucular üzerindeki bu içerik senkronizasyonunu ya da çoğaltmasını merkezi olarak tek bir sunucu üzerinden gerçekleştirip diğer tüm web sunuculara da DFS altyapısını kullanarak otomatik olarak dağıtabilirsiniz. Bu amaçla web sunuculara ait içerik her web sunucunun kendi üzerinde ayrı ayrı tutuluyorsa tüm web sunuculara aynı zamanda File Server ve DFS Replication rollerini kurup DFS altyapısını oluşturabilirsiniz.

Oluşturulacak DFS altyapısı ile web sunucular üzerinde web içeriklerinin bulunduğu dizinler belirlenen rol dağılımına göre otomatik olarak senkronize edilecektir. DFS topolojisinde yer alan web sunuculardan bir tanesini Primary (Master) olarak seçip, diğerlerini de Replica Member olarak yapılandırıyoruz.

Böylece Primary (Master) sunucu üzerinde bulunan web site içeriklerine ait yapılacak bir güncelleme sonrasında güncellenen içerik ile beraber, güvenlik ayarları, dökümanların nitelikleri, özellikleri ve güvenlik ayarları birlikte (encryption, permission, compression vb.) diğer DFS Replica Member sunuculara belirlenen peryotlarda otomatik olarak senkronize olacaktır.Yapılan içerik senkronizasyonu ya da çoğaltması ile ilgili olarak rutin rapor kayıtları çekilerek operasyonel geçmişe ait raporlarda alınabilir. Böylelikle web site içerik güncellemelerinde yeni kodlar ya da içerikle tek bir sunucuya yüklenecek buradan da otomatik olarak saniyeler içerisinde diğer sunuculara DFS altyapısı ile çoğaltılmış olacaktır.

Robocopy Aracı İle İçerik Senkronizasyonu

Web sunucular üzerinde bulunun içeriğin çoğaltılması ya da senkronizasyonu için kullanılabilecek ikinci seçenek de Robocopy aracı olabilir. Robocopy aracı günümüzde Windows sunucu işletim sistemleri üzerinde yerleşik olarak gelen ve ileri seviye özelliklere sahip dosya transferi aracıdır. Yukarıda DFS servisi kullanılarak yapılan içerik senkronizasyonunu doğrudan Robocopy ile de gerçekleştirebilirsiniz. Benim önerim sunucular arasında içerik senkronizasyonu için DFS altyapısını kullanmanız. Eğer aynı sunucu üzerinde  farklı klasör lokasyonları arasında (aynı disk birimi içerisinde ya da farklı disk birimlerinde konumlandırılmış klasörler olabilir) dosya senkronizasyon ihtiyacınızı olursa da burda Robocopy aracını kullanmanızı öneririm. Bu senkronizasyonda kaynak klasörden hedef klasöre gönderilen içerikle beraber, güvenlik ayarları, doküman nitelikleri, özellikleri (encryption, permission, compression vb.)  belirlenen peryotlarda çoğaltılmaktadır.

Ağ Katmanında Web Sunucular İçin Yük Dengelemesi

Organizasyonunuzda bulunan IIS web sunucuları yedekli ve yük paylaşımını esas alan mimari standartlara göre bir altyapıda konumlandırmalısınız. Yük dengeleme ve yük paylaşımını fiziksel yük dengeleme cihazları ile yapabileceğiniz gibi Windows Network Load Balacing bileşenini ya da IIS’in Application Request Routing (ARR) bileşenini de kullanabilirsiniz. Benim önerim bu amaçla da IIS Web sunucu  farm’ı içerisinde bulunan tüm sunucuların önünde fiziksel olarak yine yedekli mimaride çalışan yük dağıtım ve dengeleme cihazları (Load Balancer) konumlandırılmasıdır. Eğer fiziksel yük dengeleme cihazınız yoksa ya da bütçeniz müsait değilse de IIS’in ARR bileşeni ile bu yük dengelemeyi gerçekleştirmeniz olacaktır. (ARR’ın yük dengeleme dışında gelen isteklerin yönetilmesi ve yönlendirilmesi konularında ileri yetenekleri de mevcuttur.) Yük dengeleme cihazları üzerinde dışardan gelen bağlantının gitmek istediği hedef adrese göre tüm web sunucu tanımları yapılandırılmalı, sunucuların yük dağılımına göre otomatik olarak uygun sunucuya trafik yönlendirilmelidir. IIS web sunuculardan herhangi birinde yaşanacak bir kesinti ya da erişilememe durumunda yük dengeleme cihazı gelen istekleri diğer sunuculara yönlendirerek servis sürekliliğini de sağlamış olacaktır.

Dış Dünyaya Açık Web Sunucu Active Directory Domain Yapılarının Ayrılması

Sahip olduğunuz organizasyon bünyesinde bulunan active directory yapısını dış dünyaya servis veren IIS web sunucuları için kesinlikle kullanmamanız öneriyoruz. Dış dünyaya açık web sunucular için DMZ ağında tamamen izole bir active directory domain yapısı kurulmasını özellikle tavsiye ediyoruz. Bu oluşturulacak DMZ domainde belirlenen domain güvenlik standartları etkinleştirilerek web sunuculara uygulanmalıdır. DMZ ağında oluşturulacak active directory domain yapısında çalışan domain controller sunucular da yine birden fazla sayıda yedekli mimaride kurulmuş olmalıdır.

Diğer Yapılandırmalar

Buraya kadarki kısımda genel olarak dosya sunucular üzerinde uygulanmasını önerdiğimiz başlıkları ayrı ayrı inceledik. Bu başlık altında da genel olarak diğer uygulanması gereken standartları maddeler halinde bahsediyor olacağız:

IIS sunucularınızın periyodik olarak düzenli yedeklerini alın. Günlük ya da iki günde bir system state ve web içerik yedeklerini ihmal etmeyin. Özellikle yama geçişleri ya da yazılım güncellemeleri öncesinde de yine sunucunun son durumdaki bir yedeğini, eğer sanal ortamda ise de snapshot (checkpoint) kopyasını alın.

Sistem yöneticisi dışındaki hesaplar için IIS sunucular üzerinde minimum yetkileri tanımlayın. Böylece bu kullanıcıların web sunucular üzerine yazma ya da script çalıştırma gibi farklı zafiyetlere neden olabilecek aksiyonlarını engellemiş olacaksınız.

Yukarıda da belirttiğimiz gibi web trafiğinin ve verilerinizin güvenliği için SSL servisini mutlaka aktifleştirin. Özellikle bilgi girişi yapılan form vb. sayfalar için SSL’siz kullanım yapmamanızı tavsiye ediyoruz. Kullandığınız SSL güvenlikli servislere ait dijital sertifikaların bakımı, yedeklenmesi ve periyodik güncellemelerini, yenilemelerini kesinlikle ihmal etmeyin.

Basic authentication temel kimlik doğrulaması kullanılan tüm web servisleri için mutlaka SSL güvenliğini devreye alarak trafiği güvenli hale getirin. Aksi halde kullanıcı hesabınızdan verilerinize kadar herşey açık metin olarak kolaylıkla ele geçirilecektir.

Web siteleri üzerinde verilen delegasyon kurallarında varsayılan yetkilerin üzerinde yetkiler vermemeye mümkün olduğunca dikkat edin.

Web sunucularınızın sistem, performans, uygulama sağlığı, ağ bağlantıları ve servis ağacına ait sağlık durumlarını düzenli olarak profesyonel bir ürün ya da platform ile proaktif olarak izleyin. Böylece meydana gelebilecek olumlu ya da olumsuz durumların önceden farkında olarak gerekli aksiyonları ya da önlemlerinizi almış olursunuz. Bu konuda Microsoft System Center platformu içerisindeki System Center 2012 R2 Operations Manager (SCOM) ürünü ihtiyacınıza cevap verecektir. SCOM ile gelen yönetim paketlerini (management pack) kullanarak web sunucularınızın detaylı izlenmesini proaktif bir deneyimle gerçekleştirebilirsiniz.

Web sunucular üzerinde dönemsel olarak gerçekleştirilen operasyonel faaliyetler ya da zaman alan işlemler için yine Microsoft System Center platformu içerisindeki System Center 2012 R2 Orchestrator ürünü ile ya da PowerShell script çözümleri hazırlayarak bu rutin işleri mutlaka otomasyona bağlayın. Böylece günün birinde IIS günlüklerinden dolayı disk alanınızın kalmadığı ya da sunucu yama geçişlerinde atlanan bir prosedür ya da sunucudan dolayı oluşabilecek güvenlik zafiyetlerinden kaynaklı başınıza gelebilecek itibar ya da zaman kayıplarının önüne önceden geçmiş olacaksınız.

ÖZETLE :

İki bölümden oluşan bu makale serimizle organizasyonlarda her geçen gün yaygınlaşan Microsoft Internet Information Server (IIS) web ve ftp sunucu sistemleri üzerinde yönetimsel ve güvenlik alanlarında uygulanan en iyi uygulama yapılandırmalarını sizlerle paylaştık. Umarım faydalı olmuştur. Bir sonraki makalemizde görüşmek dileğiyle, esenkalın.

Mesut ALADAĞ.
Microsoft MVP, MCT, P-TSP
www.cozumpark.com | www.mesutaladag.com

Bu makalemizde Microsoft IIS sunucular üzerinde en iyi güvenlik yapılandırma önerilerinden bir tanesi olan Inetpub dizininin sistem sürücüsü yerine farklı bir sürücüye taşınmasını ele alıyoruz.

Uygulamalarımızı Windows Server 2012 R2 ile gelen IIS 8.5 versiyon arayüzünde inceliyor olsak da aynı standartlar IIS 7.0 ve sonrası tüm versiyonlar için geçerli olacaktır.

INETPUB İÇERİĞİNİ TANIYALIM :  

IIS web sunucularda güvenlik alanındaki en-iyi-yapılandırma pratiklerinden bir tanesi de Inetpub dizininin varsayılan olarak oluştuğu sistem diskinden farklı bir disk sürücüsüne taşınmasıdır. IIS 8.5 öncesi versiyonlarda bu işlemi işletim sistemi kurulumu esnasında katılımsız kurulum dosyası (unattend file) ile yapabiliyorduk. Özellikle Vista ve Windows Server 2008 ile başlayan yeni kurulum süreci ile bu uygulama biraz farklılaştı. Kurulum sonrasında Inetpub dizini otomatik olarak Windows ile aynı dizinde geliyor. Ve Inetpub dizinini Windows harici farklı bir disk sürücüne taşımak da kurulum sonrası gerçekleştirilmesi gerekiyor artık.

Aşağıdaki varsayılan kurulum sonrası Inetpub dizinini kullanan yapılandırma dosyalarını görüyorsunuz. Şimdi bu yapılandırma dosyalarını ve bunların farklı bir dizine nasıl taşındığını birlikte ele alalım. Bazı dizin isimleri sadece IIS 7 ve 7.5 versiyonuna ait olup 8.5 versiyonunda bulamayabilirsiniz.

LOGS\FREBLOGS : Failed Request Event Buffering (FREB) başarısızlıkla sonuçlanan isteklere ait günleri tutar. Varsayılan dizin yolu %systemdrive%\inetpub\logs\FailedReqLogfiles

LOGS\LOGFILES : IIS günlük dosyaları için varsayılan yol tanımı. Varsayılan dizin yolu %systemdrive%\inetpub\logs\logfiles

TEMP\AppPools : AppPool Isolation, ilk olarak IIS 7 ile gelmiş olan yeni bir özellik. IIS üzerinde oluşturulmuş uygulama havuzlarına ilişkin (application pools) yapılandırma dosyaları burada saklanmaktadır. Varsayılan konumu %systemdrive%\inetpub\temp\appPools

HISTORY : IIS sunucular için yapılandırma geçmişini tutar. Bir diğer ifade ile IIS yapılandırma ayarlarının saklandığı administration.config ve applicationHost.config dosyalarının sürekli bir yedeğini saklar. Böylece gerçekleştirilen yapılandırmalar geri alınabilir. Varsayılan konumu %systemdrive%\inetpub\history

TEMP\ASP COMPILED TEMPLATES : Classic ASP uygulamalarında derlenen ASP kodu hafıza alanında 250’yi geçerse derlenen kodlar disk üzerindeki bu alana yazılırlar. Varsayılan disk önbellekleme konumu %systemdrive%\inetpub\temp\ASP Compiled Templates

TEMP\IIS TEMPORARY COMPRESSED FILES : IIS sunucular sıkıştırılmış dosyaları gerektiğinde disk üzerinde önbellekleyebilir. Sıkıştırma önbelleği için varsayılan konum %systemdrive%\inetpub\temp\IIS Temporary Compressed Files

WWWROOT : IIS sunucular Default Web Site isimli varsayılan web sitesi ile gelmektedir. Bu siteden de varsayılan IIS yayını yapılmaktadır. Varsayılan konumu %systemdrive%\inetpub\wwwroot dizinidir.

CUSTERR : IIS sunucular için özelleştirilmiş hata sayfalarının depolandığı dizindir. Varsayılan konumu %systemdrive%\inetpub\custerr dizinidir.

WWWROOT ve FTPROOT: Özellikle servis paketleri (SP) ya da diğer kurulumlarda WWWROOT ve FTPROOT dizinlerinin nerede olduğuna ait bilgiler talep edilir. Bunda dolayı WWWROOT ve FTPROOT dizinlerine ait konum bilgisi registry içerisinde de kayıtlıdır.

INETPUB İÇERİĞİNİ TAŞIYORUZ : 

Yukarıdak maddeler halinde anlattığımız dizinleri sırasıyla taşımaya başlıyoruz. Bu taşıma operasyonlarında APPCMD komut satırı aracını kullanacağız. Tüm yapılandırma dosyaları taşındıktan sonra da INETPUB dizinini XCOPY aracı ile istenilen disk sürücüsüne kopyalayacağız.

LOGS\FREBLOGS Taşınması:

%windir%\system32\inetsrv\appcmd set config -section:system.applicationHost/sites -siteDefaults.traceFailedRequestsLogging.directory:"E:\inetpub\logs\FailedReqLogFiles"

LOGS\LOGFILES Taşınması:

%windir%\system32\inetsrv\appcmd set config -section:system.applicationHost/sites -siteDefaults.logfile.directory:"E:\inetpub\logs\logfiles

%windir%\system32\inetsrv\appcmd set config -section:system.applicationHost/log -centralBinaryLogFile.directory:"E:\inetpub\logs\logfiles

%windir%\system32\inetsrv\appcmd set config -section:system.applicationHost/log -centralW3CLogFile.directory:"E:\inetpub\logs\logfiles

TEMP\AppPools Taşınması:

reg add HKLM\System\CurrentControlSet\Services\WAS\Parameters /v ConfigIsolationPath /t REG_SZ /d E:\inetpub\temp\appPools

HISTORY Taşınması:

%windir%\system32\inetsrv\appcmd set config -section:system.applicationhost/configHistory -path:E:\inetpub\history

TEMP\ASP COMPILED TEMPLATES Taşınması:

%windir%\system32\inetsrv\appcmd set config -section:system.webServer/asp -cache.disktemplateCacheDirectory:"E:\inetpub\temp\ASP Compiled Templates"

TEMP\IIS TEMPORARY COMPRESSED FILES Taşınması:

%windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpCompression -directory:"E:\inetpub\temp\IIS Temporary Compressed Files"

WWWROOT Taşınması:

%windir%\system32\inetsrv\appcmd set vdir "Default Web Site/" -physicalPath:E:\inetpub\wwwroot

CUSTERR Taşınması:

%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='401'].prefixLanguageFilePath:E:\inetpub\custerr

%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='403'].prefixLanguageFilePath:E:\inetpub\custerr

%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='405'].prefixLanguageFilePath:E:\inetpub\custerr

%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='404'].prefixLanguageFilePath:E:\inetpub\custerr

%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='406'].prefixLanguageFilePath:E:\inetpub\custerr

%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='412'].prefixLanguageFilePath:E:\inetpub\custerr

%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='500'].prefixLanguageFilePath:E:\inetpub\custerr

%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='501'].prefixLanguageFilePath:E:\inetpub\custerr

%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='502'].prefixLanguageFilePath:E:\inetpub\custerr

WWWROOT ve FTPROOT Taşınması:

reg add HKLM\Software\Microsoft\inetstp /v PathWWWRoot /t REG_SZ /d E:\inetpub\wwwroot

reg add HKLM\Software\Microsoft\inetstp /v PathFTPRoot /t REG_SZ /d E:\inetpub\ftproot

INETPUB İçeriğinin Kopyalanması: Yukarıdaki adımlarla yapılandırma dosyalarının yeni konumları belirlendikten sonra tüm INETPUB içeriğini Windows dizininin bulunduğu sistem sürücüsünden farklı bir disk sürücüsüne tüm klasör ve dosyaların izinleri ve boş dizinleri ile beraber taşıma yapacağız. Bunun içinde XCOPY aracını ya da ROBOCOPY aracını kullanabilirsiniz. Aşağıda örnek olarak XCOPY aracının parametreleri ile taşıma yapacak komutumuzu görüyorsunuz:

XCOPY C:\Inetpub E:\Inetpub /E /O /I

/E : Boş dizinleri de kopyalar.

/O : Dosya ve dizinleri üzerlerinde tanımlı izinlerle birlikte kopyalar.

Böylece tüm Inetpub içeriğini E: sürücüsüne taşımış olduk.

ÖZETLE :

Microsoft IIS sunucular üzerinden web tabanlı mimaride hizmet veren servisler ve uygulamalar yaygınlaştıkça güvenlik önlemleri de daha fazla önem kazanmaktadır. Bu makalemizde IIS sunucular üzerinde en iyi güvenlik yapılandırma önerilerinden bir tanesi olan Inetpub dizininin sistem sürücüsü yerine farklı bir sürücüye taşınmasını ele detaylı adımlarla ele aldık.Yeni bir makalede görüşmek dileğiyle, hoşçakalın.

Mesut ALADAĞ.
Microsoft MVP, MCT, P-TSP
www.cozumpark.com | www.mesutaladag.com

Microsoft’un yeni nesil işletim sistemi olacak olan Windows Server vNext ile gelen yenilikleri incelemeye devam ediyoruz. Şu ana kadar aşağıdaki makalelerimizde Windows Server 2016 ile gelen yenilikleri sizlerle paylaşmıştık:

Windows Server vNext 2016 Technical Preview 2 Yenilikleri – Bölüm1

Windows Server vNext 2016 Technical Preview 2 Yenilikleri – Bölüm2

Windows Server 2016 TP2 DNS Politikaları – Bölüm 1

Windows Server 2016 TP2 DNS Politikaları – Bölüm 2

Yukarıda linklerini verdiğimiz makalelerimizde de belirttiğimiz gibi Windows Server vNext geliştirme süreci devam ediyor. Ürünün 2016 yılı içerisinde piyasaya çıkacağını tahmin ediyoruz. Mayıs ayı içerisinde “Windows Server Technical Preview 2” sürümü yayınlandı. Yine Mayıs ayı içerisinde ürünün resmi adının da Windows Server 2016 olacağı duyuruldu. Windows Server 2016 Technical Preview 2 ISO ya da VHD dosyasını aşağıdaki adresten indirerek testlerinize başlayabilirsiniz:
https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview

Üç bölümden oluşan bu makale serimizde de sizlerle Windows Server 2016 ile gelen yeniliklerden en önemlisi olan ve bulut altyapılarını çok daha güçlendirecek yeni Windows Server sürümü kod adı “Tuva” olan “Windows Server Nano’yu” inceliyoruz. Bu ilk bölümde Windows Server Nano’ya giriş yapıp, genel mimari özellikler ve diğer sürümlere göre avantajlarını inceliyoruz. Makalemizin ikinci ve üçüncü bölümünde de Nano Server kurulumu, yapılandırması ve yönetimi konularını detaylandıracağız.

Yeni İşletim Sistemi Dağıtımı : Windows Server Nano 

Windows Server vNext ile yeni bir işletim sistemi kurulum seçeneği geliyor : Windows Server Nano. Şu an için Windows Server Technical Preview 2 sürümü üzerinde henüz bu seçenek yok. Bundan sonraki çıkacak sürümde gelmesini bekliyoruz.

Windows Server Nano, üzerinde servisleri çalıştırma amacına yönelik, tamamen uzaktan yönetim mimarisine göre tasarlanmış yeni nesil Windows Server sürümüdür. Windows Server Nano, Windows Server işletim sisteminin 64-bit mimaride çalışan, komut satırı tabanlı bir dağıtım. Windows Server 2012 R2 ya da Windows Server 2012 R2 Core’dan farkı konsol arayüzünün olmadığı, mikro servisler için tasarlanmış yeni bir dağıtım.

Windows Server mühendislerinin deyimi ile Nano Server, “Windows NT 3.5’den bu yana en önemli değişiklik” olarak görülüyor.

Windows Server Core sürüme göre işletim sistemi çekirdeği ya da bir diğer ifade ile disk yüzeyinde kapladığı alan daha da küçültülmüş bir sürüm. Windows Server 2012 R2 Core sürümü için kapladığı alan 4 GB iken, Windows Server Nano için bu değer 0.4 GB boyutunda.

Windows Server ve Windows Server Nano karşılaştırıldığında elde edilen sonuçlar:

Yüzde 93 daha küçük VHD boyutu

Yüzde 92 daha az kritik güncelleme gereksinimi

Yüzde 80 daha az yeniden başlatma gereksinimi

Yaklaşık 1 TB RAM’e sahip Nano Server üzerinde 1000 Nano Server sanal sunucu (VM) koşturma deneyimi

Server Core sürümünün yirmide bir (1/20) boyutunda. 8.3 GB boyutundaki Server Core 410 MB’a iniyor!

Server Core ile 300 sn. olan kurulum zamanı 40 sn.’ye düşüyor.

Not : Bu rakamlar yapılacak yeni optimizasyonlarla RTM sürümünde daha da aşağıya düşebilir.

Bu kazanımlar aşağıdaki aksiyonlarla sağlanmış durumda:

Nano Server üzerinde Grafik arayüzü bileşenleri kaldırılmış

Nano Server üzerinde 32-bit desteği (WOW64) kaldırılmış

Nano Server üzerinde MSI ve Server Core bileşenlerinden çoğu kaldırılmış

Nano Server’ın yerel konsol oturumu açma desteği yok

Nano Server’a uzak masaüstü oturum açma desteği yok

Nano Server üzerinde .NET Framework’ün refactor edilmiş hali olan .NET Core bileşeni geliyor. Bu .NET Core içerisinde de CoreCLR runtime temel bileşeni ile geliyor.

Nano Server üzerinde Core PowerShell bileşeni geliyor. Core PowerShell de PowerShell’in CoreCLR üzerinde çalışacak şekilde refactor edilmiş hali. Tam olarak PowerShell kod uyumluluğunu destekliyor. PowerShell Remoting ile uzak bağlantıda Invoke-Command, New-PSSession, Enter-PSSession gibi cmdletler tamamen destekleniyor. Core Engine bileşenlerinin çoğu destekleniyor. İlk başlangıçta cmdlet sayısı sınırlı. Zaman içerisinde cmdletler de zenginleşiyor olacak.

Nano Server yönetimi tamamen uzaktan Server Manager vb. yönetim konsolları, PowerShell ya da WMI ile sağlanıyor.

Nano Server uzaktan yönetimi için Microsoft tarafından özel olarak tasarlanmış yeni nesil web-tabanlı yönetim konsolu geliyor. Bu konsol uzaktan yönetimi yapacak Windows Server 2016 üzerinde çalışıyor olacak. Bu yeni nesil konsol ile sadece Nano Server değil Core ve GUI tabanlı Windows Server işletim sistemlerinde çalışan sunucular da yönetilebiliyor olacak.  Bu konsol içerisinden yönetilebilecek bileşenlerden bazıları:

Task Manager

Registry Editor

Event Viewer

Device Manager

Sconfig

Control Panel

File Explorer

Performance Monitor

Disk Management

Users/Groups Manager

Nano Server’a sonradan isteğe bağlı Windows Rol ya da feature DISM (Deployment Image Servicing and Management) aracı kullanılarak eklenebiliyor. Fakat bu rol ya da feature’lara ait binary’ler işletim sistemi üzerinde mevcut değil.

Nano Server sistemlerinin yönetimi, kontrol ve izlemesi için PowerShell Desired State Configuration bileşeni kullanılıyor.

Nano Server üzerinde geleneksel Windows uygulamaları şu an için desteklenmiyor ve gelecekte de desteklenmeyeceği belirtiliyor. Çıkış amacı altyapı servisleri için (Hyper-V, File Server, Clustering, Web Server vb.) tasarlanmıştır.

Nano Server ile C#, Java, Node.js, Python, MySQL, OpenSSL, Ruby (2.1.5), SQLite, Nginx gibi uygulama dilleri ve runtime platformları da desteklenmektedir.

Nano Server fiziksel, sanal, Windows Server container ya da Hyper-V Container platformalarında destekleniyor.

Nano Server, uzaktan dosya transferi, uzaktan script çalıştırma, Visual Studio vb. araçlarla uzaktan hata giderme (debugging) operasyonlarını da destekliyor.

Windows Nano Server, Core Edition’da olduğu gibi Windows işletim sisteminin kurulum seçeneği olarak gelecek.

Nano Server özellikle uzun yılların birikimi, müşteri talepleri ve bulut teknolojilerinin geldiği nokta ile ön görülen yol haritası da göz önünde bulundurularak aşağıdaki ihtiyaçlara cevap verecek şekilde geliştiriliyor:

Mümkün olan en minimum seviyede yama ve yeniden başlatma ihtiyacı

İşletim sistemi imajlarında çok daha küçük boyutlar

İşletim sistemi hazırlanması ve provizyonlama sürecinde mümkün olan en az kaynak kullanımı (özellikle bulut mimarisine hizmet veren sunucular için)

Windows Server sürücü desteği Nano server için de geliyor.

İşletim sistemi provizyonlama süresinin daha da azaltılması

Sunucu rolleri ve isteğe bağlı feature’ların Nano Server dışına çıkartılması

Yerel yönetim araçları yerine web tabanlı grafiksel yönetim araçları (Azure Portal benzeri)

Nano Server üzerinde gelen rol ve feature’lar : Hyper-V, Clustering, Storage rolleri, Core CLR, ASP.NET vNext, PaaSv2 ve Container’lar.

Nano server üzerinde yerleşik olarak Antimalware koruması geliyor.

Windows Nano Server gelecek kuşak bulut altyapı ve uygulamalarının üzerine inşa edileceği önemli bir sürüm. Güçlü altyapısı ile hem modern bulut altyapılarını güçlendirecek özellikleri barındırması hem de bulut tabanlı uygulamalar için optimize edilmiş olması Windows Nano Server’ı öne çıkaran yenilikler.

Windows Server 2012 ve sonrasında Windows Server Core ve Windows Server GUI modları arasında dönüşüm ya da geçiş feature ekleme ya da kaldırma ile mümkün olabiliyordu. Fakat aynı durumunda Nano Server için olmayacak. Nano Server rol ya da feature desteği şu an için sınırlı sayıda. Core Edition ya da GUI sürümler üzerinde desteklenen belli bir kısmı zaman içerisinde de destekleniyor olacak.

Nano Server, şu anki Windows Server Technical Preview 2 sürümünde kurulum ekranında henüz bir seçenek olarak gelmiyor. Bunun sebebi de Nano Server işletim sistemi imajının sürücülerle özelleştirilme gereksinimidir. İleriki TP sürümlerinde ya da RTM sürümünde kurulum seçeneklerinden bir tanesi olacak. Fakat şu an için işletim sistemi medyası içerisinde NanoServer klasörü altında .wim imajı geliyor. Bunu kullanarak Nano Server işletim sistemi imajı hazırlanabilir.

Makelemizin ikinci bölümünde adım adım bunu gerçekleştiriyor olacağız.

Nano Server İstatistik Sonuçları:

Yama ve Servis Kalitesinde Açık Ara Önde:

Aşağıdaki grafiklerde de görüldüğü gibi 2014 yılı içerisinde “Important” kategorisinde Windows Server Full GUI sürümü için 26, Core sürümü için 23 güncelleme yayınlanırken, eğer Nano Server kullanıyor olsaydık bu rakam 9’a iniyor. Yine “Critical” kategorisinde Windows Server Full GUI sürümü için 23, Core sürümü için 8 güncelleme yayınlanırken, eğer Nano Server kullanıyor olsaydık bu rakam 2’e iniyor. Bu güncellemeler sonrasında da yeniden başlatma ihtiyacı rakamlarına baktığımızda Windows Server Full GUI sürümü için 11, Core sürümü için 6, eğer Nano Server kullanıyor olsaydık da 3 kez sistemi yeniden başlatıyor olacaktık.

Dolayısıyla Nano Server daha az güncelleme gereksinimi ile çok daha minimum seviyede yeniden başlatma ihtiyacı ile yüksek oranda hizmet servis kalitesine sahip.

Çok Daha Güvenli:

Yine aşağıdaki grafiklerde de görüldüğü gibi Windows Server Core sürümü açılış sürecinde 98 adet sürücü yüklerken, eğer Nano Server kullanıyor olsaydık bu rakam 73’e iniyor. Yine Server Core sürümü üzerinde çalışan servis sayısı 46 iken, Nano Server kullanıyor olsaydık bu rakam 22’ye iniyor. Server Core sürümü üzerindeki açık port sayısı 31 iken, Nano Server ile bu rakam da 12’ye kadar düşüyor.

Bu rakamlar da gösteriyor ki, Nano Server çok daha hızlı ve performanslı bir çalışma mimarisine sahip, gereksiz tüm servislerin minimal seviyede işletildiği, sadece çalıştırdığınız rollerin ihtiyacı olan servislerin koşturulduğu, güvenlik olarak da gereksiz tüm erişim portlarının kaldırıldığı ve çok daha güvenli bir mimaride gelen yeni bir sürüm.

Kaynak Utilizasyonunda Daha Verimli:

Kaynak kullanımı açısından elde edilen aşağıdaki istatik rapolarına göre de Server Core sürümü üzerinde çalışan Process sayısı 26 iken Nano Server ile bu rakam 21’e düşmüş. Açılışta Server Core tarafından yapılan IO miktarı 255MB iken, Nano Server ile bu rakam 150 MB’a  düşürülmüş. Server Core üzerinde kernel memory kullanımı 139 MB iken, Nano Server ile bu değer de 61 MB’a inmiş.

Kurulum ve Yaygınlaştırmada Muhteşem Sonuçlar:

Şu ana kadar incelediğimiz Nano Server işletme sürecindeki tüm istatistiki raporlara paralel kurulum sürecindeki rakamlar da net olarak Nano Server’ın gücünü ve farkını ortaya koyuyor.

Server Core için 300 sn. olan kurulum süresi, Nano Server ile 40 sn.’ye yani yaklaşık 7.5 katına indirgenmiş durumda. Disk üzerinde kapladığı alan bakımından Server Core 4.84 GB iken, Nano Server 400MB’a yakın bir değer, yani 10 katında da aşağıda bir disk alanı kullanımı söz konusu. Sanal sunucu (VM) olarak disk kullanım boyutlarını karşılaştırdığımızda da Server Core için elde edilen değer 6.3 GB iken Nano Server için bu rakam sadece 410 MB. Disk alanı kullanımında da Nano Server açık ara önde ve müşterinin beklentilerine cevap verecek boyutlarda. 

Bütün bu rakamlar gösteriyor ki, Nano Server için önemli derecede mühendislik çalışmaları yapılmış, işletim sistemi kaynak tüketimi yönüyle minimal seviyelere indirgenmiş buna karşın hızlı başlama süreci, artırılmış güvenlik, daha az güncelleme gereksinimleri vb. değerlerle özellikle sanallaştırma ve bulut mimarileri için önemli bir süreci başlatacağı gözüküyor.

ÖZETLE :

Üç bölümden oluşan bu makale serimizde de sizlerle Windows Server 2016 ile gelen yeniliklerden en önemlisi olan ve bulut altyapılarını çok daha güçlendirecek yeni Windows Server sürümü olacak olan “Windows Server Nano’yu” inceliyoruz. İlk bölümde Windows Server Nano’ya giriş yapıp, genel mimari özellikler ve diğer sürümlere göre avantajlarını inceledik. Makalemizin ikinci bölümünde de Nano Server kurulumu, üçüncü bölümde de yapılandırması ve yönetimi konularını detaylandıracağız.Makalemizin ikinci bölümünde görüşmek üzere esenkalın.

Mesut ALADAĞ.
Microsoft MVP, MCT, P-TSP
www.cozumpark.com | www.mesutaladag.com

Microsoft’un yeni nesil işletim sistemi olacak olan Windows Server vNext ile gelen yenilikleri incelemeye devam ediyoruz. Şu ana kadar aşağıdaki makalelerimizde Windows Server 2016 ile gelen yenilikleri sizlerle paylaşmıştık:

 Windows Server vNext 2016 Technical Preview 2 Yenilikleri – Bölüm1

Windows Server vNext 2016 Technical Preview 2 Yenilikleri – Bölüm2

Windows Server 2016 TP2 DNS Politikaları – Bölüm 1

Windows Server 2016 TP2 DNS Politikaları – Bölüm 2

Yukarıda linklerini verdiğimiz makalelerimizde de belirttiğimiz gibi Windows Server vNext geliştirme süreci devam ediyor. Ürünün 2016 yılı içerisinde piyasaya çıkacağını tahmin ediyoruz. Mayıs ayı içerisinde “Windows Server Technical Preview 2” sürümü yayınlandı. Yine Mayıs ayı içerisinde ürünün resmi adının da Windows Server 2016 olacağı duyuruldu. Windows Server 2016 Technical Preview 2 ISO ya da VHD dosyasını aşağıdaki adresten indirerek testlerinize başlayabilirsiniz:
https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview

Üç bölümden oluşan bu makale serimizde de sizlerle Windows Server 2016 ile gelen yeniliklerden en önemlisi olan ve bulut altyapılarını çok daha güçlendirecek yeni Windows Server sürümü kod adı “Tuva” olan “Windows Server Nano’yu” inceliyoruz. Makalemizin ilk bölümünde Windows Server Nano’ya giriş yapıp, genel mimari özellikler ve diğer sürümlere göre avantajlarını incelemiştik. Makalemizin bu bölümünde de Nano Server kurulumunu gerçekleştireceğiz.

Bu bölümde ele alacağımız konular:

Windows Nano Server Kurulumu ve Yapılandırması

İhtiyacınız olan paketlerle Nano Server imajının hazırlanması

İlave aygıt sürücülerinin eklenmesi

Unattend.xml katılımsız kurulum dosyası ile yaygınlaştırılması

Nano Server İle Çalışmaya Başlamak

Nano Server bulut tabanlı veri merkezi altyapılarında en iyi performans ve güvenlik standartlarına göre optimize edilmiş, uzaktan yönetim modeline göre tasarlanmış Windows sunucu ailesinin yeni nesil işletim sistemi dağıtımıdır.

Windows Nano Server karakteristik özellikleri:

Yerel olarak oturum açma yeteneği yoktur.

Uzak masaüstü bağlantısı ile oturum açma yeteneği yoktur.

Çok düşük boyutta disk alanı kullanır.

Çok hızlı kurulur.

Diğer Windows Server sürümlerine göre çok daha az yeniden başlatma ihtiyacı duyar.

Nano Server'ın ideal olarak kullanılabileceği senaryolar:

Cluster ya da Stand-alone mimaride çalışan Hyper-V Host Sunucusu

Scale-Out File Server (SOFS) yapıları için Storage Host Sunucusu

Tamamen bulutta geliştirilmiş uygulamalar için Container ya da sanal işletim Sistemi (VM ya da Hyper-V guest)

Nano Server Mimarisinde Paketlerle Rol ve Feature Eklenmesi

Windows Server 2016 Technical Preview sürecinde Nano Server işletim sistemi medyası içerisinde NanoServer klasörü içerisinde bulunuyor.

NanoServer klasörü içerisinde .wim imajı ve Packages alt klasörü geliyor. Packages klasörü altındaki paket dosyaları kullanılarak Nano Server VHD imajına rol ve feature eklenmesini gerçekleştirip, daha sonra da bu imajdan açılış gerçekleştireceğiz.

Aşağıdaki tabloda Nano Server tarafından desteklenen ve paketlerle eklenebilen rol ve feature listesini görmektesiniz:

WIM İmajınını VHD'ye Dönüştürmek

Öncelikle Windows Server Technical Preview 2 ISO’su ya da medyasi içerisindeki NanoServer klasör içeriğini sunucunuzun ayrı bir klasörüne kopyalayın. Ben bu işlem için C:\NanoServerVHD\ ana klasörünü oluşturdum.

C:\NanoServerVHD\WIM altına da Nano Server WIM imajını kopyaladım.

C:\NanoServerVHD\Packages altına da Nano Server rol ve feature paket dosyalarını kopyaladım.

Şimdi deScript Center adresinden Convert-WindowsImage.ps1 script dosyasını aynı klasör içerisine indirin. Bu PowerShell script medya üzerindeki .wim imajını tanımlanan dosya yoluna VHD imajı olarak dönüştürmemizi sağlıyacak.Şu anki son versiyonunun Windows 10 desteği de gelmiştir. Ben de uygulamalarımı Windows 10 üzerinde gerçekleştiriyorum.

Convert-WindowsImage.ps1 şu an itibariyle Windows 10, Windows 8, Windows 8.1 ya da Windows Server 2012 R2 sistemler üzerinde çalıştırılarak Windows 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows 7, Windows 8 ve Windows 8.1 işletim sistemlerine ait ISO ya da WIM imajlarından VHD ya da VHDX imaj üretmeyi sağlıyor. Bunun için işlem yapılan sistem üzerinde Hyper-V rolünün bulunma zorunluluğu da yok. Ben makaledeki adımlarda bir Windows 10 Insider Preview versiyonu üzerinde bu işlemleri administrator hesabı ile oturum açarak gerçekleştiriyorum.

Windows PowerShell komut satırı uygulamasını “Run as administrator” seçeneği ile başlatıyoruz.

Şimdi de aşağıdaki şekilde öncelikle Convert-WindowsImage.ps1 PowerShell script dosyasını çalıştırıyoruz.

Bu şekilde çalıştırdıktan sonra herhangi bir dosya uzantısı kullanmadan Convert-WindowsImage cmdlet ile komutları işletebilirsiniz.

Şimdi de aşağıdaki komutla WIM imajından VHD oluşturma sürecini başlatacağız:

Convert-WindowsImage -Sourcepath <path to wim> -VHD <path to new VHD file> –VHDformat VHD -Edition 1

Komutumuzu çalıştırdıktan sonra VHD imaj oluşturma süreci başlıyor.

Gerçekleştirilen adımlar:

Komut satırında Edition ile verdiğimiz imajın seçilmesi

Boş bir VHD disk oluşturulması

VHD’nin bağlanması

GPT sitili ile yapılandırılıp, bölümlenmesi

Sistem volume oluşturulması

Boot volume oluşturulması

Biçimlendirme işlemleri

İşletim sistemi imajının (Nano Server) VHD’ye aktarımı

VHD’nin bootable olarak yapılandırılması

İmajın kapatılması

İşlem adımları başarıyla tamamlandıktan sonra VHDX klasörü altında VHD dosyamızın başarıyla oluştuğunu görüyoruz.

Eğer VHD değil de VHDX oluşturmak istersek de aşağıdaki komutu kullanabilirsiniz:

Yukarıdaki adımlara benzer şekilde disk bölümleme, biçimlendirme vb. adımlar başarıyla tamamlandıktan sonra VHDX dosyamız hazır hale geliyor.

Aynı klasör içerisinde VHDX imajımız da hazır.

İmajı hazırladığım ana klasör altında dism isimli bir klasör açtım.

Windows Server 2016 TP2 medyasında Sources klasörü içerisindeki aşağıdaki dosyaları dism klasörüne kopyaladım:

api*downlevel*.dll

*dism*

*provider*

VHD ya da VHDx’i mount ederken kullanmak için de yine ana klasör altında MountDir dizini açıyoruz.

Bir paket dosyasını yüklemek için Nano Server VHD'nin bulunduğu dizine gidiyoruz, VHD ya da VHDX imajını mount edip ve DISM.exe Add-Package opsiyonunu kullanarak rol ya da feature ekliyoruz. Ben örnek olarak VHDX için bu işlemleri yapıyor olacağım. Siz benzer adımları VHD paketi kullanıyorsanız onun için de gerçekleştirebilirsiniz. Aşağıdaki örnekte Hyper-V rolü ve temel sürücücülerinin imaj içerisine eklenmesini görüyorsunuz:

cd \NanoServerVHD
md mountdir
dism\dism /Mount-Image /ImageFile:.\NanoServer.vhd /Index:1 /MountDir:.\mountdir

Bu komut sonrasında MountDir dizini içerisine Nano Server imajını açıyor.

Şimdi de aşağıdaki komutları çalıştırarak VHD imajı içerisine Hyper-V rolü için gerekli paketleri ekliyoruz:

dism\dism /Add-Package /PackagePath:.\packages\Microsoft-NanoServer-Compute-Package.cab /Image:.\mountdir

dism\dism /Add-Package /PackagePath:.\packages\en-us\Microsoft-NanoServer-Compute-Package.cab /Image:.\mountdir

dism\dism /Add-Package /PackagePath:.\packages\Microsoft-NanoServer-OEM-Drivers-Package.cab /Image:.\mountdir

dism\dism /Add-Package /PackagePath:.\packages\en-US\Microsoft-NanoServer-OEM-Drivers-Package.cab /Image:.\mountdir

İsteğe bağlı olarak Failover Cluster, Storage gibi diğer rol ya da feature bileşenlerine ait paket eklemelerine de devam edebilirsiniz:

Eklenecek rol, feature ya da ilave sürücü kalmadıysa da aşağıdaki komut ile imajı kapatabilirsiniz.

dism\dism /Unmount-Image /MountDir:.\MountDir /Commit

Rol ve feature eklemeleri sonunda imajımızın boyutu biraz daha artmış oldu.

İlave Sürücülerin Eklenmesi

Sahip olduğunuz donanımlar ya da sistem Nano Server sürümünün tam uyumlu çalışması için ilave sürücülere gereksinim duyabilir. Nano Server'a bu ilave sürücüleri eklemeden önce, yukarıda gerçekleştirdiğimiz adımlarla temel sürücüleri ilave edin ve Nano Server'ı VHD'den açmayı deneyin. Eğer sonuç başarısız olursa ya da sürücülerden dolayı sorunlar yaşarsanız bu durumda aşağıdaki adımları gerçekleştirerek ilave sürücüleri ekleyebilirsiniz:

Nano Server kurulumunu yapacağınız fiziksel sunucu üzerine Windows Server 2016 TP2 kurulumunu yapın.

Device Manager açın ve aşağıdaki kategorilerde bulunan aygıtları tanımlayın:

Network adapters

Storage controllers

Disk drives

Bu kategorilerdeki her aygıt için Properties'den Driver tabına geçip Driver Details tıklayın.

Sürücü dosyası adı ve yolunu not edin. Örneğin; e1i63x64.sys isimli dosya için C:\Windows\System32\Drivers konumu gibi.

Komut satırında dosya adını arattırın ( dir e1i*.sys /s /b). Bu örnekte sürücü harfi aynı zamanda C:\Windows\System32\DriverStore\FileRepository\net1ic64.inf_amd64_fafa7441408bbecd\e1i63x64.sys konumundadır.

Run as admin ile komut satırına geçin ve Nano Server VHD'nin bulunduğu dizine gidip aşağıdaki komutları çalıştırın:

md mountdir

dism\dism /Mount-Image /ImageFile:.\NanoServer.vhd /Index:1 /MountDir:.\mountdir

dism\dism /Add-Driver /image:.\mountdir /driver: C:\Windows\System32\DriverStore\FileRepository\net1ix64.inf_amd64_4d8ace23eb3ebde1

dism\dism /Unmount-Image /MountDir:.\MountDir /Commit

Yukarıdaki adımları ihtiyacınız olan tüm aygıt vb. sürücüler için gerçekleştirin.

Nano Server Yapılandırması

Yapılandırmayı tamamlamak için, bilgisayar adı ve Administrator şifresi tanımlanır.Bu görevleri tamamlamak için en iyi yol Unattend.xml dosyasını kullanmaktır. Örnek Unattend.xml dosyasında offlineServicing bölümünde bilgisayar adı, oobeSystem  bölümünde Administrator şifresi, specialize bölümünde de takım adı ve organizasyon kaydediliyor ve yapılandırılıyor. Fakat Nano Server'i domaine üye yapmıyor. Bu değerleri kendi ihtiyacınıza göre düzenleyebilirsiniz.

Bu örnekte offlineServicing bölümü DISM komutunu çalıştırır çalıştırmaz uygulanıyor, diğer bölümler sunucu ilk başlatıldığında imaja ekleniyor.

Not :

Bu haliyle Unattend.xml dosyası Nano Server'ı domaine üye yapmaz. Dolayısıyla bu dosyayı Nano Server'ı stand-alone rolünde Workgroup ortamında çalışan sunucu olarak hazırlar. Domaine üye yapma aksiyonunu sizin ayrıca gerçekleştirmeniz gerekiyor. ComputerName ve AdministratorPassword değerleri sadece anlık örnekler.

Bu Unattend.xml dosyası Windows 10 Technical Preview ya da Windows Server Technical Preview öncesi versiyonlarda çalışmaz.

Düzenleme yapılmış ve hazırlanmış unattend.xml dosyasını C:\NanoServerVHD klasörüne konumlandırın.

VHDX ya da VHD imajını mount edin ve admin yetkisi ile açılmış komut satırında aşağıdaki komutları çalıştırarak offlineServicing ayarlarını uygulayın:

dism\dism /Mount-Image /ImageFile:.\NanoServer.vhd /Index:1 /MountDir:.\mountdir

dism\dism /image:.\mountdir /Apply-Unattend:.\unattend.xml

Şimdi de kurulum esnasındaki dosyaları depolaması için "Panther" isimli bir klasör oluşturup, Unattend.xml dosyasını da buraya kopyalıyoruz ve sonrasında VHD'yi aşağıdaki komutlarla unmount ediyoruz:

md .\mountdir\windows\panther
copy .\unattend.xml .\mountdir\windows\panther

Bu işlemden sonra tekrar aşağıdaki komut ile imajı kapatıyoruz.

dism\dism /Unmount-Image /MountDir:.\mountdir /Commit

Bu VHDX ile Nano Server ilk açtığımızda belirttiğimiz diğer ayarlar da uygulanmış olacaktır.

Artık VHDX imajımız açılışa hazır. Bunu Hyper-V konsolunda bir Virtual Machine oluşturup disk olarak bağladıktan sonra Nano Server ile çalışmaya başlayabiliriz.

Nano Server sunucumuz açıldıktan sonra şimdi bir bağlantı testi ile erişimi gerçekleştireceğiz.

Öncelikle aşağıdaki komutla Nano Server sunucu ip adresini bağlanılacak güvenilen host listesine ekliyoruz:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value 192.168.1.53 -Concatenate

Nano Server sunucumuza bağlanmak için de Enter-PSSession cmdlet kullanıyoruz. Unattend.xml dosyasında administrator hesabı için belirttiğimiz şifreyi girip OK ile onaylayınca bağlantı gerçekleşmiş olacak.

Nano Server sunucumuza bağlantı sağladıktan sonra PowerShell komut satırından desteklenen tüm cmdletleri kullanarak uzaktan yönetimi gerçekleştirebilirsiniz.

Örneğin Nano Server üzerindeki modül listesini kontrol edelim:

Gördüğünüz gibi temel modül bileşenleri geliyor.

PowerShell.exe çağırdığımızda Nano Server üzerinde de otomatik modül yükleme özelliği ile CoreCLR altındaki temel modülleri hafızaya yüklediğiniz görüyoruz.

$PSVersionTable ile gelen versiyon bilgisi:

PowerShell Remoting bağlantımız aktif iken Nano Server üzerinde Windows Firewall aşağıdaki komutlarla devre dışı bırakıyoruz.

Nano Server paylaşımlarına başarıyla erişim sağladıyabildiğimiz test ediyoruz.

Event Viewer konsolundan Nano Server sunucumuza bağlanıp oluşan olay günlüklerini kontrol ediyoruz:

ÖZETLE:

Üç bölümden oluşan bu makale serimizde de sizlerle Windows Server 2016 ile gelen yeniliklerden en önemlisi olan ve bulut altyapılarını çok daha güçlendirecek yeni Windows Server sürümü kod adı “Tuva” olan “Windows Server Nano’yu” inceledik. Makalemizin ilk bölümünde Windows Server Nano’ya giriş yapıp, genel mimari özellikler ve diğer sürümlere göre avantajlarını incelemiştik. Makalemizin bu bölümünde de Nano Server kurulumu ve ilk yapılandırmasını detaylı olarak paylaştık. Üçüncü ve son bölümde de detaylı yapılandırmalara ve yönetim seçeneklerine devam edeceğiz.

Mesut ALADAĞ.
Microsoft MVP, MCT, P-TSP
www.cozumpark.com | www.mesutaladag.com 

Microsoft’un yeni nesil işletim sistemi olacak olan Windows Server vNext ile gelen yenilikleri incelemeye devam ediyoruz. Şu ana kadar aşağıdaki makalelerimizde Windows Server 2016 ile gelen yenilikleri sizlerle paylaşmıştık:

Windows Server vNext 2016 Technical Preview 2 Yenilikleri – Bölüm1
Windows Server vNext 2016 Technical Preview 2 Yenilikleri – Bölüm2
Windows Server 2016 TP2 DNS Politikaları – Bölüm 1
Windows Server 2016 TP2 DNS Politikaları – Bölüm 2 

Yukarıda linklerini verdiğimiz makalelerimizde de belirttiğimiz gibi Windows Server vNext geliştirme süreci devam ediyor. Ürünün 2016 yılı içerisinde piyasaya çıkacağını tahmin ediyoruz. Mayıs ayı içerisinde “Windows Server Technical Preview 2” sürümü yayınlandı. Yine Mayıs ayı içerisinde ürünün resmi adının da Windows Server 2016 olacağı duyuruldu. Windows Server 2016 Technical Preview 2 ISO ya da VHD dosyasını aşağıdaki adresten indirerek testlerinize başlayabilirsiniz:
https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview

Üç bölümden oluşan bu makale serimizde de sizlerle Windows Server 2016 ile gelen yeniliklerden en önemlisi olan ve bulut altyapılarını çok daha güçlendirecek yeni Windows Server sürümü kod adı “Tuva” olan “Windows Server Nano’yu” inceliyoruz. Makalemizin ilk iki bölümünde Windows Server Nano’ya giriş yapıp, genel mimari özellikler ve diğer sürümlere göre avantajlarını incelemiş, Nano Server kurulumu ve bağlangıç kontrollerini yapmıştık. Bu bölümde de yapılandırma ve yönetim konularını detaylandırıyoruz:

Bu bölümde ele alacağımız konular:

Uzaktan yönetim araçları ile Nano Server Yönetimi

Nano Server’ın Domaine Üye Yapılması

Nano Server üzerinde Hyper-V yönetimi

Nano Server üzerinde failover cluster kurulumu ve yönetimi

Nano Server Sunucumuzun TCPIP Ayarlarını Yapılandırmak

Şimdi de Nano Sunucumuzun TCPIP ayarlarını yapılandıralım.

Öncelikle mevcut durumda Nano Server sunucumuza yine PowerShell Remoting ile bağlanıyoruz:

Hemen akabinde aşağıdaki NETSH komutuyla mevcut TCPIP yapılandırmasının bir çıktısını alıyoruz:

Burada dikkat etmeniz gereken kısım mevcut durumdaki ağ arabiriminin adı. Bende gelen çıktıda “Ethernet 2” olarak gözüken arabirim. Şimdi bu arabirime sabit ip adresi, alt ağ maskesi (subnet mask), varsayılan ağ geçidi (default gateway) ve DNS sunucu tanımlarını aşağıdaki komutları sırasıyla çalıştırarak yapılandırıyoruz:

Sıra geldi Nano Sunucumuzu domain ortamımıza üye yapmaya.

Nano Server Domaine Üye Yapmak

Online Olarak Nano Server'ı Domaine Üye Yapmak:

Nano Server çalışırken, istediğiniz zaman aşağıdaki adımları gerçekleştirerek domaine üye yapabilirsiniz. Bu işlem için de domain içerisinde çalışan bir Windows Server Techical Preview sistemine sahip olmanız gerekiyor.

Windows Server TP versiyonunda domaine üye ve hali hazırda çalışan bir sunucudan aşağıdaki komutu kullanarak bir data blob çıkartıyoruz:

djoin.exe /provision /domain <domain-name> /machine <machine-name> /savefile .\odjblob

Bu komut oluşan data blob'unu "odjblob" isimli dosyaya yazar.

"odjblob" dosyasını aşağıdaki komut ile Nano sunucusuna kopyalanır.

Bu işlem için aşağıdaki gibi NET USE metodunu da kullanabilirsiniz.

net use z: \\<ip address of Nano Server>\c$

NOT : Eğer net use komutu başarısızlıkla sonuçlanırsa, Windows Firewall kurallarını kontrol etmenizi öneririm. Bunu kontrol etmek için de PowerShell komut satırını admin yetkisi ile açarak aşağıdaki komutları çalıştırın:

$ip = "<ip address of Nano Server>"
Enter-PSSession -ComputerName $ip -Credential $ip\Administrator

Administrator hesabının şifresini girdikten sonra Nano Server sunucusuna uzaktan PowerShell oturumu açmış olacaksınız. Nano Server sunucu adı PowerShell komut satırında göründükten sonra aşağıdaki komutu çalıştırın:

netsh advfirewall firewall set rule group="File and Printer Sharing" new enable=yes

Komut başarıyla uygulandıktan sonra Exit-PSSession komutunu çalıştırıp PowerShell oturumundan çıkın ve yukarıdaki net use komutunu tekrar çalıştırın. Eğer başarılı olursanız da aşağıdaki komutları da çalıştırarak "odjblob" dosyasını Nano Server sunucusuna kopyalayın.

md z:\Temp
copy odjblob z:\Temp

Windows Powershell komut satırını Admin modunda çalıştırın ve aşağıdaki komutları kullanarak Nano Server sunucusuna PowerShell Remoting ile bağlanın:

$ip = "<ip address of Nano Server>"
Enter-PSSession -ComputerName $ip -Credential $ip\Administrator

Administrator hesabının şifresini girdikten sonra Nano Server sunucusuna uzaktan PowerShell oturumu açmış olacaksınız. Nano Server sunucu adı PowerShell komut satırında göründükten sonra aşağıdaki komutu çalıştırın:

 djoin /requestodj /loadfile c:\Temp\odjblob /windowspath c:\windows /localos

Nano Server sunucusunu aşağıdaki komut ile yeniden başlatın ve PowerShell oturumundan çıkın:

shutdown /r /t 5
Exit-PSSession

Sunucumuz yeniden başladıktan sonra domaine üye olduktan sonra active directory içerisinde bilgisayar hesabı oluşmuş olacak.

Bilgisayar hesabı özelliklerinden işletim sistemi bilgilerini de kontrol ediyoruz:

Gördüğünüz gibi kod adı “Tuva” olan Nano Server, Windows Server TP2 ismi ile 10.0 versiyonu 10074 build numarası ile geliyor.

DNS sistemine NanoServer01 ismiyle dinamik kaydın gerçekleştiğini kontrol ediyoruz:

Bilgisayar hesabı üzerinde sağ tuş Manage ile Computer Management konsoluna uzaktan bağlanabilirsiniz:

Şimdi de Nano Server sunucumuzu Server Manager konsoluna ekleyip uzaktan yönetimi gerçekleştirelim:

Server Manager konsolunda Manage menüsünden Add Servers ile aşağıdaki gibi Nano Server sunucumuzu ekliyoruz.

All Server kategorisi altına Nano Server sunucumuz geldi.

Gelen sağ tuş menüsünden listelenen seçenekleri örneğin; Windows PowerShell kullanarak Nano Server üzerine bağlantı gerçekleştirilebilir.

Windows Nano Sunucusunu Tek Adımda Domaine Üye Yapmak

Yukarıda unattend.xml dosyasının varsayılan durumda Windows Nano Server sunucusunu domaine üye yapmadığını belirtmiştik. Aşağıda domaine üye mevcut bir Windows Server Technical Preview sunucusundan üretilmiş örnek bir data blob dosyasını görmektesiniz. Bu blob içerisinde bilgisayar adını da içermektedir. Dosyanın diğer bölümleri Administrator şifresi ve organizasyonel bilgileri içermektedir.

Öncelikle domaine üye olan bir Windows Server Technical Preview sunucusundan aşağıdaki komut çalıştırılır:

djoin.exe /provision /domain <domain-name> /machine <machine-name> /savefile .\odjblob

“odjblob” isimli dosya açılır (Notepad vb. uygulamalarda) ve içerik kopyalanır ve bu içerik unattend.xml dosyası içerisindeki <AccountData> bölümüne yapıştırılır.

Not : “odjblob” dosya içeriğini unattend.xml dosyasına yapıştırdıktan sonra sonundaki boşlukları sildiğinizden emin olun.

Bu unattend.xml dosyası  C:\NanoServerVHD klasörü altına kopyalanır. Ve aşağıdaki komutlar çalıştırılarak VHD dosyası mount edilip "offlineServicing" bölümündeki ayarlar uygulanır:

dism\dism /Mount-Image /ImageFile:.\NanoServer.vhd /Index:1 /MountDir:.\mountdir

dism\dism /image:.\mountdir /Apply-Unattend:.\unattend.xml

Kurulum esnasındaki Windows sistem dosyaları tarafından kullanılmak üzere "Panther" isimli bir klasör oluşturulur ve unattend.xml dosyası bu klasör içerisine kopyalanır.  Daha sonra aşağıdaki komutlarla VHD unmount edilir:

md .\mountdir\windows\panther

copy .\unattend.xml .\mountdir\windows\panther

dism\dism /Unmount-Image /MountDir:.\mountdir /Commit

Hazırlanan VHD'den Nano Server sunucusunun ilk açılışında diğer ayarlar da otomatik olarak uygulanır.

Windows Nano Server'da Dual-Boot Yapılandırması ve Acil Durum Araçları

Dual-boot aynı sunucu üzerine birden fazla işletim sisteminin kurulması ve açılışta istenilen işletim sisteminden açarak çalışmayı sağlayan bir kurulum modelidir. İhtiyaç durumuna göre hangi sistemden çalışmak istiyorsak o sistemden açarak kullanabilirsiniz. Windows NT tabanlı işletim sistemlerinden günümüze kadar sunucu-tabanlı tüm işletim sistemleri tarafından desteklenen bir özelliktir. Benzer şekilde Windows Nano Server için de dual boot kurulum desteklenmektedir. Windows Nano Server sürümünü başka bir Nano Server kurulumu ya da diğer işletim sistemi sürümleri ile dual-boot yapacak şekilde aşağıdaki adımları gerçekleştirerek yapılandırabilirsiniz:

Windows Nano Server üzerinde Windows Command komut satırını Admin modunda çalıştırın ve aşağıdaki komutu çalıştırarak açılış için yeni bir girdi oluşturun:

bcdedit /copy {current} /d “Nano Server”

Tekrar bcdedit yazın  ve  boot loader girdisi içerisine yeni eklenen ID alanını süslü parantezler dahil kopyalayın.

Aşağıdaki komutları  kopyalanan GUID değeri ile {GUID} içerisindekini değiştirerek çalıştırın:

bcdedit /set {GUID} device vhd=[c:]\NanoServer\NanoServer.vhd

bcdedit /set {GUID} osdevice vhd=[c:]\NanoServer\NanoServer.vhd

bcdedit /set {GUID} path \windows\system32\boot\winload.exe

Eğer Emergency Management Services (EMS) ve Hypervisor daha sonra kullanacaksanız aşağıdaki komutlarla bunları etkinleştirebilirsiniz:

bcdedit /ems {GUID} ON

bcdedit /emssettings EMSPORT:1 EMSBAUDRATE:115200

bcdedit /set HypervisorLaunchType Auto

Not : Bilgisayarınız için doğru port numarası kullandığınızdan emin olun.

Windows Server Nano İlk Açılışta Çalışacak Komutları Yapılandırmak

Windows Server Nano kurulumu tamamlandıktan sonra ve ilk oturum açılmadan önce Windows %WINDIR%\Setup\Scripts\ dizininde bir arama gerçekleştirilerek SetupComplete.cmd isminde bir dosya olup olmadığını kontrol eder. Eğer bulursa da script'i çalıştırır. Eğer bulamazsa da kurulum normal olarak devam eder. Windows bu aşamadaki aksiyonları ve gerçekleşen adımları Setupact.log dosyasına kaydeder.

Bu özellik bazı aksiyonlar için faydalıdır. Örneğin; ilk açılış sonrasında IP bilgilerini görüntülemek için "SetupComplete.cmd" dosyasını kullanabileceğiniz gibi, Nano Server imajına da sabit bir ip atamak için de kullanılabilir.

SetupComplete.cmd İle IP Bilgisini Görüntülemek

Notepad uygulaması ile "ipconfig" komutunu içeren SetupComplete.cmd isimli bir dosya oluşturun ve bunu NanoServer klasörüne kaydedin.

Aşağıdaki komutları çalıştırın:

dism\dism /Mount-Image /ImageFile:.\NanoServer.vhd /Index:1 /MountDir:.\mountdir
md .\mountdir\Windows\Setup
md .\mountdir\Windows\Setup\Scripts
copy .\SetupComplete.cmd .\mountdir\Windows\Setup\Scripts
dism\dism /Unmount-Image /MountDir:.\mountdir /Commit

SetupComplete.cmd dosyasını kullanarak sabit ip atamak için SetupComplete.cmd isimli dosyayı düzenleme modunda açın ya da yeni bir dosya açın ve aşağıdaki komutu içerisine ekleyin:

powershell.exe -command "Import-Module C:\windows\system32\windowspowershell\v1.0\Modules\Microsoft.PowerShell.Utility\Microsoft.PowerShell.Utility.psd1; Import-Module C:\windows\system32\WindowsPowerShell\v1.0\Modules\NetAdapter\NetAdapter.psd1; $ifa = (Get-NetAdapter -Name Ethernet).ifalias; netsh interface ip set address $ifa static 192.168.1.203"

Not: Yukarıdaki komutta ağ arabirimlerinden ismi Ethernet olan tanımlandı. (-Name Ethernet)

Uzaktan Windows Nano Server Yönetimi

Windows Nano Server %100 oranında uzaktan yönetilen bir işletim sistemi. Yerel bilgisayara oturum açma ya da uzak masaüstü ile (RDP) oturum açma hiçbir şekilde desteklenmemektedir. Bu kısıtlamaların yanında uzaktan çeşitli çözümlerle yönetimi gerçekleştirmek mümkündür. Bu seçenekler:

Windows PowerShell

Windows Management Instrumentation (WMI)

Windows Remote Management

Emergency Management Services (EMS)

Herhangi bir uzaktan yönetim aracını kullanabilmek için Nano Server'ın ip adresini biliyor olmamız gerekiyor. Nano Server ip adresini elde etmek için kullanılan yöntemler:

Nano Server sunucusunun ilk açılışına bir tane otomatik çalışacak BAT dosyası konumlandırıp içerisine de ipconfig komutu eklenmesi sonrasında ilk açılışta komut satırı penceresinde ip bilgisi görüntülenecektir. Görüntülenen ip adresinin bir yere not edilmesi gerekir.

Sunucuya bir seri kablo bağlantısı ile bağlanıp EMS aracı kullanılabilir. Yapılandırma esnasında Nano Server sunucusuna atanan bilgisayar adı kullanılarak ping vb. yöntemlerle öğrenilebilir. Örneğin; ping NanoServer-PC /4.

Windows Nano Server İle EMS Kullanımı

Emergency Management Services (EMS) Windows Server 2003 işletim sisteminden bu yana kullanılan ve sunuculara yerel ağ bağlantısı ya da internet gibi standart ağ bağlantı yöntemleri ile bağlanılamaması durumunda sunuculara yönetim ya da sistem kurtarma amaçlı bağlanmak için kullanılan bir özelliktir. EMS ile doğrudan klavye, ekran ya da fare bağlı olmayan sunucular da yapılandırılabildiği için yerden, enerjiden ve donanım maliyetlerinde de tasarruf sağlamış olacaksınız.Bir başka ifade ile EMS, sunucunuzu uzaktan standart yönetim araçları ile yönetebilecek duruma getirmeyi sağlayan acil kurtarma aracınızdır.

EMS ile gerçekleştirilen aksiyonlara örnek olarak:

Cevap alınamayan sunucuları kurtarmak

Sunucuları kapatma ve açma

EMS aynı zamanda yerden, enerjiden ve donanım maliyetlerinde de tasarruf sağlayarak EMS kullanımı için yönetim bilgisayarı ile Nano Server bilgisayarını birbirine seri bir kablo ile bağlamanız gerekir. Sonrasında da PuTTY.exe gibi non-Microsoft SSH/Telnet gibi bir uzak bağlantı uygulamasına sahip olmanız gerekir.

Windows Nano Server sunucusunu VHD'den açın, ve yönetim sunucusundan Admin yetkisi ile komut satırını açın ve PuTTY.exe çalıştırın. Hız değerini Nano Server yapılandırırkenki değere ayarlayın, bağlantı tipi olarak seri bağlantıyı seçin ve Serial line için PuTTY.exe tarafından kullanılacak uygun değeri girin.

PowerShell Remoting İle Windows Nano Server Yönetimi

Windows PowerShell Remoting özelliği ile Windows Nano Server yönetimi için öncelikle aşağıdakileri sağlamanız gerekir:

Nano Server'ın ip adresini yönetim bilgisayarınızın Trusted Host listesine eklenmesi

Nano Server'ın administrators grubuna bağlantıda kullanılan kullanıcı hesabının üye yapılması

CredSSP aktifleştirilmesi

Nano Server'ın ip adresini yönetim bilgisayarınızın Trusted Host listesine eklenmesi için admin yetkisi ile açılan PowerShell komut satırında aşağıdaki komutu çalıştırın:

Set-Item WSMan:\localhost\Client\TrustedHosts "<IP address of Nano Server>"

Nano Server sunucusuna uzaktan PowerShell oturumu açmak için yine admin yetkisi ile açılan PowerShell komut satırında aşağıdaki komutları çalıştırın:

$ip = “<IP address of Nano Server>”
$user = “$ip\Administrator”
Enter-PSSession -ComputerName $ip -Credential $user

Bu işlem sonrasında Nano Server üzerinde Windows PowerShell komutları kullanılarak yönetim gerçekleştirilebilir.

Not : Windows Server 2016 Technical Preview 2 sürümü ile Nano Server üzerinde normal bir Windows Server Technical Preview üzerindeki gibi tüm Windows PowerShell komutları desteklenmemektedir. Get-Command -CommandType Cmdlet komutu kullanılarak aktif komutların listesi alınabilir.

Nano Server üzerine açılan PowerShell oturumunu Exit-PSSession komutu ile sonlandırabilirsiniz.

WinRM Üzerinden Windows PowerShell CIM Oturumu İle Windows Nano Server Yönetimi

Windows PowerShell ile Windows Remote Management (WinRM)  üzerinden WMI komutlarını çalıştırmak için CIM oturumları kullanılabilir. Windows PowerShell komut satırında aşağıdaki komutları kullanarak CIM oturumları başlatılabilir:

$ip = “<IP address of the Nano Server>”
$ip\Administrator
$cim = New-CimSession –Credential $user –ComputerName $ip

Bağlantı kurulduktan ve oturum açıldıktan sonra WMI komutları kullanılarak yönetim gerçekleştirilebilir. Örneğin:

Get-CimInstance –CimSession $cim –ClassName Win32_ComputerSystem | Format-List *
Get-CimInstance -Query "SELECT * from Win32_Process WHERE name LIKE 'p%'"

Windows Remote Management (WinRM)

Windows Remote Management (WinRM) kullanılarak uzaktan Nano Server üzerinde komutlar çalıştırılabilir. WinRM'in kullanılabilmesi için öncelikle servisin yapılandırılması ve code page ayarlanması yapılır. Bunları da yine admin yetkisi ile açılan komut satırında çalıştırıyoruz:

winrm quickconfig

winrm set winrm/config/client @{TrustedHosts="*"}

chcp 65001

Bu aşamadan sonra artık uzaktan Nano Server sunucusunda aşağıdaki örnekteki gibi komutları çalıştırabilirsiniz:

winrs –r:<IP address of Nano Server> -u:Administrator -p:<Nano Server administrator password>
ipconfig

Windows Nano Server İle Hyper-V Rolü

Windows Nano Server üzerinde Hyper-V Server rolünün kullanımı Windows Server Core sürümü ile iki istisna hariç çok yakın benzerlik göstermektedir:

Tüm yönetim uzaktan gerçekleştirilmeli ve yönetim bilgisayarı Nano Server sunucusunun işletim sistemi ile aynı versiyon ve build numarasında olmalıdır.Hyper-V Manager ya da Hyper-V PowerShell cmdlet'lerin önceki versiyonları desteklenmemektedir.

RemoteFX kullanılamaz.

Şu anki son sürümde desteklenen Hyper-V özellikleri:

Hyper-V rolünün etkinleştirilmesi

Generation 1 ve Generation 2 sanal sistemlerin oluşturulması

Sanal switch'lerin oluşturulması

Sanal sistemlerin başlatılması ve Windows sanal işletim sistemlerinin çalıştırılması

Not: Şu anki Nano Server sürümünde Hyper-V Replica desteklenmemektedir.

Sanal sunucuların canlı aktarımı (live migration) için, sanal sistemin SMB paylaşımı üzerinde oluşturulmalı ya da mevcut sanal sistemlere SMB paylaşımındaki kaynakların atanmalıdır. Kimlik doğrulama yönteminin de doğru biçimde yapılandırılması önemlidir. Bunun için de iki seçeneğimiz bulunmaktadır:

Constrained delegation:

Constrained delegation önceki sürümlerdeki gibi çalışıyor. Detaylı bilgi için aşağıdaki linkleri inceleyebilirsiniz:

Enabling Hyper-V Remote Management - Configuring Constrained Delegation For SMB and Highly Available SMB

Enabling Hyper-V Remote Management - Configuring Constrained Delegation For Non-Clustered Live Migration

CredSSP

Yukarıda PowerShell Remoting ile CredSSP kullanımından bahsetmiştik. Öncelikle Nano Server üzerinde yukarıdaki hazırlıklar yapıldıktan sonra Hyper-V Manager konsolunda “connect as another user” seçeneği ile Hyper-V Manager'ı CredSSP kullanacak şekilde yapılandırılmalıdır. Bunu kullanmış olduğunuz hesap ile aynı olsa bile yapmanız gerekir.

Hyper-V Windows PowerShell cmdlet komutları CimSession ya da Credential parametrelerinde CredSSP ile çalışacak şekilde kullanılır.

Windows Nano Server İle Failover Clustering

Windows Nano Server üzerinde Failover Clustering kullanımı Windows Server Core sürümü ile çok yakın benzerlik göstermektedir. Aşağıdaki noktalara özellikle dikkat etmek gerekir:

Tüm yönetim Failover Cluster Manager konsolu ile ya da Windows PowerShell komutları ile uzaktan yönetilmelidir.

Windows Server'da olduğu gibi cluster içerisindeki tüm Nano Server sunucuların aynı domainin üyesi olması gerekir.

Windows Server'da olduğu gibi cluster yönetimi için kullanılan domain hesabı tüm Nano Server'lar üzerinde Administrator yetkilerine sahip olmalıdır.

Tüm komutlar admin yetkili komut satırlarında çalıştırılmalıdır.

Not: Şu anki Nano Server sürümünde bazı özellikler desteklenmemektedir:

Nano Server sunucularda Cluster Validation Test desteklenmemektedir.

Failover Clustering cmdletler Windows PowerShell üzerinden yerel olarak Nano Server üzerinde çalıştırılamamaktadır.

Hyper-V ve File Server dışındaki cluster rolleri desteklenmemektedir.

Windows Server Technical Preview 2 Failover Clustering özellikleri destekleniyor.

Failover Cluster yönetimi için aşağıdaki PowerShell cmdlet'ler desteklenmektedir:

Yeni bir cluster kurulumu için:

New-Cluster -Name <clustername> -Node <comma-separated cluster node list>

Cluster yapısına yeni bir node eklemek için:

Add-ClusterNode -Name <comma-separated cluster node list> -Cluster <clustername>

Cluster yapısından bir node çıkarmak için:

Remove-ClusterNode -Name <comma-separated cluster node list> -Cluster <clustername>

Scale-Out File Server rolünü eklemek için:

Add-ClusterScaleoutFileServerRole -name <sofsname> -cluster <clustername>

ÖZETLE:

Üç bölümden oluşan bu makale serimizde de sizlerle Windows Server 2016 ile gelen yeniliklerden en önemlisi olan ve bulut altyapılarını çok daha güçlendirecek yeni Windows Server sürümü kod adı “Tuva” olan “Windows Server Nano’yu” inceledik. Windows Server Nano ile ilgili yeni gelişmeleri sizlerle paylaşmaya devam edeceğiz. Windows Server 2016 ile gelen yenilikleri incelemeye devam edeceğimiz bir başka makalemizde görüşmek dileğiyle sağlıcakla kalın.

Mesut ALADAĞ.
Microsoft MVP, MCT, P-TSP
www.cozumpark.com | www.mesutaladag.com 

Merhaba bu makalemde SAP projelerinin tamamlanmasından sonra şirket içindeki tüm bilgisayarlara kurulması gereken SAP LOGON yazılımın dağıtımından bahsedeceğim.

Bilindiği üzere SAP’ı kendi içerisinde çok geniş modül tasarım olanaklarına sahip oldukça güvenli aylarca danışmanlar tarafından tasarlanan iş planları, projeler, mevcuttaki dataların yeni sisteme uyarlanması, taşınması, yeni sunucuların alınması ve yüzbinlerce dolarlık anlaşmalar olarak sıralayabiliriz.

Ve her şey tamamlandıktan sonra sıra ağ üzerindeki tüm istemcilere SAP ara yüzünün kurulmasına geliyor.

Ortalama 1000 istemcili bir yapı olduğumuzu düşünürsek bu kurulumların ve güncellemelerin tek tek kullanıcılara yüklenmesi bize çok fazla bir iş yükü çıkartacaktır.

Böyle bir durumda çok fazla strese veya ek bir maliyete girmeden SAP Installation Server Administration ile bu iş yükünden çok basit bir şekilde kurtulabiliriz.

Başlamadan önce bazı temel gereksinimlerimiz olacak;

-        Herhangi bir Windows Server 2008-2008R2-2012-2012R2 sunucusu üzerinden uygulamayı dağıtabilirsiniz veya ayrı bir sanal sunucu oluşturabilirsiniz. (çok fazla kaynak tüketimine ihtiyaç duymamaktadır)

-        Bu sunucu mutlaka etki alanında olmalıdır.

-        Sunucu üzerinde statik IP tanımlı olmalıdır.

-        Sunucunuzun kök klasöründe deploy dosyalarının tutulacağı ve dağıtımın yapılacağı Domain User haklarınına sahip bir klasör paylaştırılmalıdır.

Bu kriterleri sağlayan bir sisteminiz hazırda var ise ilgili paketlerin indirilmesine geçebiliriz.

-        Öncelikle https://support.sap.com/software/installations.html adresine SAP Portal hesabımız ile giriş yapıp SAPGUI Setup ve SAPGUI güncelleme paketlerimizi indiriyoruz. (Ben hem kurulum hem de güncelleme işlemi gerçekleştireceğimden her ikisini de indireceğim.)

SAPGUI Setup paketini kök dizinimde açıyorum.

Açtığım bu kurulum paketinin içerisinden;

sap-gui-7.3\NW_7.0_Presentation_\PRES1\GUI\WINDOWS\WIN32\Setup yolu üzerinde bulunan NwCreateInstServer uygulamamı çalıştırarak kurulum işlemlerine başlıyorum.

Kurulum gereksinimlerinden bahsederken belirtmiş olduğum paylaştırılmış klasörümüzün yolunu burada belirtiyoruz.

Bir sonraki adımda gerekli kurulum dosyaları bu paylaşımın içerisine aktarılmaya başlıyor.

Aktarım tamamlandıktan sonra SAP Installation Server Administration kurulumu başlıyor.

Kurulum bittikten sonra SAP Installation Server Administration aracını çalıştırıyoruz.

Kurulum bir kısayol oluşturmayacağından siz el ile masaüstünüze bir kısayol oluşturabilirsiniz.

SAP Installation Server Administration Tool’un ana ekranını görüyoruz sırada temel ayarlamaların yapılması var.

Öncelikle Patch işlemini yapacağım Deploy öncesi güncel versiyonun dağıtımı bize ileride daha az iş yükü getirecektir.

Daha önce indirmiş olduğumuz güncelleme paketini ekliyorum.

Güncelleme paketini ekledikten sonra paket doğrulama işlemi başlatıyorum.

Buraya kadar uygulama ilgili paketin geçerli olduğu bilgisi bize verip güncelleme işlemini başlatıyor.

Uygulama özelliklerine baktığımızda güncelleme işleminin başarılı olduğunu görüyoruz.

Sıra Distribution Service (dağıtım için gerekli olan) servisin aktif edilmesine geliyor.

Service sekmesi üzerinden MaintainLocalSecurityHandling/ConfigureLocalSecurityHandling’ i çalıştırıyoruz.

Tüm hesap bilgilerini girip ilgili servisleri çalıştıktan sonra durum çubuğunda DistributionService’ in çalıştığını görebilirsiniz.

Artık sistemimiz dağıtım için hazır dilerseniz SAP Installation Server Administration Tool konsolunu kullanarakta belli istemcilere dağıtım yapabilirsiniz.

İsterseniz kendinize özel kurulum paketleri hazırlayıp dağıtımını yapabilirsiniz.

Sadece belirlediğimiz modüllerin kurulacağı paketimizi oluşturmuş olduk.

Sırada logon.bat ile dağıtımın gerçekleştirilmesi var.

Ana ekranımızda bulunan Companent Properties üzerinden otomatik olarak oluşturulan komutlarımızı logon.bat içerisini ekliyoruz.

Logon.bat tanımlı kullanıcılarımız giriş yaptıktan sonra kurulum sessiz modda başlayacak ve ilgili kısayollar sisteme tanımlanacaktır.

Server History sekmesinden tüm aktiviteleri takip edebilirsiniz.

İleride oluşabilecek yeni güncellemeler için Automatic Workstation Update servisini başlatabilirsiniz. Additional Update Sources sekmesinden dilerseniz local olarak güncellemenizi sisteme tanımlayabilirsiniz.

Buraya kadar kurulum, güncelleme ve dağıtım için gerekli tüm adımları yapmış bulunuyoruz.

Böylece tüm kullanıcılarımız artık SAP dünyasına ilk adımı atmış bulunuyorlar.

Azure üzerinde bulunan bir SQL veri tabanınızdaki tablo içerisinde bulunan öğeleri SharePoint ve SharePoint Online içerisine liste olarak almak, birçok ayar ve aşama gerektirmektedir. Bu yazımızda bu aşamaları sizlere tek tek açıklayarak konu hakkında detaylı bilgilendirme yapacağız.

Öncelikle genellikle yaptığımız gibi bu makalede ihtiyaç duyacağımız öğeleri ve programları listeleyelim isterseniz;

1 – Microsoft Azure Hesabı
2 – SharePoint Online Üyeliği
3 – SharePoint Designer 2013

A- Microsoft Azure Üzerinde SQL Veritabanı oluşturma

SharePoint Online içine External bir content alacağımızdan Microsoft Azure üzerine bu işlem için bir adet veritabanı oluşturuyoruz. Eğer mevcut bir veritabanı dosyanız var ise onuda kullanarak B stebinden devam edebilirsiniz. Eğer yok ise ve konu hakkında da bilgi sahibi olmak istiyorsanız aşağıdaki yönergeleri takip ederek mevcut Microsoft Azure hesabınız üzerinde 1 adet SQL veritabanı oluşturunuz.

İsterseniz oluşturma işlemine hemen başlayalım;

1 – https://portal.azure.comüzerinden giriş yapıyoruz
2 – Add New > Data & Storage > SQL Database yolu ile yeni veritabanı oluşturma işlemini başlatıyoruz.


3 – Gerekli DB adını ve planı seçerek devam ediyorurz. Eğer bu aşamada mevcut bir serverınız yok ise db oluşturulurken otomatik olarak oluşturabilir yada kendiniz manuel olarak server kısmından yeni ekleyebilirsiniz.

4 – Veritabanı dosyanız oluşturulduktan sonra aşağıdaki gibi bir ekranla karşılacaksınız.

B- Secure Store Yönetimi

1 - SharePoint online Admin arayüzüne bağlanarak sol kısımdan Secure Store menüsüne tıklayın.

Office 365 üzerinde aşağıda gösterildiği gibi iki adımda sharepoint online admin kısmına erişebilirsiniz.

Eğer bu iki adım sizin için zorlayıcı ve uzun geliyor ise https://tenant-admin.sharepoint.com adresinden de hesabınızın admin yönetimine ulaşabilirsiniz.

2 - Admin arayüzüne ulaştık ve solda SharePoint yönetimi için olan menüleri görmekteyiz buradan Secure Store Linkine tıklıyoruz

3 – Açılanm ekrandan New ( Yeni ) butonuna tıklayarak Yeni Secure Store ekleme ekranını açıyoruz.

4 – Gerekli yerleri doldurarak kayıt ediyoruz.

Buradaki alanları açıklamak gerekir ise;

Target Application ID , Benzersiz bir kimlik girilmesi gerekmektedir. Bu kimlik dışarıdan gelecek olan içerik için kullanıcının kimlğini doğrulayacak olan eşsiz ID dir. Benzersiz ID bir kere oluşturulduğunda bir daha değiştirilemez.

Display Name, SharePoint Online içerisinde görünecek olan isimdir.

Contact E-mail, dış veri kaynaklarınızı eşleştiriken yada kullanım esnasında herhangi bir sorun oluşması halinde bilgilendirilmeniz için gerekli olan e-mail adresidir.

Yukarıdaki alanlarında kısmi açıklamalarını yaptıktan sonra ekranın biraz aşağısında bulunan Ok butonu ile kayıt işlemini gerçekleştiriyoruz. Bu arada kayıt etmeden önce, user kısımlarını da doldurmanız gerektiğini tekrar hatırlatalım.

5 – Oluşturulmuş olan Secure Store’umuz artık ekranımızda yer almakta. Oluşturmuş olduğumuz bu Secure Store’un yan kısmında bulunan Check ikonuna tıklayarak menüden SET butonuna tıklıyoruz.

Kısa bir işlem sürecinin ardından ;

Bir sonraki adım olan ekran karşınıza açılacaktır. Bu ekran SQL database üzerine erişim için gerekli bilgilerin girilmesi gereken ekrandır. Ben oluşturmuş olduğum sunucu bilgilerini girerek ok butonu ile devam ediyorum. Sizde daha önceden oluşturmuş olduğınuz DB user ve pass bilgilerini bu kısma girerek devam ediniz.

Bilgileri yazarak OK butonu ile işlemi kayıt ediyoruz.

C – Yeni bir External Content Type Oluşturma.

1 – SharePoint Designer 2013 programımızı açıyoruz ve sitemize bağlanıyoruz.

Eğer bu kısımda daha önceden bağlanılmış bir siteniz bulunmamakta ise lütfen Open Site butonunu kullanarak mevcut sitenize bağlantı yapınız.

2 – Sitemiz açılır açılmaz External Content Type linkine tıklayarak menümüzü açıyoruz.

3 – Ribbon Bar da bulunan External Content Type butonuna tıklıyoruz.

4  -  Açılna ekranda “Click here to discover external data sources and define operations” linkine tıklıyoruz

5 – Açılan ekrandan Add Connection butonuna tıklayarak yeni bağlantı ekleme ekranını açıyoruz

Bu ekranda Add Connection butonuna tıklandığında bize 1 den fazla seçenek çıkacak bu seçeneklerden Azure SQL DB kullanacağımızdan SQL Server olanını seçerek OK butonuna basıyoruz ve SQL Server Connection Ekleme ekranını açıyoruz.

6 –

Bağlantımızı gerçekleştirdikten sonra ekranımıza DB içersinde bulunan tablolar gelecektir. Tabloların ve verilerin daha fazla olması nedeni ile bu aşamadan itibaren azure üzerinde bulunan canlı veritabanı dosyasını geçiş yapılmıştır.

7 – mevcut tablomuzun üzerine sağ tıklayarak açılan menüden Create All Operations seçeneği seçilir.

Hemen ardından açılan ekrana Next butonu ile devam ediyoruz.

8 – bir sonraki adımda parametre ve içeri alınmak istenen field ler seçilir. Bu kısımda Next ile devam ederseniz filtre parametrelerini seçebilirsiniz. Ben herhangi bir filtre uygulamayacağım için direk Finish butonu ile ekranı kapatıyorum ve Ctrl + S işlemi ile kayıt işlemini gerçekleştiriyorum.

Akabinde eklemiş olduğumuz operasyonlar aktif olarak aşağıdaki şekilde gözükecektir.

D – External Content Type’dan Liste Oluşturma

Bu aşamaya kadar SQL server üzerinden Content Type oluşturarak işlemlerimizi tamamladık. Artık bu content type dan Liste oluşturmaya geldi.

1 - SharePoint Designer dan oluşturmuş olduğumuz External Content Type linkine tıklayarak Ribbon menüden  Create List & form butonuna tıklıyoruz.

2 – Açılan pencereden SharePoint içerisinde kullanılacak olan liste ismini giriyoruz. Ve OK butonuna basıyoruz.

Bu işlem bir iki dakka kadar sürebilir. Beklerken progresi SharePoint designer size gösterecektir.

3- Sitemizi navigate ediyoruz ve listelerin altında yeni oluşturduğumuz listemizi seçiyoruz.

Ve artık bu aşamadan sonra listemiz içindeki datalar azure hesabımızdaki db ile bağlantılı olarak ekrana gelecektir. Bu yazımızda biraz uzun da olsa BCS ve Azure Database bağlantısı hakkında bilgiler vermeye ve detaylandırmaya çalıştım.

Umarım faydalı olmuştur.

Saygılarımla

Yazımızın birinci bölümde, ISILON Lab ortamımızın alt yapısını oluşturmuştuk. Bu bölümde ise ikinci ve üçüncü ISILON Node ‘larını sistemimize dahil edeceğiz. İlk bölümdeki sistem gereklilikleri değişmemektedir.

Simulator dosyalarının bulunmuş olduğu dizindeki Clone-2 klasörü içerisindeki xxx.clone2.vmx dosyasını Vmware Workstation yazılımı ile açıyoruz ve sonrasında çalıştırıyoruz.

Bütün disklerin formatlanacağını bildiren uyarı mesajını “ yes “ yazarak onaylıyoruz.

“Join an existing Cluster” seçeneğini seçiyoruz.

Mevcut Cluster’larımızın listesi burada yer alacaktır. Bu ekranda Cluster bilgisini göremiyorsanız muhtemel problemleriniz, ilk nodunuzun kapalı olması yada network yapılandırmanızın hatalı olmasıdır.

 Sonrasında ISILON bütün herşeyi otomatik olarak gerçekleştirecektir ve kısa bir süre sonra login ekranı ile karşılacaksınız.

Yapmış olduğumuz bu işlemlerin aynısını diğer node’larımız içinde gerçekleştiriyoruz. Biz Isılon makalelerimize 3 Node ‘tan oluşan bir ortam ile devam edeceğimizden dolayı ben üçücü node ‘un kurulumunu da gerçekleştiriyorum. Simülatör yazılımı en fazla altı Node ‘tan oluşan bir Lab ortamına destek vermektedir bundan dolayı siz dilerseniz Lab ortamınızı daha da genişletebilirsiniz.

Kurulum işlemi tamamlandığında Node ‘lar ISILON yönetim penceresinde kullanım için hazırdır ve ekstra bir şey yapmanıza ihtiyaç duymazlar.

Artık Lab ortamımız hazır hale geldiğine göre ISILON kullanımına geçebiliriz. Bir sonraki makalemizde Storage Poollarımızı oluşturup temel kullanım işlemlerini gerçekleştireceğiz.

Faydalı olması dileğimle.

Microsoft’un son nesil işletim sistemi Windows Server 2012 R2 ile active directory domain servislerinde gelen güvenlik yeniliklerinden biri de “Authentication Policy (Kimlik doğrulama politikaları) ve Authentication Policy Silo (Kimlik doğrulama politika depoları)” yapı taşlarıdır.  Bu yapı taşları sayesinde hesapların tanımlanan kuralların dışında hareket etmesi engellenmektedir. Özellikle yüksek seviyede yetkiye sahip kullanıcı hesapları ile belirlenen sistemlerde ya da aygıtlarda kullanılabilmesi ya da bu aygıtlardan erişim yapılabilmesi gibi kısıtları sağlamaktadır. Silo tanımlamaları ve Authentication Policy yönetimi active directory içerisinde Active Directory Administrative Center yönetim konsolu ve Active Directory Windows PowerShell cmdlet’ler kullanılarak gerçekleştirilmektedir.

Öncelikle Authentication Policy Silo kavramını biraz açalım. Authentication Policy Silo, sistem yöneticileri tarafından kullanıcı hesabı, bilgisayar hesabu ya da servis hesaplarının atandığı konteynır ya da kap olarak işlev gören yapılardır. Böylece belli hesapların o konteynır ya da kaba uygulanan kimlik doğrulama politika kuralları ile yönetilmeleri ve bu kurallara uygun aksiyon göstermeleri sağlanmış olacaktır. Bu sayede sistem yöneticilerinin kullanıcı hesabı seviyesinde kaynaklara erişimi izleme gereksinimi de azalmış olacak, kötü niyetli kullanıcıların hesap bilgilerini çalarak kaynaklara erişimi de önlenecektir.

Windows Server 2012 R2 ile gelen yeteneklerle özellikle Enterprise Admins, Schema Admins, Domain Admins ve Administrators gibi yüksek seviyede yetkiye sahip kullanıcı hesaplarının authentication policy silo yapı taşları ile kontrol altına alınması ve yönetilmesi hedeflenmiştir. Böylece belirttiğimiz gruplara üye kullanıcı hesaplarının domain içerisinde kullanılabilecekleri alanlar, konumlar, sistemler ya da aygıtlar sınırlandırılmıştır. Authentication Policy Silo yapı taşlarına ilave olarak bu hesapları active directory domaininiz içerisindeki “Protected Users” grubuna da üye yaparak düşük seviyeli kimlik doğrulama protokolleri ve kriptolama algoritmalarının kullanıldığı ortamlardan erişim sağlanmamasını da garanti altına alarak daha güvenli bir ortam oluşturabilirsiniz. “Protected Users” grubunu ayrı bir makalede detaylarıyla ele alıyor olacağız.

Bir diğer bakış açısı ile domain seviyesinde uygulanan Default Domain Policy ayarlarından gelen 10 saat kullanım süresi olan TGT ya da Protected Users grubuna üye olduktan sonra 4 saat kullanım süresi olan TGT sizin ihtiyaçlarınızı karşılamıyorsa Authentication Policy size daha özel TGT ticket kullanım süreleri belirlemenize olanak sağlamaktadır.

Protected Users grubuna üye yapılması önerilmeyen yönetilen servis hesabı ya da  bilgisayar hesapları için korumayı etkinleştirmek istiyorsanız Authentication Policy yapıları bu ihtiyacınızı karşılayacaktır.

Authentication Policy ve Silo yapıları ile yüksek değere sahip hesapların güvenlik ve yönetim anlamında sadece yüksek değere sahip sistemler ya da aygıtlar üzerinden erişimine izin vermiş olacaksınız. Örnek olarak oluşturacağınız, “Tam Yetkili Hesaplar Silo” yapı taşı ile Enterprise, Schema ve Domain Admins hesaplarını kontrol altına alabiliriz. Ve bu siloya uygulanacak kimlik doğrulama politikalarında da domain controller sunucuları ve domain administrator konsolları haricindeki erişim noktalarından şifre (password) ya da smart kart tabanlı kimlik doğrulama yöntemleri ile erişimi kapatabilirsiniz.

Authentication Policy Silo içerisinde hangi hesapların kısıtlanacağı ve bu silonun üyelerine uygulanacak kimlik doğrulama kuralları tanımlanır. Silolar organizasyon yapınızın ihtiyaçlarına göre tanımlanır ve oluşturulurlar. Aşağıdaki tabloda active directory schema içerisinde kullanıcılar, bilgisayarlar ve servisler için tanımlanmış silo listesini görmektesiniz:

Kimlik Doğrulama Politikaları (Authentication Policy):

Authentication Policy nesneleri Kerberos protokolü tarafından sağlanan ticket için (TGT – Ticket Granting Ticket) yaşam ömrü özellikleri ve hesap tipleri için erişim kontrol şartlarını tanımlamak için kullanılır. Authentication Policy ile yapılan kontroller:

Hesaba ait ticket için (TGT) yaşam ömrü yenilenemez olarak ayarlanabilir.

Aygıta oturum açmak için kriter olarak password ya da sertifika kriteri konulabilir.

Kullanıcı ve aygıtların servislere erişimi için kimlik doğrulama sürecine ait belli gereksinim kriterleri uygulanabilir.

Authentication Policy tanımlamalarında kullanılan hesap tipleri:

Kullanıcı Hesapları

Servis Hesapları

Bilgisayar Hesapları

Kullanıcı Hesapları : Koruma altına alınacak yüksek yetki seviyesine sahip kullanıcı hesaplarının mutlaka Protected Users grubuna üye yapılması önerilir. Böylece NTLM gibi zayıf kimlik doğrulama kullanımları kabul edilmeyecektir. Authentication Policy ile kullanıcılara atanan TGT ticket’ın kullanım süresi daha düşük değerlere ayarlanabilir, sadece belli aygıtlardan oturum açabilme ya da erişim yapabilmeye zorlanabilir. Bu temel senaryoların dışında özellikle kimlik doğrulama süreci için karmaşık kriterler de etkinleştirilebilir.

Servis Hesapları : Koruma altına alınacak yönetilen servis hesapları bu kategoriye girmektedir. Yönetilen servis hesapları ile ilgili olarak aşağıdaki makalelerden de detaylı bilgi alabilirsiniz:

Windows Server 2012 R2 İle Stand-Alone Yönetilen Servis Hesapları

Windows Server 2012 R2 ile Group Managed Service Accounts-1

Windows Server 2012 R2 ile Group Managed Service Accounts-2

Authentication Policy yapılarında kullanılan servis hesapları : stand-alone servis hesapları (MSA), group managed servis hesapları (Gmsa) ve bu iki tip servis hesabından türemiş özel hesaplar. Politikalarla bir aygıtın erişim kontrol şartları belirlenerek yönetilen servis hesabı bilgilerinin kullanımı sadece spesifik aygıtlarla sınırlandırılabilir. Servis hesaplarının kesinlikle Protected Users grubuna üye yapılması önerilmez, çünkü tüm gelen kimlik doğrulama istekleri başarısızlıkla sonuçlanacaktır.

Bilgsayar Hesapları : Koruma altına alınacak bilgisayar hesapları ya da bilgisayar hesabı nesnesinden türetilen özel hesap tipleri bu kapsama girer.  Politikalarla erişim kontrol şartları belirlenerek, kullanıcının kimlik doğrulamasına kullanıcı ya da aygıtın özellikleri baz alınarak sınırlılıklar getirilebilir. Bilgisayar hesaplarının da kesinlikle Protected Users grubuna üye yapılması önerilmez, çünkü tüm gelen kimlik doğrulama istekleri başarısızlıkla sonuçlanacaktır. Varsayılan olarak NTLM kimlik doğrulama istekleri reddedilir. Diğer yandan bilgisayar hesapları için TGT ticket yaşam ömrü ya da geçerlilik süresi yapılandırılamaz.

ÖNEMLİ NOT: Authentication Policy sadece belli hesaplara uygulanacaksa bu durumda Silo kullanmadan doğrudan hesaba ilişkilendirilerek de etkinleştirilebilir.

Ortam Gereksinimleri:

Active Directory domain yapısı içerisindeki tüm domain controller sunucular Windows Server 2012 R2 versiyonunda çalışmalıdır.

Active Directory domain fonksiyonel seviyesi Windows Server 2012 R2 seviyesinde olmalıdır.

NOT: Active Directory forest fonksiyonel seviyesi için bir gereksinim zorunluluğu yoktur.

Domain Controller sunucular için Dynamic Access Control (DAC) desteği yapılandırılmalı ve ilgili ayarlar Domain Controllers OU’suna GPO olarak uygulanmalıdır. Bu amaçla aşağıdaki GPO ayarını Default Domain Controllers Policy içerisinden Computer ConfigurationàAdministrative TemplatesàSystemàKDC altından “KDC support for claims, compound authentication, and Kerberos armoring” ayarını etkinleştiriyoruz.

Yukarıdaki adımla Domain Controller sunucular için Dynamic Access Control(DAC) desteğini etkinleştirdikten sonra, domaine üye Windows 8, Windows 8.1, Windows Server 2012 ve Windows Server 2012 R2 sistemler için de Dynamic Access Control (DAC) desteği için Kerberos claim (device claim) yapılandırmasının da yine uygun GPO üzerinden aktifleştirilmesi gerekir. Bunun için de ben Default Domain Policy GPO’su içerisinden Computer ConfigurationàAdministrative TemplatesàSystemàKerberos altından “Kerberos client support for claims, compound authentication, and Kerberos armoring” ayarını etkinleştiriyorum. Siz bu ayarı sadece uygulamak istediğiniz Windows 8, Windows 8.1, Windows Server 2012 ve Windows Server 2012 R2 bilgisayar hesaplarının bulunduğu OU’ya da bağlayabilirsiniz.

Authentication Policy Yapılandırmaları:

Bu başlık altında da adım adım authentication policy ve authentication policy silo yapılarının oluşturulmasını ve uygulanmasını gerçekleştirerek admin yetkisine sahip hesapların sadece belli bilgisayardan sistemlere erişime zorlayarak kısıtlamış olacağız.

Authentication Policy ve Silo yapılandırmaları Active Directory Administrative Center (ADAC) yönetim konsolu üzerinden gerçekleştirilir.

Bunun için ilgili konsolu dsac.exe aracı ile açıyoruz.

ÖNEMLİ NOT : Authentication Policy ve Silo yapılandırmaları Active Directory Users and Computers konsolundan (dsa.msc) yönetilemez.

ADAC konsolunu açtıktan sonra ilk olarak authentication policy silo ve authentication policy oluşturuyoruz. Bu sayede hedeflediğimiz kapsamı tanımlıyor olacağız. Varsayılan durumda herhangi bir silo ya da policy tanımı bulunmamaktadır.

İlk olarak Authentication Policy tanımını yapıyoruz. Bunun için Authentication Policies altında iken Tasks panosundan ya da sağ tuş kısayolu ile Newà Authentication Polices tıklıyoruz.

Karşımıza Create Authentication Policy form ekranı gelecektir.

Burada Display Name kutusunu authentication policy için bir isim tanımlaması giriyoruz. Organizasyon isimlendirme standartlarınıza göre uygun bir görünen isim belirleyebilirsiniz.

Hemen sol bölümde gelen User kategorisine tıklayarak “Specify a Tciket Granting Ticket lifetime for user accounts” seçeneği ile 45 ile 2147483647 (2³¹-1) aralığında dakika cinsinden TGT kullanım süresi belirleyebilirsiniz. Ben şu anda 120 dakikalık süre tanımlıyorum.

Bu ayardan sonra OK ile onaylıyoruz. “Admin Erisim Politikasi” isimli politikamız Authentication Policies altına geldi.

Şimdi de Authentication Policy Silo oluşturacağız. Bunun için de yine ADAC konsolu içerisinde Authentication Policy Silos altında iken Tasks panosundan ya da sağ tuş kısayolu ile Newà Authentication Policy Silo tıklıyoruz.

Yine öncelikle silo için bir görünen isim (Display Name) tanımı yapıyoruz. Bu senaryoda “Admin Silo” isimli tanımımı giriyorum. Ve Silo politikalarının uygulanmasına zorlamak için “Enforce silo policies” seçeneğini seçiyorum. Bu seçenek yerine “Only audit silo policies” seçilmesi durumunda koruma yerine sadece izleme modunda politikalar aktif olacaktır. Yine Permitted Accounts kategorisi altından admin yetkisine sahip kullanıcıların kullandığı bilgisayar hesaplarını ve admin yetkisine sahip kullanıcı hesaplarını listeye Add ile ekliyoruz.

Aynı ekranda Authentication Policy altından “Use a single policy for all principals that belong to this authentication policy silo” seçeneği seçili iken The authentication policy that applies to all accounts in this silo etiketinin yanında gelen liste kutusundan bu siloya uygulanacak authentication policy nesnesini gösteriyoruz. Aşağıdaki şekilde de görüldüğü gibi biz biraz önce oluşturduğumuz “Admin Erisim Politikasi” isimli authentication policy seçiyoruz.

OK ile onaylıyoruz. Authentication Policy Silo konsolda listelendi.

Şimdi de politikanın atanmasını gerçekleştireceğiz. Bu aşamaya kadar henüz authentication policy silo uygulanmış durumda değil. Policy Silo ataması bizim kontrolümüzde manuel olarak gerçekleştirilen bir süreçtir. Policy ataması için yine ADAC konsolu içerisinde oluşturduğumuz Admin Silo isimli Authentication Policy Silo üzerine çift tıklayarak karşımıza gelen Authentication Policy Silo form arayüzünden gerçekleştirilir. Bu ekranda Permitted Accounts altında politikayı etkinleştirmek istediğimiz hesap üzerine çift tıklayarak hesabın özelliklerine gidiyoruz.

Hesap özelliklerinde Silo sekmesine geçiyoruz. Authentication Policy Silo kategorisi altından Assign Authentication Policy Silo seçili iken bu hesabı ilişkilendirmek istediğimiz silo’yu liste kutusundan seçiyoruz.

OK ile onaylıyoruz.

Bu adımları Permitted Accounts listesinde bu politikalardan etkilenmesini istediğiniz tüm hesaplar için ayrı ayrı uygulayabilirsiniz. Bu uygulama ile aslında bu hesaplar için msDS-AssignedAuthNPolicySilo isimli özniteliği (attribute) yapılandırmış olduk.

ADAC konsolundan grafiksel arayüz ile bu atama her hesap için ayrı ayrı gerçekleştirilmesi gerekir. Toplu atamalar için Set-ADAccountAuthenticationPolicySilo isimli PowerShell cmdlet kullanılabilir.

Şimdi uyguladığımız Authentication Policy kuralının testini gerçekleştirelim.

Oturum açma sürecinden sonra KDC tarafından atanan kerberos ticket geçerlilik süresinin Authentication Policy içerisinde belirlediğimiz gibi 120 dakika yani 2 saat olarak geldiğini görüyoruz.

Öncelikle FullAdmin kullanıcısı ile Permitted Accounts listesine eklediğim Windows 8.1 işletim sisteminden oturum açmaya çalıştığımız başarıyla gerçekleştiğini, fakat policy silo kapsamı dışındaki sistemlerden ise oturum açmak istediğinizda aşağıdaki hata ile karşılaştığınızı göreceksiniz:

Windows PowerShell İle Authentication Policy Yapılandırmaları:

Authentication Policy ve Silo yönetimi için kullanılan cmdlet listesini aşağıdaki şekilde elde edebilirsiniz:

Öncelikle Domain Admins grubuna üye olan hesapları “Protected Users” grubuna da üye yaparak koruma altına alıyoruz. Bunun için aşağıdaki şekilde görülen cmdletleri sırayla çalışıtırıyoruz:

Şimdi de Authentication Policy ve Authentication Policy Silo oluşturulmasını gerçekleştiriyoruz:

Aşağıdaki adımda da AuthenticationPolicy’ye “ad://ext/AuthenticationSilo” claim ID için silo eşleştirmesi gerçekleştirerek hangi aygıtlardan işlem yapılacağını belirledik.

Aşağıdaki cmdlet komutları ile de hem Authentication Policy hem de Authentication Policy Silo nesnelerini Enforce moduna aldık:

Bu adımdan sonra test ettiğimizde 2 saatlik TGT atamasının gerçekleştiğini görmüş olacağız. Bu ve benzeri çoğu senaryoyu ihtiyacınıza göre GUI ya da PowerShell cmdletler kullanılarak etkinleştirebilirsiniz.

ÖZETLE :

Microsoft’un son nesil işletim sistemi Windows Server 2012 R2 ile active directory domain servislerinde gelen güvenlik yeniliklerinden biri de “Authentication Policy (Kimlik doğrulama politikaları) ve Authentication Policy Silo (Kimlik doğrulama politika depoları)” yapı taşlarıdır. Bu makalemizde bu yapı taşlarını nasıl kullandığımızı uygulamalı olarak inceledik. Bir sonraki makalemizde görüşmek üzere.

Microsoft’un son nesil işletim sistemi Windows Server 2012 R2 ile active directory domain servislerinde gelen güvenlik yeniliklerinden biri de “Protected Users” güvenlik grubudur. Bu grup sayesinde üye olan hesaplar için güvensiz kimlik doğrulama protokolleri, zayıf kriptolama algoritmaları ve hassas kullanıcı hesaplarına delegasyon atamaları sınırlandırılarak active directory domain ortamının güvenliği artırılmıştır. Windows Server 2012 R2 ile tanıştığımız bu grubu detaylarıyla bu makalemizde inceliyoruz.

“Protected Users” grubu kurumsal yapı içerisindeki hesap bilgilerini etkin biçimde koruma altına almak ve yönetmek için tasarlanmış özel amaçlı bir güvenlik grubudur. Özellikle domain ortamına oturum açma ile başlayan kimlik doğrulama sürecinde hesap bilgilerine sıkılaştırılmış özel bir koruma sağlar. Bu gruba üye olan hesaplar otomatik olarak koruma altına alınırlar. “Protected Users” grubuna üye olan hesap kısıtlı ya da sınırlı kullanımı olan ve varsayılan olarak proaktif biçimde güvenliği sağlanmış demektir. Normal hesaplar gibi gelişigüzel her bilgisayarda ya da ortamda kullanılamaz. Bu kısıtlardan ya da korumadan etkilenmemenin tek yolu hesabı bu gruptan çıkarmaktır.

ÖNEMLİ UYARI : Servis hesapları ve bilgisayar hesaplarını Protected Users grubuna üye yapmamalısınız. Bu grup bilgisayar üzerinde yerel koruma sağlamaz, zira şifre ve sertifika bilgisi yerel olarak her zaman ulaşılabilir bir durumdadır. Gerek servis hesaplarında gerekse de bilgisayar hesaplarında Protected Users grubuna üye yapılmaları durumunda,  kimlik doğrulama süreci “kullanıcı adı ya da şifre yanlış” şeklinde bir hata mesajı ile başarısızlıkla sonuçlanır.

Sadece domain ortamlarında mevcut olan bu global güvenlik grubu sayesinde Windows Server 2012 R2 ve Windows 8.1 işletim sistemlerinin çalıştığı bilgisayar ya da aygıtlarda kullanılan kullanıcı hesaplarına engellenemez ya da devre dışı bırakılamaz bir koruma sağlanır.

ÖNEMLİ NOT : Protected Users grubunun kullanılabilmesi için active directory schema versiyonunun Windows Server 2012 R2 seviyesi olan “versiyon 69” yükseltilmesi gereken. Ayrıca PDC Emulator rolüne sahip olan domain controller sunucusunun işletim sisteminin de Windows Server 2012 R2 versiyonunda olması zorunludur.

Protected Users grubu ile iki katmanda koruma sağlanır:

İstemci-katmanında koruma : Windows 8.1 ya da üzeri bir işletim sisteminde çalışan bir aygıttan ya da Windows Server 2012 R2 ya da üzeri bir sunucu işletim sisteminden oturum açma esnasında tetiklenir.

Domain Controller katmanında koruma : İstemci katmanında korumaya ilave olarak Windows Server 2012 R2 domain fonksiyonel seviyesinde çalışan domain controller sunucular için de domain controller seviyesinde koruma gerçekleştirir.

ÖNEMLİ NOT: Windows 8.1 istemci işletim sisteminde çalışan aygıtlardan ya da Windows Server 2012 R2 öncesi sunuculardan oturum açan kullanıcı hesapları için Protected Users grubu ile herhangi bir koruma sağlanmaz.

Protected Users grubunun karakteristik özellikleri:

Protected Users grubunun üyelerinin NTLM, Digest Authentication veya CredSSP ile kimlik doğrulama sürecinden geçmeleri desteklenmez. Bir diğer deyişle NTLM, Digest Authentication veya CredSSP bu grubun üyesi olan hesaplar için kullanılamaz. Windows 8.1 çalışan bir aygıt üzerinde şifreler önbelleklenmez, bundan dolayı bu kimlik doğrulama protokollerinden birini kullanan aygıtlar domain ortamına oturum açmak istediklerinde başarısızlıkla sonuçlanacak ve oturum açamayacaklardır.

Bu grubun üyesi olan hesaplar için Kerberos protokolü ile DES ya da RC4 gibi zayıf kriptolama tipleri kullanılamaz. Yani domain ortamınızın en azından AES kriptolama standardına göre yapılandırılması gerekir.

Bu grubun üyesi olan hesaplar için Kerberos delegasyonu da desteklenmez. Bundan dolayı Kerberos delegasyonunu kullanarak diğer sistemlere yapılan eski bağlantılar da başarısızlıkla sonuçlanacaktır.

Kerberos Ticket Granting Tickets (TGTs) için dört saat olan varsayılan yaşam süresi, Authentication Policy ve Silo kuralları ile Active Directory Administrative Center (dsac.exe) konsolu kullanılarak yapılandırılabilir. Yani dört saat sonunda bu gruba üye olan hesaplar tekrar kimlik doğrulama sürecine tabi tutulurlar.

Aşağıdaki tabloda Protected Users grubunun özelliklerini görmektesiniz:

Protected Users Grubuna İlişkin Olay Kayıtları

Protected Users grubuna ilişkin olarak olayları çözümlemek amaçlı iki adet operasyonel olay kaydı kategorisi bulunmaktadır. Bu kayıtlar Event Viewer konsolunda Applications and Services Logs\Microsoft\Windows\Microsoft \Authentication altından erişilebilir ve varsayılan durumda kapalıdır.

Protected Users Grubunun Yapılandırılması:

Protected Users grubu istemci-tarafında koruma sağlayan bir özellik olup, kullanılabilmesi için belli ortam gereksinimlerinin sağlanması gerekir:

Protected Users grubunun oluşması için Active Directory Schema versiyonunun Windows Server 2012 R2’ye genişletilerek versiyon 69 yükseltilmesi gerekir.

Protected Users grubunun diğer domain controller sunuculara çoğaltılması için PDC Emulator FSMO rolüne sahip sunucunun Windows Server 2012 R2 işletim sisteminde  çalışması gerekir.

Hesapların bulunduğu domain ortamındaki tüm domain controller sunucularına Protected Users global security grubunun çoğaltılmış olması gerekir.

Bu koruma sadece Windows 8.1 aygıtlarından ya da Windows Server 2012 R2 sunucu sistemlerinden Windows Server 2012 R2 domain controller üzerinden kimlik doğrulaması yapılan oturum açılışlarında uygulanabilir.

Domain Controller sunucular için koruma yapılabilmesi için domain fonksiyonel seviyesinin Windows Server 2012 R2 olması gerekir.

NOT : Protected Users grubu domain fonksiyonel seviyesi Windows Server 2012 R2 altında olan domain yapılarında da uygulanabilir. Böyle bir durumda öncelikle PDC Emulator rolü Windows Server 2012 R2 sunucuya atanıp, Protected Users grubunun tüm diğer domain controller sunuculara çoğaltılması tamamlandıktan sonra, istenirse domain fonksiyonel seviyesi tekrar alt versiyonlara indirgenebilir.

UYGULAMA ADIMLARI:

Protected Users grubunun işleyişini test etmek için aşağıdaki şekilde görüldüğü gibi FullAdmin isimli bir kullanıcı hesabı oluşturuyoruz.

FullAdmin kullanıcı hesabını Domain Admins, Enterprise Admins, Schema Admins gibi yüksek seviyede yetkiye sahip yönetimsel gruplara üye yapıyoruz.

Şu an için Protected Users grubuna henüz üye yapmıyoruz. FullAdmin kullanıcısı ile Windows 8.1 ile çalışan bir bilgisayardan domain ortamına oturum açıyoruz.

Oturum açan kullanıcımıza ait kullanıcı bilgileri, grup üyelikleri ve atanan hakları listeliyoruz.

Yine oturum açan FullAdmin hesabına atanan Kerberos TGT ticket içeriğini görüntülüyoruz. Gördüğünüz gibi 10 saatlik yaşam ömrü olan TGT atanmış.

Yine klist.exe aracı ile KDC (Key Distribution Center) tarafından FullAdmin hesabına atanan Kerberos ticket listesine baktığımızda da sağlıklı bir biçimde alındığını ve Domain seviyesindeki GPO tanımından gelen 10 saatlik ömrü olan ticket verildiğini kontrol ediyoruz.

İstemci bilgisayarımızın Event Viewer konsolunda Security günlükleri içerisinde oturum açma esnasındaki kimlik doğrulama protokolünün Kerberos olduğu ve yüklenen kimlik doğrulama paketinin de yine Kerberos paketi olduğunu kontrol ediyoruz. Bunun için Security kategorisinde “Filter Current Log” seçeneği ile gelen ekranda XML sekmesine geçip aşağıdaki XML sorgusunu yapıştırıyoruz. Siz isterseniz Security kategorisinde oluşan olay kayıtları içerisinden elle arayarak da ulaşabilirsiniz. Aşağıdaki sorgu işimizi biraz daha hızlandırıp sadece istediğimiz olayları görüntüleyecektir.

Aşağıdaki şekilde görüldüğü gibi Kerberos kimlik doğrulama paketine ilişkin kayıtları görüyorsunuz.

Bu aşamada hesabımız henüz Protected Users grubuna üye olmadığı için herhangi bir kısıtlama ya da sınırlandırma söz konusu değil. Normal kullandığımız kullanıcı hesabı davranışlarının aynısını gerçekleştiren bir hesap olarak işlev gösteriyor:

İstediği versiyonda çalışan işletim sistemine RDP vb. bağlantı gerçekleştirebilir.

Hem Kerberos hem de NTLM ile oturum açabilir. (Bunu tüm DC’ler üzerindeki KDC servisini kapatarak test edebilirsiniz. Kerberos servisine ulaşamayınca NTLM seviyesine düşerek kimlik doğrulamasını bununla yapacaktır.)

Protected Users grubuna üye yapıldığında kısıtlanan kriptografi algoritmaları için şu anda herhangi bir sınırlandırma bulunmamaktadır.

Şimdi Protected Users grubuna üye yapma sürecine başlayalım.

Öncelikle domain fonksiyonel seviyemizin Windows Server 2012 R2 seviyesinde olduğunu kontrol ediyoruz.

PDC Emulator FSMO rolüne sahip domain controller sunucumuz Windows Server 2012 R2 işletim sisteminde çalışıyor.

FullAdmin hesabımızı Protected Users grubuna üye yaptık.

Şimdi Windows 8.1 istemci bilgisayarımızdan tekrar oturum açıyoruz. Aşağıdaki şekilde görüldüğü gibi Kerberos ticket’ın yaşam süresi 4 saate düşmüş oldu. Bu Protected Users grubu üyeleri için varsayılan değer.

İstemci üzerindeki Security olay kayıtlarından oturum açma esnasında yüklenen paketin Negotiate seviyesine çıktığını görüyoruz. Negotiate en güçlü, güvenilir kimlik doğrulama protolünün kullanımını sağlar.

Yukarıdaki başlıklarda Protected Users grubuna üye olan kullanıcılar için Kerberos dışında NTLM kimlik doğrulama protokolü desteklenmediğini belirtmiştik. Ben demo ortamımda çalışan domain controller sunucularım üzerinde Kerberos kimlik doğrulama sürecini gerçekleştiren KDC(Key Distribution Center) servisini kapatıyorum. (Bunu tüm domain controller sunucularımda yapıyorum. Aksi halde kullanıcımız diğer domain controller’ın KDC servisinden servis almaya devam edecektir.

Bu işlem sonrası tekrar Windows 8.1 istemcimden oturum açmaya çalıştığımda aslında beklenen KDC servisinden servis alamadığı için kimlik doğrulamanın NTLM seviyesine düşerek gerçekleşmesidir. Fakat kullanıcı hesabımı Protected Users grubuna üye yaptığımdan dolayı aşağıdaki hata mesajını alarak oturum açma sürecimizin başarısızlıkla sonuçlandığını görüyorsunuz.

Kullanıcı hesabını Protected Users grubundan çıkartırsanız bu durumda NTLM kimlik doğrulaması ile oturum açabildiğini göreceksiniz. Bu durumda yine klist ile kerberos bilgilerini listelemek istediğimizde herhangi bir kerberos ticket atanmadığını görüyor olacaksınız.

Yine bu süreçle ilgili olay kaydı için de istemci üzerindeki Event Viewer konsolunda Security kategorisinde Filter Current Log seçeneği kullanılarak aşağıdaki XML sorgu ile kimlik doğrulama paketinin NTLM olduğunu kontrol edebilirsiniz.

Ağdan Erişim Testleri:

Protected Users grubuna üye kullanıcımızla ağ üzerindeki kaynaklara IP Adresini kullanarak ağ yolu tanımlaması ile (UNC Path) ya da net use komutu ile erişmek istediğimizde de aşağıda görüldüğü gibi başarısızlıkla sonuçlandığını göreceksiniz.

Bunun nedeni IP ile ağ bağlantılarına erişimde NTLM kimlik doğrulamasını kullanıyor olmasından kaynaklanıyor. NTLM’de Protected Users grubu üyeleri için kullanılamadığından erişim başarısızlıkla sonuçlanıyor. IP yerine netbios adi ya da host adını kullandığınızda ise sorunsuz bağlanıldığını göreceksiniz.

ÖZETLE :

Microsoft’un son nesil işletim sistemi Windows Server 2012 R2 ile active directory domain servislerinde gelen güvenlik yeniliklerinden biri olan  “Protected Users” güvenlik grubunu kullanarak güvensiz kimlik doğrulama protokolleri, zayıf kriptolama algoritmaları ve hassas kullanıcı hesaplarına delegasyon atamalarının sınırlandırılmasını detaylarıyla bu makalemizde inceledik. Bir başka makalemizde görüşmek dileğiyle hoşçakalın.

Ben yazılımlarımı satın aldım, artık herhangi birşey yapmama gerek yok.

Yukarıda belirtmiş olduğum cümle ile başlayan kaç tane toplantıya girdim açıkçası hatırlamıyorum. Aslında şaşırmaktan ziyade üzülür gibi oluyorum bu soru ile karşılaşınca. Cevap açık ve net – yazılımları satın almıyorsunuz fakat lisanslıyorsunuz. Size ait değil, sadece belirli kurallar çerçevesinde kullanım hakkına sahipsiniz.

Araştırmalar göre ülkemizde %64 civarındaki kullanılan yazılımlar lisanssız/illegal olarak yani her 10 üründen 7si (+/-) kaçak yollardan kullanılıyor. Avrupa ve amerikada bu oran %30 larda, Doğu ülkelerine yada afrikaya doğru gittiğimizde oran %90 lara kadar çıkmakta. Peki bunun bir suç olduğunu bile bile neden göz ardı ediyoruz? Bana göre cevap basit:Çünkü yazılım kullanım kuralları ve yazılım varlık yönetimi çok karışık. “Ama benim elimde 500 adet office ve 500 kadar kullanıcı var bunun neyini kontrol edebilirim” diye sohbete başladık müşteri ile. Ayrıntıları anlatmadan önce, projenin sonunda yaklaşık olarak 50/60.000 Euro civarı maliyet azaltması yapabildik bu firmada. Buradan konunun elinizde bulunan ofisten ibaret olmadığını anlayabiliyoruz.

Yazılım varlık yönetimi “SAM” ingilizce gibidir. Kullanmadığınız zaman sizi üzer, kısa zaman önce yaptığınız herşey boşa gider. Herşeyi bir anda yapmaktansa parçalara bölmek daha sağlıklı olur. Microsoft yazılım varlık yönetiminin parçalara bölünmesi konusunda çalıçmalara başladı. Aşşağıda bu bölümleri daha iyi görebilirsiniz.

1)      Firmamızda hangi ürünler var bu ürünleri kimler kullanıyor?

2)      Sanallaştırma konusunda gerekli lisanslama bilgisine sahipmiyim?

3)      SQL comlexity konusunda herhangi bir çalışmam oldu mu?

4)      Test olarak kullandığım ürünler gerçekten test için mi kullanılıyor?

5)      Kaç adet mobil cihaz firmamızda bulunmakta?

6)      Güvenlik konusundaki çalışmalarımız ne aşamada?

Yukarıdaki soruların cevabını bilmiyorsanız, firmanızda çoktan bazı şeyler düzgün çalışmıyor demektir. Yazılım varlık yönetimini aşşağıdaki sebeplerden dolayı mutlaka yapmalısınız (Microsofttan alıntıdır).

1)      Mali Güvenlik

2)      Daha iyi fiyat noktaları için toplu indirimler

3)      Daha fazla yükümlülük kontrolü

4)      İyi kurumsal yönetim

5)      Artan çalışan memnuniyeti

6)      Sorunsuz işlemler

7)      İsraf ve fazlalığı azaltın/ortadan kaldırın

8)      Daha iyi bir pazar konumu

9)      Daha uzun vadeli iş değeri

10)   Gelecek için esneklik.

Bana göre sebepler şu şekilde sıralanmaktadır;

1)      Mali

2)      Güvenlik ve gizlilik

3)      Bütçeleme

4)      Bulut avantajı

5)      Firma değeri

Yukarıda görüldüğü gibi hemen başlamak için birçok sebep bulunmakta.

Yukarıda vermiş olduğum örneğe geri dönmek istiyorum. Bünyesinde 500 adet office olan firma, aynı zamanda citrix üzerinde bir şekilde farklı bir version/edition office`i bütün kullanıcılar açmış, buna ek olarak şirketin bir bölümü için sadece excel 2010, 100 kadar kullanıcıya açılmış. Firmanın bakış açısına göre 1) Citrix üzerinde açılan office ile ilgili herhangi bir bilgimiz yok daha önceki görevliler açmış. 2) Excel zaten bilgisayarlar üzerinde kurulu olan office’in içinde o yüzden sorun yok 3) Citrix te office olsa dahi bilgisayarlar üzerindeki officeler citrix üzerinde bulunan office’i kapsıyor, sonuçta hepsi aynı office.

Konuya direk düşünmeden baktığımızda gayet açık ve firmanın düşüncesi doğru gibi geliyor değil mi? Malesef değil J.

1)      Citrix üzerindeki office’i görmemiş yada bilmiyor olmaları firmayı haklı çıkartmıyor.

2)      Kullanım kurallarına göre excel (yada diğer componentler) office kurulumundan ayrıldığı zaman ayrı olarak lisanslanmak zorundadır.

3)      Farklı edition olan officeler birbirlerini kapsayamazlar.

Sonuç:

·        Denetleme durumunda 50/60.000 Euro civarı sadece office için boş yere harcama (firma Türkiyede değil).

·        Firmanızın, denetimi yaptıran firma tarafından kara listeye alınması.

·        Üst yöneticilerin gözlerinin bilgi işlem bölümüne çevrilmesi.

·        Kullanılan diğer yazılımlar ile ilgili birçok sorunun gündeme gelmesi.

Yukarıda belirtmiş olduğum durum küçük fakat durumun önemini anlatmaya yeterli. Kurumunuzun boyutu ne olursa olsun yasal, risk, mali vb. birçok sebepten dolayı yazılım varlık yönetimi ciddi bir şekilde düşünülmesi gereken bir konudur.

Bu makale ile yazılım varlık yönetini konusuna giriş yapmış olduk. Yakın zamanda yazılım varlık yönetimi konusuna farklı açılardan bakarak hazırlayacağım makaleler üzerinden görüşmek üzere.

Yazılım varlık yönetimi konusunda herhangi bir desteğe ihtiyacınız olursa lütfen çekinmeden benim ile iletişime geçebilirsiniz.