Windows Server

Windows Server 2012 R2 Active Directory Yenilikleri

Windows Server 2012 R2 sunucu işletim sistemi çıkış süresi üzerinden yaklaşık bir yıl gibi bir süre geçti.  Windows Server 2012 ile başlayan bulut-tabanlı işletim sistemi geliştirme süreci Windows Server 2012 R2 ile beraber bir adım daha ileri taşınarak buluta entegre kabiliyetler artırılmış ve yönetilebilirlik alanında da bulut-tabanlı yönetim servisleri, geliştirme platformları bu yeni sürümle daha da güçlendirilmiştir. Bildiğiniz gibi Microsoft’un yeni nesil sunucu işletim sistemi ve bu sistemleri uçtan-uca yönetim platformlarını da içine alan yeni bir vizyonu var : Cloud OS yani Bulut İşletim Sistemi. Bulut işletim sistemi sunucu tarafında Windows Server 2012 R2 ve yönetim alanında da System Center 2012 R2’nin birlikte oluşturmuş olduğu yeni nesil platform. Bu yeni vizyonla, özellikle sunucu sistemlerinde sadece sanallaştırma katmanı değil bu katmanı yöneten ilave yönetim ve orkestrasyon araçları ile sanal sistemlerin bulut-mimarisinde kurulumu, yönetimi, temel işletim sistemi fonksiyonlarının izlenmesi gibi yetenekler hem Windows Server 2012 R2 hem de System Center 2012 R2 sürümleri ile sunulmaktadır. Benzer şekilde istemci tarafında da yine Windows 8.1 sürümü ile gerek mobilite, gerekse de bulut-tabanlı uygulamalara, servislere erişim, mobil cihaz arayüzlerinden bu uygulamaların kullanımına yönelik çok daha yeni ve zengin yetenekler de beraberinde geliyor. Biz de bulut işletim sisteminin yeniliklerini tüm detaylarıyla sizlerle paylaşmaya devam ediyoruz.

Windows Server 2012 R2 Active Directory İle Teknolojide Yeni Trendler makalemizde sizlerle Active Directory entegrasyonunda gelen mobilite alanındaki BYOD özelliklerini genel olarak incelemiştik. Ayrıca özellikle Windows Server 2012 active directory domain yapıları ile henüz çalışmamış olup, doğrudan Windows Server 2012 öncesi domain yapılarından Windows Server 2012 R2 domain yapısına geçiş yapan ya da yapacak arkadaşlarımın aşağıdaki makale ve video sunumunu da ayrıca incelemelerini tavsiye ederim. Zira, Windows Server 2012 öncesine göre Windows Server 2012 işletim sistemi ile başlayan süreçte gelen yeni özellikler Windows Server 2012 R2 işletim sistemi üzerinde de geçerli.

Ø  Makale – Windows Server 2012 Active Directory Yenilikleri

Ø  Webcast – Windows Server 2012 Active Directory Yenilikleri

Biz bu makalemizde daha detaylı olarak Windows Server 2012 R2 Active Directory Servislerinde Gelen Yenilikleri inceliyoruz.

Detaylara geçmeden genel olarak maddeler halinde yeni gelen özellikleri sıralayacak olursak:

Ø  Active Directory Domain Servis Yenilikleri

o   Windows Server 2012 R2 Schema Güncellemesi

o   Windows Server 2012 R2 Forest ve Domain Fonksiyonel Seviyeleri

o   Protected Users Güvenlik Grubu

o   Authentication Policy ve Silo Yapı Taşları

o   LSASS Bellek Koruma Yeteneği

o   FRS Konusunda Son Gelişmeler

Ø  Active Directory Federasyon Servisleri Yenilikleri

o   OAuth 2.0 Desteği

o   ADFS İçin Soft Account Lockout Desteği

Ø  Active Directory Sertifika Servislerinde Gelen Yeni Özellikler

o   TPM Anahtar Doğrulama Desteği

