Начало работы с управлением на основе PowerShell для Exchange Online

Необслуживаемые сценарии всегда представляли проблему для администраторов. Это связано с тем, что для работы этих сценариев обычно требуются разрешения. Однако, поскольку эти сценарии выполняются автоматически, администратор не может получать запросы на ввод учетных данных. Исторически решением этой проблемы было сохранение учетных данных в файле или самом скрипте. Излишне говорить, что этот подход создает некоторые серьезные риски для безопасности. К счастью, Microsoft предоставила нам лучший способ проверки подлинности для автоматических сценариев, особенно в том, что касается Exchange Online.

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

Зарегистрируйте приложение

Сначала вам нужно создать (или зарегистрировать, как это называет Microsoft) приложение в Azure Active Directory. Этот процесс регистрации прост и не требует написания кода. По сути, процесс связывает сертификат и набор разрешений с идентификатором. Чтобы завершить первоначальный процесс регистрации, выполните следующие 6 шагов:

1. Войдите в свою учетную запись Microsoft 365 и откройте центр администрирования Azure Active Directory.
2. Нажмите на вкладку «Регистрация приложений».
3. Нажмите на кнопку Новая регистрация. Консоль отобразит экран регистрации приложения.
4. Введите имя приложения, которое вы хотите зарегистрировать. В этой статье я буду называть приложение «Exchange Online PowerShell».
5. Выберите тип учетной записи, который вы хотите использовать. В большинстве случаев вы бы выбрали вариант «Учетные записи только в этом организационном каталоге».
6. Нажмите кнопку Зарегистрироваться, чтобы завершить процесс регистрации

Замените разрешения по умолчанию

Следующим шагом является замена разрешений приложения по умолчанию на разрешения API. Это то, что позволит скриптам работать без присмотра. Чтобы завершить этот процесс, выполните следующие 9 шагов:

1. Выберите вкладку «Манифест» приложения. Это заставляет консоль отображать манифест приложения в формате JSON.
2. Измените значение ResourceAppID на:

3. Установите для идентификатора ResourceAccess значение:

4. Установите для параметра ResourceAccess Type значение Role, как показано на снимке экрана ниже.

5. Нажмите кнопку Сохранить, чтобы сохранить изменения
6. Выберите вкладку Разрешения API. Когда вы это сделаете, вы должны увидеть индикатор состояния, указывающий на то, что у вашей организации нет разрешений для Exchange.ManageAsApp.
7. Нажмите кнопку «Предоставить согласие администратора для» для вашей организации, как показано ниже.

8. Нажмите «Да», когда будет предложено подтвердить, что вы хотите предоставить права администратора.
9. Убедитесь, что обновления состояния отражают получение вашей организацией необходимых разрешений.

Создайте самоподписанный сертификат

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

1. Перейдите на GitHub и скопируйте содержимое файла Create-SelfSignedCertificate.ps1 в Блокнот.
2. Сохраните документ Блокнота как C:TempCreate-SelfSignedCertificate.ps. Убедитесь, что вы установили тип кодировки ANSI. Хотя в этом примере я использую папку Temp, вы можете использовать любую папку по своему усмотрению.
3. Откройте сеанс PowerShell с повышенными привилегиями
4. Укажите три параметра при запуске скрипта: CommonName, StartDate и EndDate. Параметр CommonName хранит имя, которое вы хотите присвоить своему сертификату. В этой статье я буду использовать Posey в качестве CommonName. StartDate и EndDate отражают даты действия сертификата. Вы должны ввести эти даты в формате ГГГГ-ММ-ДД. Вот пример полной команды:

5. Введите пароль при появлении запроса. Этот пароль предназначен для защиты закрытого ключа.
6. Найдите файл PFX и CER, созданный сценарием, в папке Temp.

Добавьте сертификат в зарегистрированное приложение

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

1. Вернитесь к экрану регистрации приложений, который вы использовали ранее, и выберите вкладку «Сертификаты и секреты».
2. Выберите вкладку «Сертификаты», а затем нажмите ссылку «Загрузить сертификат», как показано ниже.
3. Щелкните значок «Обзор» и выберите созданный ранее файл CER.
4. Нажмите кнопку "Добавить"

Добавьте необходимые роли

Последним шагом в процессе настройки является добавление роли администратора Exchange в приложение, которое я зарегистрировал ранее. Для этого выполните следующие 6 шагов:

1. Нажмите на вкладку Azure Active Directory.
2. Выберите вкладку Роли и администраторы. Это отличается от вкладки «Роли и администраторы» на странице «Регистрация приложения».
3. Нажмите на роль администратора Exchange (не на флажок роли)
4. Нажмите ссылку «Добавить назначения», когда откроется страница ролей.
5. Введите имя приложения, которое вы зарегистрировали, в поле поиска.
6. Выберите зарегистрированное приложение и нажмите «Добавить».

Подключение к Exchange Online

Вы можете подключиться к Exchange Online с помощью PowerShell несколькими различными способами. Метод, который вам нужно использовать, будет зависеть от того, установили ли вы сертификат, который используете, на свой компьютер. Если вы установили его (что является предпочтительным вариантом), используйте эту команду:

Если сертификат присутствует в вашей системе (но не установлен), используйте эту команду:

Вы можете увидеть, как PowerShell использует аутентификацию на основе сертификатов для подключения к Exchange Online на снимке экрана выше. Это было не так уж плохо, верно? Давайте подведем итоги!

Нижняя линия

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

У вас есть дополнительные вопросы о PowerShell или Exchange Online? Ознакомьтесь с разделами часто задаваемых вопросов и ресурсов ниже!

Часто задаваемые вопросы

Почему имя моей организации вызывает проблемы при попытке подключения к Exchange Online?

Даже если у вас есть собственное доменное имя, связанное с вашей средой Microsoft 365, вместо этого вам нужно будет использовать имя вашей организации onmicrosoft.com. В противном случае произойдет ошибка.

В чем разница между установкой сертификата и просто наличием сертификата?

Каждый компьютер Windows содержит хранилище сертификатов, доступ к которому можно получить через консоль управления Microsoft. Сертификат можно считать установленным, если вы импортировали его в хранилище сертификатов. Напротив, вы можете считать сертификат присутствующим (но не установленным), если файл сертификата находится на вашем компьютере, но вы не импортировали его в хранилище.

Где я могу найти идентификатор приложения при подключении к Exchange Online PowerShell?

Вы можете найти идентификатор приложения, указанный на экране регистрации приложений. На этом экране отображается список всех приложений, которые вы зарегистрировали. Каждое приложение в списке имеет уникальный идентификатор приложения.

Когда я пытаюсь подключиться к Exchange Online PowerShell с помощью файла сертификата, мне нужно ввести имя пользователя и пароль. Что мне вводить для имени пользователя, поскольку файл сертификата имеет связанный с ним пароль, но не имеет имени пользователя?

Вам нужно будет ввести что-то в поле имени пользователя, но не имеет значения, что вы вводите, так как используется только пароль. В демонстрации, показанной в этой статье, я использовал Администратор в качестве имени пользователя, но вы можете использовать что угодно.

Могу ли я назначить зарегистрированному приложению роли, отличные от роли администратора Exchange?

Роль администратора Exchange предоставляет все необходимые разрешения для управления Exchange Online. Возможно, вы могли бы использовать другую роль, если хотите создать более ограниченный опыт управления.