Кто настроит exchange 2010

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

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

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

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

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

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

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

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

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

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. Глобальные права на все почтовые ящики

Источник

Для системного администратора

—>
Notice: Undefined variable: t in /var/www/user97185/data/www/system-administrators.info/yandex-ad.php on line 15

Notice: Undefined variable: r in /var/www/user97185/data/www/system-administrators.info/yandex-ad.php on line 15
Рекомендую: Фриланс-биржа | Кэшбэк-сервис | Интернет-бухгалтерия

Настройка Exchange Server 2010 Outlook Anywhere

При поддержке блога про гаджеты и usb мышки 2USB.ru и интернет-магазина дизайнерских флешек shop.2usb.ru

В данном руководстве мы рассмотрим как включить и настроить Exchange Server 2010 Outlook Anywhere для обеспечения безопасного доступа к почтовым ящикам для удаленных пользователей Outlook.

Что такое Outlook Anywhere?

Outlook Anywhere это сервис, обеспечиваемый серверами с ролью Client Access Server, который позволяет клиентам Outlook осуществлять безопасное подключение через протоколы SSL/HTTPS к своим почтовым ящикам из удаленных мест. Ранее этот метод был известен как RPC-over-HTTPS, но он был переименован в Outlook Anywhere в Exchange Server 2007 и Exchange Server 2010. Суть доступа заключается в том, что обычные Outlook RPC запросы вкладываются в HTTPS и таким образом способны проходить файерволы через обычные порты SSL/HTTPS без необходимости открыть порты RPC.

Для развертывания Outlook Anywhere необходимо выполнить три основные задачи:

• Включить и настроить Outlook Anywhere на серверах Exchange Server 2010 Client Access server (CAS)
• Настроить файервол на границе сети для разрешения SSL/HTTPS подключений из внешних сетей к серверам CAS
• Настроить Outlook

Включение Outlook Anywhere на Exchange Server 2010

Зайдите в Exchange Management Console и перейдите в Server Configuration -> Client Access, далее выберите сервер CAS на котором вы хотите включить Outlook Anywhere.

Если вам несколько CAS серверов в сайте Active Directory то вам необходимо выбрать тот, который имеет выход в интернет. Или, если вы используете массив CAS серверов, тогда вам необходимо повторить эту процедуру на всех серверах массива.

После выбора нужного сервера нажмите в панели действий справа пункт Enable Outlook Anywhere.

Запустится мастер настройки Outlook Anywhere. Введите внешнее DNS имя для подключения пользователей к Outlook Anywhere и выберите метод аутентификации.

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

Метод аутентификации Outlook Anywhere, который вы выберите будет зависеть от нескольких факторов в вашем окружении.

• Basic Authentication – данным метод требует чтобы пользователи Outlook вводили свой логин и пароль каждый раз, когда они подключаются к Outlook Anywhere. Данные посылаются в открытом виде, поэтому критично важно чтобы соединение происходило только через SSL/HTTPS. Вы можете выбрать данный метод если подключаемые компьютеры не включены в домен, или если правило публикации ISA создано совместно с другими сервисами Exchange, которые требуют, или если файервол не поддерживает NTLM.
• NTLM Authentication – это идеальный метод для подключения клиентов, которые являются членами домена, так как не нужно каждый раз вводить имя пользователя и пароль. Однако NTLM может не работать с некоторыми файерволами или в определенных сценариях публикации ISA Server.

После ввода необходимых настроке нажмите Enable для продолжения, а затем нажмите Finish для закрытия мастера.

После этого для вступления изменений в силу необходимо примерно 15 минут. В логе приложений будет зафиксирована запись с Event ID 3008 и серия других событий о применение новой конфигурации на сервере.

Настройка файервола для работы Outlook Anywhere

Для того чтобы удаленные пользователи Outlook могли подключаться к Outlook Anywhere на файерволе необходимо настроить проброс SSL/HTTPS подключений на сервер CAS.

Реальные шаги зависят от используемого вами файервола. Однако базовые компоненты конфигурации следующие:

