1341386431_190На недавно проходившем Redmond Interoperability Protocols Plugfest 2013 было несколько интересных докладов, которые приоткрыли дальнейшую судьбу протокола клиентского доступа в связке Exchange↔Outlook. Начиная с Exchange 2003 для удалённого доступа использовался протокол MAPI/RPC/HTTP (MAPI over RPC over HTTP), для связи внутри корпоративной сети это был MAPI/RPC. Начиная с Exchange 2013 от второго нас избавили, остался только MAPI/RPC/HTTP. Судя по докладам с этого мероприятия совсем скоро (SP1?) будет дальнейшее усовершенствовании – MAPI/HTTP. То есть по факту мы избавляемся от достаточно старого протокола RPC при взаимодействии клиента с сервером. Но он по прежнему участвует во внутрисерверных коммуникациях.

Позже я планирую подробнее рассмотреть этот новый протокол, а пока:

Ссылки на доклады:
Exchange 2013 and MapiHttp
Outlook 2013 Client Protocols
Exchange 2013 Protocols

00018711Очень давно я писал о том, как назначать право Send-As на группу рассылки. Так как всё это отлично работало, то я подход по раздаче таких прав не пересматривал до последнего времени. Привело это к тому, что относительно недавно я столкнулся с крайне интересным инцидентом. Имеется организационная единица с группами рассылки, предположим, group1 и group2. Администратор, обладающий правами на запуск командлета Add-ADPermission в этой организационной единице, пытается выдать право Send-As на эти группы. С первой группой получается, со второй нет. Вспоминаем танцы с бубнами вокруг общих папок. Проверяем владельцев обоих групп:

[PS] C:>Set-Location ad:
[PS] AD:>(Get-Acl "CN=group1,OU=Groups,DC=o365lab,DC=pro").Owner
O365LABCAS1$
[PS] AD:>(Get-Acl "CN=group2,OU=Groups,DC=o365lab,DC=pro").Owner
O365LABadm_Stas

Видно, что владелец первой группы – сервер клиентского доступа, через который (уж так получилось) подключается EMS нашего администратора, и который имеет поэтому все возможные и невозможные права на объект. Владелец второй группы – некий администратор. Отсюда можно сделать простой вывод – наш сервер клиентского доступа не имеет каких-то прав, необходимых для назначения Send-As. Что по идее странно, так как серверы Exchange обладают достаточно широкими полномочиями в рамках AD.

Небольшое отступление. Право на выдачу прав (извините за тавтологию) обеспечивается правом Write DACL. И в первою очередь, в нашей ситуации имеет смысл посмотреть, что происходит с ним на наших двух объектах:

[PS] AD:>(Get-Acl "CN=group1,OU=Groups,DC=o365lab,DC=pro").Access | ? {$_.ActiveDirectoryRights -like "*WriteDacl*"} | ft IdentityReference,InheritedObjectType -AutoSize
IdentityReference                    InheritedObjectType
-----------------                    -------------------
O365LABExchange Windows Permissions 4828cc14-1437-45bc-9b07-ad6f015e5f28
O365LABExchange Windows Permissions bf967aba-0de6-11d0-a285-00aa003049e2
O365LABExchange Enterprise Servers  bf967a9c-0de6-11d0-a285-00aa003049e2
BUILTINAdministrators               00000000-0000-0000-0000-000000000000

Для второй группы картинка будет такая же. GUID’ы, которые представлены в колонке InheritedObjectType представляют собой объекты в схеме, для которых мы можем назначать Write DACL. Попробуем посмотреть, что скрывается за GUID’ами “4828cc14-1437-45bc-9b07-ad6f015e5f28” и “bf967aba-0de6-11d0-a285-00aa003049e2”:

[PS] AD:>$guid1 = ([GUID]'4828cc14-1437-45bc-9b07-ad6f015e5f28').toByteArray()
[PS] AD:>$guid2 = ([GUID]'bf967aba-0de6-11d0-a285-00aa003049e2').toByteArray()
[PS] AD:>Get-ADObject -fi {schemaIDGUID -eq $guid1} -SearchBase (Get-ADRootDSE).schemaNamingContext -prop schemaIDGUID | Select name,@{Name='schemaIDGUID';Expression={[guid]$_.schemaIDGUID}}
name                                         schemaIDGUID
----                                         ------------
inetOrgPerson                                4828cc14-1437-45bc-9b07-ad6f015e5f28
[PS] AD:>Get-ADObject -fi {schemaIDGUID -eq $guid2} -SearchBase (Get-ADRootDSE).schemaNamingContext -prop schemaIDGUID | Select name,@{Name='schemaIDGUID';Expression={[guid]$_.schemaIDGUID}}
name                                         schemaIDGUID
----                                         ------------
User                                         bf967aba-0de6-11d0-a285-00aa003049e2

Итого. Мы видим, что группа O365LABExchange Windows Permissions может назначать права только на два типа объектов – User и inetOrgPerson, что и является причиной проблемы с назначением права Send-As. На пользователей мы его назначать можем, на группы уже нет. Чуть позже я нашёл, что так стал отрабатываться запрос на назначение прав Send-As, начиная с Exchange 2010 RTM:

/PrepareDomain no longer applies an unscoped DeleteTree and WriteDACL ACEs on the domain partition.  Instead, these ACEs are scoped specifically to user and inetOrgPerson class objects.

Решение проблемы достаточно простое – необходимо создать группу безопасности, в которую включить группу Exchange Windows Permissions, и этой группе выдать право Write DACL на объект groups на нужные нам организационные единицы. Особо смелые могут это право выдать на весь домен.

Полезные ссылки:
Exchange 2010 and Resolution of the AdminSDHolder Elevation Issue
The Write DACL for the Exchange Enterprise Servers group should be removed from the root of the domain
Active Directory’s Object Specific ACEs and PowerShell
MSExchange ActiveSync EventID 1053