Active Directory Kullanıcı, Grup ve OU Yönetimi: AGDLP Rehberi

Bir apartman sitesini düşünün. Site yönetimi sakinleri rastgele dairelere yerleştirmez; her blok, her kat, her daire belirli bir düzene göre numaralandırılır. Sakinlerin bilgileri yönetim ofisinde tek tek tutulur; ama havuza kim girebilir, otoparka kim park edebilir, çocuk parkının anahtarını kim taşır gibi yetkiler kişi kişi değil, gruplar üzerinden tanımlanır: “A Blok Sakinleri”, “Otopark Aboneleri”, “Sosyal Tesis Üyeleri”. Site yöneticisinin tüm komplekse yetkisi vardır; blok temsilcisinin yetkisi ise kendi bloğuyla sınırlıdır. Active Directory’de OU (Organizational Unit), kullanıcı ve grup üçlüsü tam olarak bu mantıkla çalışır.

Bu rehberde OU tasarımının temel ilkelerinden başlayıp kullanıcı hesabı oluşturmaya, grup türleri ve kapsamlarına, AGDLP modeline ve yetki devrine (delegation) kadar Active Directory’nin günlük yönetim omurgası ele alınıyor. Active Directory Rehberi ana hizmetinin kullanıcı ve grup yönetimi koluna odaklanan bu makale, Active Directory GPO Yönetimi makalesinde ele alınan politikaların kime uygulanacağını belirleyen yapıyı kurmanızı sağlar.

OU Tasarımı: Organizasyonun Dijital Kat Planı

OU’ları Departmana mı, Lokasyona mı Göre Tasarlamalı?

OU tasarımında doğru cevap genellikle “ikisi de”dir: önce lokasyon, sonra departman katmanı açılır; tek şubeli bir firma da bu sıradan vazgeçmez, sadece tek bir lokasyon OU’su ile başlar. Sitenizde şu an tek blok olsa da o bloğa bir ad vermeniz gerekir; ileride ikinci blok eklendiğinde tüm numaralandırmayı baştan kurmak zorunda kalmazsınız.

Saha pratiğinde henüz şubesi olmayan, tek merkezde çalışan bir firma için önerilen yapı şu şekildedir: en üstte OU=Genel_Merkez, altında Muhasebe, Satis, BT gibi departman OU’ları. Yarın Ankara’da yeni bir şube açıldığında sadece OU=Ankara_Sube eklenir, var olan departman yapısı hiç bozulmaz; departman bazlı GPO’lar da olduğu yerde kalır. Bu sıralama Active Directory GPO Yönetimi makalesinde anlatılan LSDOU uygulama sırasıyla da uyumlu çalışır; lokasyona özel bir GPO üst seviyeye, departmana özel bir GPO alt seviyeye linklenir.

Varsayılan Users ve Computers Konteynerlerini Kullanmamak

Default Users ve Computers konteynerlerine GPO linklenemez; bu yüzden yeni oluşturulan her hesap, siz fark etmeden politikasız bir bölgede kalır. Yeni taşınan bir sakinin daire numarası verilene kadar sitenin lobisinde bekletilmesi gibidir bu: geçici bir bekleme alanı, kalıcı adres değil. Sorun, çoğu yöneticinin bu lobiyi hiç boşaltmamasıdır.

Windows Server varsayılan olarak yeni kullanıcıları CN=Users, yeni bilgisayarları CN=Computers konteynerine düşürür. redirusr ve redircmp komutları bu varsayılan hedefi gerçek bir OU’ya yönlendirir:

redirusr "OU=Yeni_Kullanicilar,OU=Genel_Merkez,DC=ad,DC=sercebilisim,DC=com"
redircmp "OU=Yeni_Bilgisayarlar,OU=Genel_Merkez,DC=ad,DC=sercebilisim,DC=com"

