Компания использует Office 365 с аутентификацией ADFS; AD Connect используется для синхронизации каталогов, ADFS - это версия Windows server 2012 R2.
Компания имеет несколько доменов Active Directory:
parent1.com
child1.parent1.com
child2.parent1.com
child3.parent1.com
parent2.com
...
...
Корневые домены настроены как федеративные домены в Office 365 (имена общедоступных доменов и доменные имена AD идентичны); это работает нормально, пользователи могут входить в Office 365, используя свои UPN, например user1@parent1.com, и их пароль AD.
Мне нужно добавить поддержку дочерних доменов; поэтому я добавил child1.parent1.com в Office 365, выполнив следующую команду (после подключения к Office 365 с учетной записью администратора с помощью Connect-MsolService):
New-MsolFederatedDomain -DomainName child1.parent1.com -SupportMultipleDomain
(N.B. Если я не использовал SupportMultipleDomain параметр, PowerShell выдаст ошибку, указав, что это необходимо).
Затем я приступил к добавлению всех необходимых записей DNS как в частном, так и в общедоступном DNS; Проверка записей DNS в Office 365 показала, что все в порядке.
Затем дочерний домен был добавлен в AD Connect, и была выполнена синхронизация; Таким образом, пользователи из дочернего домена появились в Office 365 с такими именами, как user1@child1.parent1.com. Я назначил им соответствующие лицензии и попытался войти на портал Office 365.
Однако пользователи дочернего домена не могут войти в систему; они получают сообщение об ошибке «неверный запрос» со следующими дополнительными сведениями:
Correlation ID: b1e47d45-b21c-42e9-9758-265804db7171
Timestamp: 2016-08-10 20:27:48Z
AADSTS50107: Requested federation realm
object 'http://child1.parent1.com/adfs/services/trust/' does not exist.
Очевидно, что со стороны ADFS что-то не так, но я не эксперт в этом, и я не был тем, кто его настраивал; как это исправить, чтобы пользователи в дочерних доменах могли успешно входить в Office 365?
Проблема очень мало задокументирована (сообщение в блоге Technet и некоторая документация для Azure AD), но он действительно существует, и это вызвано некорректным поведением ADFS в определенных конкретных ситуациях (несколько федеративных доменов верхнего уровня и добавление федеративных дочерних доменов в смесь); решение включает редактирование регулярного выражения в правиле утверждения ADFS, которое используется для создания IssuerUri, связанного с UPN пользователя. Цитата из второй статьи:
So lets say for example that I have bmcontoso.com and then add
corp.bmcontoso.com. This means that the IssuerUri for a user from
corp.bmcontoso.com will need to be http://bmcontoso.com/adfs/services/trust.
However the standard rule implemented above for Azure AD, will generate a
token with an issuer as http://corp.bmcontoso.com/adfs/services/trust
which will not match the domain's required value and authentication will fail.
Чтобы решить эту проблему, следует отредактировать третье правило утверждения в ADFS, начиная с
c:[Type == "http://schemas.xmlsoap.org/claims/UPN"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, ".+@(?<domain>.+)","http://${domain}/adfs/services/trust/"));
к
c:[Type == "http://schemas.xmlsoap.org/claims/UPN"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid", Value = regexreplace(c.Value, "^((.*)([.|@]))?(?<domain>[^.]*[.].*)$", "http://${domain}/adfs/services/trust/"));
Однако помните, что это может нарушить совместимость с другими сценариями, такими как фактический федеративный домен третьего уровня, родительский домен которого не является федеративным.