BT Sistem Yönetimi

Samba AD DC Kurulumu: Linux'ta Domain Controller

Samba AD DC kurulumu: Ubuntu 24.04'te samba-tool domain provision, iç DNS kararı, Kerberos doğrulaması ve kurulum öncesi/sonrası ölçülmüş port tablosu.

İlker Pehlivan

Samba AD DC kurulumu, bir Linux sunucuyu Windows istemcilerin de katılabildiği tam yetkili bir domain denetleyicisine dönüştürmek demektir. Kurduğunuz şey bir dosya paylaşım servisi değildir: kimlik doğrulayan, isim çözen ve makinelere kural dağıtan bir kimlik altyapısıdır. Bu rehber kurulumu Ubuntu 24.04 üzerinde adım adım anlatıyor, her adımı gerçek çıktısıyla doğruluyor ve çoğu rehberin hiç sormadığı soruyla açıyor: bunu kurmalı mısınız?

Bir futbol kulübünün soyunma odasında asılı bir liste vardır. Kimin hangi mevkide oynadığı, forma numarası, telefonu. O liste doğru olabilir, güncel olabilir, herkes ona bakıyor olabilir. Ama o listede adınızın yazması sizi sahaya çıkarmaz. Sahaya çıkmanız için federasyonun verdiği lisans gerekir: lisansı kulüp değil federasyon üretir, hakem maç günü ona bakar ve o lisans yalnız sizin kulübünüzde değil, federasyonun tanıdığı her sahada geçerlidir.

Bu rehber boyunca aynı sahada kalacağız. Çünkü Linux dünyasında sık karıştırılan iki şey tam olarak bu ikisidir: bir dizin oyuncu listesidir, bir domain ise federasyondur. Aşağıda önce ikisinin farkını ve Samba’nın bu tabloda nereye oturduğunu göreceğiz, sonra kurulumun ne zaman gereksiz olduğuna bakacağız. Ardından samba-tool ile domaini kuracak, kurulumun çalıştığını port port ve bilet bilet doğrulayacağız. Kararı vermiş ve doğrudan komutlara geçmek istiyorsanız provizyon bölümüne atlayabilirsiniz.

LDAP protokolünün kendisi, dizin sorgusunun nasıl kurulduğu ve Kerberos’un bilet mantığı bu rehberin kapsamı dışında kalıyor; onları LDAP ve LDAPS rehberimizde ve Kerberos rehberimizde ele alıyoruz. Burada tek bir işi yapıyoruz: o protokollerin hepsini birden sunan sunucuyu Linux üzerinde kurmak. Rehber BT sistem yönetimi hizmetimizin kimlik katmanına aittir.

Samba AD DC kurulumunda dizin ile domain farkı: solda kulüp sicilinde 7 numara, sağda aynı numarayı taşıyan ve mühürlenmiş lisans belgesi
Sicilde numaranızın yazması sizi sahaya çıkarmaz. Mühür lisansta, lisansı da federasyon verir.

Samba AD DC Nedir? Dizin ile Domain Arasındaki Fark

Samba AD DC, Samba 4 ile gelen ve bir Linux makineyi Active Directory domain denetleyicisi haline getiren sunucu rolüdür. Tek bir süreç ağacı altında dizin, kimlik doğrulama, isim çözümleme, dosya paylaşımı ve grup ilkesi dağıtımını birlikte sunar. Windows istemci açısından karşısındaki makinenin Linux olduğu görünmez.

Buraya en makul itiraz şudur: Active Directory Microsoft’un ürünü değil mi? Ürünü, ama “Active Directory” iki ayrı şeyin adı. Biri Microsoft’un kendi uygulaması, yani Windows Server’ın AD DS rolü; diğeri o domaini domain yapan protokol ve şema takımı. Samba ikincisini uygular, ve bunu kapalı bir kutuyu tersine mühendislikle çözerek değil belgelerden yapar: AB Komisyonu’nun 2004 tarihli kararı ve Microsoft’un 2007’de kaybettiği temyizin ardından protokol dokümantasyonu, açık kaynak projelerinin kullanabileceği şartlarla erişime açıldı.

Bunun en somut kanıtı da şu: bir Samba denetleyicisi, mevcut bir Windows ormanına ek denetleyici olarak katılıp replikasyon yapabilir. Taklit bir sistem karşısındakiyle dışarıdan konuşur; replikasyon ortağı olmak ise aynı dizinin içinde eşit bir üye olarak kabul edilmeyi gerektirir. Bu makalede kurduğumuz şey bir Active Directory benzeri değil, bir Active Directory domainidir.

Farkı yerine oturtan cümle şu: bir dizin kullanıcı tutar, ama kimse bir dizine katılmaz. OpenLDAP kurduğunuzda ortaya kullanıcıların, grupların ve birimlerin durduğu bir ağaç çıkar. O ağaç sorgulanabilir, güncellenebilir, yedeklenebilir. Ama hiçbir bilgisayar ona “üye” olamaz, ondan kural alamaz, ona kimliğini kanıtlayıp karşılığında bir belge alamaz. Liste, listedir.

Domain ise üyelik kurar. Bir makine domaine katıldığında kendi hesabı açılır, kendi parolası olur, kural alır ve kimlik doğrulaması artık merkezden yapılır. Federasyon benzetmesinin karşılıkları şöyle oturuyor:

KavramSahadaki karşılığı
OpenLDAP diziniKulübün soyunma odasındaki oyuncu listesi
Domain (AD DC)Federasyon
Domain joinLisans başvurusu ve tescil
Kerberos bileti (TGT)Sporcu lisansı
Servis biletiO maça özel maç kartı
Grup ilkesi (GPO)Federasyon talimatı
SYSVOL paylaşımıTalimatların yayınlandığı resmi pano

Analojinin koptuğu yer, ve tam da orası mekanizmanın kendisi: bir sporcu lisansı yıllarca geçerlidir ve hakem onu gözüyle tanır. Kerberos bileti ise saatlerle ölçülür ve hiçbir servis onu “tanımaz”, her seferinde matematiksel olarak doğrular. Bu rehberin doğrulama bölümünde aldığımız biletin ömrünü de göreceksiniz: on saat.

Samba, FreeIPA ve OpenLDAP Aynı Sorunun Üç Farklı Cevabı

Bu üçünün hangisini kuracağınız, kaç soruya cevap vermeniz gerektiğine bağlı. LDAP rehberimizde bir kimlik altyapısının cevaplaması gereken dört soruyu ele alıyoruz: kim ve neye yetkili, gerçekten o mu, dizin nerede, kurallar makinelere nasıl ulaşacak. Tablo bu dört soruya göre ayrışıyor:

Ne verirNe vermez
OpenLDAPYalnızca dizinKimlik doğrulama, isim çözümleme, politika dağıtımı
FreeIPADizin + Kerberos + DNS + sertifikaWindows istemcinin domaine katılması, grup ilkesi
Samba AD DCDizin + Kerberos + DNS + paylaşım + grup ilkesiWindows’a özgü bazı ileri roller (aşağıda)

FreeIPA satırındaki koyu ifade, bu makalenin var olma sebebidir. FreeIPA olgun ve iyi bir üründür, ama bir Windows bilgisayarı FreeIPA’ya domain üyesi yapamazsınız; yapabileceğiniz tek şey mevcut bir Active Directory ile güven ilişkisi kurmaktır, ki bu da zaten bir Active Directory’niz olmasını gerektirir. Ortamınızda Windows istemci varsa ve merkezi kimliği Linux üzerinde tutmak istiyorsanız, geriye tek seçenek kalır.

Bunun sebebi lisans ya da tercih değil, protokol. Windows bir domaine katılırken belirli bir el sıkışma dizisi bekler ve o dizinin her adımını karşılayan bir sunucu arar. Samba tam olarak o dizinin tamamını uygular. Federasyon dilinde: FreeIPA da lisans basar, ama başka bir ligin hakemi o lisansı sahada kabul etmez.

Samba AD DC Ne Zaman Kurulmaz?

