[{"data":1,"prerenderedAt":25},["ShallowReactive",2],{"blog-active-directory-ou-tasarimi-buyuyen-sirket":3,"blog-related-active-directory-ou-tasarimi-buyuyen-sirket":24},{"blogPostId":4,"title":5,"slug":6,"content":7,"excerpt":8,"featuredImage":9,"metaTitle":10,"metaDescription":11,"metaKeywords":12,"isPublished":13,"publishedAt":14,"viewCount":15,"likeCount":15,"commentCount":15,"readingTime":16,"authorId":17,"authorName":18,"categoryId":19,"categoryName":20,"tags":21,"isActive":13,"isDeleted":22,"createDate":14,"updatedDate":23,"deletedDate":18,"createdUserId":17,"updatedUserId":17,"deletedUserId":18},"0b6c39a6-fbba-49bd-84ba-84de71adeb12","Active Directory'de OU Tasarımı: Büyüdükçe Çöken Yapıyı Baştan Kurmak","active-directory-ou-tasarimi-buyuyen-sirket","\u003Ch2>Otuz kişiden üç yüz kişiye\u003C/h2>\u003Cp>Bir Active Directory yapısı kurulduğu gün nadiren sorun çıkarır. Sorunlar, şirket otuz kişiden üç yüz kişiye çıktığında başlar.\u003C/p>\u003Cp>Sahada gördüğüm tablo hemen her seferinde aynı: kurulumda kullanıcılar tek bir OU’ya atılmış, departmanlar sonradan klasör mantığıyla eklenmiş, yetkiler ise ihtiyaç doğdukça tek tek verilmiş. Yapı teknik olarak çalışır — ta ki birinin “muhasebeye şu politikayı uygula ama şubeleri hariç tut” demesine kadar.\u003C/p>\u003Cp>O cümle, kötü kurulmuş her OU yapısını tek hamlede açığa çıkarır.\u003C/p>\u003Ch2>OU bir klasör değildir\u003C/h2>\u003Cp>En sık yapılan hata, OU’ları dosya sistemi klasörü gibi düşünmektir. Oysa OU’nun iki gerçek işlevi vardır: \u003Cstrong>grup ilkesi uygulamak\u003C/strong> ve \u003Cstrong>yetki devretmek\u003C/strong>. Başka hiçbir şey için OU açılmaz.\u003C/p>\u003Cp>Bu ayrımı kaçırdığınızda ortaya “organizasyon şemasının kopyası” bir yapı çıkar: şirket şeması neyse OU ağacı odur. Kâğıt üzerinde düzenli görünür, ama şirket yeniden yapılandığında — ki yapılanır — tüm ağacı taşımanız gerekir.\u003C/p>\u003Cp>Benim tercih ettiğim ölçüt şudur: \u003Cstrong>bu OU’ya farklı bir politika uygulanacak mı, ya da yönetimi başka birine devredilecek mi?\u003C/strong> İkisi de hayırsa o OU’ya gerek yoktur.\u003C/p>\u003Ch2>Sahada işe yarayan yapı\u003C/h2>\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Katman\u003C/th>\u003Cth>İçeriği\u003C/th>\u003Cth>Gerekçesi\u003C/th>\u003C/tr>\u003C/thead>\u003Ctbody>\u003Ctr>\u003Ctd>Nesne türü\u003C/td>\u003Ctd>Kullanıcılar / Bilgisayarlar / Servis hesapları ayrı\u003C/td>\u003Ctd>Politikaların çoğu tür bazında farklıdır\u003C/td>\u003C/tr>\u003Ctr>\u003Ctd>Konum veya birim\u003C/td>\u003Ctd>Merkez, şube, üretim…\u003C/td>\u003Ctd>Yetki devri genellikle bu eksende olur\u003C/td>\u003C/tr>\u003Ctr>\u003Ctd>İstisna\u003C/td>\u003Ctd>Yönetici hesapları, kiosk makineler\u003C/td>\u003Ctd>Farklı politika gerektiren küçük kümeler\u003C/td>\u003C/tr>\u003C/tbody>\u003C/table>\u003Cp>Departman ayrımını ise OU’ya değil \u003Cstrong>gruba\u003C/strong> bırakıyorum. Departman değişikliği çok sık olur; grup üyeliğini değiştirmek saniyeler alır, OU taşımak ise politika ve yetki zincirini bozar.\u003C/p>\u003Ch2>Yetki devri: asıl kazanç burada\u003C/h2>\u003Cp>OU tasarımının en çok karşılığını verdiği yer yetki devridir. Şube sorumlusunun kendi kullanıcılarının parolasını sıfırlayabilmesi ama başka hiçbir şeye dokunamaması — bu, doğru kurulmuş bir OU yapısında birkaç dakikalık iştir.\u003C/p>\u003Cp>Yanlış kurulmuş bir yapıda ise iki kötü seçenekten birine mecbur kalırsınız: ya her parola sıfırlama merkeze gelir, ya da şube sorumlusuna gereğinden geniş yetki verilir. İkincisi çok daha sık tercih ediliyor ve \u003Cstrong>güvenlik olaylarının sessiz kaynağı\u003C/strong> oluyor.\u003C/p>\u003Ch2>Mevcut yapıyı düzeltmek\u003C/h2>\u003Cp>Bozuk bir yapıyı düzeltmenin doğru yolu her şeyi bir hafta sonunda taşımak değil. Benim izlediğim sıra şu: önce mevcut politikaların hangi OU’lara bağlı olduğunu çıkarırım, sonra hangi yetkilerin nerede verildiğini listelerim. Bu iki liste çıkmadan tek bir nesne taşımam.\u003C/p>\u003Cp>Ardından yeni yapıyı boş olarak kurar, politikaları önce test grubuna bağlar ve taşımayı departman departman yaparım. Her adımdan sonra bir gün beklerim; çünkü grup ilkesi sorunları çoğu zaman ertesi sabah, kullanıcılar oturum açtığında görünür.\u003C/p>\u003Cp>Bu iş sıkıcıdır ve kimse fark etmez. \u003Cstrong>Ama fark edilmemesi, doğru yapıldığının kanıtıdır.\u003C/strong>\u003C/p>\u003Cp>Bir noktayı özellikle vurgulamak isterim: bu düzeltme işi, teknik olmaktan çok iletişim işidir. Yapıyı değiştirdiğinizde bazı kullanıcıların masaüstü duvar kâğıdı değişir, bazılarının ağ sürücüsü bir sabah gelmez. Teknik olarak küçük olan bu ayrıntılar, haber verilmediğinde büyük şikâyetlere dönüşür.\u003C/p>\u003Cp>Bu yüzden taşımadan önce ilgili birimlere tek paragraflık bir bilgilendirme gönderiyorum: ne değişecek, ne zaman olacak, bir sorun olursa kime yazılacak. Bu üç cümle, geçiş günündeki telefon trafiğini gözle görülür biçimde azaltıyor.\u003C/p>\u003Cp>Son bir not: yeni yapıyı kurarken adlandırmayı da baştan düzeltmek gerekiyor. Türkçe karakter içeren, boşluklu ve tutarsız adlar taşınan yapıya da birebir taşınırsa, işi ikinci kez yapmış olursunuz. Kısa, tutarlı ve tahmin edilebilir adlar — birkaç yıl sonra o yapıya bakacak kişiye bırakacağınız en iyi miras bu.\u003C/p>\u003Cp>Yapıyı düzelttikten sonra en çok işe yarayan şey, kararların kısa bir belgeye yazılması oldu. Hangi OU’nun neden var olduğu, hangi politikanın nereye bağlandığı ve yetkilerin kime devredildiği tek sayfada duruyor. Bu sayfa olmadığında, birkaç yıl içinde yapı yeniden bozuluyor — çünkü herkes kendi ihtiyacına göre bir OU açıyor.\u003C/p>\u003Cp>Sahada gördüğüm en sağlıklı yapılar, en zekice tasarlanmış olanlar değil; \u003Cstrong>en iyi belgelenmiş\u003C/strong> olanlardı. Basit ama yazılı bir düzen, karmaşık ama kafalarda duran bir düzenden her zaman uzun ömürlü oluyor.\u003C/p>\u003Chr>\u003Cp>\u003Cstrong>Daha fazlası:\u003C/strong> OU ve grup yönetimini uygulamalı gösterdiğim bölümde bu yapının nasıl kurulduğunu adım adım görebilirsiniz.\u003C/p>\u003Cp>\u003Ca href='/videos/active-directory-ou-kullanici-ve-grup-yonetimi-7'>Videoyu sitemizde izle\u003C/a>  ·  \u003Ca href='https://youtu.be/SluTxejI2Xg' target='_blank' rel='noopener'>YouTube'da aç\u003C/a>  ·  \u003Ca href='https://www.youtube.com/@BapatiTech?sub_confirmation=1' target='_blank' rel='noopener'>Bapati kanalına abone ol\u003C/a>\u003C/p>","Çoğu Active Directory yapısı kurulduğunda değil, şirket büyüdüğünde çöker. OU tasarımını yetki ve politika ekseninde kurmanın sahada işe yarayan yolu.","https://img.youtube.com/vi/aFkACN9hrSU/maxresdefault.jpg","Active Directory'de OU Tasarımı: Şirket Büyüdükçe Çöken Yapıyı Baştan Kurmak - Bapati","Active Directory OU tasarımı neden büyüdükçe çöker? Yetki ve politika ekseninde doğru yapı, sık yapılan hatalar ve mevcut yapıyı düzeltme yolu.","Active Directory, OU tasarımı, grup ilkesi, yetki devri, kurumsal ağ",true,"2026-08-06T11:00:22.2254205",0,3,"ea4ea297-567a-491b-ac52-37db0674498b",null,"c5ccc953-53f1-4dea-b63d-463034d25947","DevOps ve Bulut",[],false,"2026-08-23T13:26:15.4896698",[],1789725857684]