Меню

Exchange 2010 настройка безопасности



Настройка SSL сертификата в ExchangeServer 2010

В Exchange Server 2010, как и в его предшественнике Exchange Server 2007 для работы всевозможных коммуникационных протоколов повсеместно используются сертификаты SSL. При установке первого сервера Exchange, он устанавливается с самоподписанным сертификатом. И прежде чем внедрить новый сервер Exchange, необходимо создать и присвоить ему новый SSL сертификат.

В данной статье мы попробуем настроить SSL сертификат для домена contoso.local.

Генерируем новый сертификат для Exchange Server 2010

В консоли управления Exchange Management Console перейдем в раздел Server Configuration. Щелкнем правой кнопкой по серверу и выберем пункт New Exchange Certificate.

Введем имя нового сертификата. В данном случае назовем сертификат “Contoso Exchange Server”.

Далее нам нужно указать имена всех служб Exchange 2010, которые будут защищены с помощью сертификатов SSL.

Первая служба — Outlook Web App. Укажем внешнее и внутренне имя для Outlook Web App. В данном примере настроим внутреннее имя — “ex2010.contoso.local” , внешнее — “mail.contoso.local”.

Затем настроим имя для ActiveSync. Для упрощения управления и настройки я буду использовать тоже имя, что и для Outlook Web App (mail.contoso.local).

Настроим службы: Web Services, Outlook Anywhere и Autodiscover. И опять я укажу имя “mail.contoso.local”. Для Autodiscover дополнительные имена “autodiscover.contoso.local” и “autodiscover.xyzimports.local” для всех почтовых доменов организации.

Сервер Hub Transport также для обеспечения безопасности SMTP коммуникации требует наличие SSL сертификата. Укажем имя “mail.contoso.local”.

Параметры Legacy Name (совместимость) необходимо настраивать, если вы планируете постепенный перенос служб и данных из Exchange 2003 в Exchange 2010. Имена legacy name нужно настроить для каждого обслуживаемого пространства имен в организации, например “legacy.contoso.local” и “legacy.xyzimports.local”.

После настройки всех служб, перейдем к следующему этапу мастера настройки нового сертификата Exchange.

Подтвердим, что все указанные доменные имена будут включены в запрос на генерацию нового сертификата. Если есть необходимость добавить дополнительные домены, сделайте это.

Далее мы должны заполнить справочную информацию сертификата, включая название организации, ее местоположение и место расположения файла-запроса сертификата.

Для генерации файла с запросом сертификата, нажмем кнопку New.

Работа мастера окончена.

Затем должно появиться окно, в котором указывается, что мастер в качестве типа сертификата Exchange выбрал “Unified Communications certificate” (также он называется сертификатом SAN).

После того, как мы создали запрос на новый сертификат, нужно вернуться в консоль Exchange Management Console, правой кнопкой щелкнем по серверу и выберем пункт Complete Pending Request.

Укажем путь к сертификату, убедитесь, что новый SSL сертификат импортировался успешно.


И в списке действительных сертификатов сервера появится еще один.

Назначаем новый сертификат серверу Exchange 2010

После установки нового SSL сертификата, необходимо назначить его службам Exchange Server 2010. Для этого щелкните правой кнопкой мыши по новому сертификату и выберите “Assign Services to Certificate”.

Укажем наш новый сервер Exchange и нажмем Next.

Читайте также:  Настройка пульта one for all urc 3940

Укажем службы, для которых необходимо назначить сертификат. В этом примере укажем сервисы IIS и SMTP.

После окончания мастера появится окно с предложением перезаписать текущий самоподписанный сертификат, согласимся с этим предложением, нажав Yes.

Добрый день. В данном примере рассматривается если один Exchange сервер. А что делать если их несколько, например два HubCas. На одном из них данный сертификат будет установлен, а как сдублировать его на другой сервер потом чтобы сертификат отображался и там и там?

Просто щелкните правой кнопкой мыши по новому сертификату и выберите “Assign Services to Certificate”, указав что вы хотите назначить сертификат еще одному серверу (см. предпоследний скриншот)