o   BYOD Amaçlı NDES Yetenekleri

Ø  Active Directory Dijital Hak Yönetim (RMS) Yenilikleri

Ø  Active Directory DNS Yenilikleri

Active Directory Domain Servis Yenilikleri

Windows Server 2012 R2 Schema Güncellemesi

Active directory domain yapılarında, çalışmakta olduğunuz mevcut active directory yapısını bir üst versiyona yükseltmek istiyorsak öncelikle active directory schema versiyonunun güncellenmesi gerekiyor. Bu active directory dizin servisinin ilk versiyonundan bugüne kadar benzerlik gösteren bir operasyon. Bu işlem forest-seviyesinde bir defaya mahsus gerçekleştirilen ve yeni nesne sınıflarını (class), nesne özniteliklerini (attribute) ve nesneleri oluşturan bir güncellemedir.

clip_image001

Windows Server 2012 R2 ile gerçekleştirilecek schema güncellemelerine ait dosya ve scriptler ISO içerisinde support\adprep altında gelmektedir. Normal şartlarda Windows Server 2012 R2 öncesi mevcut bir domaine Windows Server 2012 R2 additional domain controller kurulumu esnasında öncelikle buradaki dosyalar kullanılarak schema güncellemesi yapılır ve daha sonra da o sunucu üzerinde active directory domain servis yapılandırmasına devam edilir. Eğer amaç active directory yapılandırması yapmadan sadece active directory schema güncellemesi yapmaksa bu durumda yine support\adprep klasörü içerisindeki adprep.exe aracı ile eski versiyonlarda olduğu gibi adprep.exe /forestprep , adprep.exe /domainprep /gpprep, adprep.exe /rodcprep komutları uygulanabilir. Burada eskiden farklı olarak adprep aracının sadece 64-bit versiyonunun gelmesidir, artık 32-bit versiyon gelmiyor. Windows Server 2012 R2 ile adprep ile schema güncellemesi için forest içerisindeki tüm domain controller sunucuların Windows Server 2003 ve üzeri versiyonda olmaları gerekir. Bugüne kadarki active directory schema versiyonları:

Ø  Windows 2000 Active Directory (Versiyon 13)

Ø  Windows 2003 Active Directory (Versiyon 30)

Ø  Windows 2003 R2 Active Directory (Versiyon 31)

Ø  Windows 2008 Active Directory (Versiyon 44)

Ø  Windows 2008 R2 Active Directory (Versiyon 47)

Ø  Windows 2012 Active Directory (Versiyon 56)

Ø  Windows 2012 R2 Active Directory (Versiyon 69)

clip_image002

Buradaki versiyon numaraları her işletim sistemi sürümünde gelen dosya güncellemesi sayısından ortaya çıkmıştır. Dolayısıyla son versiyon itibariyle toplamda 69 adet LDF dosyasını kapsamaktadır. Windows Server 2012 R2 ile active directory schema içerisinde msDS-Device isimli yeni bir nesne sınıfı geliyor. Bu sayede Windows Server 2012 R2 ile BYOD(Bring Your Own Device) amaçlı Workplace Join özelliği de kullanılabiliyor olacak.BYOD konusunda Windows Server 2012 R2 Active Directory İle Teknolojide Yeni Trendler makalemizi de inceleyebilirsiniz.

Mevcutta çalışılan schema versiyonunu görüntülemek için dsquery komutunu ya da PowerShell komutlarını da kullanabilirsiniz:

clip_image003

clip_image004

msDS-Device isimli yeni nesne sınıfı içerisindeki özniteliklerden bazıları:

Ø  msDS-IsEnabled: Aygıtın aktif/pasif edilmesi

Ø  msDS-DeviceID: Aygıtın ID kimlik bilgisi

Ø  msDS-DeviceOSType: Aygıtın işletim sistemi tipi

Ø  msDS-DeviceOSVersion: Aygıtın işletim sistemi versiyonu

