.

Can's Windows Server Blog

AD Federation Service

  • Bir organizasyon yada platformun sınırları ötesinde identification,authorization ve authentication sağlar.
  • İki organization ve/veya entity arasında Federation Trust Relationship’e ihtiyaç duyar.
  • Böylece kendi organizaysonumuz dışından kullanıcıların kaynaklarımızı kullanmasına izin verebiliriz.
  • Microsoft indentity federation ürünüdür ve claims-based authentication sağlar.
    • Claims-based authentication : bir kişinin klasik username ve password kullanımı dışında authenticate edilmesidir.
  • Özellikleri :
    • Web based uygulamalar için SSO
    • Multi platform interoperability
    • Uygulamalar, mobil cihazlar, web browserları gibi geniş destek.
    • 3ncü kaynak uygulamaları kabul edebilecek şekilde genişleyebilmesi
  • Başka bir organizaysonun bizim kullanıcı listemize erişmesine izin vermeden erişim sağlayabilmemizdir.

AD FS Requirements

  • TCP/IP bağlantısı
    • Clientlar HTTPS Kullanarak
      • Web application Proxy
      • Resource Federation server veya Federation Server Proxy ile
      • Account Federation Server veya Federation Server Proxy ile iletişim kurabilmelidirler.
    • Federation Server Proxyleri aynı organizasyonda ki Federation Server ile HTTPS kullanarak iletişim kurabilmelidir.
    • Federation Serverları ve internal clientlar DC’ler ile authentication için temas kurabilmedir.
  • AD DS
    • Federation Server ADDS Domaini içinde olmalıdır.
    • Web application Proxy Domain içinde olmak zorunda değildir.
  • Attribute Store
    • Genellikle AD
  • DNS
    • Clientlar aşağıda kiler için DNS resolution yapabilmelidir.
      • Tüm Federation Serverları
      • Clientın kullanmak istediği web application
    • Harici Clientlar
      • Web application Proxy isminin DNS resolutionını yapabilmelidirler ancak internal federation servera gerek yok.
    • Web Application Proxy internal Federation Server’ın adını resolve edebilmelidir.
    • Dahili ve harici DNS Zonelarının configure edilmesi
      • Eğer dahili kullanıcılar internal federation servera direk ulaşacaklarsa ve harici kullanıcılar Federation Server Proxy e ulaşacaklarsa.

AD Certificate Enrollment, Renewal and Revocation

Enrollment : Çeşitli şekillerde yapılır.

Autoenrollment : Domain içinde ki sistemlerin sertfika requestlerini, storagelarını, retrieval gibi işlemlerini otomatik yapmasıdır.

Manual Enrollment : Request sahibi doğrudan CA ile temas kuramadığında Certreq.exe veya Certificates consolu ile işlemin yapılmasıdır.

CA Web Enrollment : CA üzerinde bulunan Website üzerinde certifika isteğinin yapılmasıdır. Böylece certifikalar oluşturulur.

Enroll on behalf : Bir şahsın başkası adına istekte bulunabilmesi yetkisidir.

Autoenrollment

  • Sertifika templateinin certifikayaı alacak kullanıcılar için Allow, Enroll ve Autoenroll şeklinde ayarlanmış olması gerekir.
  • CA templatei oluşturabilecek şekilde ayarlanmalı.
  • AD DS’da autoenrollment için GPO oluşturulmalı.
    • Bu GPO doğru grup ve OU’lara linklenmeli.

Certrificate Renewal

  • User sertifikaları user veya admin tarafından güncellenebilir.
  • Bir sistem veya servise tahsis edilmiş olan sertifikalar sadece adminler(veya yetkilendirdikleri kişiler) tarafından yenilenebilir.

CA Certificate Renewal

CA Konsolunda

  • CA servisini durdur.
  • yeni bir key seti oluşturun yada mevcut olanı kullanın
  • RootCA’de kendi sertifikasını yenileyecektir.
  • SubordinateCA’ler parent CA den istekte bulunucaklardır.

Domain ismine sağ tıkla ve renew.

Revocation

Bir certifikanın iptal edilmesi ve duyurulmasıdır.

CA SNap-ininden yapılır. CRL güncellenmesi otomatik veya planlı zamanlarda yapılabilir. Paylaşım web sayfası veya ADDS üzerinde olabilir.

