Правила клиентского доступа в Exchange 2019
Правила доступа клиентов помогают управлять доступом к организации Exchange 2019 в Центре администрирования Exchange (EAC) и удаленном PowerShell на основе свойств клиента или запросов на доступ клиента. Правила доступа клиента — это правила потока обработки почты (также известные как правила транспорта) для EAC и удаленных подключений PowerShell к организации Exchange. Вы можете запретить подключение EAC и удаленных клиентов PowerShell к Exchange на основе их IP-адреса (IPv4 и IPv6), типа проверки подлинности и значений свойств пользователя. Например:
- Запретите клиентский доступ с помощью удаленной оболочки PowerShell (которая также включает в себя командную консоль Exchange).
- Блокировка доступа к EAC для пользователей в определенной стране или регионе.
Процедуры правил клиентского доступа см. в разделе Процедуры для правил клиентского доступа в Exchange Server.
Компоненты правил клиентского доступа
Правило состоит из условий, исключений, действия и значения приоритета.
Условия. Определите клиентские подключения, к которому нужно применить действие. Полный список условий см. в разделе Условия и исключения правила клиентского доступа далее в этом разделе. Если клиентское подключение соответствует условиям правила, действие применяется к клиентскому подключению, и оценка правила останавливается (больше к подключению не применяются правила).
Исключения. При необходимости определите клиентские подключения, к которым не должно применяться действие. Исключения переопределяют условия и запрещают применение действий правила к подключению, даже если оно соответствует всем настроенным условиям. Оценка правила продолжается для клиентских подключений, разрешенных исключением, но последующее правило по-прежнему может повлиять на подключение.
Действие. Указывает, что следует делать с клиентскими подключениями, которые соответствуют условиям в правиле и не соответствуют ни одному из исключений. Допустимые действия:
Разрешить подключение (
AllowAccessзначение параметра Action ).Блокировать подключение (
DenyAccessзначение параметра Action ).Примечание. Блокировка подключений по определенному протоколу может повлиять на другие приложения, использующие этот протокол.
Приоритет: указывает порядок применения правил к клиентским подключениям (меньшее число указывает на более высокий приоритет). Приоритет, заданный по умолчанию, зависит от времени создания правила (чем старше правило, тем выше приоритет), а проверка в случае правил с высоким приоритетом выполняется раньше, чем в случае правил с низким приоритетом. Помните, что если клиентское подключение соответствует условиям правила, обработка правил останавливается.
Дополнительные сведения о настройке значения приоритета для правил см. в разделе Использование командной консоли Exchange для задания приоритета правил доступа клиентов.
Как оцениваются правила клиентского доступа
В приведенной ниже таблице описывается оценка нескольких правил, включающих одно и то же условие, а также правил с несколькими условиями, значениями условий и исключениями.
| Компонент | Логический оператор | Комментарии |
|---|---|---|
| Несколько правил, содержащих одно условие | Первое правило применяется, а последующие пропускаются | Например, если правило с наивысшим приоритетом блокирует удаленные подключения PowerShell и вы создаете другое правило, разрешающее удаленные подключения PowerShell для определенного диапазона IP-адресов, все удаленные подключения PowerShell по-прежнему блокируются первым правилом. Вместо создания другого правила для удаленного powerShell необходимо добавить исключение в существующее удаленное правило PowerShell, чтобы разрешить подключения из указанного диапазона IP-адресов. |
| Несколько условий в одном правиле | И | Клиентское подключение должно соответствовать всем условиям правила. Например, подключения EAC от пользователей в отделе бухгалтерского учета. |
| Одно условие с несколькими значениями в правиле | ИЛИ | Для условий, в которых разрешено несколько значений, подключение должно соответствовать одному (не всем) из указанных условий. Например, EAC или удаленные подключения PowerShell. |
| Несколько исключений в одном правиле | ИЛИ | Если клиентское подключение соответствует какому-либо из исключений, то к нему не применяются действия. Подключению не обязательно соответствовать всем исключениям. Примеры: IP-адрес 19.2.168.1.1 или обычная проверка подлинности. |
Вы можете проверить, как правила клиентского доступа повлияют на то или иное клиентское подключение (какие правила будут к нему применяться). Дополнительные сведения см. в статье Использование командной консоли Exchange для проверки правил доступа клиентов.
Важные замечания
Клиентские подключения из внутренней сети
Подключениям из локальной сети не разрешается автоматически обходить правила клиентского доступа. Поэтому при создании правил клиентского доступа, которые блокируют клиентские подключения к Exchange, необходимо учитывать, как это может повлиять на подключения из внутренней сети. Предпочитаемый способ разрешить внутренним клиентским подключениям обходить правила клиентского доступа — создать правило с самым высоким приоритетом, которое разрешает клиентские подключения из внутренней сети (со всех или только с определенных IP-адресов). Таким образом, клиентские подключения всегда разрешены, независимо от того, какие блокирующие правила будут созданы в будущем.
Правила клиентского доступа и приложения среднего уровня
Многие приложения, которые обращаются к Exchange, используют архитектуру среднего уровня (клиенты обращаются к приложению среднего уровня, а приложение среднего уровня взаимодействует с Exchange). Правило клиентского доступа, разрешающее доступ только из локальной среды, может блокировать приложения среднего уровня. Таким образом, правила должны разрешать доступ с IP-адресов приложений среднего уровня.
Приложения среднего уровня, принадлежащие корпорации Майкрософт (например, Outlook для iOS и Android), будут обходить блокировку правилами доступа клиентов и всегда будут разрешены. Чтобы предоставить дополнительный контроль над этими приложениями, необходимо использовать доступные в них возможности управления.
Время изменения правил
Для повышения общей производительности правила клиентского доступа используют кэш, поэтому изменения правил вступают в силу не сразу. Чтобы первое правило, созданное в организации, вступило в силу, может потребоваться до 24 часов. После этого изменение, добавление и удаление правил может занимать до одного часа.
Администрирование
Вы можете использовать командную консоль Exchange (удаленную оболочку PowerShell) только для управления правилами доступа клиентов, поэтому необходимо быть осторожными с правилами, которые блокируют доступ к удаленному PowerShell.
Рекомендуется создать правило клиентского доступа с наивысшим приоритетом, чтобы сохранить доступ к удаленной оболочке PowerShell. Например:
New-ClientAccessRule -Name "Always Allow Remote PowerShell" -Action Allow -AnyOfProtocols RemotePowerShell -Priority 1
Типы и протоколы проверки подлинности
Не все типы проверки подлинности поддерживаются для всех протоколов. Поддерживаемые типы проверки подлинности для каждого протокола в Exchange Server описаны в следующей таблице:
| Протокол | AdfsAuthentication | BasicAuthentication | CertificateBasedAuthentication | NonBasicAuthentication | OAuthAuthentication |
|---|---|---|---|---|---|
ExchangeAdminCenter |
поддерживается | поддерживается | н/д | н/д | н/д |
RemotePowerShell |
н/д | поддерживается | н/д | поддерживается | н/д |
Условия и исключения для правил клиентского доступа
Условия и исключения в правилах клиентского доступа определяют, к каким клиентским подключениям правило применяется, а к каким — нет. Например, если правило блокирует доступ удаленных клиентов PowerShell, можно настроить правило так, чтобы разрешить удаленные подключения PowerShell из определенного диапазона IP-адресов. В условии и соответствующем исключении используется один и тот же синтаксис. Единственное отличие заключается в том, что условия указывают, к каким клиентским подключениям правило применяется, а исключения — наоборот.
В приведенной ниже таблице описываются условия и исключения, доступные в правилах клиентского доступа.
| Параметр Condition в командной консоли Exchange | Параметр exception в командной консоли Exchange | Описание |
|---|---|---|
| AnyOfAuthenticationTypes | ExceptAnyOfAuthenticationTypes | Допустимые значения в Exchange Server:
Вы можете указать несколько значений, разделив их запятыми. Можно использовать кавычки вокруг каждого отдельного значения ("value1","value2"), но не для всех значений (не используйте "value1,value2"). |
| AnyOfClientIPAddressesOrRanges | ExceptAnyOfClientIPAddressesOrRanges | Поддерживаются адреса IPv4 и IPv6. Допустимые значения:
Вы можете указать несколько значений, разделив их запятыми. Дополнительные сведения об IPv6-адресах и синтаксисе см. в разделе Exchange 2013: IPv6-адреса основы. |
| AnyOfProtocols | ExceptAnyOfProtocols | Допустимые значения в Exchange Server:
Вы можете указать несколько значений, разделив их запятыми. Можно использовать кавычки вокруг каждого отдельного значения ("value1","value2"), но не вокруг всех значений (не используйте "value1,value2"). Примечание. Если это условие не используется в правиле, правило применяется к обоим протоколам. |
| Scope | н/д | Задает тип подключений, к которым применяется правило. Допустимые значения:
|
| UsernameMatchesAnyOfPatterns | ExceptUsernameMatchesAnyOfPatterns | Принимает текст и подстановочный знак (*) для идентификации имени учетной записи пользователя в формате <Domain>\<UserName> (например, contoso.com\jeff или *jeff*, но не jeff*). Для символов, не являющихся буквенно-цифровыми, не требуются escape-символы. Вы можете указать несколько значений, разделив их запятыми. |
| UserRecipientFilter | н/д | Указывает пользователя, к которому применяется правило, с помощью синтаксиса фильтра OPath. Например, "City -eq 'Redmond'". Фильтруемые атрибуты:
Для критериев поиска используется следующий синтаксис:
Можно связать несколько условий поиска вместе с помощью логических операторов |