DEV Community: Fatih Arslan Tugay

Tayfa ile Chrome Ana Sayfası Düzenleme

Fatih Arslan Tugay — Thu, 22 Sep 2022 06:06:01 +0000

Bu yazıda Tayfa politikaları ile istemciler üzerinde Chrome tarayıcısının ana sayfasını ayarlamayı göstereceğiz.

Öncelikle bu işlem için bir politika nesnesi oluşturmak gerekir. Politika nesnesi istenilen bir organizasyon içerisine gidilerek oluşturulur.

Politika nesnesini oluşturduktan sonra üzerine tıklanarak Makine tabına gidilir ve Chrome ayarlarına girilir.

Burada bulunan Chrome/Chromium Tarayıcı Ayarı bölümünde ana sayfa ayarı yapılacaktır.

Ayar Adı kısmına HomepageLocation girilerek ana sayfa ayarı yapılacağı belirtilir.
Ayar Değeri kısmına ana sayfa olarak ayarlanmak istenen adres girilir.
Ayar Tipi kısmında Metin seçilir. Ayarlar yapıldıktan sonra kaydedilerek çıkılır.

Bu aşamada politika ayarları yapılmış olup istemciler tarafından çekilmesi beklenmektedir. İstenirse istemciler üzerinde gpupdate -v komutu ile manuel olarak politika güncellemesi de yapılabilir. Politika güncellemesi yapıldıktan sonra istemci üzerinde Chrome veya Chromium tarayıcı açılarak ana sayfa politikası gözlemlenmiş olur.

Tayfa ve Miço ile Zabbix Agent Dağıtımı

Fatih Arslan Tugay — Thu, 28 Apr 2022 01:16:41 +0000

Zabbix ile istemcilerin monitoring edilmesi için istemcilerde Zabbix Agent bulunması gereklidir. Bu yazıda Zabbix Agent'in Tayfa ve Miço ile dağıtılmasını gösterilecektir.

Tayfa ile Zabbix Agent Dağıtımı

Tayfa ile Linux makinelere Zabbix Agent dağıtımı mümkündür. Politika oluşturup bu politikayı düzenleyerek dağıtımı sağlanabilir. Politikada yapılması gereken işlemler ele alınacak olursa:

Zabbix ajanının kurulumu
Ajanın konfigüre edilmesi
Firewall ayarlamaları

Öncelikle bu işlemleri gerçekleştirmek için bir politika nesnesi oluşturulur ve düzenlenmeye başlanır.

İlk olarak Paket politikalarındaki Kur bölümünden zabbix-agent paketinin yüklenmesi ayarlanır.
- Zabbix ajanının istenilen versiyonu kurulmak isteniyorsa https://repo.zabbix.com/zabbix/ adresinden istenilen deb ya da rpm paketi indirilir. Yine Paket politikalarındaki Otomatik Paket Kurulumu bölümünden Bilgisayar'dan Seç denilerek indirilen paket yüklenebilir.
Paket kurulumunun /etc/zabbix/zabbix_agentd.conf dosyasında bazı değişiklikler yapmak gereklidir. Bunlar sırası ile
- Server değişkenini Zabbix Server IP olarak ayarlamak
- ServerActive değişkenini Zabbix Server IP olarak ayarlamak
- Hostname değişkenini kurulum yapılan makinenin hostname olarak ayarlamak

Bu işlemler için politikadaki Genel Konfigürasyon Ayarları kısmında 3 adet ayar girilmesi gereklidir. Bu ayarların hepsinde

Dosya Yolu /etc/zabbix/zabbix_agentd.conf
Dosya Tipi Genel
Atama operatörü "="
Ayar grubu girilmeyecek
Servis Yeniden Başlatma seçeneği ise zabbix-agent olarak ayarlanacak.

3 ayarda ise sırası ile Server, ServerActive ve Hostname değişkenleri ayarlanmalıdır. Hostname değişkeni ise her makinenin kendi hostname değerini alması için $HOSTNAME olarak girilmelidir.

Gerekli konfigürasyonlardan sonra ise firewall ayarları yapılmalıdır. Zabbix ajanı olan makinelerde 10050 portunun açık olması gerekmektedir. Bu ayarın sağlanması için politikada Güvenlik Duvarı bölümüne giderek 10050 portuna izin verecek ayarlama yapılır.
Son olarak zabbix-agent servisinin enable hale getirilmesi gerekmektedir. Bu ayar da politikanın Servis kısmında servisin Açık ve Etkin olarak olarak ayarlanması ile sağlanabilir.

Tüm bu politika ayarlamaları yapıldıktan sonra Tayfa ajanı ile politika çeken makinelerde Zabbix ajanı kurulumu başarı ile sağlanmış olur.

Miço ile Zabbix Agent Dağıtımı

Miço ile Windows ve Linux makinelere Zabbix ajanı dağıtımı sağlanabilir.

Windows Makinelere Miço ile Zabbix Agent Dağıtımı

Windows makinelere Zabbix ajanı dağıtabilmek için MSI paketi indirilerek makinelere gönderilir ve istenilen ayarlarla kurulumu sağlanır.

Öncelikle https://www.zabbix.com/download_agents adresinden ilgili sürümün MSI paket dosyası indirilir.
Daha sonra Liman üzerinden Miço eklentisine gidilerek yeni bir görev oluşturulur. Görevde:
- Görev İsmi kısmına istenilen isim verilir.
- Bir kez çalıştır seçeneği işaretlenir.
- Koleksiyon kısmında isteğe bağlı olarak koleksiyon seçilir.
- Eklenti olarak file-transfer seçilir ve dosya kısmına indirilen MSI paketi yüklenir.
- Dosya Yolu olarak *C:\* verilir
- İşlem olarak powershell seçilir ve Çalışacak Betik kısmına aşağıdaki betik girilir. Betikteki <MSI_PAKET_ADI> ve <ZABBIX_SERVER_IP> değerleri değiştirilmelidir.
```
SET INSTALLFOLDER=C:\Program Files\zabbix-agent
msiexec /l*v log.txt /i C:\<MSI_PAKET_ADI> /qn^
 LOGTYPE=file^
 LOGFILE="%INSTALLFOLDER%\zabbix.log"^
 SERVER=<ZABBIX_SERVER_IP>^
 LISTENPORT=10050^
 SERVERACTIVE=<ZABBIX_SERVER_IP>^
 HOSTNAME=%ComputerName%^
 INSTALLFOLDER="%INSTALLFOLDER%"
```
Görev OK denilerek kaydedilir ve Windows makinelere Zabbix ajanı dağıtan Miço görevi hazırlanmış olur.

Linux Makinelere Miço ile Zabbix Agent Dağıtımı

Linux makinelere Zabbix ajanı dağıtabilmek için önce paket kurulumu sağlanır. Daha sonra ise konfigürasyonlar ayarlanır.

Paket kurulumu manuel olarak gerçekleştirilecekse öncelikle https://repo.zabbix.com/zabbix/ adresinden istenilen deb ya da rpm paketi indirilir.
Daha sonra Liman üzerinden Miço eklentisine gidilerek yeni bir görev oluşturulur. Görevde:
- Görev İsmi kısmına istenilen isim verilir.
- Bir kez çalıştır seçeneği işaretlenir.
- Koleksiyon kısmında isteğe bağlı olarak koleksiyon seçilir.
- Eklenti olarak file-transfer seçilir ve dosya kısmına indirilen deb veya rpm paketi yüklenir.
- Dosya Yolu olarak *C:\* verilir
- İşlem olarak bash seçilir ve Çalışacak Betik kısmına aşağıdaki betik girilir. Betikteki ve <ZABBIX_SERVER_IP> değerleri değiştirilmelidir. Ayrıca rpm paketi yüklenmek isteniyorsa** ilk satır sudo yum install /tmp/<PAKET_ADI> olarak değiştirilmelidir.
  - Paket kurulumu eğer depodan gerçekleştirilmek isteniyorsa ilk satırdaki /tmp/ kısmı zabbix-agent olarak değiştirilmelidir.
```
sudo apt install /tmp/<PAKET_ADI>
echo """PidFile=/run/zabbix/zabbix_agentd.pid
LogFile=/var/log/zabbix-agent/zabbix_agentd.log
LogFileSize=0
Server=<ZABBIX_SERVER_IP>
ServerActive=<ZABBIX_SERVER_IP>
Include=/etc/zabbix/zabbix_agentd.conf.d/*.conf
Hostname=$HOSTNAME""" > /etc/zabbix/zabbix_agentd.conf
sudo ufw allow 10050/tcp
sudo systemctl restart zabbix-agent
sudo systemctl enable zabbix-agent
```
Görev OK denilerek kaydedilir ve Linux makinelere Zabbix ajanı dağıtan Miço görevi hazırlanmış olur.

İster Tayfa politikası ile olsun ister Miço ajanı ile olsun tüm bu işlemlerden sonra Zabbix Server üzerinden ilgili Agent eklenerek monitoring işlemlerine başlanabilir.

Debian 10/11 Bind DNS Server Kurulumu

Fatih Arslan Tugay — Sat, 22 Jan 2022 22:06:46 +0000

Başlangıç

Bu yazımızda Debian 10/11 tabanlı Pardus 19.5 ve 21 sunucularda bind9 DNS Server kurulumunu ve ayarlamalarını göstereceğiz. Başlamadan önce değinmemiz gereken birkaç nokta var.

Yazıdaki IP ve makine adresleri tamamen sizlere konuyu kavratmak adına oluşturulmuştur. Lütfen kurulum ve kullanım boyunca kendi adreslerinizi kullanmayı ihmal etmeyiniz.
Resimlerin bazı kısımlarında üstü kapatılan bölümler kullanılan makinelerin IP bloklarını gizlemek adına kapatılmıştır. Beyaz renkle kapatılan bölümlerin büyük bir kısmını aşağıda da belirtileceği üzere 14.8.18 (reverse zone kısımlar için 18.8.14) olarak kabul edebilirsiniz.
Kurulumda kullanılan konfigürasyon dosyalarını GitHub reposunda bulabilirsiniz.

Kurulum

Öncelikle olası bir hatadan kaçınmak için sistemimizi güncelleyelim.

sudo apt update -y
sudo apt upgrade -y

Ardından ilgili paketleri yükleyerek sistemimize bind9 kurulumu yapalım.

sudo apt install bind9 bind9utils

Kurulum tamamlandıktan sonra BIND'ı IPv4 moduna ayarlayacağız. Bunun için bir text editor ile (tercihen nano veya vi) /etc/default/bind9 dosyasının içeriğini aşağıdaki hale getiriyoruz.

sudo nano /etc/default/bind9

# run resolvconf?
RESOLVCONF=no

# startup options for the server
OPTIONS="-4 -u bind"

DNS Server Yapılandırma

NOT: Yapılandırma sırasında içeriği değiştirilen dosyalardaki syntax çok önemlidir. En ufak noktalı virgül, space veya tab hatası hatalara sebep olabilmektedir. Bu sebeple lütfen siz de komutları ve dosyaların içeriğini örneklerdeki gibi uygulayınız.