Bu komutlar domain promotion’dan hemen sonra çalıştırılmalıdır. Haftalar sonra “bu kullanıcıya GPO neden uygulanmıyor” diye gpresult’a bakıp saatler harcamaktansa, ilk gün iki komutla bu sorunu kökünden kapatmak çok daha ucuzdur.

İç İçe OU Yapısı ve GPO Kalıtımı Üzerindeki Etkisi

Nested OU derinliği arttıkça GPO kalıtım zinciri de uzar; her ek kademe, LSDOU sıralamasına bir halka daha ekler. Bir sitede blok içinde kat, kat içinde daire grubu gibi iç içe katmanlar kurabilirsiniz, ama her katman bir yönetim kararı demektir: hangi politika nereye linklenecek, hangi OU üstten gelen kalıtımı “Block Inheritance” ile kesecek.

Saha gerçeği şu: üç kademeden (lokasyon, departman, rol) fazla derinleşen OU ağaçları genellikle ihtiyaçtan değil “belki ileride gerekir” düşüncesinden doğar. Sonuç, hangi GPO’nun hangi kullanıcıya neden uygulandığını kimsenin tam çıkaramadığı bir yapı olur. Üç kademe, küçük ve orta ölçekli kurumların büyük çoğunluğu için yeterlidir.

Lokasyon Altında Nesne Türüne Göre Ayrım: Bilgisayarlar, Kullanıcılar, Gruplar

Departman bazlı alt OU (Muhasebe, Satis, BT) küçük ve tek lokasyonlu bir yapı için yeterlidir; ama lokasyon sayısı arttığında ve delegasyonun daha ince taneli olması gerektiğinde sahada sık görülen bir alternatif, her lokasyonun altını departmana göre değil nesne türüne göre bölmektir: Bilgisayarlar, Kullanıcılar, Gruplar. Apartman benzetmesiyle düşünürseniz, her blokun kendi teknik odasını, kendi sakin defterini ve kendi ortak alan anahtarlık listesini ayrı tutması gibidir bu; hepsini tek bir çekmecede karıştırmak yerine.

Bu ayrımın asıl gerekçesi GPO hedeflemesidir: bilgisayar nesnesine uygulanacak bir politika (yazılım dağıtımı, BitLocker zorunluluğu) ile kullanıcı nesnesine uygulanacak bir politika (parola, klasör yönlendirme) çoğu zaman birbirinden tamamen farklıdır. Aynı OU içinde karışık dururlarsa WMI filtresi veya Item-Level Targeting gibi ek katmanlara ihtiyaç duyulur; ayrı OU’larda tutulduklarında GPO doğrudan doğru hedefe linklenir, ek filtreye gerek kalmaz.

Bu yapının avantajı, lokasyon bazında tam bir varlık envanterine tek bakışta ulaşmaktır: bir lokasyonun tüm bilgisayarları, kullanıcıları ve grupları kendi alt OU’sunda durur, hangi lokasyonda kaç varlık olduğu ADUC’tan saniyeler içinde görülür. Dezavantajı ise departman bilgisinin OU ağacından kaybolmasıdır; “Muhasebe’nin kullanıcıları nerede” sorusunun cevabı artık bir OU yolu değil, isimlendirme kuralı veya Security Group üyeliğidir. Saha tecrübesi bu kaybın aslında küçük bir bedel olduğunu gösteriyor: departmanlar zamanla birleşir, bölünür, yeniden adlandırılır; ama “Kullanıcılar” ve “Bilgisayarlar” kategorisi hiçbir zaman değişmez. Departman bilgisini OU yerine grup isimlendirmesine taşımak, organizasyon değiştiğinde OU ağacını yeniden kurmak zorunda kalmamanızı sağlar.

Grupları Lokasyon OU’suna Koymanın Pratik Faydası: Delegasyonu Basitleştirmek

Gruplar, lokasyonların dışında bağımsız bir top-level OU olarak da tutulabilir; bu tamamen organizasyonun tercihidir. Grupları lokasyonun altına koymak ise günlük operasyonda bir avantaj sağlar: o lokasyondaki BT personeline grup üyeliği yönetimini delege etmek, en sık tekrarlanan işlerden biridir ve gruplar lokasyonun içindeyse bu delegasyon tek bir OU üzerinden, başka hiçbir yere dokunmadan tanımlanabilir.