Bir teknolojinin alt eşiğini söylemek, onu övmekten daha faydalıdır. Samba AD DC’nin kurulmaması gereken durumlar net ve bunları baştan görmek size günler kazandırır:

  1. Zaten çalışan bir Windows domaininiz varsa. İkinci bir domain açmak kimliği merkezileştirmez, ikiye böler. İhtiyacınız ek denetleyiciyse Samba’yı ayrı domain olarak değil, mevcut domaine ek DC olarak katın.
  2. Yalnızca uygulamalarınız kullanıcı doğrulasın istiyorsanız. Bir web uygulamasının, VPN’in ya da firewall’un kullanıcıları bir yerden okuması gerekiyorsa ihtiyacınız olan şey dizindir, domain değil. OpenLDAP hem daha hafiftir hem yönetimi daha basittir.
  3. Ağınızda beş kişi ve beş bilgisayar varsa. Merkezi kimliğin kazancı makine sayısıyla katlanır. Kırılma noktasını somut görmek için sayın: 10 kullanıcı × 10 makine = 100 ayrı yerel hesap demektir ve bir çalışan ayrıldığında hesabını on makinede tek tek silmeniz, üstelik hangisini atladığınızı asla bilememeniz demektir. Beş kişilik bir ofiste bu tablo yoktur; on beş kişilik bir ofiste kaçınılmazdır.
  4. Sunucuyu Red Hat ailesinde çalıştıracaksanız. Red Hat, kurumsal dağıtımlarında Samba’yı dosya sunucusu ve domain üyesi olarak destekler, AD DC rolünde desteklemez. Kurulum teknik olarak mümkün olsa da destek kapsamı dışında kalırsınız.
  5. Kalabalık bir ortamda her işi sunucuya bağlanıp elle yapacaksanız. Bu madde diğer dördünden farklı: ürünün değil, operasyon modelinizin sınırı. Birkaç yüz kullanıcıya kadar elle yönetim yürür; binlerle ölçülen bir ortamda yürümez, ve bunu Samba’nın kendi belgeleri yazıyor. Ayrıntısı aşağıda, ölçek bölümünde.

İlk dördünün hiçbiri sizin durumunuz değilse ve beşincisine hazırsanız kuruluma geçebilirsiniz.

Samba AD DC Kurulumu İçin Ön Koşullar

Bu rehber, üzerine Samba kuracağınız Ubuntu Server’ı zaten ayağa kaldırdığınızı varsayar. İşletim sistemi kurulumu, disk düzeni ve ilk yapılandırma ayrı bir konudur ve Ubuntu Server kurulum rehberimizde ele alınmaktadır.

Bunun dışında kurulumu bloke eden üç koşul var ve üçü de kurulumdan önce halledilmezse provizyon ya çalışmaz ya da yanlış çalışır:

  • Statik IP zorunludur. Domain denetleyicisinin adresi DNS kayıtlarına ve istemci yapılandırmalarına gömülür; adres değişirse domain sessizce bulunamaz hale gelir.
  • Makine kendi tam nitelikli adını (FQDN) çözebilmelidir. Aşağıda ölçeceğiz, bu en sık atlanan adımdır.
  • 53 numaralı portu tutan başka bir servis olmamalıdır. Ubuntu’da varsayılan olarak vardır.

Bu rehberdeki bütün çıktılar 192.168.1.30 adresinde, sambadc adlı bir Ubuntu 24.04.4 sunucuda alınmıştır; domain adı ad2.sercebilisim.com, NetBIOS adı AD2. Komutları kendi ortamınızda çalıştırırken bu değerleri değiştirin.

FQDN Tuzağı: hostname -f Kısa Ad Dönüyorsa Durun

Provizyon başlamadan önce makinenin kendi tam adını çözdüğünü doğrulayın. Ubuntu’nun varsayılan kurulumunda bu çözülmez ve sebebi /etc/hosts dosyasının ilk satırlarındadır. Kurulum sırasında dosya şu satırı içerir:

Yapılandırma
127.0.0.1 localhost
127.0.1.1 sambadc

Alt satıra domainli kaydı eklemek tek başına yetmez, çünkü 127.0.1.1 satırı önce eşleşir ve kısa ad kazanır. Ölçtüğümüz sonuç:

Bash
$ hostname -f
sambadc

Beklenen çıktı bu değil. Çözüm, 127.0.1.1 satırını kaldırıp makinenin gerçek adresini tam adıyla yazmaktır:

Bash
sudo cp /etc/hosts /etc/hosts.yedek
sudo sed -i '/^127\.0\.1\.1/d' /etc/hosts
echo '192.168.1.30 sambadc.ad2.sercebilisim.com sambadc' | sudo tee -a /etc/hosts

Aynı komutu tekrar çalıştırdığımızda:

Bash
$ hostname -f
sambadc.ad2.sercebilisim.com
$ hostname -d
ad2.sercebilisim.com

Bu adımın neden bu kadar erken geldiğini söylemek gerekiyor: samba-tool provizyon sırasında makinenin kendi adını okuyup DNS bölgesine ilk kaydı bu adla yazar ve Kerberos servis adlarını (SPN) bu addan türetir. Kısa adla üretilmiş bir domain, sonradan düzeltilmesi kurulumu baştan yapmaktan uzun süren bir işe dönüşür.

Domain Adı Seçimi: Apex Alan Adını Kullanmayın

Domain adını seçerken kurumun web sitesiyle aynı adı kullanmak ilk akla gelen ve en pahalı seçenektir. sercebilisim.com adını iç domain olarak kurarsanız, iç DNS sunucunuz o alanın tamamı için otoriter hale gelir ve elle kayıt eklemediğiniz sürece iç ağdaki hiçbir makine kendi web sitenize erişemez. Bu arızanın belirtisi (“internet çalışıyor ama bizim site açılmıyor”) kaynağı akla en son gelen yerdedir.

Güvenli kalıp bir alt alan kullanmaktır: bu labda ad2.sercebilisim.com seçildi. Alt alan, apex ile çakışmaz ve dışarıdaki kayıtlara dokunmaz.

Samba Paketlerinin Kurulumu ve DNS Çakışmasının Çözülmesi

FQDN çözüldüğüne göre paketleri kurabilirsiniz. Sıralamada tek bir kritik nokta var ve çoğu rehber bunu ters yazar: paketleri systemd-resolved kapalıyken kurmayın. apt, depolara ulaşmak için çalışan bir DNS ister; onu önce kapatırsanız kurulum indirmeye başlayamadan durur.

Bash
sudo apt update
sudo DEBIAN_FRONTEND=noninteractive apt install -y \
  samba smbclient winbind libpam-winbind libnss-winbind \
  krb5-user krb5-config chrony dnsutils ldap-utils

Bu labda kurulan sürüm:

Bash
$ samba --version
Version 4.19.5-Ubuntu

Paketler indikten sonra sıra port çakışmasını çözmeye geldi. Samba AD DC kendi DNS sunucusunu getirir ve 53 numaralı portu ister; Ubuntu’da o portu systemd-resolved tutar. Ayrıca Samba’nın klasik dosya sunucusu servisleri (smbd, nmbd, winbind) kurulumla birlikte başlar ve AD DC rolüyle çakışır: AD DC modunda bu üçünü tek bir samba süreci yönetir.

Bash
sudo systemctl disable --now smbd nmbd winbind
sudo systemctl disable --now systemd-resolved
sudo rm -f /etc/resolv.conf
printf 'nameserver 127.0.0.1\nsearch ad2.sercebilisim.com\n' | sudo tee /etc/resolv.conf

Son iki satır sunucunun çözümleyicisini kendisine çeviriyor. Bu noktada makinenin dış dünyaya DNS erişimi geçici olarak kesilir; provizyon bittiğinde Samba’nın kendi DNS’i devralacak ve dışarıyı yapılandırmadaki forwarder adresine iletecek.

samba-tool domain provision: Domaini Kurmak

Provizyon, boş bir Samba kurulumunu gerçek bir domaine dönüştüren tek komuttur. Öncesinde varsayılan yapılandırma dosyasını kenara alın; samba-tool kendi dosyasını sıfırdan üretir ve mevcut dosya varsa üretmeyi reddeder.

Bash
sudo mv /etc/samba/smb.conf /etc/samba/smb.conf.varsayilan-yedek

sudo samba-tool domain provision \
  --use-rfc2307 \
  --realm=AD2.SERCEBILISIM.COM \
  --domain=AD2 \
  --server-role=dc \
  --dns-backend=SAMBA_INTERNAL \
  --adminpass='Servis123.' \
  --option='dns forwarder = 8.8.8.8'