• Необходима публичная DNS запись для внешнего хоста, которая используется Outlook Anywhere
• На файерволе должен быть публичный IP адрес, который должен резолвиться в указанное выше имя
• Необходимо правило NAT либо правило публикации, которое позволяет SSL/HTTPS подключениям достичь серверов клиентского доступа (CAS)

Если у вас используется массив CAS серверов то трафик должен перенаправляться на IP адрес массива.

Настройка клиентов Outlook на использование Exchange Server 2010 Outlook Anywhere

Перед тем как Outlook сможет подключаться к Outlook Anywhere необходимо его правильно настроить. В Outlook 2010 откройте Account Settings в том профиле Outlook, который необходимо настроить.

Нажмите дважды на записи, для того чтобы открыть свойства профиля.

Нажмите кнопку More Settings, а затем выберите вкладку Connection.

Отметьте чекбокс Connect to Microsoft Exchange using HTTP, и затем нажмите кнопку Exchange Proxy Settings.

Введите внешнее имя, указанное вами ранее при настройке Outlook Anywhere, и далее укажите тот метод аутентификации, который вы выбрали во время настройки сервера .

Нажмите OK, OK, Next и затем Finish для применении настроек в Outlook 2010. После этого необходимо перезапустить Outlook 2010 для вступления изменений в силу.

Автор: Paul Cunningham. Оригинал на английском находится на сайте exchangeserverpro.com

Полезная информация:

Мы относительно часто меняем съемные квартиры, раньше перевозили вещи сами, однако со временем количество вещей растет, как растет и лень к их перевозу. Последний раз нанимали грузчиков с машиной и радовались на то, что работают другие люди, а не мы 🙂 В дальнейшем планирую если позволят средства поступать таким же образом. Впринципе цена не так уже и высока, зато удобство очевидно.

Этот пост November 24, 2010 at 1:47 pm опубликовал molse в категории Exchange 2010, Microsoft Exchange. Желающие могут оформить RSS подписку на комменты. Both comments and trackbacks are currently closed.

2 комментов оставлено (Add 1 more)

И еще надо на панели действий выбрать Настроить внешний домен – вписываем во все нужные строки его название

хорошая статья, но на мой взгляд не хватает пары слов о сертификатах на CAS.

Источник

Установка/настройка Exchange 2010 в мульти-доменной / хостинг реализации

Я хочу описать сложности, с которыми администратор может столкнуться при настройке Exchange для нескольких доменов. Я не буду вдаваться в подробности решения данных проблем, однако опишу в общих словах как их следует решать и предоставлю ссылки на ресурсы (Microsoft или блоги специалистов по Exchange) где описано подробно решение тех или иных сложностей.
Я стараюсь обхватить как можно больше «тонкостей», однако что-то мог и забыть 🙂

Кому интересно – под кат. Внимание: очень много букв!

Прежде всего, стоит сказать о сложностях, которые мы встретим при внедрении Exchange в описанной в теме конфигурации:
• Подготовка и создание объектов. Один из важнейших пунктов. Нужно быть уверенным, что объекты создаются правильно, в нужном месте и с правильными атрибутами, что в дальнейшем поможет Exchange-среде правильно функционировать.
• Обеспечение безопасности для каждого домена/клиента. Сюда входит огромное множество функций и настроек, но если говорить просто – мы должны убедиться, что пользователи одной организации не будут видеть пользователей/данные из другой организации. Об этом надо думать сразу, при создании AD-инфраструктуры (к примеру, иерархия OU и права на них).
• Системные параметры и политики. У Exchange есть много функций, доступных пользователям и администраторам, и эти функции могут управляться разными способами. Некоторые настройки влияют на отдельного пользователя, некоторые на БД, а некоторые на всю Exchange-организацию.
• Транспорт. Очередным пунктом в настройке, который затронет всех пользователей – это транспорт. Речь идет о проблемах, когда Exchange пытается маршрутизировать почту между двумя доменами в режиме, будто они находятся в пределах одной организации, и пытается предоставить весь богатый функционал, который следует предоставлять пользователям одного AD-домена.
• Дизайн и архитектура системы. Тут я пытаюсь сказать о именах для таких служб как OWA; URL, которые предоставляются клиентам с Outlook; конечных точках для таких сервисов как AutoDiscover и Outlook Anywhere. Эти адреса/hostname видны для всех клиентов и должны быть не привязаны ни к одному из них (non-branded) для избежания дальнейших проблем.
• Масштабируемость. Еще одним ключевым атрибутом является масштабируемость. Речь идет не только о максимальном количестве доменов/пользователей, но и о расчете нагрузки, предсказании роста и определении слабых мест, чтобы понять как избегать проблем.

