Exchange Server Impersonation – Delegation ve Folder Permissions Arasındaki Farklar
Exchange server organizasyonlarında pek çok farklı yetki talepleri bulunmaktadır. Bunların en başında birisi veya bir grup adına mail gönderme gelmektedir. Ancak bu izinler bazen bu kadar masum veya bilindik olmayabilir. Özellikle arşivleme ile başlayan ve ajanda, posta kutusu raporlama, audit gibi izleme derken çok ciddi seviyelere gelmektedir. Özellikle bir hesaba verilen aşırı yetki toplam güvenlik seviyesi için büyük risk doğurabilir. Buraya kadar anlattığım işlemler aslında hep delegation – delasyon başlığı altında bildiğimiz izinler. Yani bir active directory hesabına atanmış izinler olarak tanımlanabilir. Tabiki bu izinler aslında güvenlik yöneticilerinin çok hoşuna giden türden izinler değildir.
Peki bir kullanıcı veya servis hesabına bir başka kullanıcı posta kutusuna erişim izni vermek istersek ne yapabiliriz?
Böyle bir durumda temel 3 izinden söz edebiliriz;
Delegation
Folder Permissions
Impersonation
Delegasyon aslında sektörde en çok bilinen izin verme yöntemidir. En çok bilinen izin tipi “Send on behalf of” dur. ECP üzerinde kullanıcı özelliklerinden bunu kolaylıkla yapabilirsiniz.
Delegasyonda bazen ek folder permission eklenebilir. Örnek bir PS paylaşıyorum;
Set-MailboxFolderPermission -Identity ayla@contoso.com:\Marketing -User ed@contoso.com -AccessRights Owner
İkinci izin ise aslında tamamen yukarıdaki komut ile verebileceğimiz klasör izinleridir. Burada ilgili posta kutusu adına mail gönderme ya tüm posta kutusuna erişim gibi bir izin yoktur. Örneğin bir ekip ve ekip liderini düşünün, ekip lideri kendi posta kutusundaki ekip projelerini kolaylıkla ekip ile paylaşabilir. Bu arada aklınıza hemen şu gelebilir, son kullanıcı nasıl powershell kullanır? Son kullanıcı bunu zaten outlook programı üzerinden kolaylıkla aşağıdaki gibi yapabilir;
İlgili klasör üzerine sağ tıklayıp, özellikler bölümünden istediği kişiye istediği yetkiyi verebilir.
Gelelim makalemizin aslında konusuna, Impersonation? Genelde standart yönetim işleri için istenilen bir izin olmadığından çok karşınıza çıkmayabilir, çünkü bu için sadece EWS üzerinden çalışır. Kullanıcı tarafından değiştirilemez bir izindir. Bu sayede daha basit, daha etkili ve daha güvenlik bir yetkilendirme yöntemidir. Ancak yukarıdaki iş ihtiyaçlarını karşılamak için tasarlanmamıştır. Örneğin bir kullanıcı outlook programı üzerinden istediği gibi izin verebilmekte ve bu da temel bir iş ihtiyacıdır.
Genelde ne tür izinler için kullanılır? Özellikle Office 365 ve yerleşik exchange sunucularınızdaki arşivleme, OOF mesajlarını merkezi yönetmek gibi işlerde ihtiyaç duyulur. Çünkü bu işler için genelde 3 parti yazılımlar kullanırız ve bunlarda EWS’ i kullanmayı tercih eder.
Bu izin ile nasıl tanışırsınız? Örneğin web servis üzerinden diğer kullanıcılar için mail atma yetkisi isteyen bir program kurarsanız karşınıza aşağıdaki gibi bir uyarı çıkabilir;
Peki bu izni nasıl veriyoruz? Bu izinde diğer izinlerde olduğu gibi admin loğlarından ve yine mailbox adudit, ews ve IIS loğlarından takip edilebilen bir izindir. Yani bu izni verdiğiniz servis hesaplarının da yaptığı aksiyonları yine exchange server’ ın varsayılan izleme mekanizması ile takip etme şansınız bulunmaktadır.
Peki böyle bir iş ihtiyacımız var ise nasıl ilerleyeceğiz?
Öncelikle office 365 veya Exchange Server 2013 ve sonrası için adımlar aynıdır.
Office 365 Exchange Admin Portal üzerinde sırası ile permissions bölümüne gelip + düğmesine tıklıyoruz. Çıkan pencerede yeni role grubumuz için bir isim veriyoruz.
On-Prem Exchange sunucusu içinde aynı yönergeleri Exchange Admin Portal yerine ECP üzerinden yapabilirsiniz.
Örneğin ben Impersonation seçtim ve hemen altında bulunan Role bölümüne tıklıyoruz. Açılan pencereden “ApplicationImpersonation” role’ ünü seçiyoruz.
Son durumda ise bu role grup için yetkili hesap veya grup seçiyoruz
Artık izin verme işlemini tamamlamış olduk. Ancak bu yetkilendirme için scope, yani uygulama kapsamı belirtmek isterseniz powershell’ de kullanabilirsiniz.
Öncelikle powershell ile tüm organizasyon için bir kullanıcıya bu izni vermek isterseniz aşağıdaki komutu çalıştırabilirsiniz
New-ManagementRoleAssignment -Name “ResourceImpersonation” -Role ApplicationImpersonation –User “hakan_admin”
Ya da bu kapsam çok büyük olabilir yani tüm kullanıcılarda değil de toplantı odaları için bir uygulama olabilir, rapor çıkarmak için kullanıyordum örneğin bir müşteride sadece room mailbox veya benzeri kapsam tanımlayabiliriz.
Önce kapsamı belirleyin, birkaç örnek paylaşıyorum;
New-ManagementScope -Name “ResourceMailboxes” -RecipientRestrictionFilter {RecipientTypeDetails -eq “RoomMailbox” -or RecipientTypeDetails -eq “EquipmentMailbox”}
Örneğin yukarıdaki kapsam sadece toplantı odaları ve ekipman posta kutuları için bir sınır tanımlar. Daha sonra aşağıdaki komutu çalıştırabiliriz
New-ManagementRoleAssignment –Name “ResourceImpersonation” –Role ApplicationImpersonation –User “hakan_admin” –CustomRecipientWriteScope “ResourceMailboxes”
Hakan kullanıcısına yine izin verdik ancak şimdi tüm kullanıcılar değil “Resourceailboxes” scope içeriğinde yetkili oldu. Aşağıdaki bu konuda yararlı birkaç örnek paylaşıyorum;
İlk örneğimizde mail sunucuları için bu izni veriyoruz.
New-ManagementScope -Name “Mailbox Servers 1 through 3” -ServerList MailboxServer1, MailboxServer2, MailboxServer3
İkinci örneğimizde ise AD site belirliyoruz.
New-ManagementScope -Name “Redmond Site Scope” -ServerRestrictionFilter {ServerSite -eq “CN=Redmond,CN=Sites,CN=Configuration,DC=contoso,DC=com”}
Bu örnekte ise belirli bir OU için yetki veriyoruz.
New-ManagementScope -Name “Executive Mailboxes” -RecipientRoot “contoso.com/Executives” -RecipientRestrictionFilter {RecipientType -eq “UserMailbox”}
Bu örnekte ise title’ da VP geçen ancak kişiler filtreleyip hemen sonra o grup için “Executive Administrators” güvenlik grubuna “Mail Recipients” yetkisi verebiliyoruz.
New-ManagementScope -Name “Protected Exec Users” -RecipientRestrictionFilter { Title -Like “*VP*” } -Exclusive; New-ManagementRoleAssignment -SecurityGroup “Executive Administrators” -Role “Mail Recipients” -CustomRecipientWriteScope “Protected Exec Users”
Son örneğimiz ise örneğin mailbox database seviyesinde yetki sınırları tanımlayabiliriz.
New-ManagementScope -Name “Seattle Databases” -DatabaseRestrictionFilter {Name -Like “SEA*” }
Peki yetki tanımlama işleminden sonra yapınıza göre Active Directory domain controller sunucularının replikasyonunun tanımlanmasını bekleyin ve yetki ihtiyacı olan uygulama için ilgili servis hesabını bir daha tanımlayın.
Umarım faydalı bir makale olmuştur. Bir sonraki makalemde görüşmek üzere.
Kaynak