Ana içeriğe geç

SecuraWall.com

E-posta güvenliği ve sürekliliği

Keşfedin
Linux · Teknik Rehber

Linux Active Directory Alternatifi: Samba AD DC Rehberi

Samba AD DC ile Linux üzerinde domain controller, Kerberos, DNS ve Windows istemci üyeliğini; sınırlamalar ve geçiş riskleriyle inceleyin.

Teknik gözden geçirme: 29 Eylül 2026Bilgi Merkezi

Bu rehber neyi çözer?

Samba, Linux üzerinde Active Directory uyumlu domain controller rolü sunabilir; ancak Microsoft AD’nin her ileri özelliğinin birebir eşdeğeri kabul edilmemelidir.

Samba AD DC neler sağlar?

Domain üyeliği, Kerberos, LDAP tabanlı dizin işlevleri, DNS ve Windows istemcilerin domaine katılması temel kullanım alanlarıdır.

Birden fazla DC ve replikasyon tasarlanabilir; sürüm/destek matrisi dikkatle izlenmelidir.

Group Policy ve entegrasyon

Birçok GPO senaryosu çalışabilir; ancak Entra hibrit, AD CS, ileri güvenlik ürünleri ve özel Microsoft entegrasyonları pilotta doğrulanmalıdır.

Mevcut GPO ve servis hesapları envanteri geçiş öncesi çıkarılmalıdır.

DNS ve zaman

AD uyumlu yapılarda DNS ve doğru zaman senkronizasyonu kritik bağımlılıktır.

DC yedekliliği, NTP/chrony ve site/subnet tasarımı planlanmalıdır.

Geçiş yöntemi

Mevcut domain fonksiyonları, GPO, uygulama LDAP/Kerberos bağımlılıkları ve istemci sürümleri analiz edilmelidir.

Laboratuvar/pilot ortam ve test edilmiş rollback planı olmadan doğrudan üretim geçişi önerilmez.

Sık Sorulan Sorular

Samba AD DC ücretsiz mi?

Samba açık kaynaklıdır; tasarım, destek, yedekleme, monitoring ve uzmanlık maliyetleri yine vardır.

Windows istemciler domaine katılabilir mi?

Uygun sürüm ve yapılandırmada Windows istemciler Samba AD domain’ine katılabilir.

Microsoft AD’den geçiş risksiz mi?

Hayır. DNS, GPO, servis hesapları, replikasyon ve uygulama bağımlılıkları dikkatle test edilmelidir.

Linux Sunucu Projenizi Değerlendirelim

Mevcut Windows/Linux rollerinizi, uygulama bağımlılıklarını ve geçiş hedeflerinizi birlikte değerlendirebiliriz.

Teknik Görüşme

Mimari ve çalışma modeli

Samba AD DC, domain kimliği, Kerberos ve dizin hizmetlerini destekleyen bir rol sunar. Windows AD ile aynı bütün özellik ve sürüm matrisini varsaymayın. DNS, zaman senkronizasyonu, domain join, GPO ve SYSVOL işletimi tasarımın parçasıdır. İkinci DC kurmak SYSVOL ve kurtarma davranışını doğrulama gereksinimini kaldırmaz.

  1. 1DNS ve zaman
  2. 2Domain/Kerberos
  3. 3Samba dizin ve SYSVOL
  4. 4İstemci ve GPO testi
Dizin replikasyonu, SYSVOL/GPO ve domain kurtarmasını ayrı kabul maddeleri yapın.

Tasarım parametreleri

DC rolü ve sürüm
Samba AD DC, domain member ve dosya sunucusu rollerini ayırın; SYSVOL ve replikasyon desteğini sürüme göre doğrulayın.
DNS ve saat
Kerberos için DNS ve saat tutarlılığını sağlayın; istemci resolverını domain tasarımıyla eşleştirin.
Servis ve kullanıcı
Gerçek servis kullanıcısını, grup üyeliğini, çalışma dizinini ve gerekli yetkileri listeleyin. Root ile başarılı test sınırlı hesapla çalışmayı kanıtlamaz.
Depolama ve kalıcılık
Mount, dosya sistemi, inode ve kalıcı veriyi birlikte kontrol edin. Yeniden başlatma ve yeniden oluşturma aynı test değildir.
Ağ ve güvenlik katmanı
Dinlenen arayüz, firewall, TLS ve SELinux/AppArmor politikalarını ayırın. Bir katmandaki engel başka katmanın ayarıyla çözülmez.
Paket ve işletim yöntemi
Sürüm, depo, güncelleme yöntemi ve servis bağımlılıklarını belgeleyin. Bakım sonrası reboot ve uygulama doğrulamasını planlayın.

Hesap ve uygulama örneği

Örnek pilotta domain join, kullanıcı oturumu, grup yetkisi ve bir test GPO’su uygulanır. DNS veya zaman kaybının Kerberos etkisi incelenir. DC yedeği ve geri dönüşü desteklenen yöntemle ayrı ortamda test edin; çalışan domaini yalnız VM snapshotına güvenerek geri döndürmeyin.

Hata teşhisi