Parametrelerin her biri geri dönüşü olan ya da olmayan bir karar taşıyor:

  1. --realm, Kerberos alanının adıdır ve büyük harfle yazılır. Bu bir stil tercihi değildir: Kerberos alan adlarını büyük harfle ayırt eder ve küçük harfle yazılmış bir realm ileride bilet doğrulama hatalarına yol açar.
  2. --domain, eski NetBIOS adıdır ve realm’in ilk parçasından bağımsızdır. On beş karakterle sınırlıdır, eski istemciler ve bazı uygulamalar hâlâ bu adı kullanır.
  3. --server-role=dc, makineyi üye sunucu değil denetleyici yapar. Rolü sonradan değiştirmek yeniden provizyon demektir.
  4. --dns-backend=SAMBA_INTERNAL, Samba’nın yerleşik DNS’ini seçer. Alternatifi BIND9_DLZ’dir ve BIND9’un gelişmiş yeteneklerini (görünüm tabanlı yanıt, karmaşık forward kuralları) gerektiren ortamlar içindir. Sıradan bir kurumda yerleşik sunucu fazlasıyla yeter ve bakımı yoktur.
  5. --use-rfc2307, dizine POSIX özniteliklerini (uidNumber, gidNumber) ekler. Ortamda Linux istemci varsa bunu başta açın; sonradan eklemek şema değişikliği demektir.
  6. --option='dns forwarder = ...', iç DNS’in bilmediği isimleri nereye soracağını söyler. Bu satır yazılmazsa sunucu dış dünyayı çözemez. Buraya genel bir çözümleyici (8.8.8.8, 1.1.1.1), servis sağlayıcınızın sunucusu ya da kurumda zaten çalışan bir DNS yazılabilir. Seçim tek başına teknik değil: dış sorgularınız yazdığınız adrese gider, dolayısıyla kurumsal bir ortamda kimin ne gördüğünü de belirler.

Komut, şema güncellemelerini uygulayıp bitirdiğinde özet bloğunu basar:

Çıktı
Server Role:           active directory domain controller
Hostname:              sambadc
NetBIOS Domain:        AD2
DNS Domain:            ad2.sercebilisim.com
DOMAIN SID:            S-1-5-21-1582394196-3898595221-1882180955

Üretilen yapılandırma dosyasının kısalığı şaşırtıcıdır ve bu kasıtlıdır: AD DC modunda davranışın çoğu dosyada değil dizinin kendisinde tutulur.

INI
[global]
	dns forwarder = 8.8.8.8
	netbios name = SAMBADC
	realm = AD2.SERCEBILISIM.COM
	server role = active directory domain controller
	workgroup = AD2
	idmap_ldb:use rfc2307 = yes

[sysvol]
	path = /var/lib/samba/sysvol
	read only = No

[netlogon]
	path = /var/lib/samba/sysvol/ad2.sercebilisim.com/scripts
	read only = No

Son iki adım: Kerberos istemci yapılandırmasını yerine koymak ve servisi başlatmak. Provizyon, doğru içerikli bir krb5.conf dosyasını zaten üretmiştir; sisteme kopyalamanız yeterlidir. Servis tarafında ise Ubuntu’ya özgü bir ayrıntı var: samba-ad-dc servisi paket kurulumunda maskelenmiş gelir ve maskesi kaldırılmadan başlatılamaz.

Bash
sudo cp /var/lib/samba/private/krb5.conf /etc/krb5.conf
sudo systemctl unmask samba-ad-dc
sudo systemctl enable --now samba-ad-dc

Kurulum Doğrulama: Portlar, DNS Kayıtları ve Kerberos Bileti

Servis ayağa kalktı, ama “çalışıyor” demek için bunu görmek gerekiyor. Doğrulamayı üç katmanda yapacağız ve üçü de ölçülebilir: makine artık hangi kapıları açtı, isimleri çözebiliyor mu, kimlik doğruluyor mu?

Açılan Portlar: Öncesi ve Sonrası

En hızlı doğrulama, dinlenen portları kurulumdan önceki halleriyle karşılaştırmaktır. Bu yüzden aşağıdaki komutu kurulumdan önce bir kez çalıştırıp çıktısını sakladım, kurulumdan sonra aynısını tekrarladım:

Bash
sudo ss -tuln

Sonuç tablosu, “domain kurmak” ifadesinin somut karşılığıdır:

PortServisKurulum öncesiKurulum sonrası
53DNSYalnız loopbackAğa açık
88KerberosKapalıAçık
135RPC uç nokta eşleyiciKapalıAçık
139NetBIOS oturumKapalıAçık
389LDAPKapalıAçık
445SMBKapalıAçık
464Kerberos parola değiştirmeKapalıAçık
636LDAPSKapalıAçık
3268Global CatalogKapalıAçık
3269Global Catalog (TLS)KapalıAçık

Tabloyu okurken şuna dikkat edin: bunların hiçbiri ayrı ayrı kurulmadı. Tek bir provizyon komutu, dört ayrı soruya cevap veren beş ayrı servisi birden ayağa kaldırdı. Federasyon kurulduğunda lisans masası, saha kaydı ve talimat panosu birlikte açılır; ayrı ayrı sipariş verilmez.

DNS: Kayıtlar Kendiliğinden Oluştu mu?

Domainin kendi DNS’i, istemcilerin denetleyiciyi bulmasını sağlayan SRV kayıtlarını provizyon sırasında üretir. Elle kayıt eklemeniz gerekmez; doğrulamanız gerekir.

Bash
host -t SRV _ldap._tcp.ad2.sercebilisim.com 127.0.0.1
host -t SRV _kerberos._udp.ad2.sercebilisim.com 127.0.0.1
host -t SRV _gc._tcp.ad2.sercebilisim.com 127.0.0.1
Çıktı
_ldap._tcp.ad2.sercebilisim.com has SRV record 0 100 389 sambadc.ad2.sercebilisim.com.
_kerberos._udp.ad2.sercebilisim.com has SRV record 0 100 88 sambadc.ad2.sercebilisim.com.
_gc._tcp.ad2.sercebilisim.com has SRV record 0 100 3268 sambadc.ad2.sercebilisim.com.

Çıktıda üç şeye bakın:

  • Son alan kaydın işaret ettiği sunucudur ve makinenizin tam adı olmalıdır. Kısa ad görüyorsanız FQDN adımı atlanmış demektir.
  • Sondan bir önceki sayı port numarasıdır; 389, 88 ve 3268 beklenen değerlerdir.
  • Sorgunun 127.0.0.1’e yapılması kasıtlıdır: sunucunun kendi kayıtlarını kendi DNS’inden okuduğunu doğruluyoruz.

Forwarder’ın çalıştığını da aynı anda ölçün, çünkü bu satır yazılmadıysa sunucu dış dünyaya kapanmıştır:

Bash
$ host -t A sercebilisim.com 127.0.0.1
sercebilisim.com has address 216.150.16.129
sercebilisim.com has address 216.150.1.65

Kerberos: İlk Bileti Almak

Asıl doğrulama budur. Domain kurulduysa, bir kullanıcı adı ve parola karşılığında bilet üretebiliyor olmalı.

Bash
kinit administrator@AD2.SERCEBILISIM.COM
klist
Çıktı
Ticket cache: FILE:/tmp/krb5cc_1001
Default principal: administrator@AD2.SERCEBILISIM.COM

Valid starting       Expires              Service principal
08/13/2026 20:55:13  08/14/2026 06:55:13  krbtgt/AD2.SERCEBILISIM.COM@AD2.SERCEBILISIM.COM
	renew until 08/14/2026 20:55:13

Bu üç satır, kurulumun başarılı olduğunun en güçlü kanıtı. Okurken şunlara bakın:

  1. krbtgt/... satırı bilet veren bileti (TGT) gösterir: lisansın kendisi. Bundan sonraki her erişim bu belgeye dayanacak.
  2. Başlangıç ve bitiş saatleri arasında on saat var. Yukarıda söylediğimiz analoji kopması burada ölçülüyor: sporcu lisansı sezon boyu geçerlidir, bu belge akşama kadar.
  3. renew until satırı, biletin parola tekrar sorulmadan yenilenebileceği tavanı verir.

kinit bu labda ayrıca beklemediğim bir satır bastı:

Çıktı
Warning: Your password will expire in 41 days on Thu 24 Sep 2026

Bu uyarı bir yan detay değil, makalenin tezinin kendisi. Kimse bu sunucuya parola politikası tanımlamadı; domain kurulur kurulmaz kendi kuralını getirdi ve ilk girişte onu size hatırlattı. Ölçüp doğrulayabilirsiniz:

Bash
$ sudo samba-tool domain passwordsettings show
Password complexity: on
Password history length: 24
Minimum password length: 7
Maximum password age (days): 42
Account lockout duration (mins): 30