Kullanacağımız iki makinenin bilgilerini aşağıdaki tabloda görebilirsiniz. Birçok konfigürasyon yapacağımızdan ve bu konfigürasyonlarda makinelerin hostname, IP gibi bilgilerini kullanacağımızdan konfigürasyon dosyalarının hangi değişkenine ne yazmamız gerektini aşağıdaki tabloya bakarak anlayabiliriz.

Rol	Hostname	IP	Oluşacak FQND*
DNS Server (nameserver)	testdnsserver	14.8.18.121	testdnsserver.testzone.local
DNS Client	testdnsclient	14.8.18.120	testdnsclient.testzone.local

*FQDN = Fully-Qualified Domain Name

*Oluşturacağımız DNS bölgesinin (zone) ismi tamamen bize bağlıdır. Lokalde denemeler yapacağımız için kendi isteğimize bağlı olarak "testzone.local" adında bir zone oluşturacağız.

Öncelikle konfigürasyonlarımızı yapacağımız dizine gidelim (bundan sonraki işlemleri bu klasör içerisinden yapacağız yani yazacağımız komutlar da buradaki pathe göre olacak). Daha sonra ilk dosyamızı düzenlemeye başlıyoruz. named.conf.options dosyasında güvenilir ağ üyelerini (host) ve forwarderları belirleyeceğiz.

cd /etc/bind/
sudo nano named.conf.options

### DOSYA ICERIGI ###
acl "trusted" {
        14.8.18.121; # dns serverim
        14.8.18.120; # dns clientim
};

options {
        directory "/var/cache/bind";
        recursion yes;
        allow-recursion { trusted; }; # yukarida trusted olarak tanimladigim hostlara recursive query izni veriyorum
        listen-on { 14.8.18.121; }; # nameserver ozel IP adresi

        forwarders {
                8.8.8.8; # google dns
                8.8.4.4;
        };

        dnssec-validation auto;
        listen-on-v6 { any; };
};

Recursive modda clientlardan domain talebi geldiğinde ve istenen domain nameserverda bulunamadığında nameserver diğer nameserverlara talebi iletir, bulunamadığında ise öneride bulunur. Döngü halinde çalışır. Iterative modda ise nameserverda istenen domain varsa size IP'yi verir, yoksa bilmediğini söyler. Profosyonel DNS Serverlarında recursive modun kapatılması önerilir çünkü kötü amaçlı aşırı sayıda yapılan request saldırıları ile DNS Server meşgul edileceğinden kendi işlevini de yerine getiremez hale gelir. Fakat biz lokalde çalıştığımızdan açık bırakabiliriz.

Ardından alan yani zoneları belirleyeceğiz. named.conf.local dosyası boş durumda olabilir. Biz örnek bir dosya oluşturacağız. İsterseniz kopyala yapıştır yaparak, isterseniz de named.conf.default-zones dosyasından şablonu kopyalayarak gerekli konfigürasyonlarla kendi dosyanızı oluşturabilirsiniz.
- Yukarıda DNS alan adımızın testzone.local olacağından bahsetmiştik. Buradaki ayarlarımızı da bu alan adına göre yapıyoruz. Oluşturacağımız db dosyasının adı da db.testzone.local oluyor. (/etc/bind dizininin altında zones/ klasörü oluşturacağız ve burada zoneların db dosyalarını düzenleyeceğiz. Şimdilik yalnızca file pathi veriyoruz.)
- Reverse Lookup Zone adımızı 18.8.14.in-addr.arpa, db dosyamızın adını ise db.14.8.18 olarak verdik. Örneğin IP bloğumuz 192.168.1.0 olsaydı zone adımız 1.168.192.arpa, db dosyamızın adı ise db.192.168.1 olacaktı.

sudo nano named.conf.local

### DOSYA ICERIGI ###
zone "testzone.local" {
        type master;
        file "/etc/bind/zones/db.testzone.local";
};

zone "18.8.14.in-addr.arpa" {
        type master;
        file "/etc/bind/zones/db.14.8.18";
};

Forward Lookup Zone

İlk olarak zonelar için ayrı bir klasör oluşturuyoruz. Daha sonra ise db.local dosyasını (oluşturacağımız dosyaya syntax olarak benzediğinden bu şablon üzerinde oynama yapmak daha kolay olacaktır) Forward Lookup Zone adımızı vererek buraya kopyalayalım. Bu isim named.conf.local dosyasında verdiğimizle aynı, yani db.testzone.local olacak. Ardından bu dosyanın konfigürasyonuna geçebiliriz. Birkaç temel bilgi vermek gerekirse:

sudo mkdir zones
cp db.local zones/db.testzone.local