Örnek vermek gerekirse: PC_GM_MUH (Genel Müdürlük Muhasebe Bilgisayarlar Grubu) grubuna üye ekleme çıkarma yetkisi, Delegation of Control Wizard’da “Modify the membership of a group” görevi seçilerek USER_GM_IT (Genel Müdürlük BT Personel Grubu) grubuna verilir. En kötü senaryoda bile bu yetkinin kapsamı sadece o lokasyonun grupları ile sınırlı kalır; USER_GM_IT üyesi bir BT personeli Halkali lokasyonunun gruplarına dokunamaz. Bina yöneticisine kendi binasının ortak alan anahtarlık listesini güncelleme yetkisi vermek gibi düşünebilirsiniz bunu; başka binanın anahtarlığına dokunma hakkı yoktur.

Top-level Yardımcı OU’lar: Evrensel_Gruplar, Sunucular, Servis_Kullanicilari

Lokasyon ağacının dışında, kompleksin tamamına hizmet eden üç top-level OU saha pratiğinde sık görülür: Evrensel_Gruplar, Sunucular, Servis_Kullanicilari. Apartman kompleksinin jeneratör odası veya güvenlik kulübesi gibi düşünebilirsiniz bunları: belirli bir bloğa değil, kompleksin tümüne ait ortak alanlardır.

Evrensel_Gruplar, belirli bir lokasyona bağlı olmayan grupları toplar; Firewall grupları, yazıcı grupları gibi örnekler tipiktir. Hangi grupların buraya, hangilerinin lokasyon altına gireceği kesin bir kural değil, şirketin yönetim kültürüne bağlı bir tercihtir.

Sunucular, sunucu bilgisayar nesnelerini istemcilerden tamamen ayırır. Sebep basit: sunuculara uygulanan GPO seti (sertleştirme, audit politikaları, hizmet bazlı ayarlar) istemci politikalarından köklü biçimde farklıdır; aynı OU’da karışık dururlarsa bir gün yanlışlıkla bir istemci GPO’su sunucuya da uygulanır.

Servis_Kullanicilari, insan olmayan, uygulama veya servis bazlı oturum açan hesapları normal kullanıcılardan ayırır. Bu ayrım denetimde anında işe yarar: bir hesabın OU’suna bakarak “bu bir insan mı, bir servis mi” sorusuna saniyeler içinde cevap verirsiniz; Fine-Grained Password Policy gibi servis hesabına özel bir parola politikası hedeflemeniz gerektiğinde de OU ayrımı bu işi kolaylaştırır.

Bu servis hesabı yetki fazlalığı sorununun gMSA (group Managed Service Account) ile nasıl çözüldüğü ve break-glass hesapları, Tier 0 izolasyonu gibi diğer sertleştirme adımları Active Directory Güvenlik Sertleştirmesi Rehberi makalesinde ayrıntılı olarak ele alınıyor.

Kullanıcı Hesabı Oluşturma ve Yönetimi

ADUC ile Tekli Kullanıcı Hesabı Oluşturma

Tekli kullanıcı hesabı, Active Directory Users and Computers (ADUC) konsolunda ilgili OU’ya sağ tıklayıp New > User seçilerek oluşturulur. Yeni bir sakinin siteye taşınması gibidir bu: isim, soyisim, oturum açma adı gibi temel kimlik bilgileri ilk ekranda girilir, parola ve hesap seçenekleri ikinci ekranda tamamlanır.

Sihirbazda iki alan özellikle kritiktir: UPN (User Principal Name) modern oturum açma biçimidir (ayse.demir@ad.sercebilisim.com), sAMAccountName ise 20 karakter sınırlı eski NetBIOS adıdır. Tek hesap için bu yöntem hızlıdır, ama onlarca hesap aynı anda açılacaksa arayüzden tek tek girmek saha pratiğinde zaman kaybıdır.