AD Managing Certificate Authority

  • GPO kullanılabilir.
  • Credential Roaming çoklu sistemlerdeki sertifikaların yönetilmesi
  • Autoenrollment : Sertifikaların otomatik yenilenmesi, oluşturulması.

CA Güvenliği

  • CA Objectine tahsisli izinler.
    • Read
    • Issue and Manage Certificates
    • Manage CA
    • Request Certificates

Issue ve Manage yetkisi verilmiş kişileri belirli templateler ile de kısıtlamak mümkün.

CA Yönetimi için Güvenlik Kuralları

CA Administrator: CA Konsolundan yetkilendirilir. Bu kullanıcılar CA’in tüm değerlerini ayarlayabilir ve gerekli görürlerse başka rollerde atayabilirler.
Yetkileri :
* Manage Ca
* Issue and Manage Certificates

Certificate Manager : CA Konsolunda yetkilendirilir.
Yetkileri:
* Issue and Manage Certificates

Backup Operator: İşletim sistemi yetkisidir.
Yetkileri:
* Dosya ve klasörleri backuplar
* Dosya ve klasörleri Restore eder.

Auditor : İşletim sistemi rolü, CA üzerinde ki security policyi tanımlar
Yetkileri :
* AUditing ve security loglarını yönetir.

Enrollees : İzin verilen kullanıcıların CA’i görmesine ve sertifika isteği yapmasını sağlar.
Yetkileri :
* Request Certificates (CA Objecti üzerinde tanımlı)
* Enroll (sertifika templatei üzerinde tanımlı)

Backup and Restore

CA Snap-ini içinden yapılır.

CA Backup :

  • Private Key
  • CA Certificate
  • Certificate Database
  • Certificate Database Log

CA Restore :

  • Restore edilecek Itemları seç
    • Certificate Database
    • Certificate Database Log
  • Diğer Itemler.
  • CertSVC servisini yeniden başlat.

AD Subordinate CA Installation

Yine server managerdan install ediliyor ancak role seçerken Certification Authority ve Certification Authority Web Enrollment da seçiliyor.

Bunu kurmak için Enterprise Admin olmamız gerekiyor. Kurulumdan sonra ki ayarları yaparken yine role seçerken yukarda daha önce seçtiğimiz her iki rolüde seçeceğiz.

Keyide oluşturduktan sonra kendi certificasını oluşturması için rootCA’e istek csr göndereceğiz.

bu işlem ya online (1) yada offline (2) olabilir.

Offline da “.req” tipinde bir dosya oluşturuluyor.

AD RootCA Installation

Computer Adı ve IPsini verdikten sonra server manager da role olarak ekliyoruz.

Çoğunlukla next next next diyerek geçiyoruz. Servisleri seçiyoruz.

Kurulumdan sonra ayar yapmak gerekiyor direk başlıyoruz. Zaten wizard ile kolay.

Enterprise seçiyoruz. RootCA Seçiyoruz ilk olduğu için. Key oluşturuyoruz. Hash algoritmasını seçiyoruz. diğer ayarları seçiyoruz ve sonunda configure diyoruz.

Böylece kurulum ve ayarlama kısmı bitiyor. Artık Server Manager’dan tools dan certificatre authorityi seçebiliriz.

Standalone kurulumuda hemen hemen aynı, domain e gerek yok ve standalone seçmemiz gerekiyor.

Offline RootCA

Bu tip bir RootCA’i offline a almadan önce bazı önemli bilgileri almamız gerekiyor ki subordinate RootCA’ler çalışabilsin.

  • CDP -> CRL Distribution Point. yani clientlar CRL’i ararken nereye bakacaklar.

gelen pencerede CDP lokasyonunu yazacağız. yazdıktan sonra en sona “/” koyacağız.

http://c1-dc2.c1.local/certdata/

Sonra variableda <CAName> i seçip inserte tıklıyoruz.

Sonra variableda <CRLNameSuffix> seçip inserte tıklıyoruz.

Sonra <DeltaCRLAllowed> da ekliyoruz.

Bu şekilde ekledikten sonra en sona “.crl” yazıyoruz ve

OK ile insert ettikten sonra iki seçeneği daha işaretlememiz gerekiyor.

AIA Authority Information Access

Bununla clientlar certifikaları bulabilecekler.

Yine Certifcate Authority penceresinde CA e sağ tıklayıp properties i seçiyoruz.