Ø  msDS-DevicePhysicalIDs: Aygıtın fiziksel ID bilgisi

Ø  msDS-DeviceObjectVersion: Aygıtın schema versiyon bilgisi

Ø  msDS-RegisteredOwner: Aygıtın AD’ye kaydeden ilk kullanıcı bilgisi.

Ø  msDS-ApproximateLastLogonTimeStamp: Aygıttan son logon olma zaman bilgisi

Ø  msDS-RegisteredUsers: Aygıtı AD’ye kaydeden tüm kullanıcı listesi

Ø  msDS-IsManaged: Aygıtın şirket ortamındaki bir MDM uygulaması tarafından yönetilip yönetilmediği bilgisi

Ø  msDS-CloudIsManaged: Aygıtın bulut-tabanlı bir MDM tarafından yönetilip yönetilmediği bilgisi

Windows Server 2012 R2 ile schema içerisinde gelen ms-DS-AuthN-Policy sınıf ile merkezi kimlik doğrulama politikaları (authentication policy) yazabiliyoruz. Bu özellik sayesinde kullanıcı-bazında Kerberos ticket life-time belirlenebiliyor. Bu sayede Kerberos-tabanlı saldırılara karşı daha sıkı politikalar belirlenebiliyor, domain admin gibi yüksek yetkili hesaplara daha düşük süreli ticket kullanımları tanımlanabiliyor.

Windows Server 2012 R2 Domain ve Forest Fonksiyonel Seviyeleri

Active Directory mimarisinde domain ve forest içerisinde desteklenen domain controller işletim sistemleri ile forest ve domain yeteneklerini belirleyen iki önemli kriter vardır: forest fonksiyonel seviyesi (forest functional level – FFL) ve domain fonksiyonel seviyesi (domain functional level – DFL). Domain ve Forest Fonksiyonel seviyeleri konusunu Windows Server 2012 R2 bakış açısıyla ayrı bir makalede ele alacağız. Domain ve Forest Fonksiyonel seviyeleri çalışılan domain ya da forest yapılarının yeteneklerinin sınırlarını belirler. Örneğin, active directory domain yapınızda kullanıcı seviyesinde şifre ve hesap kilitleme politikaları amaçlı fine-grained-password-policy uygulamak isterseniz domain fonksiyonel seviyesinin Windows 2008 ya da üzerinde olması gerekir. Yine active directory içerisinde silinen nesneleri geri dönüşüm kutusundan kurtarmak amaçlı recyle-bin özelliğini kullanmak isterseniz forest seviyesinin minimum Windows Server 2008 R2 ya da üzerinde olması gerekir. Forest ya da domain seviyelerini istenilen seviyeye yükseltmek için o domain ve forest içerisindeki tüm domain controller sunucuların tamamının minimum yükseltilmek istenen versiyon seviyesinde olması gerekir. Ve domain ve forest seviyelerinin yükseltilmesi sonrasında o domaine daha alt versiyonda bir domain controller kurulumu yapılamaz.

ÖNEMLİ : Tamamen yeni kurulan bir Windows Server 2012 R2 active directory domain ve forest yapısında minimum forest ve domain seviyesi Windows Server 2008 ve üzeri seviyelerde çalışabilir. Mevcutta çalışan bir Windows 2003 domain yapısında ise forest ya da domain level Windows 2003 ve üzeri versiyonlarda olabilir.

Windows Server 2012 R2 domain seviyesi ile gelen yetenekler:

·         Authentication policy ve silo kullanımı

Windows Server 2012 R2 forest seviyesine geçiş ile Windows 2012 forest fonksiyonel seviyesinden farklı bir yetenek şu an için yükseltmeye gereksinim göstermiyor.

Protected Users Güvenlik Grubu:

Windows Server 2012 R2 ile güvenlik amaçlı yeni bir global security grup geliyor : Protected Users. Bu grup sayesinde özellikle yüksek seviyede yetkili yönetimsel hesaplar koruma altına alınabiliyor. Protected Users grubuna üye yapılan kullanıcılara ait karakteristik özellikleri maddeler halinde ele alırsak:

·         Düşük seviyeli kimlik doğrulama protokollerini (NTLM, Digest Authentication, CredSSP) kullanarak kimlik-doğrulama sürecini gerçekleştiremezler.

·         Grup üyeleri Kerberos kimlik doğrulama protokolünü kullanmaları zorunludur.

·         Kimlik doğrulama süreci öncesindeki kullanıcı bilgilerinin şifrelenmesinde DES ve RC4 gibi zayıf seviyeli şifreleme teknikleri desteklenmez.

·         Kerberos tarafından atanan ticket-granting-ticket (TGT) geçerlilik süreleri çok daha düşüktür.

·         Normal hesaplarda gerçekleştirilen cache yapısındaki bilgilerle çevrimdışı (offline) logon olabilme yeteneği bu grubun üyeleri tarafından gerçekleştirilmez.

·         Bu grubun üyesi kullanıcılar için sınırlı delegasyon (constrained delegation) amaçlı kullanılamaz.

·         Bu gruba servis hesapları ve bilgisayar hesaplarının üye yapılması önerilmez.

Protected Users grubunun kullanılabilmesi için gereksinimler:

·         Active directory schema yapısının Windows Server 2012 R2’ye yükseltilmesi

·         Domain fonksiyonel seviyesinin Windows Server 2012 R2’ye yükseltilmesi

·         PDC Emulator FSMO rolüne sahip domain controller sunucunun Windows Server 2012 R2 versiyonunda çalışıyor olması

·         Bu özelliğin kullanılacağı istemci bilgisayarların Windows 8.1, sunucu bilgisayarların da Windows Server 2012 R2’ye yükseltilmesi (bu grup sayesindeki koruma yeteneklerini sağlayan yeni kodlar bu versiyonlarda sağlanmıştır.)

Protected Users ile ilgili detaylı uygulama ve diğer bilgileri ayrı bir makalede ele alıyor olacağız.

Authentication Policy ve Silo Yapı Taşları

Authentication Policy ve Silo yapı taşları sayesinde kullanıcıların hangi bilgisayarlardan domaine logon olabilecekleri kontrol altına alınabilir. Protected Users güvenlik grubu ile entegre bir yapıda kullanılarak logon olan hesaplara erişim kontrol kuralları (access control condition) yazılarak, belli politikalara göre logon denetimi sağlanabilir.Kimlik doğrulama politikaları Kerberos Authentication Service (AS) ya da Ticket Granting Service (TGS) değişimi aşamalarında devreye girerek uygulanır. Authentication Policy ve Silo kullanımı için gereksinimler:

·         Active directory schema yapısının Windows Server 2012 R2’ye yükseltilmesi

·         Domain fonksiyonel seviyesinin Windows Server 2012 R2’ye yükseltilmesi

·         PDC Emulator FSMO rolüne sahip domain controller sunucunun Windows Server 2012 R2 versiyonunda çalışıyor olması

·         Logon olunan istemci tarafında bu koruma politikalarının uygulanabilmesi için işletim sisteminin Windows 8.1 versiyonuna yükseltilmesi

Authentication Policy ve Silo Yapı Taşları ile ilgili detaylı uygulama ve diğer bilgileri ayrı bir makalede ele alıyor olacağız.

LSASS Bellek Koruma Yeteneği