Теперь я постараюсь сказать о каждом пункте в частности:
Структура AD. Тут стоит придерживаться нескольких правил:
1) Каждый домен – отдельный OU.
2) Все пользователи каждого домена – в соотв. группе для этого домена.
3) Использование Active Directory List Object Mode. При включении List Object Mode в настройках Security (Advanced) для каждой OU можно будет выставлять права на List. Вот тут-то нам и потребуется группа из второго пункта – разрешить List OU определенного домена можно только пользователям этого домена. Это позволит разграничивать видимость объектов.

Обеспечение безопасности для каждого домена/клиента. Я уже начал обсуждать это в предыдущем пункте:
1) Использование AD List Object Mode.
2) Использование модифицированных Global Address List и Offline Address Book для каждого домена. Для этого потребуется создавать Address Book Policy (которые стали доступны только в Exchange 2010 SP2). В блоге Михаила Токарева подробно описан этот процесс.
3) Порталы администрирования для администраторов в каждом домене. Для того, чтобы определённый пользователь мог сам администрировать определенную группу пользователей Exchange (через ECP), в Microsoft был создан механизм Role Groups. О том, как создавать группы ролей (где Вы и создадите набор прав для администраторов) написано тут. Однако при создании эти ролей Вам нужно будет указывать Scope – зоны, на которые они распространяются. В качестве «зон» рекомендую использовать OU (для каждого клиента – свою). О создании таких Management Scopes с помощью PowerShell и командлета New-ManagementScope Вы можете прочитать тут.
4) Я не рекомендую давать права на просмотр Message Tracking Logs (подтверждения о доставке), т.к. они распространяются на всю организацию и Администраторам будет видна вся почта.
5) Изменение прав на календари. По-умолчанию ВСЕ пользователи Exchange будут видеть Free/Busy статус ВСЕХ остальных пользователей Exchange. С помощью командлета Set-MailboxFolderPermission или утилит, таких как ExFolders, отобрать у «Default» пользователя доступ, но предоставить необходимые разрешения пользователям данного домена.
6) Опционально: Биллинг для клиентов. К сожалению, в Exchange не встроено механизмов биллинга, однако Вы можете создавать свои даже на базе Excel. Для получения статистики по ящикам рекомендую ознакомиться с командлетами Get-MailboxStatistics и Get-ActivesyncDeviceStatistics, используя которые (Вы можете фильтровать статистику по клиентам/доменам с использованием PowerShell) можно получить статистику и выгрузить ее в CSV/XLS.
7) Я не рекомендую включать Outlook Protection Rules, т.к. при включенном Outlook Advanced Logging будет доступны данные об SMTP-доменах всех клиентов.
8) Базы Exchange. Многие из тех, кто имеет опыт работы с Exchange скажет, что «удобнее» для каждого клиента создать свою базу и хранить все ящики одного домена в отдельной базе. Но, если у Вас нет веского основания так делать, не разделяйте клиентов по базам. Ведь в случае проблем с 1 базой – вся почта домена будет недоступна, а это неприемлемо. Создайте несколько баз и используйте Automatic Mailbox Distribution и дайте Exchange самому выбирать в какую базу «класть» ящики. О том, как работает Automatic Mailbox Distribution вы можете прочитать здесь.

Системные параметры и политики. Этот пункт очень сильно «пересекается» с предыдущим, поэтому тут я скажу не много.
1) Не надо предоставлять клиентам прямой доступ (LDAP + MAPI). Это плохая идея. Многие хостеры так и делают (к примеру, Masterhost), но я не могу согласиться с правильностью такого решения. ТОЛЬКО RPC over HTTPs (тем более в следующей версии Exchange есть только такой доступ). Такой тип доступа чуть сложнее в начальной настройке но гарантированно избавит Вас от проблем в будущем.
2) Следите за Вашим файрволом. За DDoS-атаками, за возможными bruteforce атаками. Не оставляйте сетевую безопасность «на потом».
3) Я рекомендую отключать политику «авто-блокирования» аккаунтов в случае неверного ввода паролей (иначе злоумышленнику будет очень просто заблокировать аккаунт), но обязательно используйте политики, требующие от пользователей сложные пароли.