У меня не было такой опции в меню действий как «Назначение служб сертификатов» в графической консоли Exchange, поэтому пришлось делать через PowerShell.
Службы я смог назначить выполнив команду:
Enable-ExchangeCertificate -Thumbprint 50CBA321D03DB2710D0973A5A8611175CA4F40CE -Services SMTP,IIS
где значение Thumbprint я получил с помощью команды Get-ExchangeCertificate.
Чтобы сдублировать сертификат на второй HubCAS я попытался экспортировать его в формат .pfx с помощью команды:
$file = Export-ExchangeCertificate -Thumbprint 50CBA321D03DB2710D0973A5A8611175CA4F40CE -BinaryEncoded:$true -Password (Get- Credential).password
Set-Content -Path «c:\certificates\tmcert.pfx» -Value $file.FileData -Encoding Byte
После чего на другом HubCAS попытался выполнить импорт сертификата Exchange. Через меню обзор выбрал свой tmcert.pfx, ввёл пароль сертификата, в след. окне указал на тот самый HubCAS где не установлен сертификат. Но при выполнении этого процесса получил ошибку: «Не удается импортировать сертификат. Сертификат с отпечатком 50CBA321D03DB2710D0973A5A8611175CA4F40CE уже существует».

Таким образом сертификат у меня отображается лишь на одном HubCAS и я не знаю как мне сдублировать его на второй HubCAS.

Внутри одной организации не нужно экспортировать сертификат с одного CAS/HT на другой CAS/HT.
На первом сервере выполните следующее:
1. Откройте Exchange Management Console

2. Встаньте на уровень Server Configuration

3. В нижней панели щелкните ПКМ по своему сертификату и выберите Assign Services to Certificate

4. Добавьте второй сервер (кнопка Add )

так нет такой кнопочки вернее она есть о выбор серверов не дает. но это только в сертификате не созданным

Сейчас проверил — все на месте. Возможно дело в том, что вы не создали запрос (request) на выпуск сертфиката, но не импортировали его.

Здравствуйте! Возникла проблема! Итак, после создания сертификата «cert.req» необходимо импортировать сертификат, и вот вопрос: exchange просит указать файл с расширением *.cer, *.crt а наш созданный сертификат с расширением *.req как быть?

*.req — это файл с запросом сертификата — на основании которого генерируется новый сертификат.
Перечитайте внимательно — этот момент в статье был описан:
«После того, как мы создали запрос на новый сертификат, нужно вернуться в консоль Exchange Management Console, правой кнопкой щелкнем по серверу и выберем пункт Complete Pending Request.»

Все равно не ясно. =\ А где сертификат генерируется? выбрав пункт Compele Pending Request необходимо указать сертификат( как я понял), а у нас лишь *.req – это файл с запросом сертификата

Читайте также:  Добавить настройки к инст

На основании сгенерированного запроса на выпуск сертификата (тот самый req файл) нужно выписать сертификат. Сделать это можно в корпоративном центре сертификации -Certificate Authority (если есть), у внешнего поставщика (тот же Digicert) либо выписать себе сапоподписанный сертфикат сторонними утилитами (естественно, он будет недоверенным)

Добрый день,
установили новый сертификат на сервере EX, и у пользователей в сети начало выходить окно «Ввести логин\пароль» постоянно

Возможно сертификат недоверенный? Попробуйте добавьте выдающий CA в Trusted Root Cert на клиенте и на сервере Exchange

я сделал все как было написано тут:
http://forum.oszone.net/thread-210110.html
сомнения в работе autodiscover, такое мнение что все пользователи в сети пытаются коннектиться не по локалке, а через другую точку: _https://mail.contoso.com/Autodiscover/Autodiscover.xml

Добрый день,
такой вопрос, я мигрировал с exchange 2003 на 2010 и старый exchange имел одно и тоже имя с сертификатом который был куплен mail.domain.ru теперь новое имя сервера
ex.domain.ru, можно ли сделать так что бы старый сертификат так и остался для внешних пользователей а внутренний работал с само подписанным?

В Exchange 2010 на CAS сервер импортируйте старый сертификат и смените external имя для OWA /ActiveSync и прочих на mail.domain.ru

Доброго дня заработает ли купленный Wildcard сертификат для сайта
У которого. имя *.firma.ru у почтовика имя mail2.firma.ru
https://image.ibb.co/fvGeBd/SSL.png

Куплен был тут:
https://masterhost.ru/service/ssl/DomainServerSign_Wildcard/
Но тогда не было приписки «В стоимость сертификата включена поддержка трех почтовых субдоменов OWA, MAIL, AUTODISCOVER и WWW»

Да, Exchange 2010 поддерживает использование wildcard сертфикатов.

Источник