Local Security Authority Subsystem Service (LSASS), Windows işletim sistemlerinde güvenlik politikalarının uygulamasından sorumlu servistir. Windows işletim sistemi ortamına giriş yapan kullanıcının doğrulanması, şifre değişim zamanlarının kontrolü, erişim jetonlarının (access token) oluşturulması gibi faaliyetleri yerine getirir. Bu işlem süreçleri ile ilgili bilgileri de Windows Security günlük kayıtlarına yazar. Arka planda çalışan process adı, lsass.exe’dir. Bu ismi kullanan farklı zararlı yazılımlar da bilgisiyarınıza bulaşarak ciddi zararlar verebilir. Dolayısıyla Windows sistemindeki lsass.exe ile sahte olanlarını iyi ayırt etmek gerekir. Bu konuda ilk bakılacak kriter orjinal lsass.exe’nin Windows\system32 dizini altında olmasıdır.  Bu konumun dışında çalışan lsass.exe process’leri yüksek ihtimalle virus, trojan, worm gibi zararlı, bulaşıcı uygulamalardır. LSA (Local Security Authority) ise, bir sistem üzerindeki yerel güvenlik ile ilgili her türlü bilginin tutulduğu ve Local Security Policy olarak da bilinen LSASS içerisinde bulunan Windows’un korumalı altsistemidir. Policy bilgilerini tutmasının yanında isimlerle, security identifier (SID) çevrimlerini de sağlar. LSA Authentication adı verilen bir süreç ile kullanıcılar yerel bilgisayara kimlik doğrulama sürecinden geçerek logon olmaları da yine LSA ile sağlanır. LSA bellek koruma yeteneği için LSA plug-in sürücüsünün (smart-card sürücüsü ya da password filtresi) Microsoft tarafından dijital imzalı olması gerekir. Bu imzanın olabilmesi için ilgili sürücülerin Microsoft’un laboratuvarlarında test edilme ve onaylanma sürecinden (WHQL Sertifikasyon Süreci) geçmiş olması gerekir. Ayrıca yine Microsoft’un güvenlik geliştirme süreçlerinden de (SDL) geçmiş olmalıdır. Dolayısıyla kendi geliştirmiş olduğunuz ya da üçüncü parti olarak satın alınan bir şifre filtreleme uygulamasının kullanıcı logon sürecinde devreye girmesi ve fonksiyonunu icra etmesi için Microsoft’un WHQL sertifikasyon sürecinden onaylanmış olma zorunluluğu vardır.

clip_image005

Windows 8.1 ve Windows Server 2012 R2 ile yukarıda anlattığımız LSA kimlik doğrulama aşamasında devreye giren process’ler için ilave koruma kontrolleri geliyor. Bu kontroller sayesinde yetkisiz süreçler tarafından bellekteki bilginin okunması, hatta kod-enjekte edilmesi gibi istenmeyen durumlar önlenebiliyor. Bu yetenek sayesinde LSA üzerinde depolanan ve yönetilen kullanıcı erişim bilgilerine ilave güvenlik korumaları da sağlanmış oluyor. Bu koruma Windows 8.1 üzerinde uygulanabilirken, şu an için Windows RT 8.1 üzerinde yapılandırılamaz. Bu yetenek ile birlikte Secure Boot seçeneği de ortaklaşa kullanılırsa daha yüksek seviyede bir koruma da sağlanmış olacaktır.

LSASS Belek Koruması için gereksinimler:

İşletim sistemi Windows Server 2012 R2 ya da Windows 8.1 olmalıdır.

Bu özelliğin domain controller üzerinde etkinleştirilebilmesi için active directory schema versiyonunun Windows Server 2012 R2’ye yükseltilmesi ve domain controller sunucuların da Windows Server 2012 R2 versiyonuna yükseltilmesi gerekir.

LSASS Bellek Koruma Yeteneği ile ilgili detaylı uygulama ve diğer bilgileri ayrı bir makalede ele alıyor olacağız.

FRS Konusunda Son Gelişmeler