Sonra Location a yine aynı veriyi giriyoruz.

http://c1-dc2.c1.local/certdata/

sonra <serverdnsname> –> insert

Bu sefer ilk soldaki ilk mavi ok ile olan yere manuel olarak “_” ve sağdaki mavi ok ile gösterildiği gibi sona “.crt” ekliyoruz ve ok’e basıyoruz.

Ok ile gösterilen seçeneğide işaretledikten sonra OK diyoruz ve servisi yeniden başlatıyoruz.

Şimdi certificate revocation listi publish edebiliriz.


AD Certificate Services

AD CS SErver role ile aşağıda ki kabiliyetleri kazanırız.

  • CA olabiliriz ve bu Certificate Servislerimizin kalbi olacaktır.
  • CA Web Enrollment : bunu eklersek network ve domainimizin dışındaki kişileride enroll edebiliriz. (enroll kaydetmek gibi)
  • Online Reponder: bunu eklersek clientlar CRL (Certificate Revocation List) i sorgulayabilirler.
  • NDES : böylece router vs gibi hardwareler için certifika alabiliriz.
  • CES : Certificate Enrollment Webservice : böylece kullanıcılarımız CA’e erişebilirler.
  • CEP : CES ile CEP (Certificate Enrollment Policy Web Service) ile beraber çalışır. Böylece domain ve ntwork dışındaki Clientlar CA ile temas kurabilir.

Cross Certification Hierarchy

2 tipte yapılabilir.

  • Bizim organizasyonumuzun ROOT CA’i diğer organizasyona güvenir.
  • Bizim organizasyonumuzun ALT (Sub) CA’leri diğer organizasyonun ROOT CA’ine güvenir.

Böylece clientlar CA sorgusunu ya SubCA yada RootCa ile yapabilirler.

CA hiyerarşisi oluştururken çeşitli opsiyonlar mevcuttur. Aslında opsiyonlar organizasyonun boyutları ile alakalıdır. Organizasyon büyüdükçe CA sayısı artıyor.

Normalde tek RootCA en çok kullanılandır.

Sonra gelen ise 2 seviyeli (two-tier) hiyerarşidir. Bir RootCa ike SubCA (issuingCA)’e yetki verir ve bunlar clientlara certifika oluşturur.

Daha sonra ise Multi-tier hiyerarşidir. RootCA altında PolicyCA’leri ve PolicyCA’lere bağlı IssuingCA’ler mevcuttur. Askeri emir komuta yapısı gibi. Her komutana bir kaç asker bağlı. En tepede tek komutan.

  • Single Root Hiyerarşisi dışında RootCA offline yapılıyor güvenlik önlemi olarak? Tam neden anlamadım

Standalone CA

  • StandaloneCA Domaine katılmaz.
  • Kullanıcılar istedikleri sertifika tipini ve identifiying bilgilerini sağlamak zorundadırlar.
  • Templateleri desteklemez.
  • Tüm sertifika istekleri admin onaylayanakadar pendingdir.

Enterprise CA

  • AD DS ihtiyacı vardır.
  • AD DS’te cetificate Stores a ihtiyacı vardır.
  • GPO ile TrustedRoot CA storeına sertifika gönderebilir.
  • Kullanıcı sertifikalarını ve CRL’leri AD DS’de publish edebilir.
  • Sertifikaları template göre oluşturabilir.
  • Sertifika oluşturmak için autoenrollment yapabilir.

Root CA oluşturma

  • Oluşturulacak ilk CA’dir.
    • Standalone
    • Enterprise olabilir.
  • Coğu tek CA aynı zamanda EnterpriseRootCA’dir.
  • Domain ve Computername verildikten sonra değiştirilemez.
  • Private Key Cryptographic Service Provider (CSP) ile RSA defaulttur.
  • Genellikle Key 2048 defulttur ancak 4096 daha güvenlidir.
  • Default hash algoritması SHA-256’dır. Serfikaların imzalanması için kullanılır.

RootCa olarak

  • bir isim ve Configuration optionlarına
  • Certificate DB ve log ları için lokasyona
  • Root Certifikate için geçerlilik süresine karar vermemiz gerekir. (genellikle 5 Yıl)

SubordinateCA’leri ise

  • Lokasyona göre
  • Amacına göre (SMIME,RAS,EFS sertifikaları için ayrı ayrı)
  • Load-Balancing ve/veya High-Availibility için birbirinin aynısı olacak şekilde
  • Kurum içi görev yapılarına göre