PowerShell ile Toplu Kullanıcı Oluşturma (New-ADUser, Import-Csv)

New-ADUser ve Import-Csv birlikte kullanıldığında, yüzlerce kullanıcı tek komutla ve standart alanlarla oluşturulur. Yeni teslim edilen bir bloğun elli dairesine aynı gün elli sakin taşınması gibi bir senaryodur: kapı kapı dolaşmak yerine, hepsi aynı listeden aynı anda işleme alınır.

Import-Csv "C:\AD\yeni-kullanicilar.csv" | ForEach-Object {
    $SecurePass = ConvertTo-SecureString $_.Parola -AsPlainText -Force
    New-ADUser -Name $_.AdSoyad `
        -SamAccountName $_.KullaniciAdi `
        -UserPrincipalName "$($_.KullaniciAdi)@ad.sercebilisim.com" `
        -Path $_.OUYolu `
        -AccountPassword $SecurePass `
        -Enabled $true `
        -ChangePasswordAtLogon $true
}

CSV dosyasında en az AdSoyad, KullaniciAdi, Parola ve OUYolu sütunları bulunmalıdır. -ChangePasswordAtLogon $true parametresi ilk oturumda parola değişimini zorunlu kılar; bu olmadan yüzlerce hesap aynı geçici parolayla aylarca dolaşabilir, ki bu saha pratiğinde sık görülen bir güvenlik açığıdır.

Hesap Şablonları ve Zorunlu Alanlar

Hesap şablonu, var olan bir kullanıcıyı “Copy” ile çoğaltarak grup üyeliklerini ve OU yolunu otomatik taşımak demektir. Sitenin standart kira sözleşmesi gibi düşünün: her yeni sakin için sıfırdan sözleşme yazmak yerine, şablon kopyalanır, sadece isim ve daire numarası değişir.

Kopyalanan hesapta departman, şirket, grup üyelikleri gibi alanlar otomatik gelir; sadece ad, soyad, oturum açma adı ve parola elle girilir. Zorunlu alanları (departman, ofis, telefon) standartlaştırmadan bırakan kurumlarda, altı ay sonra raporlama ve denetim sırasında bu alanların yarısı boş çıkar.

Grup Türleri ve Kapsamları

Security Group ve Distribution Group Farkı

Security Group hem kimlik doğrulama sırasında erişim yetkisi taşır hem de e-posta dağıtım listesi olarak kullanılabilir; Distribution Group ise sadece e-posta dağıtımı içindir ve ACL üzerinde hiçbir yetki taşımaz. Sitenin ortak alan erişim kartı ile sadece duyuru panosuna isim yazdırmak arasındaki fark gibidir bu: kart sizi havuza sokar, pano kaydı sadece bilgilendirir.

Modern ortamda erişim kontrolü için neredeyse her zaman Security Group seçilir; Distribution Group ihtiyacı genellikle Exchange veya Microsoft 365 tarafındaki e-posta dağıtım listeleriyle karşılanır. Bir grup açarken “bu sadece bilgilendirme için mi, yoksa birine bir kaynağa erişim mi verecek” sorusunu sormak, ileride hangi türde açıldığını hatırlamaya çalışmaktan çok daha pratiktir.

Domain Local, Global ve Universal Kapsam Farkları

Grup kapsamı (scope), o grubun hangi sınır içinde geçerli olacağını belirler: Domain Local tek domain içindeki kaynaklara, Global aynı domain içindeki hesapları, Universal ise forest genelindeki erişimi kapsar. Tek bir sitenin otopark kartı (Domain Local), o sitenin sakinler listesi (Global) ve holding bünyesindeki tüm sitelerde geçerli VIP kartı (Universal) arasındaki fark gibi düşünebilirsiniz.

