У меня есть локальные AD и AD на Azure, а также ADFS и прокси-сервер ADFS для аутентификации пользователей на локальном AD. Я выполнил все шаги на сайте Microsoft, чтобы настроить доверие между Azure AD и локальным AD. Однако там говорится, что Dir Sync необходим для достижения единого входа для пользователей в локальном и облачном AD. Я не хочу использовать Dir Sync и хочу, чтобы мои ADFS могли аутентифицировать пользователей из моего локального AD и Azure AD.
Может ли кто-нибудь подсказать мне шаги, необходимые для достижения этой цели?
решение1
Предполагая, что это для O365 или Intune - DirSync является обязательным компонентом. DirSync позволиттакой жевход в систему, то есть пароли одинаковы в обеих средах. Добавление ADFS позволитодинокийвход в систему, что означает, что пользователи будут проходить аутентификацию без необходимости ввода учетных данных. DirSync является основополагающим компонентом как для одинакового входа, так и для единого входа.
Реализовать единый вход в клиент Azure AD только с помощью ADFS невозможно.
решение2
У меня был тот же вопрос и комментарий отмавирынаставил меня на верный путь. Я провел небольшое исследование, заставил это работать, и вот что сработало для меня.
Не уверен, что это "поддерживаемое" решение, потому что им, похоже, очень нравится их DirSync. Однако, имеет смысл, что оно поддерживается по этой причинемавирыупоминалось, а именно, что позволяет инфраструктуре, отличной от Active Directory, по-прежнему использовать единый вход в Office 365.
Вот что вам нужно сделать:
Включите SSO на стороне Office 365, запустив апплеты PowerShell Convert-MsolDomainToFederated. Вы, вероятно, уже это сделали.
Создайте учетные записи пользователей, для которых вы хотите включить единый вход на стороне Office 365, вручную или в PowerShell.
После того, как вы их создали, вам нужно использовать ObjectGUID натвойОбъект учетной записи AD как неизменяемый идентификатор на стороне Azure.
Я использовал их в качестве справочных материалов, но включу информацию на случай, если эти URL-адреса исчезнут в будущем:
Вам нужно закодировать ObjectGUID для вашего пользователя в base64 и установить его. Кодируемый вами 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[email protected]-ImmutableId "ci2LdGtw+EKLJYL9hzOGDw=="
Убедитесь, что UPN в вашей учетной записи пользователя (на стороне вашего домена AD) совпадает с[email protected]UPN, который есть у Office 365 на их стороне, или вы получите странную ошибку на стороне Azure. Я думаю, что код ошибки — 8004786C
Если у вас нет суффикса UPN, доступного для установки для пользователя в среде AD, вы должны добавить этот суффикс через «Active Directory Domains and Trusts». Или, если вы хотите быть умным, установите другой атрибут для своей учетной записи AD и ADFS отправит этот атрибут как неизменяемый идентификатор. Если вы не понимаете, о чем я, то просто установите UPN. :)
Microsoft Office 365 не будет отображаться как опция в выпадающем меню, инициированном ADFS IDP на вашем сервере. Похоже, что это инициировано 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, не вводя никаких данных.
решение3
Помогает ли это вообще?http://technet.microsoft.com/en-us/library/dn296436.aspx
Прошло некоторое время с тех пор, как я делал то, о чем вы просите, но это было в моих заметках.