Merhaba, Bu makalemizde Exchange 2010 ürünü ile birlikte özellik olarak gelen ve 2013 Platformunda da devam eden Adını sıkça duyduğumuz Role Based Access Control özelliğini inceliyor ve detaylandırıyor olacağız. Öncelikle RBAC nedir neden kullanılır kısaca değinmekte yarar var. Örneğin çok Lokasyona sahip bir işletmede Sistem Yöneticisi olarak çalışıyorsunuz ve Coğrafi bölgeleriniz mevcut. Ankara, İzmir, Gaziantep vs. gibi ve burada çalışan personel sayısı hem fazla hem de o Bölgeler de görev yapan IT Support Personeliniz mevcut. Bu durumda mevcut iş yükünüzün azalması için Yönetimini yaptığınız Sistemlerin Bazılarında Delegasyon yoluna giderek Teknik bilgisi yeterli olan Donanım destek uzmanı arkadaşlara bazı görevleri atayarak günlük gelen bazı talepleri onların çözmesini ve sizin üzerinizde yoğunluk oluşturmamasını sağlayabilirsiniz. Hepimizin bildiği üzere Bazı yapılarda ( İlaç, sağlık, Medya, Perakende ) personel sirkülasyonu yoğun olur. Sürekli işe girişler işten ayrılışlar vs. Bu gibi durumlarda Exchange yönetimi sizdeyse ve başka bu görevi yapan kişi yoksa bu işlemlerin bazıları sizin üzerinize kalacaktır. RBAC özelliği sayesinde bölgelerinizdeki IT ekibinize Exchange Server üzerinde belirlediğiniz rolleri atayabilir ve sadece belirlediğiniz kişi ve gruplar üzerinde işlem yapmalarını sağlayabilirsiniz. Kısaca RBAC nedir üzerinden tekrar geçtikten sonra uygulamaya başlayabiliriz. Öncelikli olarak Coğrafi yerleşkelerinizdeki IT Support personellerinizin olduğu Group’ları öncelikle belirlemeniz ve ardından bu gruplara önce Active Directory tarafında sadece User Create ve Password Resetleme bazlı delegasyon vermelisiniz. Bizim örneğimizde Mevcut Active Directory yapımız ve OU şemamız aşağıdaki gibidir.
Mevcut Active Directory ve OU Yapımız.
.
Resim-1
Dikkat ederseniz 1 Tane Merkez Bölgemiz Yani İstanbul Lokasyonumuz mevcut. Diğer Coğrafi bölgelerimiz aslında bir nevi şube yapısında ve o bölgelerde IT Support personelimiz mevcut. Biz bölgelerimize bölge bazlı delegasyon ve ardından kendi Mailbox Databaselerine Mailbox Create edebilme yetkisi vereceğiz. Özellikle üzerinde durmak istediğim bir husus Hem DC Tarafında hem Exchange tarafında Delagasyon yaparken User bazlı değil Universal Security Group bazlı yaparsanız hem yönetimi hem de Destek personellerinizin sayısının artması ya da azalması durumunda tekrar delegasyonla uğraşmak yerine mevcut grupa ilgili işe başlayan yeni personeli üye yaparak çözüm üretmiş olursunuz.
Exchange tarafında öncelikle Delegasyon yaparak ilerleyelim.
Delegasyon yapılacak bölge OU > Ankara-Bolge ilgili Universal Security Group ismi aşağıdaki gibidir.ve şu an için tek üyeye sahiptir.
Resim-2
Exchange Delegasyonunu Exchange Sunucu üzerinde Exchange Management Shell de ilgili parametreleri çalıştırarak yapıyoruz. Burada dikkat edilmesi gereken husus Delegasyon yapacağımız Security Group’un Universal Sec. Group olması. Ve parametrelerin aşağıdaki gibi kendi yapınıza özgü Doğru OU ismi ve Doğru Unv.Security Group ismi yazılarak parametrelerin sağlanmasıdır.
Resim-3
Yukarıdaki örnekte aslında şunu yaptık. 1. Atayacağımız role için bir isim oluşturduk bu isim “AnkaraMailRecipients” 2. “ANK-ITM” universal sec. Groupa bu role için yetki verdik. 3. Contoso.com Domainindeki Ankara-Bolge OU birimini kapsam içine alması için OU Scope alanına bu bilgiyi girdik.
İlk Satırdaki parametrede Mail Recipients için delegasyon yaptık. 2. Satırdaki parametreyle de Mail Recipient Creation işlemi için delegasyon yaptık ve bu işlemin sonunda bu gruba üye olan Emre.A kullanıcısı ile Exchange Administrative Center a giriş yaptığımız da karşımıza gelen ekran aşağıdaki gibidir.
Resim-4
Fark ettiğiniz üzere Delegasyonla yalnızca User Mailbox Create etme ve yetki sahibi olduğu OU üzerindeki Recipients rolüne sahip olduğu için ilgili kullanıcının EAC alanı oldukça kısıtlı.
Aynı Delegasyon işlemlerinizi mevcut yapınızda kaç tane coğrafi lokasyona sahipseniz her birine eğer Exchange üzerinde delegasyon vermek istiyorsanız teker teker yapmanız gerekir. Ben örnek olması açısından Ankara-Bolge OU birimini seçtim. Fakat komutların doğru parametreler girildiği takdirde sorunsuz çalıştığını görmeniz açısından Adana-Bolge OU birimi içinde ilgili Universal Security Groupa delegasyon yapacağım.
Active Directory tarafında Adana-Bolge OU düzenim ve grup bilgim aşağıdaki gibidir.
Resim-5
Resim-6
Resimde Gördüğünüz üzere Adana-Bolge OU birimi içinde ilgili Universal Security Grup’a delegasyonla Mailbox Create etme ve sadece kendi OU biriminde bu işlemleri yapabilmesi için delegasyon tanımladık.
Delegasyon sonrası EAC üzerinde ilgili kullanıcının yetki durumu aşağıdaki gibidir.
Resim-7
Buraya kadar doğru parametrelerle ilgili OU birimleri üzerinde belirlediğimiz USG’lere üye IT Personelimize Exchange 2013 üzerinde Mailbox Create edebilme yetkisi tanımladık. Asıl bundan sonraki süreç işimize daha çok yarayacağı gibi istemediğimiz karışıklıkların önüne geçmiş olacağız J hepinizin bildiği üzere Exchange yönetiminde en önemli hususlardan biri doğru birimlere doğru Mailbox Database yapılarını konumlandırmak örneğin; Merkez Muhasebe birimindeki kullanıcılarınızın kullanmış olduğu Mailbox Database kısıtlamalarının VIP kullanıcılar için geçerli olmasını istemezsiniz veya tam tersi. İşte bu noktada Mailbox Create ederken doğru seçim yapılmadığı takdirde kısa süre sonra Mailbox ım doldu kota sorunum var vs. gibi şikâyetler alırsınız. Burada tanımlayacağımız Restrictionlar sayesinde bölge IT personeliniz kendi bölgeleri dışındaki hiçbir Mailbox Database üzerinde Mailbox Create edemeyecekler. İşlemlere geçmeden önce Exchange Sunucumuz üzerindeki Mailbox Databaselerin durumunu ve isim bilgilerini aşağıda paylaşıyorum.
Resim-8
İlk olarak yazımın başında yapmış olduğum üzere Ankara-Bolge OU birimi için Database bazlı Restriction uygulayacağım. Komutları yine biraz sıkıcı gelse de J Exchange Management Shell üzerinde çalıştırıyoruz.
Öncelikle bir Ankara-Bolge DB’leri için Management Scope oluşturalım. İlgili resim ve parametreleri aşağıdaki gibidir.
Resim-9
Şimdi de önceden oluşturduğumuz role grupla bu yeni oluşturduğumuz ve Database filtreleme görevi görecek olan Management Scope ilişkisini kuralım.
Resim-10
Yukarıda yapmış olduğumuz işlem ile oluşturmuş olduğumuz Database Resctriction görevi görecek olan Management Scope ile önceden var olan rolümüz arasında ilişki kurduk. Dikkat ederseniz Role Assign alanında Security Group ismini veriyoruz. Ve o Security grup üzerinde hali hazırda yetki olduğu için sadece yetkilerde bir güncelleme oluyor. Ve Mail Recipients ve mail Recipient Creation işlemlerinde yukarıdaki Scope’a uygun kriterleri hedef almasını sağlamış oluyoruz. Şimdi deneme sırasına geçebiliriz J
Resim-11
Resimdeki hata da belirttiği üzere Emre A kullanıcısı Ankara-Bolge OU su üzerinde yetkili ve Mailbox Database Restriction işlemini uygularken biz Ankara Mailbox DB01 üzerinde uyguladık. Dolayısıyla Emre A kullanıcısının Adana Mailbox DB01 üzerine Mailbox Create etme yetkisi yok. Verdiği hata da bu yönde. Fakat doğru Mailbox seçimini manuel yapabilir veya direk seçim yapmadan next ile ilerlerse varsayılan olarak Ankara Mailbox DB01 üzerinde Mailbox Create ettiğiniz göreceksiniz.
Gelin aynı işlemi hızlıca Adana-Bolge OU birimi içinde gerçekleştirelim bazı komut ve detaylara girerek siz okuyucuları sıkmak istemiyorum parametreler yazımın başında da bahsettiğim gibi aynı tek değişken madde ortamınızdaki Domain ismi ve OU isimleriniz ve yetki ataması gerçekleştireceğiniz Universal Security Group isimleri olacaktır.
Adana-Bolge OU su için delegasyon ve Mailbox Database restriction işlemi gerçekleştiriyorum.
Resim-12
Parametrelerimiz yukarıda da gördüğünüz gibi aynı. Fakat OU ve Sec. grup isimleri sadece değişik.
Şimdi gelelim deneme işlemine J normal şartlar altında bu yaptığımız işlemle Adana daki IT Personelimiz Şafak Tan. Adana Mailbox DB01 dışında bir DB’ye Mailbox oluşturamaması lazım.
Resim-13
Hata mesajımızı görmüş olduğunuz üzere Ankara Mailbox DB01 üzerine Mailbox Create etmek istediğimizde bizi bu Mailbox DB üzerine yazma yetkimiz olmadığı için uyarıyor J
Yani işlemimiz başarılı.
Buraya kadar yapmış olduğumuz işlemlerle hem yapınızda dağınık bir coğrafi lokasyon durumu ve bölge IT support birimleriniz söz konusuysa Exchange delegasyonu gerçekleştirebilirsiniz hem de Delegasyon yaparken bölge bazlı Mailbox Database kısıtlamasına giderek kimin hangi DB üzerinde Mailbox Create ettiğini veya doğru yanlış yapılacak Mailbox oluşturma işlemlerini önlemiş olursunuz. Gerçek hayatta bu senaryonu kendim 13 lokasyon da faaliyet gösteren bir Sağlık Grubunda uyguladım. En çok fayda sağlayan nokta hem gereksiz iş yükünün azalması hem de oluşabilecek hataları önlemek yönündeydi.
Bu konuyla ilgili sorularınızı alt kısımda bulunan yorumlar alanını kullanarak sorabilirsiniz.
Referanslar