Çoğu KOBİ’de tek domain, tek forest yapısı olduğu için Universal kapsama nadiren ihtiyaç duyulur; gerçek saha kullanımı büyük ölçüde Global (kullanıcıları toplama) ve Domain Local (kaynağa erişim verme) ikilisi etrafında döner. Universal grup, yalnızca birden fazla domain’in olduğu forest yapılarında gerçek bir karşılık bulur.

AGDLP Modeli: Grupları İç İçe Geçirme Stratejisi

AGDLP, Account, Global Group, Domain Local Group, Permission sırasıyla izin verme zinciridir ve Microsoft’un resmi olarak önerdiği yetkilendirme modelidir. Sakin önce blok kartını gösterir, kart havuz listesine düşer, liste kilidi açar: zincirin her halkası bir öncekinin yetkisini taşıyarak ilerler.

Bu modele bağlı kalmak, yeni kullanıcı geldiğinde tek tek klasörlere izin vermek yerine, kullanıcıyı doğru Global Group’a eklemek demektir. Doğrudan kullanıcıya izin vermek başta hızlı görünür, ama altı ay sonra “bu klasöre kimler erişebiliyor” sorusunun cevabı kullanıcı sayısı kadar satır gerektirir. AGDLP’de aynı sorunun cevabı tek bir grup adıdır.

Yetki Devri: Delegation of Control

Delegation of Control Wizard ile OU Bazlı Yetki Verme

Delegation of Control Wizard, bir OU’ya sağ tıklanıp açılan ve o OU üzerinde kime hangi yetkinin verileceğini adım adım tanımlayan sihirbazdır. Site yöneticisinin tüm komplekse, blok temsilcisinin ise sadece kendi bloğuna yetkisi olması gibi: bu sihirbaz “kendi bloğuna yetkisi olan” tarafı kurar.

Sihirbaz beş adımda ilerler: OU seçimi, yetki verilecek kullanıcı veya grup seçimi, görev listesinden yetki seçimi (parola sıfırlama, hesap kilidi açma, grup üyeliği yönetimi gibi sık kullanılan görevler hazır gelir), özel görevler için ACL bazlı ince ayar ve onay. En az yetki ilkesi burada belirleyicidir: bir gruba sadece ihtiyaç duyduğu görev verilir, “her ihtimale karşı” geniş yetki tanımlanmaz.

Helpdesk Personeline Parola Sıfırlama Yetkisi Tanımlama

En sık kullanılan delegasyon senaryosu, helpdesk ekibine Domain Admins’e eklemeden sadece parola sıfırlama ve hesap kilidi açma yetkisi vermektir. Kapıcıya site girişinin yedek anahtarını vermek, daire satış yetkisi vermek değildir: ikisi de “yetki” kelimesiyle anılır ama kapsamları çok farklıdır.

Wizard’da “Reset user passwords and force password change at next logon” görevi seçilip helpdesk grubuna atanır; bu işlem sonrası helpdesk personeli kullanıcı oluşturamaz, grup silemez, GPO değiştiremez. Saha gerçeği şu ki, Domain Admins’e gereğinden fazla kişi eklenmiş ortamlarda bir gün mutlaka biri yanlışlıkla yanlış OU’da bir politika değiştirir; delegasyon bu riski en başında keser.

Bu riskin nereye kadar uzanabileceğini bizzat gördüm: devraldığım bir kurumda en alttaki kullanıcıdan en üstteki yöneticiye kadar herkesin hesabı Domain Admins, hatta Schema Admins ve Enterprise Admins yetkisindeydi ve bu yönetici hesapları aynı zamanda günlük kullanılan kullanıcı hesabıydı. İş, BT ile hiçbir ilgisi olmayan bir noktaya kadar gitmişti: yirmi kişilik muhasebe ekibi, sırf ortak kullanılan bir muhasebe yazılımı şifre sormadan sorunsuz çalışsın diye Domain Admin yapılmıştı, local admin değil. Bir gün ekipten biri programın ortak dosyasını yanlışlıkla silince, gün boyu çalışma durdu. Sistem yönetimini devraldıktan sonra önce bu doğrudan admin yetkilerinin tamamını topladım, ardından Delegation of Control Wizard ile USER_GM_IT, USER_HLK_IT gibi gruplara sadece kendi OU’ları üzerinde işlem yetkisi tanımladım; bir BT personeli artık kendi OU’sunun dışına hiç çıkamıyordu.