Oluşturabiliriz.

AD GPO Preferences ve Item-Level Targetting

Preferences

  • Preferences enforce edilmez, kullanıcı değiştirebilir.
  • GPO ile aynı refresh cycle ile update olur ama 1 defalık da yapabiliriz.

GPO Prefenrences ile bazı ayarları yeni oluşturabiliriz, silebiliriz, yeniden yapabiliriz.

Item-Level Targetting

  • Adminler Preferences in etkili olması için gerekli şartları listeleyebilirler.
  • 27 farklı kategori ile sistemler ve kullanıcılar hedeflenebilir böylece hassas ayar yapılabilir.
  • AND/OR ve boolean mantıkları çalışmaktadır.
  • GPO background güncellemeleri ile güncellenirler.

Peki nerede kullanırız.

  • Örneğin bir Drive mapping in belirli bir AD grubuna veya IP adres aralığına engellenmesinde.
  • Enerji ayarlarında
  • Printer kurulumlarında
  • Shortcut oluşturmada.

GPO editlerken hem kullanıcı hemde bilgisayarlarda Preferences mevcuttur.

Örnek drivemapping

Drive Maps -sag klick->new -> Location’ı manual yazıyorum sonra Drive letter seçip –> common a tıklıyorum.

Ve yeni gelen listede kategoriler vs ayarlar ile item-level targetting e başlıyorum.

biraz oynamak gerekiyor. Burda bu şart sağlanıyor eğer

  • Kullanıcı “mmuster” ise VE bağlandığı bilgisayarın C sinde 80 GB dan fazla boş alan varsa VEYA Bilgisayar C1-DC2 veya domain C1 değilse. Saçma ama şartlar ama nasıl olduğunu gösteriyor.

AD Client Settings

Folder redirection

Yeni bir GPO oluşturduk onu editliyoruz.

GPO Edit -> User Configuration -> Policies -> Windows Settings -> Folder Redirection

Buradan istediğimiz Klasör seçip sağ tıklıyoruz ve properties diyoruz.

İki seçenek var basic ve advanced. Basic seçtiğimizde herkesin aynı klasörünü aynı yere yönelmiş oluyoruz. Advanced ile ise kişi bazında ayarlama yapıyoruz.

GPO ile yazılım yükleme

GPO ile sistemlere yazılım yükleyebiliriz. bunun 4 yolu vardır.

  • Yazılımı Computer Configuration’a atarız. Sistem yeniden boot edildiğinde yazılım yüklenmiş olur.
  • Yazılımı User Configuration’a atarsak kullanıcı login olduğunda yazılım otomatik olarak yüklenir.
  • Publish yaparsak sadece User Configurationa yapabiliriz. Bu durumda kullanıcı o programın kullanıldığı bir extensionla olan bir dosyaya çift tıkladığında yazılım çalışır.
  • Add/Remove Programs kullanıllarak publish yaparsak kullanıcı oturduğu sistemde add/remove programstan yazılımı yüklemelidir.

Bu şekilde yazılım dağıtırken sadece .msi paketlerini kullanabiliriz.

Reporting yoktur. Kim yükledi, kim yüklemedi takip etmez.

Bir alternatif te “system center configuration manager” kullanmaktır.

Daha sonra .msi paketini seçiyoruz.

Script Deployment

Scripti ya Computer Configuration yada User Configurationa yapabiliriz.

AD Admin Templates

Admin templates dosyaları .adm ve .admx dir.

.adm dosyaları Windows 2000/2003 tarafından kullanılır.

  • SYSVOL ile her GPO’ya kopyalanır.
  • Ayarlaması zordur.

Çok faydalı değildir.

.admx günceldir.

  • .adml dosyası ile beraber gelir. Local dilede çalışması için
  • yeri “Windows\PolicyDefinitions” tır.
  • Ağ gibi merkezi bir yerde saklanabilir.
  • XML ile geliştirilebilir.

