Samba AD DC Kurulumu: Linux'ta Domain Controller

Samba AD DC kurulumu, bir Linux sunucuyu Windows istemcilerin de katılabildiği tam yetkili bir domain controller’a 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 Nedir? Dizin ile Domain Arasındaki Fark

Samba AD DC, Samba 4 ile gelen ve bir Linux makineyi Active Directory domain controller 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 Group Policy 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 DC’si, mevcut bir Windows forest’ine ek DC 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:

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:

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 DC’yse 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 controller’ın 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:

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ç:

$ 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:

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:

$ 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 zone’una 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.

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:

$ 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.

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.

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 DC 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 bir Public DNS’in (8.8.8.8, 1.1.1.1), servis sağlayıcınızın sunucusunun ya da kurumda zaten çalışan bir DNS’in adresi 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:

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.

[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.

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:

sudo ss -tuln

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

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 DC’yi bulmasını sağlayan SRV kayıtlarını provizyon sırasında üretir. Elle kayıt eklemeniz gerekmez; doğrulamanız gerekir.

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

_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:

$ 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ı.

kinit administrator@AD2.SERCEBILISIM.COM
klist

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ı:

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 password policy tanımlamadı; domain kurulur kurulmaz kendi kuralını getirdi ve ilk girişte onu size hatırlattı. Ölçüp doğrulayabilirsiniz:

$ 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.

Kerberos Biletiyle Parolasız Erişim: Tek Bilet, İki Servis

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:

smbclient //sambadc.ad2.sercebilisim.com/sysvol -N --use-kerberos=required -c 'ls'

  .                                   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:

ldapsearch -H ldap://sambadc.ad2.sercebilisim.com -Y GSSAPI \
  -b 'DC=ad2,DC=sercebilisim,DC=com' -s base '(objectClass=*)' dn

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:

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:

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:

sudo samba-tool user create ahmet 'Lab.Parola.2026' \
  --given-name=Ahmet --surname=Yilmaz

User 'ahmet' added successfully

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

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:

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 DC’leri 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 Group Policy’yi hazır getirir:

$ 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. GPO’nun 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ı GPO’ları tanımlayabilirsiniz, ve bunun sebebi ilk bakışta ters görünen bir yerde duruyor: Group Policy’yi domain controller 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:

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 Group Policy alabilir, ama sözlük değişir. samba-gpupdate şunları uygular:

• Sistem tarafı: parola ve Kerberos policy’si, 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 policy’leri
• Ağ ve güvenlik: OpenSSH yapılandırması, firewalld kuralları, sertifika otomatik kaydı

Hepsi geri alınabilir: policy’yi kaldırdığınızda makinede iz kalmaz. Ama bunlar Windows ayarlarının Linux’ta çalışan hali değildir, Samba’nın kendi policy 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:

$ 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 GPO’nun içi boştur, yani şu anda dağıtılacak bir ayar yok. Kuracağımız GPO’yu 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:

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:

[
  {
    "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:

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 DC’sine 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.

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 DC’nin Linux olduğunu ne bilir ne sorar.

Bu, Group Policy’ye ö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 Group Policy’yi istemcinin uyguladığını, DC’nin 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 DC’yi 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:

İ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ı DC 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:

#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ı policy’si başarıyla güncellendi. Raporu iki kapsamda ayrı ayrı okumak gerekiyor, çünkü ikisi farklı şey söylüyor. Önce bilgisayar tarafı:

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, Group Policy’yi 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 policy yenilendikten sonra kullanıcı kapsamındaki rapor şöyle:

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 DC) 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.

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 GPO’nun 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 Group Policy’nin 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:

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 DC 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 DC eklemek SYSVOL’ü kendiliğinden çoğaltmaz. Windows, Group Policy dosyalarını DC’ler 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 GPO’ların SYSVOL üzerinden sunulduğunu gördük; ikinci bir Samba DC’si 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ı, DC’lerden birini “GPO’ların düzenlendiği tek yer” ilan etmeniz gerekir: diğerlerinde yapılan değişiklikler senkronizasyonda ezilir.

Ama bu, ikinci DC’yi 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 policy dağıtımıdır; GPO’lar ve oturum açma betikleri, o paylaşımı sunan DC 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 GPO’ları 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 controller’a 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 DC’ye 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.

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ürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn