Symantec Backup Exec, Storage Space и хранилка Lenovo.
Symantec Backup Exec 2014 - Использование Windows- и Linux-серверов для хранения резервных копий.
https://www.youtube.com/watch?v=HCUVwM39r20
Storage Spaces в Windows Server 2012
https://www.osp.ru/winitpro/2012/12/13033403/
LenovoEMC px4 300d overview with latest firmware
https://www.youtube.com/watch?v=dVcah75YEf4
Symantec Backup Exec 2014. Работа с Microsoft Exchange
https://www.youtube.com/watch?v=4nWU6Yl7X_c
Symantec Backup Exec, Storage Space и хранилка Lenovo.
Symantec Backup Exec 2014 - Использование Windows- и Linux-серверов для хранения резервных копий.
https://www.youtube.com/watch?v=HCUVwM39r20
Storage Spaces в Windows Server 2012
https://www.osp.ru/winitpro/2012/12/13033403/
LenovoEMC px4 300d overview with latest firmware
https://www.youtube.com/watch?v=dVcah75YEf4
Symantec Backup Exec 2014. Работа с Microsoft Exchange
https://www.youtube.com/watch?v=4nWU6Yl7X_c
SQL server
SQL server
SQL server
SQL server
SQL server
SQL server
Securing Exchange Server. Делегирование полномочий.
Если с Exchange работаете только вы, то всё просто. Если администраторов несколько, от стоит задуматься о различных полномочиях. Об этом мы и поговорим в этом модуле.
После установки Exchange в AD вам доступны множество групп, которые Exchange'м и создаются.

Для делегирования полномочий вам достаточно включить юзера в одну из этих групп.
-
Delegated Setup – Члены этой группы получают возможность запускать программу установки Exchange 2010, и, следовательно, развертывать, но не устанавливать новый сервер Exchange 2010. Развертывание можно осуществлять только на тех серверах, которые уже получили разрешения от администратора с дополнительными полномочиями.
-
Discovery Management – Участник группы Discovery Management имеет возможность выполнять поиски по всем почтовым ящикам в организации Exchange, а также включать функцию Legal Hold в Exchange 2010.
-
Help Desk – Члены группы Help Desk получают полномочия, обычно нужные для службы техподдержки, например, модификация данных о пользователях, такие как: адрес и номер телефона.
-
Hygiene Management – Эта группа используется для обеспечения полномочиями, связанными с управлением и настройкой антивирусного и антиспамового элементов в Exchange 2010.
-
Organization Management – Группа аналогична административной роли Exchange Full Administrator в Exchange 2003 и роли Exchange Organization Administrator в Exchange 2007. По сути, членство в этой группе дает пользователю право почти любую задачу в Exchange 2010 за исключением некоторых, основной среди которых является возможность осуществлять поиск по почтовым ящикам; которую можно получить через группу Discovery Management.
-
Public Folder Management – Эта группа дает возможность своим членам управлять средой общих папок.
-
Recipient Management – Участник этой группы может создавать и модифицировать получателей Exchange.
-
Records Management – Группа дает возможность своим членам контролировать и настраивать функции соответствия в Exchange 2010. Примеры подобных функций включают транспортные правила, настроенные на сервере Hub Transport, а также классификации сообщений в Outlook.
-
Server Management – Эта группа предоставляет возможность управлять всеми серверами Exchange в организации. Полномочия, получаемые участниками этой группы работают, таким образом, на уровне конфигурации сервера, находящейся в консоли Exchange Management Console, и не работают, скажем, на организационном уровне, находящемся в консоли Exchange Management Console.
-
UM Management – Согласно своему наименованию, данная группа дает возможность управлять всеми аспектами среды Unified Messaging.
-
View-Only Organization Management – группа позволяет своим членам просматривать конфигурацию любого элемента в организации Exchange.
У этих групп есть недостатки:
1. Полномочия, даваемые в рамках этих групп, выдаются на всю организацию целиком. К примеру, если у вас 10 серверов и вы включает юзера в Recipient Management, то он может создавать ящики на каждом сервере.
2. Полномочия в группах достаточно шаблонны, т.е. если вы хотите что-то своё, то реализовать у вас ничего не получится.
Вывод. Если у вас одна организация Exchange и немного серверов, то вам вполне подойдёт стандартный вариант с использованием перечисленных групп. Если у вас сложная структура и вы хотите вручную заниматься полномочиями, то поможет вам в этом RBAC (Role Based Access Control, Управление доступом на основе ролей).
RBAC (Role Based Access Control, Управление доступом на основе ролей).
Для начала нужно определиться и ответить на следующие вопросы.
Какой функционал мы будем передавать? Делегирование полномочий в Exchange 2010 осуществляется через передачу полномочий на выполнение конкретных командлетов, т.к. все действия выполняют командлеты. Используется для этого одна из Management Role (управляющая роль). Management Role - это группировка командлетов вместе. Наберите get-ManagementRole и посмотрите на список. Каждая из этих Management ролей является

