Вход в office 365 через интрасеть

У одного из моих клиентов в настоящее время есть сайт интрасети, где пользователи могут автоматически входить в Exchange 2010. Все это делается с помощью специальной формы, которая проверяет подлинность по owaauth.dll. Мы автоматически предоставляем заранее определенные имя пользователя и пароль в форме, и пользователь входит в почтовый ящик без какой-либо дополнительной формы аутентификации пользователя. Они хотели бы и дальше так работать, но на этот раз для Office 365.

Что важно знать:

  • Вход в систему не требуется
  • Имена пользователей / пароли известны администраторам / разработчикам
  • Локальный AD и Azure AD не подключены и не будут подключены
  • Пользователи проходят аутентификацию по IIS, поэтому аутентификация ЕСТЬ
  • Почтовый ящик из другого домена, чем локальный.

На данный момент мы обнаружили: - Вы можете использовать Office 365 для аутентификации вашего собственного приложения (в обратном направлении от того, что мы хотели) - owaauth.dll больше не существует

Мы очень хорошо понимаем, что это не идеальное решение, но иногда вы просто не можете реализовать лучшее решение, и по-прежнему нужны некоторые функции.

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

Есть ли кто-нибудь, кто может пролить свет на эту проблему?

Имена пользователей / пароли известны администраторам / разработчикамВызовите охранника! Быстро! Покинуть корабль!
Patrick Hofman 11.04.2018 11:44
2
1
230
1

Ответы 1

Как только у вас появится клиент O365, по умолчанию у вас будет Azure AD. Так регистрируются все пользователи в O365, так что этого не избежать. Поэтому я бы предложил изучить подход API Azure Graph с использованием учетной записи субъекта-службы, которая имеет права для входа в систему от имени пользователей. Затем каким-то образом внутренне сопоставьте их с пользователями в IIS VS других имен пользователей домена. Я предполагаю, что именно так это работает сейчас.

API предназначен для использования на сервере, а не для входа в систему с помощью клиента с именем пользователя и паролем.

Patrick Hofman 11.04.2018 11:53

То, что говорит Патрик, мы тоже узнали. И, конечно же, есть Azure AD. Я нигде не говорил, что нет. Локальный AD и Azure AD просто не синхронизируются.

Aspage 11.04.2018 12:15

Я не обязательно понимаю вопрос. Из того, что я прочитал, у вас есть сценарий единого входа, в котором пользователи входят в IIS, я предполагаю, с «разными» именами пользователей домена Ad, а затем используется учетная запись службы, чтобы продвинуть его дальше. Однако, если он изменит имя пользователя, он также сможет получить доступ к электронной почте других пользователей?

Mareks Zirdzins 11.04.2018 12:29

Прямо сейчас сайт интрасети имеет локальную аутентификацию AD. Таким образом, пользователь не может войти в систему как кто-то другой. Что мы буквально делаем: - Ты кто? - Проверьте AD для своего отдела - Получите учетные данные почтового ящика отдела с нашего SQL-сервера - Зарегистрируйте его в почтовом ящике своего отдела Так, как г-н X, он может войти только в почтовый ящик отдела X, потому что он не может использовать другое имя пользователя. Тот же принцип, который мы хотели бы использовать снова, но затем для входа в Office 365.

Aspage 11.04.2018 14:06

Мне кажется, вы используете общие почтовые ящики с известными и сохраненными именами пользователей и паролями. Итак, в основном вам нужен сценарий единого входа GRAPH для определенного пользователя из одного приложения в другое. В этом случае используйте такой подход: docs.microsoft.com/en-us/azure/active-directory/develop/…

Mareks Zirdzins 11.04.2018 14:49

Другие вопросы по теме