GPO’lar domaine SYSVOL klasörü üzerinden yayılır. Biz templateler için bir merkezi storage oluşturabiliriz.

  • önce “PolicyDefinitions” tam adıyla aşağıdaki lokasyonda bir klasör oluşturuyoruz.
    • \\FQDN\SYSVOL\FQDN\Policies
    • Ör: \\test.microsoft.com\SYSVOL\test.microsoft.com\policies
  • Sonra kaynak bilgisayardan tüm dosyaları kopyalarız (Windows\PolicyDefinitions)
  • Artık hedef sisteme ortak merkezi ( \\FQDN\SYSVOL\FQDN\Policies ) yerden kopyalıyoruz (Windows\PolicyDefinitions)

AD GPO oluşturma ve yönetme

Bir GPO’nun kimlere etkilediğini görmek için GPO’yu seçip delegation tab ına bakmamız gerekir.

Görüldüğü gibi “authenticated users” ta read var ama görülmesede “apply gpo” da var. İstersek tek tek de ekleyebiliriz. Delegation tabının altında “ADD” var oradan kişiyide ekleyebiliriz. Eklerken onlara haklarda verebiliriz. Ama bu kısıtlı olacaktır.

İstersek ekledikten sonra seçip advanced e tıklayarak daha da detaylı haklar verebiliriz.

Herhangi bir kişiyi ekleyip daha sonra özelliklerden “DENY” dersek o zaman o kişi bu GPO’dan etkilenmez.

Çok GPO olduğunda performans etkilenebilir. Bunun için computer veya user bölümlerinden kullanmadığımızı disable edebiliriz.

GPO Loopback Processing

Burada TestGPO’yu editliyoruz ve loopback özelliğini etkileyeceğiz. Yukarıda görüldüğü gibi aradığımız özelliği buluyoruz. Sonra ona çift tıklayıp ayarlıyoruz.

  • Önce Enable yapıyoruz.
  • Sonra karar veriyoruz “replace” mi “merge” mü?

Replace : Kullanıcı login olduğunda computer settings uygulanıyor ama user settings uygulanmıyor.

Merge : her ikiside uygulanıyor ama çakışmada computer settings üstün geliyor.

Kiosk veya Lab gibi bir ortamda kimin login olduğunu umursamıyorsak bunu kullanabiliriz.

Slow Link Detection :

eğer bir client 500 kb/sec dan yavaş ise çok yavaş clienttır. Bu durumda sadece önemli vew gerekli GPO’ları almasını sağlayabiliriz.

Yine yukardaki gibi GPO’yu editlerken

Computer Configuration -> Policies->Administrative Templates Policy Definition -> System-> Group Policy

içinde “Configure Group Policy Slow Link Detection” seçiyoruz.

  • önce enable ediyoruz
  • Windows 2000 den daha önceki sistemlerde etkili değilmiş
  • 500 kbps ye default olarak geliyor ama biz değiştirebiliriz.

Önemli Policyler

Slow link enable edildiğinde “Slow link Processing” on olanlar gönderilir diğerleri slow link ile bağlanan clienta gönderilmez.

GPO’lar ne zaman etkili olur ?

  • Öncelikle PDC DC GPO’ları diğer DC’lere push edecek.
  • Kullanıcı önce sing off sonra tekrar sign-in olmalı.
  • Computer Configuration bölümü editlenmiş ise Computer yeniden başlatılmalı.
  • Manual olarak da yapılabilir.
    • CMD ile
      • gpupdate /target:computer or /target:user
      • gpupdate /force /logoff /boot
      • gpupdate /force /wait:100
      • Yukarıda ki switchleri kullanabiliriz. böylece istersek kullanıcıları logoff yapabiliriz veya sistemleri reboot edebiliriz ve hatta bunları yaptırmadan önce istersek bekleyebiliriz.
    • Powershell ile
      • Invoke-gpupdate

GPO’Ların Güncellenmesi

GPO’lar default olarak 90dakika +-30 dakikada ve güvenlik ayarları her 16 saatte bir güncellenecektir.

Manual olarak CMD/Powershell ile veya GPO management üzerinde OU’ya sağ tıklayıp GPO Update ile.

Bunun sağlanması ise GPO Management Editor ile

detect edilerek yapılıyor. ve 3 ile görülen rapor geliyor.

GPO Processing

GPO’lar Clientlarda işlenirler. Bunun için client-side extensions kullanılır. Bunlar GPO’yu DC’den alırlar, download edip cachelerler ve sonra ayarları işlerler.

Eğer client üzerinde hangi GPO’ların işlendiğini görmek istersek CMD’den “gpresult” yaparız.