File Replication Service(FRS), Windows Server işletim sistemleri üzerinde paylaştırılmış dosyaları ve GPO(Group Policy Object) nesnelerinin çoğaltılması, dağıtımı ve replikasyonunundan sorumlu olan servistir. Windows NT zamanındaki NT LAN Manager Replikasyon servisinin yerini almıştır. Zaman içerisinde FRS’de yerini DFSR(Distributed File System Replication) servisine bırakmıştır. DFSR aynı zamanda servisi çalıştıran dosyanın isminden de çıkışla NTFRS olarak da tanımlanır. FRS ile bir dosya oluşturulması, dosyada değişiklik yapılması gibi durumlar gözlemlenerek bu değişikliğin diğer sunuculara ya da sistemlere senkronizasyonu sağlanır. Aynı dosya üzerinde farklı sunucularda yapılan değişikliklerdeki çakışmalar tarih ve saat bilgileri kullanılarak çözümlenir. Active Directory yapılarında FRS,  domain controller sunucular arasındaki SYSVOL paylaşımının replikasyonu için kullanılır. Bildiğiniz gibi SYSVOL içerisinde group policy nesneleri ve script dosyaları bulunmaktadır ve bunlar logon olan tüm kullanıcılar ve sistemler için kritik öneme sahip dosyalardır. Dolayısıyla FRS replikasyonundaki sağlamlık ve tutarlılık son derece önemlidir. Windows 2003 R2 ve Windows 2008 ile beraber DFS servisi de replikasyon servisi olarak gelmiştir. DFS’in replikasyon programlama, bant genişliği sınırlandırma gibi destekleri de vardır. DFS, Remote Differential Compression özelliği ile dosyaların tamamı yerine sadece değişikliklerin senkronizasyonunu gerçekleştirme yeteneği vardır. Günümüzde FRS de SYSVOL replikasyonu için hala kullanılmaktadır. Fakat Windows 2008 ve üzeri domain yapılarında active directory geçişleri sonrasında SYSVOL replikasyonunun da FRS’den DFSR’a taşınması gerçekleştirilmeli ve FRS servisi de durdurulmalıdır. Böylece daha performanslı, güvenilir, sağlam ve yeni teknolojide SYSVOL replikasyonu çalışmış olacaktır. Tamamen yeni bir kurulum ile yapılandırılmış Windows 2008 ve üzeri active directory domain yapılarında SYSVOL replikasyonu otomatik olarak DFSR üzerinden gerçekleştirilmektedir.

Windows Server 2012 R2 sonrasında artık FRS tamamen kalkıyor. Dolayısıyla özellikle Windows Server 2012 R2 active directory domain geçişi sonrasında FRS’den DFSR’a geçiş zorunlu hale geliyor, aksi halde bir sonraki active directory versiyonuna geçiş desteklenmeyecek.

SYSVOL replikasyonunun FRS’ten DFSR’a geçişini ayrı bir makalede adım adım uygulamalarıyla ele alıyor olacağız.

Active Directory Federasyon Servis Yenilikleri

OAuth 2.0 Desteği

Windows Server 2012 R2 ile Active Directory Federasyon Servislerinde OAuth 2.0 kimlik doğrulama framework desteği geldi.

