У меня есть локальные AD и AD на лазурном сервере, и у меня есть настройка прокси-сервера ADFS и ADFS для аутентификации пользователей в локальном AD. Я выполнил все шаги на сайте Microsoft, чтобы установить доверие между Azure AD и локальным AD. Однако в нем говорится, что Dir Sync необходим для обеспечения единого входа для пользователей в локальной и облачной AD. Я не хочу использовать Dir Sync, и я хочу, чтобы моя ADFS могла аутентифицировать пользователей из моих локальных AD и Azure AD.
Может ли кто-нибудь сообщить мне, что нужно сделать, чтобы этого добиться?
Предполагая, что это для O365 или Intune - DirSync является обязательным компонентом. DirSync позволит тем же войти в систему, то есть пароли одинаковы в обеих средах. Добавление ADFS позволит не замужем вход, то есть пользователи будут беспрепятственно проходить аутентификацию без запроса учетных данных. DirSync - это основополагающий компонент как для одинаковой, так и для единой регистрации.
Вы не можете выполнить единый вход в клиент Azure AD только с помощью ADFS.
У меня был такой же вопрос и комментарий от maweeras поставил меня на правильный путь. Я провел небольшое исследование, все заработало, и вот что сработало для меня.
Не уверен, что это «поддерживаемое» решение, потому что им действительно нравится их DirSync. Однако имеет смысл, что он поддерживается по причине maweeras упоминалось, а именно, позволяя инфраструктуре, отличной от Active Directory, по-прежнему иметь единый вход в Office 365.
Вот что вам нужно сделать:
Единый вход включает домен на стороне Office 365, запустив апплеты PowerShell Convert-MsolDomainToFederated. Вы, наверное, сделали это.
Создайте учетные записи пользователей, для которых вы хотите включить единый вход в Office 365, вручную или с помощью PowerShell.
После того, как вы их создали, вам нужно использовать ObjectGUID на ваш Объект учетной записи AD в качестве их неизменяемого идентификатора на стороне Azure.
Я использовал их в качестве справки, но я включу информацию на случай, если эти URL-адреса исчезнут в будущем:
Вам нужно base64 закодировать ObjectGUID для вашего пользователя и установить его. Кодируемый GUID не должен включать скобки:
Сценарий здесь выполняет преобразование за вас: http://gallery.technet.microsoft.com/office/Covert-DirSyncMS-Online-5f3563b1
GUID объекта AD (в «формате реестра») 748b2d72-706b-42f8-8b25-82fd8733860f
Закодировано: ci2LdGtw + EKLJYL9hzOGDw ==
Вы устанавливаете это в учетной записи в Azure через PowerShell:
Set-MsolUser -UserPrincipalName user@azuredomain.com -ImmutableId "ci2LdGtw + EKLJYL9hzOGDw =="
Убедитесь, что имя участника-пользователя в вашей учетной записи (на стороне домена AD) совпадает с именем участника-пользователя user@azuredomain.com на стороне Office 365, иначе вы получите странную ошибку на стороне Azure. Я думаю, код ошибки 8004786C
Если у вас нет суффикса UPN, доступного для настройки вашего пользователя в среде AD, вы должны добавить этот суффикс через «Active Directory Domains and Trusts». Или, если вы хотите быть умным, установите другой атрибут в своей учетной записи AD и попросите ADFS отправить этот атрибут в качестве неизменного идентификатора. Если вы не понимаете, что я имею в виду - просто установите UPN. :)
Microsoft Office 365 не будет отображаться как вариант в раскрывающемся меню, инициированном IDP ADFS на вашем сервере. Похоже, это SP инициирован, и вы должны запустить танец SAML, сначала зайдя на их портал:https://portal.microsoftonline.com
Вы можете использовать что-то вроде Fiddler, чтобы захватить беседу SSL, а затем проанализировать некоторую информацию. http://community.office365.com/en-us/wikis/sso/using-smart-links-or-idp-initiated-authentication-with-office-365.aspx для того, чтобы иметь больше ощущения, инициированного IDP, когда пользователь нажимает на вашу ссылку и полностью выполняет удобный вход в Office 365, ничего не вводя.
Это вообще помогает? http://technet.microsoft.com/en-us/library/dn296436.aspx
Прошло некоторое время с тех пор, как я сделал то, о чем вы просите, но это было в моих заметках.