#office365 #exchangewebservices #multi-factor-authentication
#office365 #exchangewebservices #многофакторная аутентификация
Вопрос:
Моя NT-служба в Windows использует EWS API для доступа к учетным записям Office 365 для выполнения некоторой периодической работы. Оно написано на C . Когда клиент устанавливает мое приложение, он выбирает пользователя / пароль, который NT-service использует для отправки запросов EWS. Пользователь / пароль сохраняются в некотором conf-файле в зашифрованном виде. Теперь Microsoft вынуждает использовать MFA для Office 365. Вопрос в том, как фоновая NT-служба может передавать MFA с дополнительным SMS-кодом, если она не взаимодействует с пользователем? Я читал о приложении-pasword https://learn.microsoft.com/en-us/azure/active-directory/user-help/multi-factor-authentication-end-user-app-passwords
Это работает, но они пишут «Ваш администратор может не разрешить вам использовать пароли приложений». Также это создает проблемы для пользователя при управлении паролем этого приложения. Есть ли какие-либо альтернативные решения для использования MFA из приложения, которые не взаимодействуют с пользователем (например, NT-services)? Кто-нибудь может помочь?
Ответ №1:
Вы можете зарегистрировать свое приложение в клиенте Exchange и пройти аутентификацию с помощью сертификата — https://developermessaging.azurewebsites.net/2018/09/11/authenticating-against-exchange-web-services-using-certificate-based-oauth2-tokens/
Запрос пароля никогда не потребуется.
Комментарии:
1. Спасибо за ваш совет. Я нашел информацию о том, что мой текущий метод запроса токена OAuth также должен работать с подключением EWS. Я использую POST-запрос к /<tenant_id>/oauth2/token с grant_type=client_credentialsamp;client_id=%s amp; client_secret =%s amp; scope =%s, и я обнаружил, что проблема возникает с запросом на автоматическое обнаружение. Если я использую outlook.office365.com/EWS/Exchange.asmx сразу — все работает. Итак, вопрос в том, правильно ли не использовать автообнаружение для учетных записей Office365?
2. Можно не использовать автообнаружение с Office365, поскольку URL-адрес статичен, исключение составляют национальные клиенты learn.microsoft.com/en-us/graph/deployments и гибридная современная аутентификация, но это небольшая группа клиентов.
Ответ №2:
Одним из более простых способов передачи этого было бы использование условного MFA или доверенных IP-адресов https://dirteam.com/sander/2020/07/07/todo-move-from-mfa-trusted-ips-to-conditional-access-named-locations/ эффективно разрешить вашему приложению обходить его (учитывая, что оно должно выполняться в доверенном контексте).
TOTP (одноразовые пароли на основе времени) в качестве вторичного фактора является наиболее автоматизируемым, напримерhttps://gsexdev.blogspot.com/2020/07/using-2-authentication-factors-for-mfa.html но я бы рекомендовал первый подход, поскольку это будет более надежным в долгосрочной перспективе.
Третьим вариантом было бы использовать поток учетных данных клиентаhttps://learn.microsoft.com/en-us/azure/active-directory/develop/scenario-daemon-overview это избавляет вас от использования имени пользователя и пароля, что является более безопасным вариантом. Для этого я бы, вероятно, перешел из EWS в Graph API, поскольку вы также можете расширить доступ в Graph.
Комментарии:
1. Спасибо за ваш совет. Я нашел информацию о том, что мой текущий метод запроса токена OAuth также должен работать с подключением EWS. Я использую POST-запрос к /<tenant_id>/oauth2/token с grant_type=client_credentialsamp;client_id=%s amp; client_secret =%s amp; scope =%s, и я обнаружил, что проблема возникает с запросом на автоматическое обнаружение. Если я использую outlook.office365.com/EWS/Exchange.asmx сразу — все работает. Итак, вопрос в том, правильно ли не использовать автообнаружение для учетных записей Office365?