Kurulum tarihine 42 gün eklerseniz uyarıdaki tarihi bulursunuz. Bir dizin bunu yapmaz; dizin ne yazarsanız onu saklar. Kural koyan şey federasyondur.

Tek Bilet, İki Servis: Domainin Ne Kazandırdığını Ölçmek

Portlar açık, bilet elde. Peki bu ne kazandırdı? Cevabı tek bir ölçümle görebilirsiniz ve bu ölçüm, tüm makaledeki en önemli çıktıdır.

Elimizdeki biletle parola girmeden iki ayrı servise erişeceğiz. Önce dosya paylaşımına:

Bash
smbclient //sambadc.ad2.sercebilisim.com/sysvol -N --use-kerberos=required -c 'ls'
Çıktı
  .                                   D        0  Thu Aug 13 20:54:05 2026
  ..                                  D        0  Thu Aug 13 20:54:05 2026
  ad2.sercebilisim.com                D        0  Thu Aug 13 20:54:05 2026

		10218772 blocks of size 1024. 4826996 blocks available

Sonra aynı biletle dizine:

Bash
ldapsearch -H ldap://sambadc.ad2.sercebilisim.com -Y GSSAPI \
  -b 'DC=ad2,DC=sercebilisim,DC=com' -s base '(objectClass=*)' dn
Çıktı
SASL/GSSAPI authentication started
SASL username: administrator@AD2.SERCEBILISIM.COM
SASL SSF: 256
SASL data security layer installed.
dn: DC=ad2,DC=sercebilisim,DC=com
result: 0 Success

İkisinde de parola sorulmadı. Şimdi bilet çantasına tekrar bakın:

Çıktı
Valid starting       Expires              Service principal
08/13/2026 20:55:13  08/14/2026 06:55:13  krbtgt/AD2.SERCEBILISIM.COM@AD2.SERCEBILISIM.COM
08/13/2026 20:55:38  08/14/2026 06:55:13  cifs/sambadc.ad2.sercebilisim.com@AD2.SERCEBILISIM.COM
08/13/2026 20:56:07  08/14/2026 06:55:13  ldap/sambadc.ad2.sercebilisim.com@AD2.SERCEBILISIM.COM

Bir parola girişi, üç bilet. Baştaki lisans duruyor, altına iki maç kartı eklendi: biri dosya servisi (cifs) için, biri dizin (ldap) için. İkisini de siz istemediniz, istemci yazılımlar lisansı gösterip kartlarını kendileri aldı.

Tek oturum açmanın (SSO) mekanizması tam olarak budur ve bir dizinin yapamayacağı şey de budur. OpenLDAP’a bağlanan her uygulama parolayı ayrı ayrı ister, çünkü elinde gösterilecek bir belge yoktur; her kapıda kimliğini baştan ispatlar.

Ölçüm Sırasında Alınan Hata da Öğretici

Yukarıdaki komutu ilk denememde localhost yazarak çalıştırdım ve reddedildi:

Çıktı
Kerberos auth with 'administrator@AD2.SERCEBILISIM.COM' to access 'localhost' not possible
session setup failed: NT_STATUS_ACCESS_DENIED

Sebep yetki değil, isim. Kerberos biletleri servis adına (SPN) yazılır ve localhost diye bir servis adı kayıtlı değildir. Peki neden makine kendi kendine bağlanırken bile tam adı istiyor? Çünkü bilet, biletin sunulacağı sunucunun adıyla şifrelenmiş bir parça taşır; adres değil ad. Yanlış ad, açılamayan bir zarf demektir.

Bu, sahada gerçek bir teşhis kuralına dönüşüyor: Kerberos’la ilgili bir erişim reddi gördüğünüzde önce yetkilere değil, bağlandığınız isme bakın. IP ile bağlanan bir yapılandırma Kerberos’u sessizce devre dışı bırakır.

Samba AD DC’de Kullanıcı, OU ve Grup İlkesi Yönetimi

Domain çalışıyor, ama içi boş. Kullanıcı açmak samba-tool ile tek satırdır:

Bash
sudo samba-tool user create ahmet 'Lab.Parola.2026' \
  --given-name=Ahmet --surname=Yilmaz
Çıktı
User 'ahmet' added successfully

Açtığınız kullanıcının dizinde nasıl durduğunu aynı Kerberos biletiyle sorgulayabilirsiniz:

Çıktı
dn: CN=Ahmet Yilmaz,CN=Users,DC=ad2,DC=sercebilisim,DC=com
sAMAccountName: ahmet
userPrincipalName: ahmet@ad2.sercebilisim.com

Dizin ağacının üst seviyesine baktığınızda ise domainin dizinden farkı gözle görülür hale gelir:

LDAP
CN=Users,DC=ad2,DC=sercebilisim,DC=com
CN=Computers,DC=ad2,DC=sercebilisim,DC=com
OU=Domain Controllers,DC=ad2,DC=sercebilisim,DC=com
CN=Builtin,DC=ad2,DC=sercebilisim,DC=com
CN=System,DC=ad2,DC=sercebilisim,DC=com

Bu birimleri kimse oluşturmadı. OpenLDAP kurduğunuzda ağaç boştur ve ou=Kullanicilar gibi birimleri siz açarsınız; burada ise CN=Computers ve OU=Domain Controllers kendiliğinden geldi, çünkü bir domainin bilgisayarları ve denetleyicileri olması yapının gereğidir. Liste isteğe bağlıdır, federasyonun defterleri değildir.

Aynı şey kurallar için de geçerli. Provizyon iki grup ilkesini hazır getirir:

Bash
$ sudo samba-tool gpo listall
GPO          : {31B2F340-016D-11D2-945F-00C04FB984F9}
display name : Default Domain Policy

GPO          : {6AC1786C-016F-11D2-945F-00C04FB984F9}
display name : Default Domain Controllers Policy

Bu ilkelerin dosyaları SYSVOL paylaşımında durur ve istemciler oraya SMB ile ulaşır. Grup ilkesinin nasıl oluşturulduğu, linklendiği ve hangi sırayla uygulandığı ayrı bir konudur ve GPO yönetimi rehberimizde ele alınıyor.

Windows İstemciler Grup İlkesini Nasıl Alıyor?

Windows istemciler için Windows’takinin aynısı grup ilkelerini tanımlayabilirsiniz, ve bunun sebebi ilk bakışta ters görünen bir yerde duruyor: grup ilkesini domain denetleyicisi uygulamaz. DC yalnız iki iş yapar, ilkeyi dizinde saklar ve dosyalarını SYSVOL üzerinden sunar. İndirip uygulayan, kendi istemci tarafı eklentileriyle Windows’un kendisidir.

Zorlama motoru istemcide olduğu için sunucunun işletim sistemi denklemden çıkar. İstemci dosyayı alır, uygular ve onu kimin sunduğunu hiç sormaz. Yönetimi de alıştığınız yerden yaparsınız: Windows bir makinedeki Group Policy Management Console, ya da komut satırında samba-tool gpo.

Windows’ta karşılığı olmayan tek ek adım, ADMX şablonlarıdır. Samba, Microsoft’un şablon dosyalarını dağıtmaz; SYSVOL’e siz yüklersiniz:

Bash
samba-tool gpo admxload -U Administrator
samba-tool gpo admxload -U Administrator --admx-dir=/yol/microsoft-admx

İkinci satırı atlamayın: Samba’nın kendi şablonlarını yükleyip Microsoft’unkileri yüklemezseniz Windows domain üyelerini yönetemez hale gelirsiniz.

Linux domain üyeleri de grup ilkesi alabilir, ama sözlük değişir. samba-gpupdate şunları uygular:

  • Sistem tarafı: parola ve Kerberos politikası, sudoers kuralları, PAM erişim kuralları, smb.conf seçenekleri
  • Dosya ve betik: dosya dağıtımı, sembolik link, cron işleri ve açılış betikleri
  • Kullanıcıya görünen: /etc/motd ve /etc/issue, GNOME ayarları, Firefox ve Chrome politikaları
  • Ağ ve güvenlik: OpenSSH yapılandırması, firewalld kuralları, sertifika otomatik kaydı

Hepsi geri alınabilir: politikayı kaldırdığınızda makinede iz kalmaz. Ama bunlar Windows ayarlarının Linux’ta çalışan hali değildir, Samba’nın kendi politika kümesidir. “Denetim Masasını gizle” ayarının Linux’ta bir karşılığı yoktur. Ortak olan dağıtım mekanizmasıdır, ayarların kendisi değil.

Son olarak veritabanının sağlığını doğrulayın:

Bash
$ sudo samba-tool dbcheck
Checking 283 objects
Checked 283 objects (0 errors)

Aynı GPO’yu Samba Tarafında Kurmak: USER_ARKA_PLAN

Mekanizmayı gördük, sıra onu çalıştırmaya geldi. Provizyonun getirdiği iki varsayılan ilkenin içi boştur, yani şu anda dağıtılacak bir ayar yok. Kuracağımız ilkeyi rastgele seçmedik: Windows tarafında zaten yaptığımız bir GPO’nun aynısını burada kuruyoruz. GPO yönetimi rehberimizde USER_ARKA_PLAN adlı bir ilkeyle kullanıcıların masaüstünü siyaha çeviriyoruz; burada aynı adı, aynı dosyayı ve aynı stili kullandık. Değişen tek şey ilkeyi kuran araç, ve karşılaştırmayı anlamlı kılan da bu.

Önce görsel NETLOGON paylaşımına konur, sonra ilke oluşturulup hedefine linklenir:

Bash
sudo samba-tool ou create "OU=Kullanicilar,DC=ad2,DC=sercebilisim,DC=com"
sudo samba-tool gpo create USER_ARKA_PLAN -U administrator
sudo samba-tool gpo load "{GPO-GUID}" --content=wallpaper.json -U administrator
sudo samba-tool gpo setlink "OU=Kullanicilar,DC=ad2,DC=sercebilisim,DC=com" "{GPO-GUID}" -U administrator

Windows ile arasındaki tek gerçek fark üçüncü satırda. GPMC’de bu ayarı User Configuration → Policies → Administrative Templates → Desktop → Desktop → Desktop Wallpaper yolundan, hazır bir arayüzle seçersiniz. samba-tool’un böyle bir arayüzü yoktur; ayarın karşılığı olan registry değerlerini kendiniz verirsiniz:

JSON
[
  {
    "keyname": "Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\System",
    "valuename": "Wallpaper",
    "class": "USER",
    "type": "REG_SZ",
    "data": "\\\\ad2.sercebilisim.com\\netlogon\\siyah.png"
  },
  {
    "keyname": "Software\\Microsoft\\Windows\\CurrentVersion\\Policies\\System",
    "valuename": "WallpaperStyle",
    "class": "USER",
    "type": "REG_SZ",
    "data": "0"
  }
]

Bu fark bir uyumsuzluk değil, bir araç farkıdır ve ikisi de aynı dosyayı üretir. Samba’nın yazdığı Registry.pol çözüldüğünde Windows’un beklediği PReg biçimi karşımıza çıkıyor:

Çıktı
PReg
[Software\Microsoft\Windows\CurrentVersion\Policies\System]
    Wallpaper      = \\ad2.sercebilisim.com\netlogon\siyah.png
    WallpaperStyle = 0

Bu ilkeyi komut satırı yerine grafik arayüzle de kurabilirsiniz. RSAT kurulu bir Windows makinesindeki GPMC, buradaki Samba denetleyicisine bağlanıp aynı GPO’yu açar ve düzenler; yönettiği domain yine ad2.sercebilisim.com olur, yani değişen tek şey oturduğunuz koltuktur. Araçların kurulumunu ve neyi yönettiklerini RSAT kurulumu rehberimizde ele alıyoruz. Komut satırını burada tercih etmemizin sebebi, işin tamamının Linux üzerinden yürütülebildiğini göstermek.

Protokollerin bu kadar sorunsuz oturduğunu hayal etmekte zorlanıyorsanız, aşağıdaki kareye bakın.

Windows'taki Group Policy Management Console'da ad2.sercebilisim.com ormanı ve samba-tool ile kurulmuş USER_ARKA_PLAN ilkesinin Details sekmesi: User version 1 (AD), 1 (SYSVOL)
Microsoft'un kendi konsolu, Linux üzerinde çalışan bir denetleyicinin domainini ve komut satırından kurulmuş bir ilkeyi hiçbir fark gözetmeden okuyor.

Bu ekranda dikkat çeken şey, olağanüstü hiçbir şeyin olmaması. Ama üç satır, işin gerçekten oturduğunu ölçülebilir biçimde gösteriyor:

  1. Unique ID: {C6BB7ABF-...} komut satırında samba-tool gpo create’in bastırdığı GUID’in aynısı. Konsol ilkeyi tanımakla kalmıyor, aynı nesneyi gösteriyor.
  2. User version: 1 (AD), 1 (SYSVOL) en kıymetli satır. Bir GPO’nun iki yarısı vardır: dizindeki nesne ve SYSVOL’deki dosyalar. Bu iki sayı eşitse yarılar tutarlıdır; ayrıldığında GPO’lar sessizce yanlış uygulanmaya başlar ve teşhisi zor arızaların klasik kaynağı olur. Sunucu tarafında okuduğumuz GPT.INI değeri olan 65536, Windows’un burada gösterdiği bu iki sayının ta kendisi.
  3. Computer version: 0, bilgisayar kapsamına hiçbir ayar tanımlamadığımızı doğruluyor; yukarıdaki gpresult çıktısında bilgisayar tarafının neden boş göründüğünün cevabı da bu.

Konsol, karşısındaki denetleyicinin Linux olduğunu ne bilir ne sorar.

Bu, grup ilkesine özgü de değil. dsa.msc ile açılan Active Directory Users and Computers aynı yoldan bağlanır ve bu domaindeki kullanıcıları, grupları ve birimleri aynı şekilde yönetir; Kullanicilar birimini ve içindeki hesabı orada da görürsünüz. Sebebi yine mekanizmada: bu konsollar karşı tarafta bir işletim sistemi değil, konuşulan protokolleri arar. Hangi konsolların geldiğini ve nasıl kurulduklarını RSAT kurulumu rehberimizde ele alıyoruz.

Geriye tek soru kalıyor: ilke yönetim konsolunda düzgün görünüyor, peki istemciye gerçekten ulaşıp uygulanıyor mu? Bunu Grup İlkesi İstemciye Ulaştı mı bölümünde ölçüyoruz.

Windows İstemcide Doğrulama: Katılım, Kerberos ve Grup İlkesi

Bir önceki bölümde grup ilkesini istemcinin uyguladığını, denetleyicinin yalnız sakladığını ve sunduğunu anlattık. Şimdi bunun gerçekten böyle olduğunu ölçüyoruz, çünkü Samba’yı FreeIPA’dan ayıran iddia tam olarak burada sınanıyor.

Katılmanın istemci tarafındaki adımları ve sık çıkan hataları bilgisayarı domaine ekleme rehberimizde ele alıyoruz; burada yapılan tek şey, kurduğumuz domainin bir Windows sunucuyu kabul ettiğini doğrulamak. Tek ön koşul, istemcinin DNS adresinin bu denetleyiciyi göstermesi.

Katılma Sonrası: Hesap Açıldı mı, Makine Domainde mi?

Labda katılan makine Windows Server 2025 Datacenter Evaluation. Katılma tamamlandıktan hemen sonra dizindeki bilgisayar nesnesine bakıldığında tablo yarım görünüyordu, ve bu yarımlık öğretici:

AlanKatılmadan hemen sonraMakine domaine açılıp oturum açtıktan sonra
userAccountControl40964096
pwdLastSetdoludolu
dNSHostNameyokwindows-server.ad2.sercebilisim.com
operatingSystemyokWindows Server 2025 Datacenter Evaluation
servicePrincipalNameyokHOST/, RestrictedKrbHost/, WSMAN/
DNS A kaydıNXDOMAIN192.168.1.41

İlk iki satır katılmanın başarılı olduğunu söylüyor: 4096 doğru hesap tipidir (makine hesabı) ve dolu bir pwdLastSet, makine hesabının parolasının kurulduğunu, yani güvenli kanalın oluştuğunu gösterir.

Alt üç satır ise farklı bir şey söylüyor ve karıştırılmaması gereken ayrım budur. dNSHostName, operatingSystem ve DNS kaydını denetleyici yazmaz; makinenin kendisi yazar ve bunu domaine üye olarak ilk açılışında yapar. Yani katılma komutu hesabı açar, makineyi domaine sokmaz. Sahada “join oldu ama çalışmıyor” diye rapor edilen arızaların bir kısmı tam olarak bu ara durumdur ve üç özniteliğe bakarak saniyeler içinde ayırt edilir.

Bu satırların dolması aynı zamanda tersini de gösteriyor: dizin artık istemcinin hangi işletim sistemini çalıştırdığını biliyor, çünkü makine kendi bildirdi.