BelirtiOlası neden / ayrımDoğrulama
Domain join var ama giriş başarısızDNS, saat veya ticket durumu farklı olabilir.SRV çözümleme, zaman farkı ve Kerberos kayıtlarını gerçek istemcide inceleyin.
Servis aktif ama yanıt vermiyorProcess sağlığı, port dinleme ve uygulama sağlığı farklı kontrollerdir.Yerel sağlık kontrolünü uzak istemci isteğiyle karşılaştırın; log ve bağımlılık durumunu inceleyin.
Dosya yazılamıyorİzin, ACL, read-only mount, inode veya disk doluluğu etkili olabilir.Servis kimliğiyle dizin zincirini ve mount durumunu doğrulayın; izinleri topluca açmayın.
Reboot sonrası yapılandırma kaybolduGeçici mount, runtime ayarı veya yanlış yapılandırma kaynağı kullanılmış olabilir.Kalıcı ayarı ve açılış sırasını kontrol edin; temiz reboot testini tekrarlayın.

Kabul ve doğrulama kontrolleri

  1. Dizin replikasyonu, SYSVOL/GPO ve domain kurtarmasını ayrı kabul maddeleri yapın.
  2. Servisi tanımlanan sınırlı kimlikle çalıştırıp temel iş akışını test edin.
  3. Reboot sonrasında mount, ağ, zaman ve uygulama durumunu doğrulayın.
  4. Yapılandırma, veri ve anahtarları ayrı kurtarma kalemleri olarak kaydedin.
  5. Güncellemeden önce ve sonra aynı sağlık testini çalıştırın.
  6. Ayrı hedefe geri yükleyerek platform bağımlılıklarını doğrulayın.

İlgili kavramlar

Kimlik doğrulama ve oturum

Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.

DNS önbelleği ve bağımlılık

DNS cevabı yalnız kaydın authoritative sunucudaki değerine bağlı değildir; istemci ve recursive resolver önbellekleri de sonucu etkiler. TTL değişikliği daha önce önbelleğe alınmış yanıtların ömrünü geriye dönük kısaltmaz. A/AAAA, CNAME, MX ve TXT kayıtları farklı işlevlere sahiptir. İç ve dış görünümü ayrı test edin; split DNS nedeniyle cevapların farklı olması tasarlanmış olabilir. Arıza araştırmasında kullanılan resolver, yanıt türü, TTL ve sorgu zamanını kaydedin. IP ile erişimin çalışması tek başına DNS yapılandırmasının doğru olduğunu göstermez.

Replikasyonun kapsamı

Replikasyon veri veya durum değişikliklerini başka bir kopyaya aktarır. Senkron aktarım gecikme ve bağlantı bağımlılığı yaratabilir; asenkron aktarım ise geride kalabilir. Kopyanın güncel olması, yanlış değişikliklerden korunması anlamına gelmez: silme veya bozulma da taşınabilir. Gecikmeyi yalnız bağlantı durumu üzerinden değil, uygulamanın tamamlanan son işlemiyle karşılaştırın. Kaynak düğüm kaybedildiğinde yazma yetkisinin hangi kopyaya geçeceğini ve eski düğüm geri gelince nasıl uzlaştırılacağını tanımlayın. Replikasyon gecikmesi ile gerçek kurtarma noktasını ayrı raporlayın.

Dosya izinleri ve servis kimliği

Dosya erişimi kullanıcı/grup, izin bitleri, ACL ve güvenlik politikalarının birleşimine bağlıdır. Bir uygulamanın root olarak çalışması izin sorununu gizleyebilir; üretim için gerekçeli ve sınırlı servis kimliği tercih edilir. Dizin üzerinde arama/geçiş izni ile dosya okuma izni farklıdır. Paylaşım katmanında verilen izin, dosya sistemindeki kısıtı her zaman aşmaz. Hata araştırmasında uygulamanın gerçekten hangi kullanıcıyla çalıştığını, dizin zincirini ve ACL’leri inceleyin. İzinleri topluca açmak yerine gereken erişimi dar kapsamda test edin.

Uygulama tutarlılığı

Bir kopyanın açılabilir olması, uygulama verisinin tutarlı olduğunu kanıtlamaz. İşletim sistemi önbelleği, veritabanı günlükleri ve birden fazla disk veya servis arasındaki işlem sırası sonucu etkiler. Crash-consistent kopya beklenmedik kapanma sonrasındaki duruma benzer; application-consistent kopya uygulamanın desteklediği hazırlık ve yazma düzenini dikkate alır. Geri dönüşte yalnız dosya sayısını değil, işlem bütünlüğünü, kayıt ilişkilerini ve uygulama testini kontrol edin. Yedekleme ürününün desteklediği entegrasyonu, uygulama sürümünü ve hata çıktısını doğrulamadan tutarlılık varsaymayın.

Sürüm ve destek yaşam döngüsü

Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.

Birincil teknik dokümantasyon

Kurumsal IT Ürün Satışı, Lisanslama ve Kurulum
Kurumsal IT Proje & Çözüm Senaryoları
Tüm ilgili içerikleri görüntüleyin
WhatsApp'tan Yazın
Kopyalandı!