OAuth 2.0 teknik olarak bir yetkilendirme sistemi ya da çerçevesidir. OAuth 2.0, bir mobil istemci üzerinde çalıştırılan bir uygulamanın bir kaynağa erişim isteğinde, ortamdaki “Authorization sunucusundan” aldığı token ile kaynağın bulunduğu sunucuya bağlanır. OAuth 2.0 protokolünün günlük hayattaki kullanımına en güzel örnek bir kimlik sağlayıcıdan aldığınız hesapla twitter, facebook gibi sistemlere logon olmayı örnek gösterebiliriz. Örneğin; facebook, linkedin ya da twitter hesabınızla, bu platformlara entegre uygulama ya da web platformlarına giriş. Bu tip bağlantılarda kimlik doğrulama sürecini incelerseniz oauth barındıran adresleri göreceksiniz. OAuth 2.0 aynı zamanda bulut-servisleri ve bulut-tabanlı uygulamalara özellikle mobil sistemlerden daha güvenli erişim imkanı sağlamaktadır. Kerberos’a göre daha esnek bir protokol olmasının yanında, implementasyonu daha komplekstir. Özetle OAuth 2.0 bir yetkilendirme ve kimlik doğrulama protokolüdür. OpenID Connect ise OAuth 2.0 üzerinde bulunan basit kimlik katmanıdır. OpenID Connect, kimlik sağlayıcıların ve dış partilerin OAuth 2.0 kullanarak birbiri arasındaki kimlik bilgilerinin iletişimi ve erişiminin nasıl sağlanacağını tanımlayan bir spesifikasyondur. Bu spesifikasyon sayesinde OAuth 2.0 tarafından gereksinim duyulan birçok alana varsayılan değer atanarak OAuth 2.0 implementasyonu daha da kolaylaştırılmıştır. OpenID Connect aynı zamanda farklı implementasyonlar için Oauth yapılandırmasında standardizasyonu da sağlar. Özellikle farklı üreticiler için OAuth yapılandırmalarını daha da kolay hale getirir. Geçen yıl Gartner tarafından yapılan bir araştırmada internet üzerinden perakende satış yapan sitelerin yarısından fazlasının Microsoft, Facebook, Google, Linkedin, Twitter gibi sosyal ağlardaki kimlik bilgileriyle sağlanacağı tahmin ediliyordu. Böyle bir uygulama için yetkilendirme ve kimlik yönetiminde ortak methodları sağlayan platform olarak OAuth 2.0 ve OpenID Connect öne çıkmayı başardı. Özetle, OAuth 2.0 ve OpenID Connect framework’lerini, bulut servislerinde kimlik doğrulama süreçlerini işleten, bulutun Kerberos’una benzetebiliriz.

ADFS İçin Soft Account Lockout Desteği

Active Directory ortamlarında bulunan ve dışardan ADFS-koruması üzerinde erişim sağlanan uygulamalara ya da sistemlere erişimde sistemde bulunan kullanıcı hesaplarına yapılabilecek DOS ya da brute-force şifre deneme ataklarına karşı bir koruma önlemi diyebiliriz. Dışardan yapılan yanlış şifre denemelerini ADFS üzerinden doğrudan içerdeki active directory domain servislerine aktarıp, domain politikalarında belirlenen yanlış girme sayısı dolduğunda hesabın kilitlenmesi yerine arada “soft lockout” politikasını devreye alıp, active directory domain servislerine yanlış denemeleri geçirmeyip, ADFS üzerinde bunu kontrol eden bir mekanizma kurabiliyoruz. Soft lockout politikası ADFS üzerinde PowerShell ile Set-ADFSProperties cmdlet ile etkinleştirilebilir. Bu senaryoda erişim yapılan uygulamayı Windows Server 2012 R2 ile Web Application Proxy (WAP) ile dışarıya açıyoruz. Ve soft-lockout etkinleştirmesi WAP üzerinden dışardan yapılan erişimler için geçici olarak uygulanıyor. Gerçekte içerdeki kullanıcı hesabında badPwdCount sayısını etkilemeden, herhangi bir kilitleme gerçekleştirilmiyor.

Active Directory Sertifika Servis Yenilikleri

TPM (Trusted Platform Module) Anahtar Doğrulama Desteği

TPM korumalı anahtar desteği bildiğiniz gibi Windows 8’den bu yana kullanılıyor. TPM bu kullanımda sertifikaya ait özel anahtarın korunması görevini yerine getiriyor. Windows Server 2012 R2 öncesinde sertifika otoritesinin sağladığı dijital sertifikaya ait sertifika istek özel anahtarının bir TPM tarafından korunup korunmadığını kriptografik olarak doğrulaması için bir mekanizma bulunmuyordu.

clip_image006

Windows Server 2012 R2 ile beraber sertifika sağlayacı tarafından sertifika isteğindeki özel anahtarın TPM tarafından korunup korunmadığı kontrolü yapılabiliyor ve bu doğrulama bilgisi de yayınlanan sertifikaya yansıtılıyor.

 

BYOD Amaçlı NDES Yetenekleri

Network Device Enrollment Service (NDES), Active Directory Sertifika Servislerinin bir alt rol servisi olup, kullanım amacı ortamdaki ağ cihazlarına sertifika dağıtımı ve yönetimi yapmaktır. NDES, Microsoft’un Simple Certificate Enrollment Protocol (SCEP) implementasyonudur. SCEP, Cisco Systems tarafından geliştirilen ve daha sonra IETF Standartlarına kabul edilen, aygıtlar üzerine x509 v3 sertifikaların istekte bulunma ve yüklenme problemini ortadan kaldıran bir standarttır. Microsoft kendi platformunda bunu NDES olarak getiriyor. NDES’in standart SCEP’e göre daha üstün özellikleri de bulunmaktadır. Windows Server 2012 R2 ile beraber özellikle BYOD kanalında tüm IOS ve Windows cihazlar için sertifika dağıtımı desteği geldi.

Active Directory Dijital Hak Yönetim Servisi (RMS) Yenilikleri

Windows Server 2012 R2 ile beraber Active Directory RMS Servislerinde ADFS v1 web ajan desteği de kalktı. AD RMS SDK için de 2.0 versiyonu geldi ve eski versiyon kalktı. Dolayısıyla RMS ile uygulama geliştirmek için AD RMS SDK 2.0 versiyonuna geçiş yapmanız gerekir.

DNS Yenilikleri

Zone Seviyesinde İstatistikler:

Windows Server 2012 ile beraber gelen Get-DNSServerStatistics powershell komutu ile şu başlıklarda istatistiksel bilgileri alabiliyorduk: CacheStatistics, DatabaseStatistics, DnssecStatistics, DsStatistics, ErrorStatistics, MasterStatistics, MemoryStatistics, NetBiosStatistics, PacketStatistics, PrivateStatistics, Query2Statistics, QueryStatistics, RecordStatistics, RecursionStatistics, SecondaryStatistics, SecurityStatistics, TimeoutStatistics, TimeStatistics, UpdateStatistics, ve WinsStatistics.

Windows Server 2012 R2 ile beraber zone seviyesinde ZoneQueryStatistics, ZoneTransferStatistics, ZoneUpdateStatistics hakkında da bilgiler alabiliyoruz artık.

clip_image007

DNSSEC Yenilikleri :

Windows Server 2012 R2 ile beraber zone imzalamada kullanılan anahtarların üretimi, depolanması, yenilenmesi, silinmesi ve yaşlandırılması gibi operasyonlar zone’un primary DNS sunucusundan ayrı Key Master isimli bir sunucuda gerçekleştirilecek şekilde izolasyon desteği geldi. Bu sayede artık Key Master sunucusu bu anahtarların yönetimini yaparken, diğer DNS sunucular ilgili anahtara erişerek zone’ların imzalanması vb. süreçleri yerine getirebiliyorlar.

Yeni PowerShell DNS CmdLet Komutları:

Windows Server 2012 R2 ile beraber DNS yönetimi için aşağıdaki powershell cmdlet’ler geldi:

Ø  Step-DnsServerSigningKeyRollover

Ø  Add-DnsServerTrustAnchor –Root

Ø  RootTrustAnchorsURL

Sonuç Olarak;

Bu makalemizde Windows Server 2012 R2 Active Directory ile bu yılın öne çıkan teknoloji trendlerinden olan ve hedefi insan merkezli IT vizyonunu hayata geçirmeyi amaçlayan BYOD (Bring Your Own Device) için gelen çözümleri inceledik. Önümüzdeki makalelerde Windows Server 2012 R2’de BYOD uygulamasının implementasyonunu adım adım tüm detaylarıyla ele alıyor olacağız. Bir başka makalemizde görüşmek üzere hoşçakalın.

İlgili Makaleler

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Başa dön tuşu