İstemci Tarafından Kerberos

Sunucu tarafında aldığımız biletleri yukarıda görmüştük. Aynı olayın istemciden çekilmiş hali daha güçlü, çünkü Windows’un kime güvendiğini kendi ağzından söylüyor:

Çıktı
#1>     Client: Administrator @ AD2.SERCEBILISIM.COM
        Server: krbtgt/AD2.SERCEBILISIM.COM @ AD2.SERCEBILISIM.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Kdc Called: sambadc.ad2.sercebilisim.com

#2>     Client: Administrator @ AD2.SERCEBILISIM.COM
        Server: cifs/sambadc.ad2.sercebilisim.com @ AD2.SERCEBILISIM.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Kdc Called: sambadc.ad2.sercebilisim.com

Üç satır önemli:

  1. Kdc Called: sambadc... Windows, bilet veren makamın hangisi olduğunu yazıyor ve o makine Linux.
  2. AES-256-CTS-HMAC-SHA1-96 kullanılan şifreleme; eski ve zayıf bir yönteme düşülmemiş.
  3. krbtgt ve cifs ayrı satırlarda: biri lisansın kendisi, diğeri paylaşıma girmek için alınan maç kartı. İstemci tarafında da aynı ikili yapı.

Grup İlkesi İstemciye Ulaştı mı?

Sıra, kurduğumuz ilkenin istemciye gerçekten ulaşıp ulaşmadığına geldi. İstemcide gpupdate /force çalıştırıldığında hem bilgisayar hem kullanıcı politikası başarıyla güncellendi. Raporu iki kapsamda ayrı ayrı okumak gerekiyor, çünkü ikisi farklı şey söylüyor. Önce bilgisayar tarafı:

Çıktı
COMPUTER SETTINGS
    CN=WINDOWS-SERVER,CN=Computers,DC=ad2,DC=sercebilisim,DC=com
    Last time Group Policy was applied: 14.08.2026 at 02:10:27
    Group Policy was applied from:      sambadc.ad2.sercebilisim.com
    Domain Name:                        AD2
    Domain Type:                        Windows 2008 or later

    Applied Group Policy Objects
    -----------------------------
        N/A

The following GPOs were not applied because they were filtered out
    Default Domain Policy
        Filtering: Not Applied (Empty)

Bu çıktıda iki satır birlikte okunur:

  1. Group Policy was applied from: sambadc.ad2.sercebilisim.com aradığımız kanıttır. Windows, grup ilkesini kimden aldığını adıyla yazıyor ve o makine Linux. Bu satır varsa dizin, SYSVOL ve istemci arasındaki zincir çalışıyor demektir.
  2. Applied Group Policy Objects: N/A ise ilk bakışta arıza gibi görünür, değildir. Sebebi hemen altında yazıyor: Default Domain Policy boş olduğu için işlenmeden atlanmış. Kurduğumuz USER_ARKA_PLAN da burada görünmez, çünkü o bir kullanıcı ilkesi; bilgisayar kapsamına hiçbir ayar tanımlamadık.

Yani bilgisayar tarafında beklenen tablo tam olarak budur: kanal çalışıyor, o kapsamda taşınacak bir yük yok. Asıl aradığımız şey kullanıcı tarafında.

İlkenin hedeflediği hesap ilker.pehlivan. O hesapla oturum açılıp politika yenilendikten sonra kullanıcı kapsamındaki rapor şöyle:

Çıktı
RSOP data for AD2\ilker.pehlivan on WINDOWS-SERVER : Logging Mode

USER SETTINGS
    CN=İlker Pehlivan,OU=Kullanicilar,DC=ad2,DC=sercebilisim,DC=com
    Last time Group Policy was applied: 14.08.2026 at 02:31:32
    Group Policy was applied from:      sambadc.ad2.sercebilisim.com
    Domain Name:                        AD2

    Applied Group Policy Objects
    -----------------------------
        USER_ARKA_PLAN

The following GPOs were not applied because they were filtered out
    Default Domain Policy
        Filtering:  Not Applied (Empty)

Bu çıktı üç soruyu birden cevaplıyor: ilke hangi kullanıcıya uygulandı (OU=Kullanicilar altındaki hesap), nereden geldi (sambadc, yani Linux denetleyici) ve hangi ilke uygulandı (USER_ARKA_PLAN). Az önce boş görünen Applied Group Policy Objects listesi artık dolu; Default Domain Policy ise hâlâ (Empty) olduğu için atlanıyor, çünkü ona bir ayar koymadık.

Geriye gözle görülen sonuç kalıyor. Ama tek başına siyah bir ekran kanıt değildir: masaüstü zaten siyah olabilir, kullanıcı kendisi seçmiş olabilir. Kanıtı tamamlayan şey, ekranın renginin kilit mesajıyla aynı karede görünmesi.

Windows Server 2025'te Personalization Background ekranı: arka plan siyah ve altında 'Some of these settings are managed by your organization' uyarısı, oturum açan kullanıcı ilker.pehlivan@ad2.sercebilisim.com
Siyah ekran tek başına kanıt değil; onu kanıta çeviren, aynı karedeki 'kuruluşunuz tarafından yönetiliyor' uyarısı ve oturumun Samba domainindeki kullanıcıya ait olması.

Ekrandaki Some of these settings are managed by your organization satırı, Windows’un o ayarı artık kullanıcıya kapattığını söylüyor. Yani ilke yalnızca uygulanmakla kalmadı, kullanıcının değiştirmesini de engelledi. Kişiselleştirme bölümü de griye düşmüş durumda.

Bu, Samba tarafında kurulmuş bir grup ilkesinin bir Windows istemcide hem uygulandığının hem dayatıldığının kanıtı.

Buradan çıkan sonuç, makalenin başında kurduğumuz tabloyu kanıtlıyor: FreeIPA’nın veremediği iki şeyi, yani Windows istemcinin domaine katılmasını ve grup ilkesinin bir Windows istemciye dağıtılmasını, Samba veriyor.

Samba AD DC Sık Yapılan Hatalar ve Teşhis

Doğrulama adımlarından biri beklediğiniz çıktıyı vermediyse, sebep büyük ihtimalle aşağıdaki dörtten biridir. Sıralama, arızanın görülme sıklığına göre:

BelirtiMuhtemel sebepKontrol
Provizyon FQDN hatasıyla duruyor/etc/hosts içinde 127.0.1.1 satırı duruyorhostname -f kısa ad dönüyor mu
Servis başlıyor ama DNS cevap vermiyor53 portunu systemd-resolved tutuyorsudo ss -tulnp | grep :53
samba-ad-dc başlatılamıyorServis maskeli, ya da smbd/nmbd çakışıyorsystemctl is-enabled samba-ad-dc
Kerberos erişimi reddediliyorIP ya da localhost ile bağlanılıyorBağlantıda tam ad kullanılıyor mu

Teşhis sırasında en çok zaman kaybettiren iki nokta şunlar:

  • Portun açık görünmesi servisin çalıştığı anlamına gelmez. 53 portunda bir şey dinliyor olabilir ama o şey systemd-resolved olabilir. Port numarasına değil, portu tutan sürece bakın; ss komutunun -p bayrağı bunu verir.
  • Ubuntu’da samba-ad-dc servisi maskeli gelir ve maskeli bir servis enable edilse bile başlamaz. Hata mesajı bunu her zaman açık söylemez.

Kurulum sonrası saat senkronizasyonunu da atlamayın: Kerberos, istemci ile denetleyici arasındaki saat farkının beş dakikayı aşmasına izin vermez ve fark aşıldığında hata mesajında zaman geçmez. Sunucuya chrony bu rehberde kuruldu; iç saat kaynağının nasıl yapılandırıldığını Linux NTP sunucusu rehberimizde ele alıyoruz.

Samba AD DC’nin Sınırları: Neyi Karşılamaz