### DOSYA ICERIGI ###
;
; BIND data file for local loopback interface
;
$TTL    604800
@       IN      SOA     testdnsserver.testzone.local. root.testzone.local. (
                              3         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
; name servers - NS records
        IN      NS      testdnsserver.testzone.local.

; name servers - A records
testdnsserver.testzone.local.   IN      A       14.8.18.121

; 14.8.18.0/24 - A records
testdnsclient.testzone.local.   IN      A       14.8.18.120
;

Reverse Lookup Zone

Reverse Lookup Zone dosyası, ters DNS aramaları için DNS PTR kayıtlarını tanımladığımız yerdir. Bu zone dosyasını da yine zones klasörünün altında oluşturacağız. Yine db.local dosyasını Reverse Lookup Zone adımızı vererek buraya kopyalayalım. Bu isim named.conf.local dosyasında verdiğimizle aynı, yani db.14.8.18 olacak. Ardından bu dosyanın konfigürasyonuna geçebiliriz.

cp db.local zones/db.14.8.18

### DOSYA ICERIGI ###
;
; BIND reverse data file for local loopback interface
;
$TTL    604800
@       IN      SOA     testdnsserver.local. root.testdnsserver.local. (
                              2         ; Serial 
                         604800         ; Refresh
                          86400         ; Retry 
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
; name servers  
        IN      NS      testdnsserver.testzone.local.
; PTR records
121     IN      PTR     testdnsserver.testzone.local.
120     IN      PTR     testdnsclient.testzone.local.

Server Konfigürasyonu Kontrolleri

named-checkconf ve named-checkzone komutları işe oluşturduğumuz dosyaları kontrol edebiliriz.

Eğer hata yoksa named-checkconf komutunda herhangi bir hata ile karşılaşmayız, varsa bize hatanın ne olduğunu ve hangi dosyada olduğunu göstermektedir.
named-checkzone komutunu ise named-checkzone <ZONE_ADI> <ZONE_DOSYASI> şeklinde çalıştırdığımızda OK çıktısını almalıyız.

Aşağıdaki örnekte yazdığımız dosyaları öncelikle named-checkconf ile kontrol ettik. Daha sonra named.conf.local dosyasında bir yeri bozup aynı komutla tekrar kontrol ettiğimizde bize hatayı gösteriyor. Daha sonra düzeltip tekrar named-checkconf dediğimizde ise hatayla karşılaşmıyoruz. En son ise iki zone dosyamızı da kontrol ederek OK çıktısını alıyoruz.

Kontrolleri sağladıktan sonra bind9 servisimi yeniden başlatarak statusumu kontrol ediyorum.

sudo systemctl restart bind9
sudo systemctl status bind9

Client Konfigürasyonu

Client tarafında ise DNS Nameserver'imizi DNS sunucularımızın listesine eklememiz gerekiyor. Bu sunucular sunucumuzun /etc/resolv.conf dosyasında tutulmaktadır ve maksimum 3 adet nameserver verilebilir. Bu dosyayı kendi nameserverimize göre düzenleyelim.

sudo nano /etc/resolv.conf

### DOSYA ICERIGI ###
search testzone.local   
nameserver 14.8.18.121
#Diger (onceden bulunan) nameserverlerimizi buraya yazabiliriz

Daha sonrasında ise nslookup veya nslookup komutlarıyla DNS Serverimizden doğru yanıt alıp alamadığımıza bakıyoruz. Doğru IP ve hostnameler verdiğimizde yanıtı alabiliyoruz fakat yanlış bir IP veya hostname denediğimizde "server can't find" çıktısı alıyoruz.

Ayrıca dig komutuyla daha da ayrıntılı çıktı alabiliriz.

Liman MYS Envanter Eklentisinde Raporlama

Fatih Arslan Tugay — Tue, 18 Jan 2022 11:03:35 +0000

Envanter eklentisinde yapılan filtrelemelerin sonucunu raporlayarak kayıt altında tutabiliriz. Öncelikli olarak filtrelenmenin nasıl yapıldığının bilinmesi gerekmektedir. Bunun için Liman MYS Envanter Eklentisinde Filtreleme yazısını okuyabilrsiniz.

Örnek bir filtreleme yapmak gerekirse, ağaçtan Linux Machines OU'su seçilip Model kısmına "1996", İşlemci kısmına "KVM" yazılıp ilgili bilgisayarlar listelenir.

Daha sonra Rapor Hazırla butonuna tıklanıp CSV Raporu Oluştur dendiğinde ilgili filtrelemenin raporu oluşturulmaktadır.

Rapor oluşturulduğunda raporun tarihi ve hangi OU için oluşturulduğu da listede görünmektedir. Böylece raporlar kısmında ayrıştırma yapılabilir. Raporu yerele indirmek için indirme butonu kullanılır.

Rapor açıldığında ilgili filtreleme sonucunda çıkan bilgisayarların özelliklerinin raporda tablo halinde bulunduğu görülür.

Bir diğer filtreleme olarak ağaçtan Computers OU'su seçilip Bilgisayar Ara kısmına "pardus", Aranacak Konumlar kısmında ise yalnızca İsim seçilerek hostname bilgisinde "pardus" içeren bilgisayarlar listelenir.

Bu filtrelemenin de raporu oluşturulduğunda Raporlar kısmına geldiği görülür. Yukarıda açıklandığı gibi tarih ve OU bilgisinden ayırt edilebilir.

Liman MYS Envanter Eklentisinde Filtreleme

Fatih Arslan Tugay — Tue, 18 Jan 2022 11:02:50 +0000

Envanter eklentisinde sunulan alanlara istenilen filtreler yazılarak makineler içerisinde filtreleme yapılır. Bu kısımda her filtrenin hangi özellik üzerinde filtreleme yaptığı açıktır fakat Bilgisayar Ara filtresini açıklamak gerekirse:

Bu filtre, hemen alt kısmında yer alan Aranacak Konumlar bölümünde işaretlenen özellikler içerisinde filtreleme yapar.
- Örneğin Aranacak Konumlar bölümünde İşletim Sistemi seçilip, Bilgisayar Ara kısmına "redhat" yazılırsa, İşletim Sistemi bilgisi içerisinde "redhat" içeren bilgisayarlar filtrelenecektir.
- Örneğin Aranacak Konumlar bölümünde İsim seçilip, Bilgisayar Ara kısmına "server" yazılırsa, İsim (yani hostname) bilgisi içerisinde "server" içeren bilgisayarlar filtrelenecektir.

Bir diğer filtreleme seçeneği ise OU bazlı filtrelemedir. Sol tarafta yer alan ağaçtan istenilen bir organizasyona tıklandığında yalnız o organizasyonun altındaki bilgisayarlar filtrelenmektedir.

Geniş çaplı bir örnek vermek gerekirse, alttaki görselde görüldüğü üzere Linux Machines OU'su seçilir. Üretici kısmına "QEMU", İşlemci kısmına "KVM", Bilgisayar Ara kısmına ise "centos" yazılıp Aranacak Konumlar'dan İsim ve İşletim Sistemi seçildiğinde:

Linux Machines OU'sunda bulunan,
Üretici bilgisinde "QEMU" içeren,
İşlemci bilgisinde "KVM" içeren,
İsim (hostname) veya İşletim Sistemi bilgisinde "centos" içeren

tüm makineler filtrelenmiş olur.

Farklı bir örnek olarak ağaçtan Computers OU'su seçilip Bilgisayar Ara kısmına "pardus" yazıldığında ve Aranacak Konumlar'dan yalnızca İşletim Sistemi seçildiğinde yalnızca Computers organizasyonundaki Pardus işletim sistemine sahip bilgisayarlar filtrelenmiş olur.

Windows 10 PuTTY Kurulumu

Fatih Arslan Tugay — Mon, 17 Jan 2022 15:37:23 +0000

Bu yazımızda Windows 10 işletim sistemi üzerinde PuTTY programının kurulumunu anlatacağız.

PuTTY Nedir?

PuTTY, SSH bağlantısı ile birlikte uzak bir sunucuya bağlantı kurmamızı sağlayan bir yazılımdır. PuTTY ile birlikte sunucularınıza SSH/Telnet bağlantısı gerçekleştirerek erişim sağlayabilirsiniz.

Kurulum

Öncelikle programın yükleme dosyasını indirmemiz gerekmektedir. Linke tıklayarak ilgili siteye gidelim. Direkt .msi uzantılı kurulum dosyası indireceğimizden Package files kısmından işlemcimize uyumlu pakete tıklayarak indirelim.

İlk önce Next diyerek kuruluma başlıyoruz. İlk gelen kısımda programın kurulacağı yeri seçiyoruz. Default olarak gelen yeri değiştirmeden Next diyerek devam edebiliriz. Daha sonra gelen ekranda ise istediğimiz özellikleri seçtiğimiz ekran geliyor. İşaretli yerdeki simgelerin hepsini resimdeki hale getirerek Install diyelim ve kuruluma başlayalım.

Kurulum tamamlandıktan sonra kurulum sihirbazını kapatarak masaüstüne gidelim. PuTTY simgesine tıklayarak programı kullanmaya başlayabiliriz.

Liman MYS'de LDAP organizasyon birimi yetkilerinin düzenlenmesi

Fatih Arslan Tugay — Fri, 14 Jan 2022 15:16:08 +0000

Liman MYS'nin kurumsal sürümünde yer alan "Domain eklentisi"nde bildiğimiz üzere domain LDAP şemasını görebildiğimiz bir ağaç yapımız var. Bu yazımızda ağaç yapısı üzerinde kullanıcı bazlı yetki düzenlemesi yapmayı göstereceğiz.

Öncelikli olarak Domain Eklentisi'ni LDAP üzerinde izin yönetimi yetkisine sahip olan kullanıcı olarak administrator bilgileriyle giriş yapıyoruz. Bu ayarlar LDAP üzerinde izin yönetimi yetkisine sahip herhangi bir kullanıcı ile de yapılabilir.

Eklentiyi eğer ilk defa açıyorsak zaten giriş ekranında Eklenti Ayarları sayfası açılır ve bizden bir domain kullanıcı adı ve parolası ile doğrulama yapmamızı ister. Fakat eklentiye daha önce giriş yapıldıysa sağ üst köşedeki Eklenti Ayarları butonu ile bu ekrana gidebiliriz.

Gelen ekranda Kullanıcı Adı kısmına domaindeki kullanıcı adımızı, Parola kısımlarına da şifremizi yazarak Kaydet dediğimizde domain eklentisine bu kullanıcının yetkileriyle giriş yapmış olacağız. Bu ekranı unutmayalım çünkü yazının ilerleyen kısımlarında tekrar değineceğiz. İlk olarak administrator veya yetkili bir kullanıcı ile giriş yaptığımıza emin olalım.

Tekrar eklentiye gelecek olursak, belli bir organizasyon birimi (OU) üzerinde kullanıcı bazlı yetki düzenlemesi yapacağımızdan istediğimiz bir OU üzerine gelerek sağ tıklıyoruz ve Yetkileri Düzenle diyoruz.

Önümüze gelen İzinler ekranında Kullanıcı veya Grup kısmındaki Ekle butonuna tıklayarak yetkilerini düzenlemek istediğimiz kullanıcı adını aratıyoruz. Kullanıcımıza tıklayarak Ekle butonuna basıyoruz.* Ardından gelen ekranda default olarak seçtiğimiz kullanıcının Okuma (Read) izni gözüküyor. Biz bunu REDDET konumuna getiriyoruz ve alt taraftaki Uygula butonuna tıklayarak seçimlerimizi kaydediyoruz.

*Aynı şekilde İzinler kısmından silmek istediğimiz bir kullanıcı veya grup olduğunda Kullanıcılar veya Grup kısmından seçerek Sil diyebiliriz.

Şimdi ise sıra geldi bu kullanıcının elinden aldığımız okuma yetkisini test etmeye. Şimdi ise yazının ilk kısımlarında gösterdiğimiz Eklenti Ayarları sayfasına giderek bu sefer yetkileriyle oynadığımız kullanıcının bilgileriyle giriş yapıyoruz. Kaydet butonuna tıkladığımızda gelen ağaç yapısında az önce okuma yetkisini kaldırdığımız birimi göremedik. Bu vesileyle de yetki düzenlemesini başarıyla sağlayabildiğimizi görmüş oluyoruz.

Liman MYS'de ağaç yapısı üzerinden belirli organizasyona yetki verme

Fatih Arslan Tugay — Fri, 14 Jan 2022 09:02:20 +0000

Liman'da bilindiği üzere ağaç yapılı bazı eklentiler bulunmakta. Buna örnek olarak Domain Eklentisi'ni gösterebiliriz. Domain Eklentisi'nden alınan aşağıdaki görselde ağaç yapısına bir örnek görülebilir.

Bu yazımızda ise ağaç yapısının görüntülendiği eklentilerde (Domain, Envanter Eklentisi vb) tüm ağaç yerine kullanıcı bazlı olarak belirlenen Organizasyon Birimi'ne (Organizational Unit - OU) yetki verilmesini göstereceğiz. Adım adım ilerleyelim.

Öncelikle Liman'ın Sistem Ayarları kısmına (1) girerek Rol Grupları sekmesine (2) geliyoruz.
Rol Grubu Ekle seçeneğinden (3) istediğimiz isimle bir rol grubu ekleyerek alttaki tabloya geldiğini görüyoruz. Daha sonra rol grubumuzun üstüne (4) tıklayarak Rol Grubu Ayarları ekranına geçiyoruz.

Rol Grubu Ayarları ekranında Kullanıcılar sekmesine (5) tıkladıktan sonra "+" butonundan (6) kullanıcı ekleme ekranını açıyoruz.
Ekleyeceğimiz kullanıcıyı -yani yalnızca belirlenen organizasyona yetki vereceğimiz kullanıcıları- (7) kullanıcı listesinden seçtikten sonra Seçilen Kullanıcıları Gruba Ekle (8) butonuna tıklayarak kullanıcıları rol grubumuza ekliyoruz. Butona tıkladıktan sonra gelen ekranda Kullanıcılar sekmesine (5) seçtiğimiz kullanıcıların geldiği görülecektir.

Şimdi sıra hangi OU bazında yetki vereceğimize geldi. Öncelikle eklentimize gelerek (bu yazı için Domain Eklentisi kullanılacak) istediğimiz OU'ya sağ tıkladıktan sonra gelen seçeneklerden DN Kopyala diyerek DN bilgisini kopyaladık.

Ardından tekrar sırasıyla Sistem Ayarları -> Rol Grupları -> ( sırasıyla 1,2,3 ve 4. adımlar) ekranına gelerek Özel Veriler sekmesine (9) geliyoruz. "+" butonundan (10) özel veri ekleme ekranını açıyoruz ve "Adı" kısmına (11) "GOZUKECEK_OU" yazıyoruz, "Değeri" kısmına (12) ise az evvel kopyaladığımız OU DN'ini yapıştırıyoruz ve Ekle butonuna (13) tıklayarak veriyi ekliyoruz. Butona tıkladıktan sonra gelen ekranda Özel Veriler (9) sekmesine eklediğimiz verinin geldiği görülecektir.

Bu işlemi yetkili bir kullanıcı için yaptığımızdan dolayı Rol Grubu Ayarları ekranında Eklenti Yetkileri ve Sunucu Yetkileri sekmelerinde düzenlemeler yapmamıza gerek yoktur çünkü zaten eklediğimiz kullanıcının eklenti ve sunucu bazlı yetkileri bulunmaktadır. Eğer bu kullanıcı yetkili kullanıcı olmasaydı Eklenti Yetkileri ve Sunucu Yetkileri sekmelerinden hangi eklenti ve hangi sunucu için kısıtlama yapacaksak onların yetkilerini de vermemiz gerekirdi. Bu senaryo ile ilgili başka yazılarımızda ayrıntılı olarak bahsedeceğiz.

Şimdi ise sıra geldi yaptıklarımızı test etmeye. Liman'a yetki kısıtı yaptığımız kullanıcı ile giriş yaptıktan sonra ilgili eklentiye girdiğimizde ağaç yapısında yalnızca özel verilerde eklediğimiz OU'yu görüntüleyebiliyoruz. Böylece bu kullanıcının yetkisi bu OU ile kısıtlanmış oldu. OU Görünürlüğü Değiştir (14) kısmından tüm ağacı (15) seçsek bile değiştir butonuna (16) tıkladığımızda yine de yalnızca ilgili OU'yu görebiliriz.

Sertifika Şablonları

Fatih Arslan Tugay — Tue, 31 Aug 2021 11:40:04 +0000

Sertifika Şablonu Nedir

Sertifika Şablonu (Certificate Template), sertifika yetkilisinin (Certification Authority, CA) temel bir parçasıdır. Bu şablonlar; sertifika kaydının, kullanımının ve yönetiminin kurallarını içeren bir küme ve sertifika ilkesinin önemli bir ögesidir. Şablonlar, forest (orman) içerisindeki tüm CA'lar tarafından kullanılmak üzere Active Directory Etki Alanı Hizmetleri'nde (Active Directory Domain Services, AD DS) depolanır. Bu durum, sertifika ilkesinin tüm ormanda tutarlı bir şekilde uygulanmasını sağlar.

CA, sertifikalar ile ilgili bir istek (sertifika verme veya yenileme gibi) aldığında bu isteği gerçekleştirmek için bir dizi kurallara ve ayarlara uyması gerekir. Bu kurallar kimi zaman basit, kimi zaman da karmaşık olabileceği gibi tüm kullanıcılara veya yalnızca belirli özelliklere filtrelenmiş kullanıcılara/gruplara uygulanabilir. İşte sertifika şablonları da CA'nın sertifikalar ile ilgili gelen isteklerde uyacağı bu kurallar ve ayarlardır. Ayrıca sertifika şablonu, bu isteği gönderen istemciye de sertifika isteğinin hangi kurallara göre oluşturulup gönderileceğine ilişkin yönergeler de verir.

Sertifika şablonları Windows Server makinelerde run -> mmc -> certificate templates kısmında görüntülenebilir. Burada sertifika yetkilisi kendisi sertifika şablonu oluşturmamış olsa bile; varsayılan olarak çoğu kuruluşun gereksinimlerini karşılayacak şekilde tasarlanmış, çeşitli, önceden yapılandırılmış sertifika şablonları vardır. Ayrıca yine varsayılan olarak, bir sunucuya CA yüklendiğinde Sertifika Şablonları ek bileşeni de otomatik olarak yüklenir. Active Directory Sertifika Hizmetleri (AD CS) araçlarını yüklemek için Sunucu Yöneticisi kullanılarak Sertifika Şablonları ek bileşeni farklı bir sunucuya yüklenebilir.

Sertifika Şablonu Oluşturma

Varolan bir şablonu çoğaltarak (duplicate) ve bu şablonun özelliklerini yeni şablon için varsayılan olarak kullanarak bir sertifika şablonu oluşturabilirsiniz. Farklı türdeki sertifika yetkilileri (CA) farklı sertifika şablonlarını desteyebilmektedir. Örneğin bazı sertifika şablonları yalnızca Windows Server 2003 çalıştıran kuruluş CA'ları tarafından verilip yönetilebilirken, bazıları için CA'nın Windows Server 2008 çalıştırıyor olması gerekebilir. Bu sebeple gereksinimlerinizi en uygun şekilde karşılayan bir sertifika şablonu bulup onu çoğaltarak kendi şablonunuzu oluşturmak için varolan sertifika şablonlarını iyi bir biçimde incelemeniz gerekir. Ayrıca sertifika şablonu oluşturabilmek için Domain Admins veya eşdeğer bir grup üyeliği olması gerekir.

Yeni bir sertifika şablonu oluşturmak için yapmanız gerekenler sırasıyla:

run -> mmc -> certificate templates kısmını açarak Sertifika Şablonları ek bileşenine giriyoruz.
Gerekli incelemelerden sonra çoğaltılacak şablonu sağ tıklatarak Yineleme Şablonu seçeneğini tıklatıyoruz.
Açılan ekranda, yukarıda da bahsedildiği gibi, desteklenecek olan en düşük CA sürümünü seçiyoruz.
General kısmında sertifika şablonumuz için yeni bir isim giriyoruz.
- Bu kısımdaki Active Directory'de sertifika yayımla seçeneği, sertifika şablonuyla ilgili bilgilerin kuruluşun tamamında kullanıma sunulup sunulmayacağını belirler. Bu seçenek işaretlendiğinde sertifika LDAP veritabanından erişilebilir hale gelir.
Gerekli değişiklikler varsa yaptıktan sonra Tamam diyerek işlemi tamamıyoruz.

Benzer şekilde silmek istediğimiz bir şablon varsa sağ tıklatıp Sil ve Evet diyerek silebiliriz.

Sertifika Şablonlarını Yönetme

Yeni bir sertifika şablonu oluşturduğunuzda, gerek genel özelliklerini gerekse detaylı ayarlarını özelleştirmek mümkündür. Bu kısımda sertifika şablonlarının bazı alt özelliklerini açıklayacağız.

Uzantılar

Sertifika şablonları, kullanımlarını düzenlemeye yarayan birtakım uzantılar kullanılarak özelleştirilebilir. Bu uzantılardan bazılarını açıklamak gerekirse:

Temel kısıtlamalar CA sertifikalarının yalnızca belirli uygulamalarda kullanılmasını sağlamak için kullanılır.
Verme ilkeleri sertifika verirken uygulanan bir grup yönetim kuralıdır. Bunlar, sertifikada CA'da tanımlanan bir nesne tanımlayıcısıyla (OID) gösterilir. Bu nesne tanımlayıcısı verilen sertifikaya eklenir. İlgili, sertifikasını gösterdiğinde verme ilkesini doğrulamak ve söz konusu verme ilkesi düzeyinin istenen eylemi gerçekleştirmek için yeterli olup olmadığını belirlemek üzere hedef tarafından incelenebilir.
Uygulama ilkeleri belirli amaçlar için hangi sertifikaların kullanılabileceği konusunda karar vermeniz için size önemli bir olanak sunar. Bu da istenmeyen amaçlarla yanlış kullanılmaları kaygısı taşımadan geniş ölçüde sertifikalar vermeniz olanak sağlar.
- Uygulama ilkelerine bazen genişletilmiş anahtar kullanımı veya gelişmiş anahtar kullanımı da denir. Ortak anahtar altyapısı (Public Key Infrastructure, PKI) uygulamalarının bazı uygulanışları uygulama ilkelerini yorumlayamadığından, Windows Server tabanlı bir CA tarafından verilen sertifikalarda uygulama ilkeleri ve gelişmiş anahtar kullanımı bölümlerinin her ikisi de görünür.
Anahtar kullanımı bir kısıtlama yöntemidir ve hangi sertifikanın ne amaçla kullanılacağını belirler. Bu da yöneticinin, yalnızca belirli görevler için kullanılabilecek sertifikalar vermesine olanak sağlar. Sertifikanın hedeflenen amacı dışındaki kullanımını denetlemek için sertifikalara otomatik olarak kısıtlamalar konulur.
Anahtar arşivleme sertifikalar verildiği zaman bir ilgilinin anahtarlarını şifreleyip CA veritabanında depolamanıza olanak sağlar. Çünkü ilgili kişiler özel anahtarlarını kaybettiğinde, ilgili genel anahtarla kalıcı olarak şifrelenen bilgilere erişilemez. Bir ilgili özel anahtarlarını kaybederse, bilgiler veritabanında alınarak ilgiliye sağlanabilir. Bu da şifrelenen bilgilerin kaybolmadan kurtarılmasını sağlar.

İstek İşleme

İstek İşleme sekmesi bir sertifika şablonunun amacını, desteklenen şifreleme hizmeti sağlayıcılarını (CSP), en az anahtar uzunluğunu, verilebilirliğini, otomatik kayıt ayarlarını ve güçlü özel anahtar koruması gerekip gerekmeyeceğini tanımlar.

Sertifika amacı, sertifikanın hedeflenen birincil kullanımını tanımlar ve aşağıdaki dört ayardan biri olabilir.

Ayar	Amaç
Şifreleme	Şifreleme ve şifre çözme için şifreleme anahtarları içerir.
İmza	Yalnızca verileri imzalamaya yönelik şifreleme anahtarları içerir.
İmza ve şifreleme	Verilerin şifrelenmesi, şifresinin çözülmesi, ilk oturum açma veya verileri dijital olarak imzalama dahil olmak üzere bir sertifikanın şifreleme anahtarının birincil kullanımlarını kapsar.
İmza ve akıllı kartla oturum açma	Akıllı kartla ilk oturum açmaya ve verileri dijital olarak imzalamaya olanak sağlar; veri şifreleme için kullanılamaz.

Sertifika yetkilileri (CA), sertifika verildiğinde bir ilgilinin anahtarlarını kendi veritabanlarında arşivleyebilir. İlgililer anahtarlarını kaybederse, bilgiler veritabanından alınarak ilgiliye güvenli şekilde sağlanabilir. Bununla ilgili ayarlar da aşağıda açıklanmıştır.

Ayar	Amaç
İlgilinin şifreleme özel anahtarını arşivleme	Veren CA anahtar arşivleme için yapılandırılırsa, ilgilinin özel anahtarı arşivlenir.
Özel anahtarın verilmesine izin ver	İlgilinin özel anahtarı, yedekleme veya başka bir bilgisayara aktarım amaçlı olarak bir dosyaya verilebilir.
İptal edilen ya da süresi dolan sertifikaları sil (arşivleme)	Bir sertifika süre sonu veya iptal nedeniyle yenilenirse, daha önce verilen sertifika ilgilinin sertifika deposundan kaldırılır. Varsayılan olarak bu seçenek etkin değildir ve sertifika arşivlenir.
Konunun içerdiği simetrik algoritmaları içer	İlgili sertifikayı istediğinde, ilgili desteklenen simetrik algoritmaların listesini sağlayabilir. Bu seçenek veren CA'nın, söz konusu sunucu tarafından tanınmasa veya desteklenmese bile bu algoritmaları sertifikaya eklemesine olanak sağlar.

İstek İşleme sekmesi ayrıca, bir sertifika şablonu için bu tabloda açıklanan bazı kullanıcı girdisi ayarlarının da tanımlanmasına olanak sağlar.

Ayar	Amaç
Herhangi bir kullanıcı girdisine gerek kalmadan nesne kaydını yap	Bu seçenek, herhangi bir kullanıcı müdahalesi olmadan otomatik kayda izin verir ve hem bilgisayar, hem de kullanıcı sertifikaları için varsayılan ayardır.
Kayıt sırasında kullanıcıya sor	Bu seçenek devre dışı bırakıldığında, kullanıcıların sertifika şablonuna dayalı bir sertifikanın yüklemesi için herhangi bir girdi sağlaması gerekmez.
Kayıt sırasında kullanıcıya sor ve özel anahtar kullanıldığında kullanıcı girdisi iste	Bu seçenek, kullanıcının kendi özel anahtarında güçlü bir özel anahtar koruma parolası ayarlamasına olanak sağlar ve bu parolanın (anahtar oluşturulurken ve sertifika ve özel anahtar her kullanıldığında) kullanıcı tarafından kullanılmasını zorunlu kılar.

Şifreleme

Şifreleme sekmesi, aşağıdaki özellikleri yapılandırmak için kullanılır:

Özellik	Açıklama
Algoritma adı	Yayımlanan sertifikanın anahtar çiftinin destekleyeceği bir algoritma seçin. Bu liste yalnızca, İstek İşleme sekmesinde seçilen sertifika amacı için gerekli şifreleme işlemlerini destekleyen algoritmaları görüntüler.
En düşük anahtar boyutu.	Belirlenen algoritmayla kullanılan anahtarlar için gereken en az boyutu belirtmenize olanak sağlar. Varsayılan olarak, seçilen algoritma için bilgisayarda desteklenen anahtar uzunluğu alt sınırı kullanılır.
Sağlayıcılar	Bu listede bilgisayarda bulunan ve aşağıdaki yapılandırma seçeneklerinin bir bileşimiyle belirtilen ölçüte uyan tüm sağlayıcılar bulunur. Şifreleme sekmesindeki Algoritma adı ve En az anahtar boyutu İstek İşleme sekmesindeki Amaç ve Özel anahtar verilebilsin.
Karma algoritma	Gelişmiş bir karma algoritma seçmenize olanak sağlar. Varsayılan olarak AES-GMAC, MD2, MD4, MD5, SHA1, SHA256, SHA384 ve SHA512 algoritmaları kullanılabilir.
Başka imza biçimi kullan	RSA algoritması seçildiğinde, bu onay kutusu bu şablon için oluşturulan sertifika isteklerinin PKCS #1 V2.1 biçiminde ayrı bir imza içerdiğini belirtmenize olanak sağlar.

Şablonları Başkalarıyla Değiştirme

Bazen, istemcilere verilmiş olan bir sertifika türünün özelliklerini değiştirmek isteyebilirsiniz. Bunu, söz konusu sertifikanın amacına yönelik olarak güncelleştirilmiş bir sertifika şablonu oluşturarak ve eski şablona dayalı sertifikaların ilgililerinin yeni şablona dayalı yeni sertifikaları almasını istediğinizi belirterek yapabilirsiniz. Bu yordam, ilgilileri özgün sertifika şablonunda belirtilen yenileme tarihinden önce yeni bir sertifika almaya zorlar.

Özne Adları

Bir sertifikayla ilişkilendirilmiş özel anahtarın sahibi özne olarak bilinir. Bu bir kullanıcı, program veya herhangi bir nesne, bilgisayar ya da hizmet olabilir. İlgili adı, ilgilinin kim veya ne olduğuna bağlı olarak çeşitlilik gösterebildiğinden, sertifika isteğinde ilgili adı sağlanırken belirli bir esneklik gerekir. Windows, AD DS'de depolanan ilgili bilgilerinden ilgili adını otomatik olarak oluşturabileceği gibi, ilgili adı ilgili tarafından el ile de sağlanabilir (örneğin, sertifika isteği oluşturup göndermek için sertifika kaydı Web sayfaları kullanılarak).

Bu sekmede:

İstekte sağlanmış seçeneği belirlendiğinde, sertifika yenileme isteğine konu adı ekleme görevini kolaylaştırmak ve bilgisayar sertifikalarının otomatik olarak yenilenmesini sağlamak için, otomatik kayıt yenileme istekleri için varolan sertifikaların konu bilgisini kullan seçeneği kullanılabilir. Varolan sertifikalardaki konu bilgileri, kullanıcı sertifikalarının otomatik yenilenmesi için kullanılmaz.
- Otomatik kayıt yenileme istekleri için varolan sertifikaların konu bilgisini kullan seçeneği, sertifika kayıt istemcisinin, otomatik olarak yenileme istekleri oluşturulurken veya Sertifikalar ek bileşeni kullanılırken aynı sertifika şablonunu temel alan varolan bilgisayar sertifikasından konu adı ve konu diğer adı bilgilerini okumasına neden olur.
Bu Active Directory bilgisinden oluştur seçeneği belirlendiğinde ek seçeneklerin yapılandırılması gerekir.

Sertifika Şablonu Sunucusu

İnternet Protokolü güvenliği (IPsec) zorlaması ile Ağ Erişim Koruması (NAP) dağıtımları gibi yüksek hacimli sertifika verme senaryoları, benzersiz ortak anahtar altyapısı (PKI) gereksinimleri oluşturur. Bu gereksinimleri karşılamak için, sertifika şablonlarını yüksek hacimli CA tarafından kullanılacak şekilde yapılandırmak üzere, Windows Server 2008 R2 uygulamasında sunulan aşağıdaki seçenekler kullanılabilir. Bu seçenekler, bir sertifika şablonun özellik sayfasındaki Sunucu sekmesinde bulunur.

Sertifikaları ve istekleri CA veritabanında depolama: Yüksek hacimli senaryolarda verilen sertifikaların kullanım süresi, normalde verildikten sonraki birkaç saat içinde sonra erer ve bunları veren CA, yüksek hacimli sertifika istekleri işler. Varsayılan olarak, CA veritabanında her isteğin ve verilen her sertifikanın kaydı depolanır. Yüksek hacimli istekler, CA veritabanının büyüme hızını ve yönetim maliyetini artırır. Sertifikaları ve istekleri CA veritabanında depolama seçeneği, şablonu yapılandırarak, CA'nın sertifika isteklerini CA veritabanına kayıt eklemeden işlemesini sağlar.
Verilen sertifikalara iptal bilgilerini ekleme: Sertifikaların bazı yüksek hacimli CA'lar tarafından iptali yararlı değildir, çünkü sertifikaların kullanım süresi, verildikten sonraki birkaç saat içinde sona erer. Verilen sertifikalara iptal bilgilerini ekleme seçeneği, şablonu yapılandırarak, CA'nın iptal bilgilerini verilen sertifikaların dışında tutmasını sağlar. Bu yöntem, sertifika doğrulaması sırasında iptal durumunun denetlenmesini önleyerek doğrulama süresini kısaltır.
- Sertifikaları ve istekleri CA veritabanında depolama seçeneği kullanıldığında bu seçeneğin de kullanılması önerilir.

Sertifika Şablonları Dağıtma

Bir CA oluşturduğunuzda, sertifika şablonları AD DS'de depolanır ve ormandaki tüm kuruluş CA'larının kullanımına sunulabilir. Bir CA, Windows Server işletim sisteminin daha yeni bir sürümüne yükseltildiğinde, bu yöntem sertifika şablonlarıyla ilgili çoğaltma, güvenlik yönetimi ve yükseltme işlemlerini kolaylaştırır. Bunun için, kök etki alanının Domain Admins grubunun tüm sertifika şablonlarında Tam Denetim izni olması veya bu iznin başka bir kullanıcı veya gruba verilmiş olması gerekir.

Uygun sertifika şablonları planlanıp oluşturulduktan sonra, bu şablonlar kuruluştaki tüm etki alanı denetleyicilerine otomatik olarak çoğaltılır. Bu çoğaltmanın tamamlanması normalde yaklaşık sekiz saat sürer. Bu zaman dilimi nedeniyle, istemcilere sertifika şablonuna dayalı sertifikalar vermeden önce sertifika şablonunu oluşturmanız ve çoğaltılmasına izin vermeniz gerekir. Bu işlemi yapmak için en iyi zaman, ortamınızın boşta kaldığı süredir. Çoğaltma tamamlanmadan şablonların yapılandırılmasının ve sertifikaların kullanılmasının istenmeyen etkileri olabilir.

Sertifikaların CA tarafından verilebilmesi için, önce sertifika şablonunun bir CA'ya eklenmiş olması gerekir. CA'ya sertifika şablonu eklemek için:

run -> mmc -> certification authority kısmını açıyoruz
Sertifika Şablonları'nı sağ tıklattıktan sonra Yeni'yi tıklatıp ardından Verilecek Sertifika Şablonu'nu tıklatıyoruz.
Açılan listede istediğimiz şablonu seçerek Tamam'ı işaretliyoruz.

Benzer şekilde CA'dan silmek istediğimiz bir şablon varsa Sertifika Şablonları'na tıklayıp listeden istediğimiz şablona sağ tıklayıp Sil ve Evet diyerek silebiliriz. Bu işlemler için Domain Admins veya Enterprise Admins veya bunlara eşdeğer bir grup üyeliği olması gerekir.

Kaynaklar:

Sertifikalar ve Active Directory Sertifika Hizmetleri

Fatih Arslan Tugay — Tue, 31 Aug 2021 11:38:41 +0000

Sertifika Nedir?

Sertifika; bir ortak anahtarın değerini, karşılık gelen özel anahtarı bulunduran kişinin, aygıtın veya hizmetin kimliğine bağlayan, dijital olarak imzalanmış bir deyimdir. Sertifikaların yararlarından biri de, ana bilgisayarların, erişim önkoşulu olarak kimliklerinin doğrulanması gereken bağımsız özneler için bir dizi parola tutma zorunluluğunun ortadan kalkmasıdır. Bunun yerine ana bilgisayar, yalnızca sertifikayı verenle güven oluşturur.

Sertifikaların içerdiği bilgiler aşağıda sıralanmıştır:

Öznenin ortak anahtar değeri,
Öznenin ad ve e-posta adresi gibi tanımlayıcı bilgileri,
Geçerlilik süresi (sertifikanın geçerli kabul edileceği süre),
- Her sertifika, geçerlilik süresinin sınırlarını belirleyen bir Geçerlilik Başlangıcı ve Geçerlilik Sonu değeri içerir. Bir sertifikanın geçerlilik süresi dolduğunda, sertifikanın öznesi yeni bir sertifika istemek zorundadır.
Sertifikayı verenin tanımlayıcı bilgileri,
İlgilinin ortak anahtarı ile ilgilinin tanımlayıcı bilgileri arasındaki bağlantının geçerliliğini doğrulamaya yarayan, sertifikayı verene ait dijital imza.

Sertifikalar; bir kişinin veya nesnenin kimliğinin doğrulanması, bilgilerin yalnızca amaçlanan kişinin kullanmasını sağlayan gizliliğin sağlanması, yetkili olmayan okuyuculardan bilgilerin gizlenmesi (şifreleme) ve inkar edememe, ileti bütünlüğü gibi özellikleri sağlayan dijital imzalama amaçları ile kullanılabilir. Bu amaçlara daha detaylı bakmak gerekirse:

Kimlik doğrulama, iletişimin daha güvenli olması için çok önemlidir. İletişim kuran taraflar fiziksel olarak birbirlerini görmeyecekleri için ağ üzerinde kimlik doğrulama karmaşık bir işlemdir. Bu, ahlak dışı bir kişinin iletilere müdahale etmesine ve diğer kişi veya varlığı taklit etmesine olanak verebilir.
Herhangi bir ağda bilgisayarlar arasında hassas bilgiler gönderiliyorsa, kullanıcılar verilerinin gizliliğini sağlamak için genellikle bir tür şifreleme kullanmak isteyeceklerdir.
Şifreleme işlemi, değerli bir eşyayı sağlam bir kutuya kilitlemek gibi düşünülebilir. Tam tersi olan şifre çözme bu kutuyu açıp değerli öğeyi almaya benzetilebilir. Bilgisayarlarda; e-posta iletisi, diskteki dosyalar veya ağ üzerinden aktarılan dosyalar içindeki hassas veriler bir anahtar yardımıyla şifrelenebilir. Şifrelenen veri ve veriyi şifrelemede kullanılan anahtarlar çözülemez.
Dijital imza, verinin bütünlüğünden ve kaynağından emin olmak için kullanılan bir araçtır. Dijital imza, imzalandığı zamandan beri verinin değiştirilmediğine dair güçlü bir kanıt ve veriyi imzalayan kişinin veya varlığın kimliğini doğrulayan bir belgedir. Bu durum, en önemli güvenlik hizmetlerinden olan ve elektronik ticaret işlemlerinde temel olan bütünlük ve inkar edememe özelliklerini sağlar. Dijital imzalar genellikle, veriler düz metin biçiminde veya şifrelenmemiş olarak dağıtıldığında kullanılır.

Dijital sertifikaların, tek başına bilgisayarlar ile ağlar ve İnternet üzerindeki rolü hızla artmaktadır. Sertifikalar, çok az kullanıcı müdahalesi ile veya herhangi bir kullanıcı müdahalesi olmadan kullanılabilse de, sertifika içeriklerini görüntülemek, anlamak ve bu içeriklerin kullanımını yönetmek de önemli olabilir. Bu amaçları Sertifikalar ek bileşenini kullanarak gerçekleştirebilirsiniz.

Sertifika Ek Bileşeni

Sertifika ek bileşeni, kullanıcılar ve yöneticilerin bir kullanıcı, bilgisayar veya hizmet ile ilişkili sertifikaları görüntülemek ve yönetmek üzere kullanacağı birincil araçtır. Kullanıcının sertifika istemesine, yenilemesine, bulmasına, görüntülemesine, taşımasına, kopyalamasına ve silmesine olanak sağlar. Bunun yanı sıra, kullanıcı Sertifika ek bileşenini kullanarak, aşağıdaki görevleri kolaylaştıran sihirbazları başlatabilir:

Yeni sertifikalara kaydolma
Varolan sertifikaları yenileme
Sertifika bulma
Sertifika alma, verme veya yedekleme

Çoğu durumda, kullanıcıların sertifikalarını ve sertifika depolarını kişisel olarak yönetmeleri gerekmez. Bu işlemler, yöneticiler, ilke ayarları ve sertifika kullanan programlar aracılığıyla gerçekleştirilebilir. Yöneticiler Sertifika ek bileşeninin birincil kullanıcılarıdır; bu nedenle, yönetme yetkileri olan diğer bilgisayar veya hizmetlere ilişkin sertifika depolarının yanı sıra kendi kişisel sertifika depolarında da çok çeşitli sertifika yönetim görevleri gerçekleştirebilirler. Kullanıcılar yalnızca kendi kişisel depolarındaki sertifikaları yönetebilirler.

Bilgisayar veya hizmet kullanıcı hesabınız için sertifikaları yönetme arasında geçiş yapmak için, konsola (Microsoft Management Console, MMC) eklenmiş ayrı Sertifika ek bileşeni örneklerinizin olması gerekir.

Sertifikaları Yönetme

Sertifikalar genellikle, belirli bir bilgisayara, kullanıcıya veya hizmete, belirli bir amaç, süre ve genel olarak belirli alıcılar için verilir. Sonuç olarak, ek sertifikalar almanız, varolan sertifikaları yenilemeniz, bir sertifikanın özelliklerini gözden geçirmeniz veya değiştirmeniz ya da sertifikaları taşımanız gereken zamanlar olabilir. Bu görevlerin çoğu tek bir kullanıcı, bilgisayar veya hizmet için gerçekleştirilebilse de, diğer görevlerin bir yönetici tarafından sunucuda otomatik olarak gerçekleştirilmesi daha iyidir.

Sertifika Alma: Bir sertifikaya kaydolmak için, sertifikanın bir parçası olacak ortak anahtarla ilişkilendirilmiş özel anahtara erişimi olan kullanıcı, bilgisayar veya hizmet tarafından bir sertifika isteği yapılması gerekir. Sistem yöneticiniz tarafından oluşturulan ortak anahtar ilkelerine bağlı olarak kullanıcılar, bilgisayarlar ve hizmetler, kullanıcı müdahalesi olmadan otomatik olarak sertifikalara kaydolabilir.
Sertifika Yenileme: Her sertifikanın bir geçerlilik süresi vardır. Geçerlilik süresinin sonunda, sertifika artık kabul edilebilir veya kullanılabilir kimlik bilgisi olarak değerlendirilmez. Sertifika ek bileşeni, bir Windows kuruluş sertifika yetkilisi (CA) tarafından verilmiş bir sertifikayı, geçerlilik süresi dolmadan önce veya dolduktan sonra Sertifika Yenileme Sihirbazı'nı kullanarak yenilemenize olanak tanır. Bir sertifikayı yenilemeden önce bilmeniz gerekenler şunlardır:
- Sertifika veren sertifika yetikilisi (CA)
- Sertifika için yeni bir ortak anahtar ve özel anahtar çifti istiyorsanız, bu anahtar çiftini üretmek için kullanılması gereken şifreleme hizmeti sağlayıcı (CSP)
Sertifika Görüntüleme: Sertifikalar birçok amaç için yayımlanabilir ve kullanılabilir. Sertifika depoları, sertifika bilgileri ve özelliklerini; arşivlenmiş ve iptal edilmiş sertifikalar hakkındaki bilgileri gözden geçirmek yararlı olabilir.
Sertifika Taşıma: Birçok uygulama yalnızca bir sertifika deposundaki sertifikaları arar. Bir sertifika gerek duyduğunuz bir sertifika deposunda değilse, bu sertifikayı bir depodan diğerine taşıyabilirsiniz.
Sertifika Yönetimini Otomatikleştirme: Sertifikaların ayrı ayrı yönetilmesi imkansız olmasa da zahmetli bir görevdir. Birçok kuruluş, bir sunucuda yapılandırılan ve bir etki alanındaki, gruptaki veya kuruluş birimindeki istemcilere uygulanan Grup İlkesi (Group Policy) ayarlarını kullanarak sertifikaları yönetir.

Active Directory Sertifika Hizmetleri

Active Directory Sertifika Hizmetleri (AD CS), ortak anahtar teknolojilerinden yararlanan yazılım güvenliği sistemlerinde kullanılan sertifikaların verilmesine ve yönetilmesine yönelik özelleştirilebilir hizmetler sağlar. Sertifika istekleri almak, isteklerdeki bilgileri ve istek sahibinin kimliğini doğrulamak, sertifika vermek, sertifikaları iptal etmek ve sertifika iptal verileri yayımlamak üzere bir veya daha fazla sertifika yetkilisi (CA) oluşturmak için AD CS'yi kullanabilirsiniz. AD CS ile aşağıdakileri de yapabilirsiniz:

Web kaydı, Ağ Aygıtı Kayıt Hizmeti'ni ve Çevrimiçi Yanıtlayıcı hizmetini kurma.
Kullanıcılar, bilgisayarlar ve yönlendirici gibi ağ aygıtları ile ilgili sertifikaların kayıt ve iptal işlemlerini yönetme.
Sertifika dağıtmak ve yönetmek üzere Grup İlkesi kullanma.

AD CS'yi tek bir CA için tek bir sunucuyla dağıtabilseniz de, dağıtımlarda kök CA'lar, ilke CA'ları ve sertifika veren CA'lar olarak yapılandırılan birden çok sunucu ve Çevrimiçi Yanıtlayıcılar olarak yapılandırılan başka sunucular bulunabilir.

AD CS'yi yönetmek için aşağıdaki MMC ek bileşenleri kullanılabilir:

Sertifika Yetkilisi: CA'ları, sertifika iptali ve sertifika kaydı işlemlerini yönetmek için birincil araçtır.
Sertifika Şablonları: Active Directory Etki Alanı Hizmetleri'ne (AD DS) yayımlamak ve kuruluş CA'larıyla kullanmak üzere sertifika şablonlarını çoğaltmak ve yapılandırmak için kullanılır.
Çevrimiçi Yanıtlayıcı: Çevrimiçi Sertifika Durum Protokolü yanıtlayıcılarını yapılandırmak ve yönetmek için kullanılır.
Kuruluş PKI'sı: Birden fazla CA'yı, sertifika iptal listelerini ve yetkili bilgi erişimi konumlarını izlemek ve AD DS'ye yayımlanan AD CS nesnelerini yönetmek için kullanılır.
Sertifikalar: Bir bilgisayar, kullanıcı veya hizmetle ilgili sertifika depolarını görüntülemek ve yönetmek için kullanılır.

PKI Sistemi, Sertifika Hiyerarşisi ve Sertifika Yetkilisi Türleri

Genel anahtar altyapısı (PKI); genel anahtar şifreleri kullanarak, elektronik işlemlerde yer alan her varlığın kimlik doğrulamasını yapan ve geçerliliğini doğrulayan dijital sertifika, CA ve kayıt yetkililerinden oluşan bir sistemdir. Microsoft PKI, ölçeklenebilen ve artan sayıda ticari ve diğer CA ürünleriyle uyumluluk sergileyen hiyerarşik bir CA modelini desteklemektedir.

En basit biçimiyle bir sertifika hiyerarşisi tek bir CA'dan oluşur. Bununla birlikte, hiyerarşilerde genellikle açıkça tanımlanmış üst/alt ilişkilerine sahip birden fazla CA bulunur. Bu modele göre, alt CA'lar kendi üstündeki CA tarafından verilen sertifikalarla onaylanır ve böylece bir CA'nın genel anahtarı kendi kimliğine bağlanır. Bir hiyerarşide en üstte bulunan CA'ya kök CA denir. Bir kök CA'nın altındaki CA'ya da alt CA denir.

Kök CA bir kuruluşun PKI'sinde en çok güvenilen CA türü anlamına gelir. Kök CA tehlikeyle karşılaşır veya yetkisiz bir varlığa sertifika verirse, kuruluşunuzdaki sertifika tabanlı tüm güvenlik unsurları saldırıya açık duruma gelir. Bu nedenle, bir kök CA'nın fiziksel güvenliği ve sertifika verme ilkesi alt CA'lara göre sıkıdır. Kök CA'lar güvenli e-posta gönderme gibi görevler için son kullanıcılara verilebilmekle birlikte, çoğu kuruluşta yalnızca alt CA adı verilen başka CA'lara sertifika vermek için kullanılırlar.
Alt CA, kuruluşunuzdaki başka bir CA tarafından kendisine sertifika verilen CA'dır. Tipik olarak bir alt CA, güvenli e-posta, Web tabanlı kimlik doğrulama veya akıllı kart kimlik doğrulaması gibi belirli kullanımlar için sertifikalar verir. Alt CA'lar daha altta yer alan başka CA'lara da sertifika verebilir. Böylece, bir kök CA, kök tarafından sertifika verilen alt CA'lar ve diğer alt CA'lar tarafından sertifika verilen alt CA'lar birlikte bir sertifika hiyerarşisi oluştururlar.

CA hiyerarşisinin yönetim açısından sağladığı bazı yararları saymak gerekirse:

Kullanım: Sertifikalar, e-posta güvenliğini sağlama ve ağ kimlik doğrulaması gibi birtakım nedenlerle verilebilir. Bu kullanımlar açısından verme ilkesi farklı olabilir ve bu ilkelerin yönetiminde temel olan farklılıklardır.
Kuruluş bölümleri: Bir varlığın kuruluştaki rolüne bağlı olarak, farklı sertifika verme ilkeleri söz konusu olabilir. Bu ilkeleri ayırmak ve yönetmek için de alt CA'lar oluşturabilirsiniz.
Coğrafi bölümler: Kuruluşların fiziksel olarak birçok yerde varlıkları olabilir. Bu yerler arasındaki ağ bağlantıları, yerlerin çoğu veya tümü için ayrı alt CA'lar gerektirebilir.
Yük dengeleme: PKI'niz çok sayıda sertifika vermek ve yönetmek için kullanılacaksa, yalnızca bir CA bulunması bu tek CA için dikkate değer bir ağ yüküne neden olabilir. Aynı türden sertifikalar vermek için birden fazla alt CA kullanılması ağ yükünü CA'lar arasında dağıtır.
Yedekleme ve hataya dayanıklılık: Birden fazla CA bulunması, ağınızda kullanıcı isteklerini yanıtlamak için her zaman kullanılabilir durumda CA olması olasılığını artırır.
Güvenlik ve kullanılabilirlik arasındaki dengeyi kurmak amacıyla CA güvenliği ortamını esnek şekilde yapılandırma.
Kurulan güven ilişkilerini ve diğer kısımları etkilemeksizin CA hiyerarşisinin belirli bir kısmını kapatma yeteneği.

Windows'da, bir kök CA'yı güvenli kabul ediyorsanız, hiyerarşide geçerli CA sertifikasına sahip olan her alt CA'yı da güvenli kabul etmiş olursunuz. Böylece, kök CA bir kuruluşta çok önemli bir güven unsuru durumundadır ve buna göre güvenliğinin sağlanması gerekir.

Kaynaklar:

Active Directory Grupları

Fatih Arslan Tugay — Wed, 25 Aug 2021 06:45:18 +0000

Grup Nedir?

Kullanıcı hesaplarını, bilgisayar hesaplarını ve grup hesaplarını bir araya getirerek (grup oluşturarak) yönetilebilir birimler halinde toplamak için kullanılan Active Directory nesnelerine grup (group) adı verilir. Bireysel kullanıcılar yerine gruplarla çalışmak, ağ bakımını ve yönetimini basitleştirmeye yardımcı olur. Grup nesneleri aracılığıyla kullanıcıların ağ üzerindeki kaynaklara erişimi ve bu kaynaklar üzerindeki izinleri merkezi şekilde konrol edilebilmektedir. Örnek olarak ağ üzerindeki belirli bir kaynağa erişecek olan birden fazla kullanıcıyı, yeni oluşturacağımız bir grubun üyesi yapmak ve ardından bu grubun izin atamalarını yapmak izin yönetim işlemlerini oldukça kolaylaştıracaktır.

Grup nesneleri Active Directory yapısı içinde CN=Group,CN=Schema,CN=Configuration,DC=example,DC=lab içerisinde tutulurlar. Ayrıca "group" değerinde "objectClass" attributeları ve grupları türlerine göre ayırt etmemizi saylayan "groupType" attributeları bulunur.

Grup Türleri

Active Directory grup hesabında 2 farklı grup türü olduğu görülmektedir:

1. Güvenlik Grubu (Security Group)

Güvenlik grupları, Active Directory ağı içerisindeki kaynaklara güvenlik hakları (izin) atamak için kullanılabilir. İzinler, kaynağa kimlerin erişebileceğini ve tam denetim gibi erişim düzeyini belirler. Güvenlik grubu kullanılarak, bir departmanda bir grup kullanıcı hesabı toplanabilir ve onlara paylaşılan bir klasöre erişim atanabilir. Bu işlem için dağıtım grubu kullanılamaz.

Ayrıca Active Directory yüklendiğinde bazı güvenlik gruplarına kullanıcı hakları otomatik olarak atanır. Örneğin, Active Directory'deki Yedekleme Operatörleri (Backup Operators) grubuna eklenen bir kullanıcı, etki alanındaki her etki alanı denetleyicisinde bulunan dosyaları ve dizinleri yedekleme ve geri yükleme yeteneğine sahiptir çünkü varsayılan olarak yedekleme dosyaları ve dizinleri ve geri yükleme dosyaları ve dizinleri kullanıcı hakları Yedekleme Operatörleri grubuna otomatik olarak atanır.

Güvenlik gruplarını listeleyecek bir LDAP filtresi kullanmak istersek: (&(objectCategory=group)(groupType:1.2.840.113556.1.4.803:=2147483648))

2. Dağıtım Grubu (Distribution Group)

Dağıtım grupları aynı anda bir grup kullanıcıya e-posta göndermek aracılığıyla e-posta dağıtım grubu olarak kullanılabilir. Dağıtım grupları güvenlik açısından etkin değildir, bu nedenle isteğe bağlı erişim kontrol listelerinde listelenemezler. Bir güvenlik grubu, dağıtım grubunun tüm yeteneklerine sahiptir. Fakat bir kullanıcının aynı anda birçok güvenlik grubuna üyeliği performans azalmasına neden olabilir. Bu nedenle kullanılabileceği her yerde dağıtım grupları tercih edilmelidir.

Aynı şekilde dağıtım gruplarını listeleyecek bir LDAP filtresi yaratmak için "groupType" değeri güvenlik grubu olmayan tüm grupları seçmemiz yeterlidir: (&(objectCategory=group)(!(groupType:1.2.840.113556.1.4.803:=2147483648)))

Grup Kapsamı (Scope)

Gruplar, grubun etki alanı ağacında (domain tree) veya ormanda (forest) ne ölçüde uygulandığını tanımlayan bir kapsamla karakterize edilir. Grubun kapsamı, gruba nerede izin verilebileceğini tanımlar. Her grup kapsamı kendine özgü çeşitli özelliklere sahiptir. Active Directory tarafından tanımlanan üç grup kapsamı vardır:

Domain Local: Yalnızca oluşturulduğu domain içerisinde görülebilir, dolayısıyla izin atamaları yalnızca bulunduğu domainden yapılabilir. Bulunduğu domain dışından erişilemez ve grup içerisinde başka bir Domain Local Grup barındırmadığı sürece Universal kapsamına dönüşüm yapabilir.
Global: Hem kendi domaininde, hem de güven ilişkisinde olduğu (Trust) diğer domainlerde görülebilir ve buralardan erişim sağlanabilir, izin ataması yapılabilir. Başka bir Global Grup içerisinde üye olmadığı sürece Universal kapsamına dönüşüm yapabilir.
Universal: Bulunduğu orman yapısı içerisindeki tüm domainlerdeki kaynaklardan erişim ve izin atamaları sağlanabilir. İçerisinde Universal Grup barındırmadığı sürece Domain Local ve Global kapsamlarına dönüşebilir.

Kaynak: https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups

Active Directory Kavramları ve Site Yapısı

Fatih Arslan Tugay — Wed, 25 Aug 2021 06:44:55 +0000

Bu yazıda Active Directory Site Yapısını ayrıntılarıyla birlikte açıklamaya çalışacağız. Fakat öncelikle Active Directory ile ilgili temel kavramları ele alalım.

1. Temel Kavramlar

Öncelikle sunucu ve istemciden bahsedecek olursak:

Server (Sunucu): Ağ üzerindeki istemcilere veri, kaynak ve dosya paylaşımlarını yapan hizmet sağlayıcılarına server adı verilir. Ağı yönetmek, dosya veya uygulama paylaşımı yapmak, veri tabanı barındırmak, web sayfalarıyla e-posta barındırmak gibi amaçlarla kullanılabilirler.

Client (İstemci): Bir ağ üzerinde, sunucu bilgisayarlardan hizmet alan kullanıcı bilgisayarlarıdır. Bilgiye erişim yetkileri sunucu tarafından belirlenir.

Active Directory (AD); içerisinde sunucu, istemci, kullanıcı ve yazıcı gibi bilgileri tutan bir dizin servisi ve veri tabanı'dır. Kaynak kontrolünü ve merkezden yönetimi büyük oranda kolaylaştırdığından çokça tercih edilen bir servistir. Active Directory servisi, Domain Controller olarak adlandırılan sunucu veya sunucular üzerinde tutulur. Bazı Active Directory kavramlarını kısaca tanımlamak gerekirse:

Domain (Etki Alanı): Kullanıcı ve bilgisayar hesapları gibi nesnelerin yönetimi için oluşturulan mantıksal bir alandır. Farklı iki domain arasında bilgi ve kaynak paylaşımı amacıyla kurulan mantıksal ilişkiye güven ilişkisi (trust/domain trust) adı verilir.

Domainler, diğer domainler ile alt-üst ilişkisi kurularak düzenlenebilirler. Oluşturulan ilk domain, Active Directory yapısındaki Kök (Root) Domain'i ifade eder. Bu aşamadan sonra oluşturulacak ek Domain'ler dizinin Tree ve Forest yapısını oluşturur.
Organizational Unit (OU) ise domain içerisinde bulunan nesneleri (kullanıcı,grup veya bilgisayar hesapları gibi) organize etmeyi sağlayan birimlerdir. Mevcut kullanıcılarımızı bir grup içerisinde toplayıp tek bir yerden yönetmemizi kolaylaştıran Active Directory'nin olmazsa olmaz birimidir.

Tree (Ağaç): Aynı isim altında toplanmış domainlerin hiyerarşik olarak oluşturduğu yapıdır. Aynı domain ağacı içerisinde bulunan domainler tek bir isim yapısını paylaşmaktadırlar.

Forest (Orman): Birden fazla Tree'nin bir araya gelmiş halidir. Oluşturulan ilk domain Tree'yi oluşturur ve böylece Forest da oluşmuş olur. Bu Forest'a daha sonra eklenecek Tree'ler, Forest içerisindeki Tree ile aynı isim yapısını paylaşmasalar da aynı Global Catalog ve Schema'ya sahip olurlar.

Global Catalog (GC): Active Directory Forest'larındaki her bir nesnenin aranabilir bir bölümünü içeren dağıtık bir veri deposudur.

Schema (Şema): Kullanıcı, grup, bilgisayar ve yazıcılar gibi bütün nesnelere ait bilgileri içerir. Forest içerisinde sadece bir Schema bulunur ve bütün nesne bilgileri bu Schema üzerine yazılır. Yeni oluşturulan veya içeriği değiştirilen bir nesnenin Schema içerisinde dinamik olarak güncellemesi yapılır.

Lightweight Directory Access Protocol (LDAP): Active Directory içerisinde de kullanılan, temel olarak dizin servislerini sorgulama ve güncellemeye yarayan bir protokoldür. AD objelerine erişimde LDAP isimlendirme yöntemi kullanılır ve iki tanım içerir:

Distinguished Names (DN): AD nesnelerinin, ağ ortamında kendilerine ulaşılmasını sağlayan ve komple bir path içeren isimleridir. Örneğin: CN=fatihpc,OU=Sistem,DC=fatih,DC=lab

Burada kullanılan "CN" Common Name, "OU" Organizational Unit ve "DC" Domain Controller anlamına gelmektedir. Dikkat ettiysek "fatih.lab" olan domain adımızı DC=fatih,DC=lab şeklinde ifade ettik.

Relative Distinguished Name (RDN): DN içerisinde asıl belirtilmek istenen nesne adıdır ve nesneye ait benzersiz tanımı içerir. Yani domain içerisinde tektir. Örneğin yukarıdaki örnekte kullandığımız DN'de fatih.lab domaini içerisinde tek olan RDN "CN=fatihpc"dir.

Şimdiye kadar bahsettiğimiz kavramların tamamı, Active Directory'nin mantıksal yapısını oluşturmaktaydı. Bunun haricinde Active Directory'nin fiziksel yapısı da bulunmaktadır. Mantıksal yapı ile ağ kaynakları organize edilirken, fiziksel yapı ile de ağ trafiğinin kontrolü ve konfigürasyonu gerçekleştirilir. Fiziksel yapı Domain Controller ve Site'lardan oluşmaktadır.

2. Domain Controller (DC)

Domain Controller (Etki Alanı Denetleyicisi), üzerinde Active Directory veri tabanının bir replikasını bulunduran sunucudur. Şirket yapısındaki ağların ve sistemlerin çatısını oluşturmaktadır. Domain üzerinde yapılan herhangi bir değişiklik doğrudan Domain Controller üzerinde de gerçekleştirilir, ardından domain üzerindeki tüm Domain Controller'lar bu değişiklikleri replikasyon yolu ile kopyalarlar.

Domain Controller'lar dizin bilgisini bulundururlar ve logon, kimlik doğrulama ve dizin arama işlemlerini yürütürler.
İstemcilerden gelen tüm isteklere yanıt vererek gerekli yönlendirmeleri yaparlar.
Group Policy (Grup İlkesi) sayesinde domain içerisinde güvenlik ilkeleri oluşturularak güvenlik sağlarlar.
- Group Policy, Domain Controller üzerinden güvenlik ayarları, kısıtlamalar, standart konfigürasyonlar, yazılım dağıtımı gibi işlemleri yapmamızı sağlayan bir merkezi yönetim protokolüdür.
Global Catalog sayesinde Domain yapısının bilgisini kendi bünyesinde barındırır.

İki farklı Domain Controller yapısından bahsedebiliriz.

Primary Domain Controller (Birincil Etki Alanı Denetleyicisi): Active Directory kurulumu yapılan ilk server bilgisayar Primary Domain Controller olarak görev alır. Bir domain ortamında yalnızca bir tane Primary DC olabilir.
Additional Domain Controller (Ek Etki Alanı Denetleyicisi): Primary DC kurulumu yapıldıktan sonra Active Directory kurulumu yapılan her bir server bilgisayar Additional DC görevi yürütür. Aynı domain ortamında birden fazla Additional DC olabilir.

Yedeklilik ve yüksek erişilirlik gibi ilkelerden dolayı bir domain üzerinde en az 3 tane DC kurulması tavsiye edilmektedir.

2.1 FSMO Rolleri

Domain ve Forest ortamında çeşitli görevler alan 5 adet rol bulunmaktadır. Bunlara Flexible Single Master Operations veya kısaca FSMO adı verilir. Bu 5 rol standart olarak Forest içerisindeki ilk kurulan Server'ın Domain yapısını oluşturan Primary DC üzerinde bulunmaktadır.

Schema Master: Schema yapısının Active Directory üzerindeki bütün nesnelerin bilgilerini tutan yapı olduğunu yukarıda belirtmiştik. Bu yapı, sınıflardan (class) oluşur ve her bir sınıf içerisinde o sınıfa ait öznitelikler (Attribute) bulunur. Bir nesneye ait hangi bilgilerin saklanacağı bu öznitelikler ile tanımlanır. Tüm AD nesne sınıfı ve öznitelik güncellemeleri ve bunlara ait bilgiler Schema Master üzerinde tutulur. Schema Master rolü Schema'nın yönetimini yapmakla birlikte Domain Controller'lar arası tüm AD replikasyonlarını yapmakla sorumludur. Forest içerisinde tektir.
Domain Naming Master: Domain içerisine giriş-çıkış yapan nesnelerin bilgilerini tutar ve yönetir. Bu rolün Global Catalog rolüne sahip bir DC'da olması tavsiye edilir. Forest içerisinde tektir.
PDC Emulator: FSMO rolleri içerisinde kaynakları en yoğun kullanan roldür. Şifre değişiklikleri ve resetlemeleri, Group Policy ve SYSVOL paylaşım erişimlerini yönetir.
RID Master: AD Domain yapısı içerisindeki her bir nesnenin benzersiz kimlik numarası vardır ve bu numaralara RID (Relative Identifier) adı verilmektedir. Ayrıca RID atanırken, AD nesnesinin oluşturduğu Domain altında ilgili Domain'in kimlik numarasıyla beraber atanır. Bu numaraya da SID (Security Identifier) denir. Her Domain'in kendine ait sabit bir değerde SID numarası vardır ve her atanan RID numarası bu SID numarasının altında atanır. RID Master rolü, AD ortamında oluşturulan nesnelere RID numarası atama işlemini gerçekleştirir.
- RID Master rolünün sahibi olan sunucuda 1 milyarın üzerinde RID numarası bulunur. RID Master olmayan DC'lerde ise bu sayı yalnızca 400 (Windows Server 16 ve sonrasında 500) ile kısıtlıdır. Bu DC'ler, bu rakam tükenmeden hemen önce RID Master rolüne sahip DC ile iletişime geçerek tekrar bir 400 tane daha RID numarası talep ederler. İşte bu işlemleri yerine getiren rol RID Master rolüdür.
Infrastructure Master: Domain'ler arası bilgi transferini yapar ve güncel tutulmasını sağlar. OU'dan OU'ya taşıma (nesnenin yerinin değiştirilmesi) durumundaki Update değişikliklerinden sorumludur. Üzerindeki bilgi her daim günceldir.

3. Site Yapısı

Büyük bir ağ yapımız olduğunda -örneğin kurumsal bir firmanın farklı şehirlerde veya ülkelerde hizmet verdiğini düşünelim- farklı lokasyonlarda konumlanan Domain Controller'ların ayrıştırılmaları gerekmektedir. Bunun sebebini açıklayacak olursak, her istemcinin bulunduğu lokasyondaki Domain Controller'dan kimlik doğrulama işlemini yapması zorunludur. Uzak bir şubeden kimlik doğrulama işlemi yapacağımızı düşünürsek; bu işlemi yapacağımız DC, tek bir site yapısı (varsayılan olarak Default-First-Site-Name) içerisinde bulunursa kimlik doğrulama işlemi çok uzun zamanlar sürebilir. Bu sebeple kişi hangi şubeye giderse gitsin o coğrafyadaki site (lokasyon) içerisinde bulunan DC ile iletişim kurmalıdır.

Bir site, yüksek bant genişliğine sahip hatlarla bağlanmış bir veya birden çok IP alt ağlarını ifade eder. Eğer Site'ları doğru bir şekilde yapılandırırsak gerek logon gerekse replikasyon işlemlerindeki ağ trafiğini en aza indirgemiş oluruz. Site yapısının en önemli amaçlarından birisi kullanıcının logon sırasında doğru Domain Controller'ı en hızlı ve en güvenli bağlantı ile bulabilmesidir.

Elbette farklı coğrafyalardaki Domain Controller'ların veri tabanları tutarlı olmalıdır. Bunu kendi aralarındaki replikasyonlar ile sağlarlar. Bu replikasyonlar ikiye ayrılır:

Intrasite (Site İçi) Replikasyon: Aynı Site içerisindeki Domain Controller'ların gerçekleştirdiği replikasyondur. Varsayılan olarak 15 dakikada bir gerçekleşir. RPC (Remote Procedure Call) (Uzak Çağrı Yordamı) Over IP Protokolü ile gerçekleştirilir. Replikasyondaki veriler sıkıştırılmadan iletilir.
Intersite (Site'ler Arası) Replikasyon: Farklı Site'lar arası replikasyondur, Bridgehead Server adı verilen sunucular arasında gerçekleştirilir ve varsayılan olarak 3 saatte bir gerçekleşir. RPC Over IP (tavsiye edilir) veya SMTP (Simple Mail Transfer Protocol) üzerinden gerçekleştirilir. Replikasyondaki veriler sıkıştırılarak iletilir.

3.1. Site Link Kavramı

Site Link'ler, Site'lar arasındaki fiziksel bağlantıyı temsil eder ve Site'lar arası replikasyonu ve replikasyon yönetimlerini sağlarlar. Varsayılan Site Link DEFAULTIPSITELINK olarak isimlendirilmiştir.

Site Link Bridge'ler ise Site Link'leri birbirlerine bağlarlar. Aslında varsayılan olarak tüm Site Link'ler birbirlerine bağlı (Bridged) durumdadırlar. Ancak tüm Site'lar birbirlerine Routing (yönlendirme) ile erişebilir durumda değilse gereken yerlere Site Link Bridge'ler oluşturulmalıdır.

3.2 KCC Kavramı

Site kavramını açıklarken DC'ler arasında Intersite ve Intrasite olmak üzere iki çeşit replikasyon olduğunu belirtmiştik. KCC (Knowledge Consistency Checker), 15 dakikada bir çalışarak Site içerisinde hangi DC'nin hangi DC ile replikasyon yapacağını belirleyen bir Intrasite (Site İçi) Replikasyon Topolojisi oluşturup bağlantı nesnelerinin otomatik olarak oluşmasını sağlar. Bu topoloji oluşturulurken DC'ler arasındaki en iyi bağlantı hesaplanır ve en iyi yolun kullanılması sağlanır.

Site içerisindeki her Domain Controller, KCC görevini üstlenir ve aynı Site içerisindeki KCC Domain Controller'lar replikasyon topolojisini oluşturmak amacıyla birbirleri ile RPC üzerinden haberleşirler.

3.3. ISTG Kavramı

KCC, Site içi replikasyon topolojisini oluşturduğu gibi Site'lar arası replikasyon topolojisini de oluşturmaktadır. Site'lar arası replikasyon topolojisi ile diğer Site'lardaki DC'lerdeki değişikliklerin, tüm Domain'deki DC'lerde güncel tutulması sağlanmaktadır. Site'lar arası replikasyon trafiğinde sadece ISTG (Intersite Topology Generator) rolündeki DC'ler görevlidir ve bunlara Bridgehead Server adı verilmektedir.

Bir Site içerisindeki en az bir DC otomatik olarak ISTG yani Bridgehead Server olarak atanır. Fakat KCC, bir Site içerisinde birden fazla ISTG atayabilir. Eğer Site içerisindeki Bridgehead Server'a ulaşılamaz ise Site içindeki GUİD değeri en yüksek olan DC Bridgehead Server olarak atanır.

GUID (Globally Unique IDentifier): Bilgisayar yazılımlarında tanımlayıcı olarak kullanılan benzersiz bir referans numarasıdır. GUID terimi, genel olarak UUID (Universally Unique IDentifier) standardının çeşitli uygulamalarından biridir.

Bir Site içerisindeki bilgilerde değişiklik olduğunu düşünelim. Bu değişiklik öncelikle Site içerisindeki Domain Controller'larda replike olur. Ardından Bridgehead Server DC üzerinden diğer Site'lardaki Bridgehead Server DC'lar replikasyon yaparlar ve son olarak bu replikasyon bilgilerini kendi Site'ları içerisindeki diğer DC'lara replike ederler.