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.
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.
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 Universal Security Group ismi yazılarak parametrelerin
sağlanmasıdır.
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.
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.
Resimde Gördüğünüz üzere Adana-Bolge OU birimi içinde ilgili universal
security grupa 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.
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 şikayetler 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.
İ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.
Ş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.
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 Assignee 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
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.
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
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.
Faydalı olması dileklerimle.
Hiç yorum yok:
Yorum Gönder