Транспорт.
1) Требуется запретить отправку на Distribution-группы из других доменов. Для этого нужно ограничивать отправителей, которые имеют право отправлять на DG и требовать аутентификацию для отправки на DG. Это можно настроить через EMC или командлет Set-DistributionGroup.
2) Ограничение размера писем. К примеру, ограничение размера входящих писем на Edge-сервере должно быть меньше или равно ограничению, установленному для внутренней почты. Обратное будет просто тратой ресурсов Edge-сервера. Помните, что с помощью пользовательских лимитов Вы можете дать пользователю или группе пользователей превышать лимиты, установленные для всей организации Exchange.
3) Настройка маршрутизации почты для «соседних» доменов через внешний relay. Это требуется если Вы хотите полностью «замаскировать» почту от доменов на данном Exchange, если они отправляются домену-«соседу». Конечно, в header’ах останется некоторая информация, однако Вы обеспечите симуляцию того, что почта получена из Интернета, что, в свою очередь, предотвратит resolve этого отправителя во внутреннего.
4) Помните, что если Вы захотите использовать Mutual TLS (о том, что это такое, можно прочитать тут), настройки TLSRecieveDomainSecureList и TLSSendDomainSecureList настраиваются для всей организации Exchange. И если Вы собираетесь предложить данную функцию клиентам, нужно будет убедиться, что они понимают, почему флаг «Безопасно» будет отображаться на некоторых письмах, которые они будут получать.
5) Рекомендуется включить Анти-спам агентов на Hub-серверах, чтобы проверялась почта между доменами. Как это сделать – написано тут.
6) Требуется отключить внутренние сообщения Out Of Office между доменами. Ведь если пользователь выберет «отправлять OOF только внутри моей организации» письмо OOF может уйти пользователю данного Exchange, но из другого домена. Чтобы предотвратить это требуется создать несколько правил транспорта, которые будут разрешать сообщения класса IPM.Note.Rules.Oof.Template.Microsoft (именно этот класс имеют OOF письма) только между одинаковыми доменами (по правилу на домен).
7) Отключить некоторые «подсказки» при отправке писем. При мульти-доменной структуре придется пожертвовать некоторым функционалом, таким как отображение членов групп и предупреждений о том, что у получателя включен OOF-автоответ и т.д. Вы можете менять данные настройки через командлет Set-OrganizationConfig.

Дизайн и архитектура.
1) Используйте общие URL. К примеру, зарегистрируйте домен exchsuperhost.ru. Создайте узлы m.exchsuperhost.ru и m2.exchsuperhost.ru (для отказоустойчивых EDGE – это будут MX с разным приоритетом), mail.exchsuperhost.ru (для клиентского доступа и OutlookAnywhere) и autodiscover.exchsuperhost.ru для Autodiscover. Пускай Ваши клиенты используют CNAME для веб-интерфейсов и Ваши MX-адреса для MX и SPF записей. Это очень сильно упростит администрирование и отслеживание почты.
2) Рекомендую не предоставлять пользователям доступ по POP и IMAP, т.к. это может создать проблемы при миграциях, а также при работе пользователей.
3) Задумайтесь о виртуализации. Microsoft не имеет ничего против виртуализации некоторых ролей Exchange. Это поможет сократить расходы на оборудование и лицензии.

Масштабируемость. Тут все зависит от Ваших клиентов, оборудования и т.д. Все, что я могу посоветовать: не используйте «устаревшие» технологии (такие как Public Folders), рассчитывайте «железные» мощности и место на хранилищах и дисковых полках, старайтесь использовать динамические группы рассылки и максимально автоматизируйте свою работу – PowerShell скрипты, правила транспорта, GAL, политики именования и хранения.

Буду рад ответить на Ваши вопросы и выслушать Ваши советы 🙂 Спасибо!

Источник