группировкой командлетов по темам. Например, роль Databases содержит командлеты для работы с базами данных.
Чтобы посмотреть командлеты в определенной Management-роли, используйте командлет Get-ManagementRoleEntry, указав Management-роль.
Например, Get-ManagementRoleEntry "Databases\*" (\* - показать все командлеты).

Management-роли вы можете создавать сами (командлетом New-ManagementRole), с любым набором командлетов.
Следующий вопрос. Кому будем выдавать права? Здесь используются Role Group (группа ролей или ролевая группа). Вернитесь в самое начало модуля и посмотрите скриншот из AD, где мы рассматривали группы в Microsoft Exchange Security Groups. Это и есть Role Group. Role Group - это группа в AD, за которой закреплена хотя бы одна Management-роль. Т.е. вы можете создать Role Group под названием "Админы БД", за которой будет закреплена Management-роль под названием Databases. Эта созданная Role Group будет отображаться в AD.
Наберите Get-RoleGroup и посмотрите все Role Group. Для наглядности можете открыть AD.

В AD групп отображается больше, т.к. не все они предназначены для делегирования полномочий.
Используя New-RoleGroup, создадим свою Role Group под названием "Rostov Database Admins" и привяжем к ней Management Role, которая называется

Databases. Смотрим в AD, группа появилась. Можно добавлять в неё пользователей (или сразу указать их, перечислив после ключа -Members в EMS).
И последний вопрос - где будут применяться наши полномочия?
Дело в том, что по-умолчанию, всё, что мы сделали до этого, будет применяться ко всей организации. Есть такое понятие, как Scope (область). По-умолчанию используется область Default, т.е. если мы не указываем, где будут применяться наши полномочия, юзер получит полномочия в рамках всей организации.
Нам нужно создать Management Scope (управляемая область).
Рассмотрим несколько примеров создания Management Scope с разными параметрами (набрав команду Get-Help New-ManagementScope -Examples в EMS можно посмотреть перечисленные ниже примеры использования):
New-ManagementScope -Name "Hub Servers 1 through 3" -ServerList HubServer1, HubServer2, HubServer3
Создаем Management Scope с именем "Hub Servers 1 through 3". Ключом -ServerList мы указываем, какие сервера попадут в эту область (перечисляем DNS-имена Exchange-серверов). HubServer1, HubServer2 и HubServer3 - это сервера, на которые в итоге юзер получит полномочия.
New-ManagementScope -Name "Redmond Site Scope" -ServerRestrictionFilter {ServerSite -eq "Redmond"}
Ключом -ServerRestrictionFilter {ServerSite -eq "Redmond"} указано, что в Management Scope попадут все Exchange-сервера в сайте Redmond.
New-ManagementScope -Name "Executive Mailboxes" -RecipientRoot "contoso.com/Executives" -RecipientRestrictionFilter
{RecipientType -eq "UserMailbox"}
Ключ -RecipientRoot "contoso.com/Executives" - все, кто в OU-шке Executives.
Ключ -RecipientRestrictionFilter {RecipientType -eq "UserMailbox"} - те, у кого уже есть почтовые ящики
New-ManagementScope -Name "Protected Exec Users" -RecipientRestrictionFilter { Title -Like "*VP*" } -Exclusive
Ключ -Exclusive исключает указанное значение. Поэтому в нашем примере в область попадут юзеры, у которых в имени не встречается "VP".
New-ManagementScope -Name "Seattle Databases" -DatabaseRestrictionFilter {Name -Like "SEA*" }
В эту область попадут базы данных, чьи имена начинаются на "SEA"
Для примера создадим свою управляемуя область под названием "Rostov Databases", куда попадут БД, начинающиеся с "Rostov"
New-ManagementScope -Name "Rostov Databases" -DatabaseRestrictionFilter {Name -Like "Rostov*" }

Итак, Management Scope мы создали. Но с нашей Role Group под названием "Rostov Database Admins", которую мы создали ранее, она пока никак не связана.
Для связи Role Group и Management Scope используется Assigment Policy. Есть командлет New-RoleAssignmentPolicy, которым можно создать политику, которая захватит ролевую группу и область. В Exchange 2010 без SP1, всё что мы разобрали (в т.ч. и Assigment Policy), можно было делать только через EMS. С выходом SP1 всё упростилось. В ECP появилась возможность отчасти настраивать RBAC.
В ECP мы можем просмотреть группы. Выбрав группу, справа можно посмотреть назначенные роли, членов и область. Область, как видите, по

умолчанию стоит Default, что означает, что применяется абсолютно ко всем.

Нажав New, можно создать новую группу, закрепить за ней существующую область, добавить роли с наборами командлетов и добавить членов.

