У нас есть клиент, который хочет, чтобы их пользователи использовали различные учетные записи пользователей для SharePoint Онлайн и почты Exchange/Office 365 (как странный, поскольку это звучит существует законная причина этого). Все учетные записи находятся в том же домене, и клиент настроил ADFS с их арендатором. Все статьи и сообщения я могу найти соглашение онлайн с полной противоположностью этого сценария (или SSO или многодоменный с одним арендатором).
То, что я задаюсь вопросом, - то, если мы можем настроить SharePoint Онлайн и Exchange с другим идентификатором области (или что-то подобное) так, чтобы ADFS мог быть инициирован для использования другого механизма аутентификации для одной области по сравнению с другим.
**** Редактирование ****
На комментарии ниже вот немного больше цвета к причине необходимости в двух идентификаторах области (или любой другой механизм для решения проблемы). У клиента есть по существу два вида учетных записей пользователей в их организации. Большинство - стандартные заурядные учетные записи пользователей, кто получает доступ к O365 через SSO, обеспеченный ADFS.
Другие типы пользователей обычно не входят в рабочие станции и не имеют присвоенных собственных столов. Эти пользователи используют совместно использованные рабочие станции, которые постоянно зарегистрированы в соответствии с универсальными, общими учетными записями. Когда эти пользователи получают доступ к общим рабочим станциям (я назвал их киосками в комментариях ниже, но это - небольшое искажение), и затем попытайтесь получить доступ к O365, ADFS регистрирует пользователей в как универсальная учетная запись. Это прекрасно, когда пользователи переходят к SharePoint Онлайн для основной страницы портала (при движении в защищенные sub сайты, пользователи получают страницу доступа запрещен, но существует опция войти в систему как другой пользователь), но не для того, когда они пытаются получить доступ к электронной почте (они получают ошибочную страницу, потому что универсальная учетная запись не имеет ящика входящих сообщений и нет никакого средства повторно пройти проверку подлинности).
Мои начальные взгляды состояли в том, если мы могли бы использовать два IdP (или один сервер ADFS с двумя RP) затем, мы могли использовать SSO/WIA для области SharePoint и затем использовать автора форм для области Exchange. Другая мысль, которую я имел, использовала правило требования в ADFS (они находятся на ADFS 3/2012R2) вынудить автора форм, если UPN пользователя соответствовал шаблону. Заключительное решение для плоскодонки, которое я имел, состояло в том, чтобы использовать GPO для отключения SSO в IE для общих учетных записей.
Ответ любезно предоставлен Джеспером Сталем .
Вам нужно будет поиграть с зонами IE, чтобы сломать токен аутентификации на киоск-машинах, вы можете легко добиться этого с помощью групповой политики.
Объяснение : ваши пользователи попытаются получить доступ к Office 365, они будут перенаправлены в ADFS для аутентификации ADFS будет читать их TGT-билет Kerberos, создавать токен и пересылать его в Office 365 для дальнейшей обработки.
Решение : Чтобы избежать отправки токена авторизованного пользователя на компьютерах киоска из ADFS в Office 365, вам необходимо указать IE НЕ отправлять имя пользователя / пароль вошедшего в систему ADFS, но вместо того, чтобы открыть окно входа в систему для пользователя, сидящего перед машиной, чтобы использовать свое собственное имя пользователя / пароль, это может быть достигнуто следующим образом:
Для пользователей на их выделенных машинах : разместить ссылки ADFS в « Зоне локальной интрасети » SSO будет включен, если вы сделаете это.
Для киоск-компьютеров : поместите ссылки ADFS в « Надежные сайты » зона, это нарушит единый вход, и пользователям будет предложено ввести имя пользователя и пароль при каждом посещении Office 365.
Fo Что касается использования групповой политики для размещения сайтов в зонах, я бы порекомендовал использовать входы « Registry », используя следующее:
Key Location: Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\YOURADFSLINK
Value Name: http
Value Type: REG_DWORD
Value Data: 1 or 2
«Значение данных» 1 означает «Зона локальной интрасети, 2 означает» Зона надежных сайтов "