Права доступа к почтовым ящикам и группам Exchange 2010/13

За время работы с Exchange сервером очень часто от пользователей получали запросы на предоставление различного доступа к почтовым ящикам пользователей, к общим почтовым ящикам или к группам рассылки. Ну про легитимность данной процедуры поговорим как-нибудь отдельно, а вот техническая сторона иногда вызывала затруднения.

Часто запросы звучали так: «Хочу чтобы пользователь мог читать, но не мог удалять письма в почтовом ящике!» Или так: «Хочу отправлять сообщения от имени группы!»

Давайте разберемся по порядку чем нам с этим может помочь родная консоль Exchange.


Рис.1. Права доступа к ящику пользователя в консолях Exchange 2010/2013

Как мы видим из рис.1, к почтовому ящику пользователей через консоль могут быть предоставлены: полный доступ и/или доступ отправки от имени. Эти же права распространяется и на общие почтовые ящики (mailbox type=shared).


Рис.2. Права доступа к группе рассылки в консолях Exchange 2010/2013

Для групп рассылки (рис.2) все немного проще и хуже одновременно. В консоли 2010 даже нет возможности выдачи прав. В консоли 2013 такая возможность присутствует.

Теперь давайте отбросим «костыли» консолей Exchange и обратимся непосредственно к Powershell’у и к Active Directory, которые позволят нам поиграться с правами намного гибче.

Читайте также:  Lock on нет настроек экрана

1. Предоставление прав «Отправить как»

Предоставление прав «отправить как» — это даже не функция «Exchange» — это целиком права Active Directory. Так что мы можем спокойно использовать закладку Security в AD для выдачи таких прав.


Рис.3. Права на отправку от имени пользователя и от имени группы рассылки

То же самое можно сделать и используя Powershell с подключенным модулем ActivDirectory. К примеру: предоставление пользователю с логином IvanovVV прав отправлять сообщения как «Поддержка пользователей».

Add-ADPermission «Поддержка пользователей» -user «IvanovVV» -ExtendedRights Send-As

Данный способ подходит как для предоставления прав на почтовые ящики, так и для предоставления права на группы рассылки.

2. Предоставление прав на почтовые ящики пользователей и на общие почтовые ящики, кроме прав «Отправить как».

Предоставление прав на почтовые ящики затрагивает непосредственно базы Exchange сервера, поэтому для данного действия будем использовать консоль PowerShell с подключенным модулем Exchnage. К примеру: предоставим полные права пользователю IvanovVV к почтовому ящику, который имеет alias (синоним) «Service.Desk».

Add-MailboxPermission -Identity «Service.Desk» -user «IvanovVV» -AccessRights FullAccess -InheritanceType All

В данном случае мы предоставили пользователю полные права. Полные права мы могли бы предоставить и через консоль Exchange, но через Powershell мы можем немного расширить свои возможности по уровню предоставления прав: AcessRights: FullAccess, ExternalAccount, DeleteItem, ReadPermission, ChangePermission, ChangeOwner.

Параметр InheritanceType позволяет указывать, будут ли разрешения наследоваться папками в почтовом ящике.

Более подробно с примерами и описанием все параметров можно прочитать тут: Add-MailboxPermission

3. Предоставление «Глобальных» прав к почтовым ящикам.

Предположим что вы крутой админ и вам нужен полный доступ к ящикам всех пользователей. Или у вас есть крутой сервис, который лазает по ящикам пользователей. Тогда для вас протоптан путь в консоль ADSI — Configuration — туда, где хранятся настройки и права самого Exchange. Смотрим Рис.4. Все выставленные там права наследуются всеми почтовыми базами и, как следствие, наследуются всеми, вновь создаваемыми почтовыми, ящиками. К уже созданным почтовым ящикам права необходимо будет выставлять вручную (ну или через PS скрипт).


Рис.4. Глобальные права на все почтовые ящики

P.S.: Я специально в статье не учитывал такую функцию как «Отправить от имени» (Send on behalf) — данная функция, в силу российского менталитета, в России почти не используется, по крайней мере я ни разу этого не видел и не слышал о таком. Но такая функция тоже присутствует и нам стоит о ней помнить.

Данная статья не подлежит комментированию, поскольку её автор ещё не является полноправным участником сообщества. Вы сможете связаться с автором только после того, как он получит приглашение от кого-либо из участников сообщества. До этого момента его username будет скрыт псевдонимом.

Источник

Adblock
detector