Создадим новую Role Group. Указываем имя, к примеру имя Rostov Help Desk.
Далее применяем область. Зде сь мы можем указать либо те, которые были созданы нами (в нашем примере Rostov Databases) в выпадающем списке, либо прописать конкретный OU (например contoso.com/users). В разделе Roles, нажав Add указываем Management Role (управляющая роль с определенным набором командлетов, описанная в самом начале раздела RBAC).
После создания можете перейти в AD в Microsoft Exchange Security Groups и увидеть созданную группу.
Как я ранее говорил, в ECP появилась возможность настраивать RBAC лишь отчасти. К примеру мы не можем создать здесь области, это доступно только через EMS. Также мы не можем создать Management Role. Поэтому, если вас не устраивает стандартный набор командлетов, то создать новые Management Role со своими наборами командлетов можно только через EMS.
Во всех остальных случаях, вполне подойдёт EMС. Можно к примеру изменять существующие Role Group, в том числе и стандартные (Добавлять членов, менять области и прочее).
Публикация сервера exchange 2010 через TMG.
Хороший видос https://www.techdays.ru/videos/2814.html
Безопасность при обмене электронной почтой.
Как уже отмечалось в предыдущих модулях, обмен электронной почты не требует аутентификации. Это влечёт ряд проблем с точки зрения безопасности, т.к. от имени кого угодно можно отправить письмо кому угодно.
Для обеспечения криптографической безопасности электронной почты существует стандарт S/MIME (Secure/Multipurpose Internet Mail Extensions).
S/MIME делится на две технологии: цифровое подписывание и шифрование. Их можно использовать вместе или по отдельности.
Зачем нужна цифровая подпись письма:
1. ЦП может идентифицировать отправителя. Если в письме с ЦП указан Вася, мы можем быть уверены, что письмо прислал действительно Вася.
2. Целостность. Мы можем быть уверены, что письмо не менялось в процессе передачи.
Шифрование дает только одно - гарантию того, что письмо никто не прочитает, кроме получателя. ЦП такой гарантии дать не может.
Тонкости настройки этих технологий рассматриваются в более продвинутых курсах (M10233 Проектирование и развертывание почтовых решений Microsoft Exchange Server 2010), но для понимания приведу схему и описание к ней.
Есть отправитель и получатель.

В обязательном порядке отправитель должен иметь сертификат. Наличие сертификата означает, что отправитель имеет закрытый ключ в локальном хранилище и открытый ключ, который собственно в самом сертификате и содержится.
Если мы будем использовать цифровую подпись, то наличие сертификата у получателя не требуется. Например хостер высылает вам счёт. Чтобы быть уверенным, что это действительно ваш хостер, хостер использует цифровую подпись письма.

Отправитель сделал письмо. Дальше выполняется функция хэширования. Это математическая функция, которая выполняет преобразование данных. По сути вы запихиваете любой объем данных на хэш-функцию, а на выходе получаете отпечаток фиксированного размера, который уникально идентифицирует объем данных, который на него поступил. Т.е. если вы загнали какое-то письмо, на выходе вы получаете хэш. Не должно быть другого такого письма, чтобы пропустив его через эту хэш-функцию (хэш-функция всем известна), можно было бы получить такой хэш. Это первое правило хэш-функции.
Второе правило хэш-функции заключается в том, что нельзя из хэша получить письмо (из фарша кусок мяса обратно не собрать).
Зачем вообще хэш? Хэш будет уникально идентифицировать письмо. Можно выполнить хэширование при отпраке и хэширование при получении, сравнить хэши и сделать вывод. Если письмо поменяется хотя бы на один байт, хэш измениться процентов на 30.

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

На получателя отправляется само письмо (естественно не зашифрованное), хэш (зашифрованный закрытым ключом) и открытый ключ. Получатель берет этот открытый ключ, дэшифрует хэш, сам выполняет хэширование и проверяет, не изменился ли хэш.
Да, злодей может взять открытый ключ и дэшифровать хэш. И что дальше? Ну сделал он свой хэш. А чем он его будет шифровать? Закрытый ключ отправителя есть только у отправителя.
Итак, с ЦП разобрались. Злодей может прочитать письмо, но подделать его не сможет.
Если вы хотите вдобавок защитить письмо от прочтения, потребуется использовать шифрование. В этом случае сертификат также должен быть на стороне получателя. Самое главное- отправитель письма должен иметь возможность получить доступ к открытому ключу получателя.
Если вы работаете в пределах одной организации, то всё просто. У вас ключи и сертификаты хранятся в GAL. Если письмо нужно зашифровать, отправитель генерирует симметричный ключ (он же шифрует, он же дешифрует (читайте теорию шифрования)) и шифрует им письмо, а сам ключ шифруется открытым ключом получателя, который отправитель может взять в GAL. Таким образом расшифровать письмо получиться только у получателя.
Если организации разные, то можно создать почтовый контакт и сертификат будет запихиваться в этот контакт. А контакт есть в GAL. Т.е. вы можете взять у получателя сертификат с открытым ключом, запихнуть его в контакт и он будет в GAL.
Следующий модуль: Maintaining Exchange Server.