Kurulum çalışıyor, ama bir teknolojiyi tanımak sınırlarını bilmekle tamamlanır. Samba AD DC bir Windows Domain Controller’ın yerini büyük ölçüde alır; tamamen değil.

  • İkinci denetleyici eklemek SYSVOL’ü kendiliğinden çoğaltmaz. Windows, grup ilkesi dosyalarını denetleyiciler arasında DFS-R ile replike eder; Samba bu mekanizmayı uygulamadığını kendi belgelerinde yazıyor. Dizin replike olur, SYSVOL olmaz.
  • Şema düzeyinde bazı ileri roller eksiktir. Örneğin AD Certificate Services, Samba’nın kendi içinde gelen bir rol değildir; sertifika otoritesi gereken bir ortamda o katmanı ayrıca kurmanız gerekir.
  • Fonksiyonel seviye provizyonda 2008 R2 kurulur, ama sabit değildir. samba-tool domain level raise ile yükseltilir; tavanı sürümünüz belirler, bu rehberdeki Samba 4.19 2012_R2’ye kadar çıkar, 2016 için 4.20 gerekir. En yeni Windows seviyelerine bağlı bir özellik bekliyorsanız sürümünüzün tavanını önceden doğrulayın.
  • Destek çizgisi dağıtıma bağlıdır. Yukarıda geçti ama tekrar etmeye değer: Red Hat ailesinde AD DC rolü destek kapsamı dışındadır.

Bunlardan ilki mimari kararınızı doğrudan değiştirdiği için açmaya değer. Bir önceki bölümde grup ilkelerinin SYSVOL üzerinden sunulduğunu gördük; ikinci bir Samba denetleyicisi kurduğunuzda o paylaşımı çoğaltma işi size kalır. Pratikte rsync ya da robocopy tabanlı bir kurgu, cron işi ve SSH anahtarları demektir. Dahası, denetleyicilerden birini “grup ilkelerinin düzenlendiği tek yer” ilan etmeniz gerekir: diğerlerinde yapılan değişiklikler senkronizasyonda ezilir.

Ama bu, ikinci denetleyiciyi anlamsız kılmaz ve ayrımı doğru kurmak önemli. Dizin replikasyonu çalışır, yani kimlik doğrulama gerçekten yedeklenir: SYSVOL’ü taşıyan sunucu kapansa bile kullanıcılar oturum açmaya devam eder. Kırılan şey yalnızca politika dağıtımıdır; grup ilkeleri ve oturum açma betikleri, o paylaşımı sunan denetleyici geri gelene kadar uygulanmaz.

Ölçekte Samba AD DC: Sınır Kullanıcı Sayısı Değil

Buraya kadarki sınırlar teknikti. Sonuncusu değil, ve pratikte en belirleyici olan o.

Kullanıcı sayısı Samba için erken biten bir sınır değil. Fransız bakanlıkları NT4 desteği sona erince Samba AD DC’ye geçti; Maliye Bakanlığı için 100.000 kullanıcı hedeflendi ve sonuçta 300.000 hesapla çalışıldığı aktarılıyor. Yani birkaç bin kullanıcılı bir kurum, Samba ölçeğinde büyük değil orta bir kurulumdur.

Bunun bedeli donanımda ödenir ve formülü bellidir: 4 GB taban, üstüne her 1000 kullanıcı için 2 GB. Üç bin kullanıcılı bir ortam yaklaşık 10 GB bellek ve 6 vCPU ister. Sebebi de somut: her oturum açmada grup ilkelerini sunmak için ayrı bir smbd süreci başlar, yani bellek baskısını yaratan şey nesne sayısı değil eşzamanlı oturum açma sayısıdır.

Asıl sınır burada başlıyor: sunucunun kapasitesi değil, sizin yönetim modeliniz. Elle yönetim birkaç yüz kullanıcıya kadar yürür, binlerle ölçülen bir ortamda yürümez, ve bunu tahmin etmeye gerek yok, Samba’nın kendi belgeleri yazıyor. Büyük domainler için yazdıkları sayfada kullanıcı ve grup listeleyen komutların nesne sayısı arttıkça yavaşladığını, bir dakikaya ulaştıklarında hata vermeye başladıklarını söylüyor ve bunların yerine dizini programatik olarak sorgulamayı öneriyorlar.

Buradan çıkan ayrım, bu rehberin nasıl okunması gerektiğini de belirliyor:

  • Kurulum zamanı. Bu rehberdeki her şey SSH ile yapıldı ve doğrusu da budur. Kurulum bir kez yapılan bir inşa işidir.
  • İşletme zamanı. Günlük yönetim denetleyiciye bağlanarak yapılmaz. Nesne yönetimi ayrı bir makineden RSAT ile, toplu işlemler dizine ağ üzerinden konuşan otomasyonla, kurumsal ölçekte ise kullanıcı yaşam döngüsü İK kaynağından beslenen bir kimlik yönetimiyle yürür.

Bu ayrım bir üslup tercihi değil, güvenlik modelinin gereği. Microsoft’un ayrıcalıklı erişim rehberi, bir domain denetleyicisine yapılan her etkileşimli ve uzak oturum açmayı yüksek hassasiyetli bir olay sayar ve onaylı yönetici listesi dışındaki her girişte alarm üretilmesini ister. Günlük işinizi denetleyiciye bağlanarak yaparsanız her gün alarm üretirsiniz: kendi erken uyarı sisteminizi kendi elinizle gürültüye çevirmiş olursunuz.

Aynı sonuca operasyon tarafından da varılıyor. Manuel, tekrarlayan ve sistem büyüklüğüyle doğrusal ölçeklenen işin mühendislik literatüründeki adı toil’dir ve azaltılması gereken bir maliyet kalemi sayılır. Dört bin kullanıcılı bir ortamda kullanıcı açmak için sunucuya bağlanmak tam olarak bu tanıma girer.

Sonuç: Liste Tutmakla Lisans Vermek Aynı İş Değil

Samba AD DC kurulumu, bir Linux sunucuyu kullanıcı listesi tutan bir makineden, kimlik doğrulayan ve kural dağıtan bir otoriteye çeviriyor. Aradaki farkı en iyi anlatan şey bu rehberde aldığımız iki ölçüm: kurulumdan önce kapalı olan on port, kurulumdan sonra tek komutla açıldı; ve bir kez girilen parola, iki ayrı servise ayrı ayrı geçerli üç belge üretti.

Kurulum kararını verirken teknik yeteneğe değil ihtiyaca bakın. Yalnızca uygulamalarınızın okuyacağı bir kullanıcı listesi arıyorsanız bir dizin yeterlidir ve daha az bakım ister; ama makineleri yönetecek, tek oturum açma kuracak ve merkezi kural dağıtacaksanız listenin yapamayacağı işler başlar. Ortamda Windows istemci de varsa, Linux üzerinde bunu karşılayan tek yol Samba’dır.

Sıradaki adım, kurduğunuz domaine ilk üyeyi katmaktır. İstemci tarafındaki adımları ve sık çıkan katılma hatalarını bilgisayarı domaine ekleme rehberimizde, Windows tarafında aynı rolün nasıl kurulduğunu ise Active Directory kurulum rehberimizde bulabilirsiniz.

Samba AD DC Kurulumu Hakkında Sık Sorulan Sorular

Çalışan bir Windows domaininiz varsa Samba AD DC kurmak için bir sebebiniz yok demektir; ikinci bir domain, birleştirme değil bölünme üretir. Samba'nın kazandırdığı senaryo başkadır: domain yokken sıfırdan kurulacaksa, ya da mevcut domaine ek denetleyici gerekiyor ve o makineye Windows Server lisansı almak istemiyorsanız. İkinci durumda Samba mevcut domaine ek DC olarak katılır, ayrı bir domain açmaz. Karar ölçütü lisans maliyeti değil, kaç tane kimlik kaynağınız olacağıdır: doğru cevap her zaman bir tanedir.
Teknik olarak yapabilirsiniz ama Samba projesinin kendi tavsiyesi bunun aksi yönünde: bir AD DC yalnızca kimlik doğrulama ve dizin hizmeti vermeli, dosya ve yazıcı paylaşımını domaine katılmış üye sunucular üstlenmeli. Sebep pratik: DC üzerindeki paylaşım izinleri domain veritabanıyla aynı makinede tutulduğu için bir yapılandırma hatası doğrudan kimlik katmanını etkiler. Ayrıca DC'yi bir gün yeniden kurmanız gerektiğinde üzerindeki dosya servisini de taşımak zorunda kalırsınız.
Evet, Samba AD DC'nin FreeIPA'dan ayrıldığı nokta tam olarak budur. FreeIPA bir Windows istemciyi domaine alamaz, yalnızca mevcut bir AD ile güven ilişkisi kurabilir. Samba ise Windows istemcinin beklediği protokollerin tamamını (Kerberos, LDAP, DNS, SMB ve grup ilkesi dağıtımı) sunduğu için istemci açısından bir Windows Domain Controller'dan ayırt edilemez. Grup ilkesi yönetimini de Windows tarafındaki alışılmış konsollarla yaparsınız.
Geçici olarak keser, sonra Samba'nın kendi DNS'i devralır. Sıra önemlidir: paketleri kurarken sistemin DNS'i çalışıyor olmalı, bu yüzden systemd-resolved'i apt işlemlerinden sonra kapatırsınız. Provizyon bittiğinde sunucu kendi DNS servisini çalıştırır ve kendisine sorar; dışarıdaki isimleri de yapılandırmadaki forwarder adresine ileterek çözer. Yani sonuçta hem iç isimler hem dış isimler çözülür, ama artık ikisini de tek bir servis karşılar.
Kurabilirsiniz ama desteklenmez ve bu ayrım üretim ortamında önemlidir. Red Hat, kurumsal Linux dağıtımlarında Samba'yı yalnızca dosya sunucusu ve domain üyesi rolünde destekler; AD DC rolü destek kapsamı dışındadır ve dağıtımın deposundaki paket bu rol için gerekli bileşenleri içermeyebilir. Debian ve Ubuntu tarafında ise AD DC rolü paketlenmiş halde gelir. Dağıtım seçimini alışkanlığa göre değil bu destek çizgisine göre yapın.
İlker Pehlivan

