ADFS устанавливают с Локальным AD и Azure AD без Синхронизации Dir
Я не вижу проблемы с правилами. Для блокирования IP-адреса Вы используете
# iptables -A INPUT -s 127.0.0.100 -j DROP
Если Вы все еще можете соединиться от того IP-адреса, затем свериться с tcpdump, если Вы на самом деле соединяетесь с тем IP, или если по некоторым причинам (Прокси, VPN...) Вы видимы на хосте с правилами iptables как другой IP-адрес.
Предполагая, что это для O365 или Intune - DirSync является обязательным компонентом. DirSync разрешит одинаковый вход в систему, то есть пароли будут одинаковыми в обеих средах. Добавление ADFS позволит однократный вход , то есть пользователи будут беспрепятственно проходить аутентификацию без запроса учетных данных. DirSync - это основополагающий компонент как для одинаковой, так и для единой регистрации.
Вы не можете выполнить единый вход в клиент Azure AD с помощью только ADFS.
Это вообще помогает? http://technet.microsoft.com/en-us/library/dn296436.aspx
Прошло много времени с тех пор, как я сделал то, о чем вы просите, но это было в моих заметках.
У меня был такой же вопрос, и комментарий из maweeras поставил меня на правильный путь. Я немного перепробовал, заставил его работать, и вот что сработало со мной.
Не уверен, что это "поддерживаемое" решение, потому что им действительно нравится их DirSync. Однако есть смысл в том, что оно поддерживается по той причине, о которой говорилось в maweeras, а именно в том, что это решение позволяет инфраструктуре, отличной от Active Directory, все еще использовать SSO в Office 365.
Вот что вам нужно сделать:
SSO включить домен на стороне Office 365, запустив апплеты Convert-MsolDomainToFederated powershell. Скорее всего, вы сделали это.
Создайте пользовательские учетные записи, которые хотите включить SSO на стороне Office 365 вручную или с помощью powershell.
После их создания вам нужно использовать ObjectGUID на вашем объекте учетной записи AD в качестве их Неизменяемого идентификатора на стороне Azure.
Я использовал их в качестве справочной информации, но я включу эту информацию на случай, если эти URL исчезнут в будущем:
Вам нужно кодировать в base64 ObjectGUID для вашего пользователя и установить его. Кодируемый вами GUID не должен содержать скобок:
Здесь скрипт выполняет преобразование за вас: http://gallery.technet.microsoft.com/office/Covert-DirSyncMS-Online-5f3563b1
AD ObjectGUID (в "Формате реестра") 748b2d72-706b-42f8-8b25-82fd8733860f
Encoded: ci2LdGtw+EKLJYL9hzOGDw==
Вы устанавливаете это в учетной записи на Azure через powershell:
Set-MsolUser -UserPrincipalName user@azuredomain.com -ImmutableId "ci2LdGtw+EKLJYL9hzOGDw=="
Убедитесь, что UPN вашей учетной записи пользователя (на стороне вашего домена AD) совпадает с UPN user@azuredomain.com, который есть на стороне Office 365, иначе вы получите странную ошибку на Azure Side. Я думаю, что код ошибки 8004786C
Если у вас нет UPN суффикса, который можно задать для пользователя в вашей AD среде, вы должны добавить этот суффикс через "Active Directory Domains and Trusts" (Домены и трасты Active Directory). Или, если вы хотите быть умным, установите другой атрибут в учетной записи AD и заставите ADFS отправить этот атрибут в качестве неизменяемого ID. Если вы не понимаете, о чем я - просто установите 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, ничего не вводя.