İsimlendirme Standartları ve Sık Yapılan Hatalar

Kullanıcı, Grup ve OU İçin Tutarlı İsimlendirme Kuralları

Tutarlı bir isimlendirme kalıbı, altı ay sonra “bu grup ne işe yarıyordu” sorusuna kimsenin cevap verememesini önler. Active Directory GPO Yönetimi makalesinde GPO’lar için önerilen {PC|USER}_{LOKASYON}_{KISA AD} kalıbına paralel, kullanıcı ve grup nesneleri için de benzer bir disiplin önerilir:

Bu kalıbın amacı estetik değil, fonksiyoneldir: bir grup adına bakarak hangi kaynağa, hangi yetki seviyesinde erişim verdiğini tahmin edebilmelisiniz.

Sık Yapılan Hatalar

Saha pratiğinde tekrar eden üç hata var:

• Doğrudan kullanıcıya izin vermek: AGDLP zincirini atlayıp klasöre doğrudan kullanıcı eklemek, kısa vadede hızlı ama uzun vadede takip edilemez bir izin yığını yaratır.
• Default konteynerleri boşaltmamak: Yeni hesapların GPO almayan bir bölgede unutulması, bu rehberin başında ele alınan en yaygın “GPO neden çalışmıyor” sebebidir.
• Grup iç içe geçirmeyi abartmak: Bir grubu başka bir grubun içine, onu da üçüncü bir grubun içine koymak, AGDLP’nin dört katmanını on katmana çıkarır; kimin neye eriştiğini izlemek imkansızlaşır.

Doğrudan yetkinin sahada nereye varabildiğini bir denetimde gördüm: personel maaşlarının tutulduğu sunucudaki kritik bir klasöre, yıllar önce ayrılmış bir kullanıcı doğrudan yetkiyle eklenmiş halde duruyordu, sanki biri sessizce kendini listeye yazmış gibi. O kullanıcı işten çıksa veya departman değiştirse bu erişim kimsenin haberi olmadan ayakta kalacaktı; üstüne onlarca farklı sunucuda, dosya sunucusunun her alt klasöründe benzer doğrudan izinler birikmişti ve hiçbiri tek bir yerden görülemiyordu. Bunların tamamını Security Group’a taşımak günlerce sürdü, ama taşındıktan sonra tek bir grup üyeliğini kaldırmak, o kişinin tüm erişimini bir hamlede kesebilecek hale geldi: yıllarca süren dağınıklık, sabırlı bir temizlikle çözüldü.

Bu üç hatanın ortak noktası aynı: kısa vadeli hız, uzun vadeli denetlenebilirlikten çalınır.

Sonuç

OU, kullanıcı ve grup disiplini kurulduktan sonra Active Directory yönetimi, dağınık bir siteyi yönetmekten standart bir apartman kompleksini yönetmeye döner: kim nerede oturuyor, kim hangi ortak alana erişebilir, kim hangi bloğun temsilcisi sorularının hepsinin tek bakışta cevabı vardır. Bu temel kurulmadan üzerine ne GPO ne de güvenlik politikası sağlıklı oturur.

Bu rehberde kurulan OU ve grup yapısının üzerine politika uygulamak için Active Directory GPO Yönetimi makalesine, domain’in ilk kurulumu için Active Directory Kurulum Rehberi makalesine bakabilirsiniz. Active Directory’nin mimari bütününe dönmek isterseniz Active Directory Rehberi ana sayfası başlangıç noktasıdır.

Yazan

İlker Pehlivan

Kurucu | Ağ ve Sistem Yöneticisi

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