Yazan

İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştüren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.

Benzer Makaleler

Microsoft Entra ID Connect Kurulumu: AD'yi Buluta Bağlama

Microsoft Entra ID Connect kurulumu, UPN senkronizasyonu ve Seamless SSO yapılandırması. Active Directory kullanıcılarını Microsoft 365'e tek kimlikle bağlayan adım adım rehber.

3 dk okuma

Active Directory GPO Yönetimi: Group Policy Rehberi

Active Directory Group Policy (GPO) yönetimi: GPO nasıl oluşturulur, LSDOU uygulama sırası, sık kullanılan politikalar ve GPO sorun giderme adımları.

16 dk okuma

Active Directory DNS Yapılandırması: Forwarder ve Zone

Active Directory DNS forwarder, reverse lookup zone, conditional forwarder ve split-brain DNS yapılandırması. Windows Server'da kurulum ve sorun giderme için ekran görüntülü rehber.

18 dk okuma

Active Directory Kullanıcı, Grup ve OU Yönetimi (AGDLP)

Active Directory'de OU tasarımı, kullanıcı ve grup yönetimi: AGDLP modeli, PowerShell ile toplu kullanıcı oluşturma, yetki devri ve isimlendirme standartları.

16 dk okuma

Active Directory UPN Suffix Yapılandırması

Active Directory'de alternatif UPN suffix ekleme ve kullanıcı UPN'lerini güncelleme. Mail adresi ile Windows girişini tek kimlikte birleştiren adım adım rehber.

5 dk okuma

Active Directory Kurulum Rehberi: Windows Server 2025

Windows Server 2025 üzerinde Active Directory kurulumu: ön koşullar, DC promotion, DNS doğrulama, ikinci DC ekleme ve kurulum sonrası sağlık kontrolleri.

20 dk okuma

Active Directory Rehberi: Mimari, Kurulum ve Yönetim

Active Directory nedir, nasıl kurulur ve yönetilir? FSMO, GPO, replication, güvenlik, yedekleme ve hybrid identity dahil Windows Server'da uçtan uca AD rehberi.

25 dk okuma

Active Directory Certificate Services (AD CS) Kurulumu

Active Directory Certificate Services kurulumu adım adım: Enterprise Root CA yapılandırması, geri alınamayan kararlar, AIA/CDP ayarı ve kurulum doğrulaması.

25 dk okuma

Bilgisayarı ve Sunucuyu Domain'e Ekleme: Ön Koşul ve Hatalar

Windows bilgisayar ve sunucuyu domain'e ekleme: DNS, saat ve hostname ön koşulları, Add-Computer, OU yerleşimi, redircmp ve sık görülen katılım hataları.

25 dk okuma

Hypervisor Nedir? Sanallaştırma Katmanı Nasıl Çalışır

Hypervisor bir işletim sistemine sahte donanım sunar. Tip 1 ve Tip 2 farkı, vCPU ve RAM overcommit, snapshot ile yedek ayrımı ve doğru boyutlandırma.

16 dk okuma

IIS Nedir? Windows Server'da Kurulum, HTTPS ve Güvenlik

IIS nedir, Windows Server'da nasıl kurulur? Web sunucusu rolünü ekleyin, iç CA sertifikasıyla HTTPS bağlayın, SNI ve güvenliği yapılandırın.

22 dk okuma

Linux NTP Sunucusu Kurulumu: chrony ile İç Saat Kaynağı

Linux NTP sunucusu kurulumu: Ubuntu'da chrony yapılandırması, allow ile istemci ağı, doğrulama ve izleme. Platform kararı ve Stratum 1 için GPS/PPS.

23 dk okuma

FreeRADIUS Kurulumu: Ubuntu'da Adım Adım

Ubuntu üzerinde FreeRADIUS ile adım adım kurulum: paket kurulumu, istemci ve kullanıcı tanımı, radtest ile doğrulama ve paket düzeyinde yakalama.

8 dk okuma

RSAT Kurulumu: AD Yönetim Konsolları ve GPMC

RSAT kurulumu: Windows 10, 11 ve Windows Server'da uzaktan sunucu yönetim araçları, GPMC ve ADUC konsolları, nereden çalıştırılacağı ve neyi yönettiği.

19 dk okuma

Ubuntu Server Nasıl Kurulur? 24.04 LTS Kurulum Rehberi

Ubuntu Server 24.04 LTS kurulumu adım adım: donanım gereksinimleri, statik IP ve LVM disk yapılandırması, OpenSSH kurulumu ve kurulum sonrası ilk kontroller.

14 dk okuma

Ubuntu Server: LTS, Sıkılaştırma ve Dağıtım Seçimi

Kurumsal Ubuntu Server rehberi: dağıtım karşılaştırması, LTS ve Ubuntu Pro destek takvimi, paket yönetimi, sıkılaştırma ve Active Directory entegrasyonu.

22 dk okuma

Veri Merkezi Migration: Taşıma Planı ve Kesinti Penceresi

Veri merkezi taşıma nasıl planlanır: envanter ve bağımlılık analizi, kesinti penceresi, her adım için geri dönüş planı ve taşıma gecesinde doğrulama sırası.

13 dk okuma

Kurumsal Veri Yedekleme ve Felaket Kurtarma Çözümleri

Kurumsal veri yedekleme ve felaket kurtarma: 3-2-1-1-0 kuralı, RTO/RPO hedefleri, değiştirilemez depolama ve düzenli geri yükleme testiyle yedekleme çözümleri.

15 dk okuma

Windows Server DHCP Kurulumu: Scope, Rezervasyon ve Failover

Windows Server DHCP kurulumu: scope ve exclusion yapılandırması, MAC adresiyle IP rezervasyonu, failover ve doğrulama. Ekran görüntülü adım adım rehber.

35 dk okuma

Windows Server 2025: Roller ve Lisanslama

Windows Server sürümleri, çekirdek bazlı lisanslama ve CAL modeli, sunucu rolleri ve destek yaşam döngüsü: hangisini ne zaman kuracağınızın kurumsal rehberi.

25 dk okuma

Windows Server 2025 Kurulum Rehberi: Adım Adım

Windows Server 2025 kurulumu: sürüm ve lisans seçimi, kurulum medyası hazırlama, adım adım kurulum, hostname, statik IP, NTP ve temel güvenlik sıkılaştırma.

21 dk okuma

Cacti Kurulumu: Ubuntu'da SNMP ile Ağ İzleme

Ubuntu 24.04'te Cacti kurulumu: apt paketinin web sihirbazını neden atladığı, SNMP ile switch izleme, trafik grafiği oluşturma ve Zabbix'ten farkı adım adım.

16 dk okuma

Syslog Sunucusu Kurulumu: Ubuntu'da Merkezi Log

Ubuntu 24.04'te rsyslog ile merkezi syslog sunucusu kurulumu: imudp, 514 portu, gönderen başına ayırma, switch bağlama ve disk planı. Lab ölçümüyle.

17 dk okuma

Active Directory Güvenlik Sıkılaştırması Rehberi

Active Directory'i saldırılara karşı sıkılaştırma: Tier modeli, LAPS, Fine-Grained Password Policy ve ayrıcalıklı hesap izleme ile pratik adımlar ve hatalar.

17 dk okuma

Ücretsiz Değerlendirme

Linux sunucularınız AD'ye bağlı değilse kimlik iki yerde tutuluyor demektir. Birleştirelim.