В рамках реализации установки SharePoint 2013 я настроил единый вход с ADFS на Windows Server 2012R2.
Существует два отдельных леса AD: один как часть размещенного SharePoint / ADFS, а другой - корпоративный лес на месте.
В настоящее время у меня корпоративная AD настроена как Claims Provider Trust
в SharePoint ADFS
. Я могу успешно передать атрибут электронной почты из корпоративной AD в SharePoint.
Я хочу добиться некоторой формы инъекции претензий из Hosted AD Forest
как часть входа в систему с Corporate AD
учетная запись.
В частности, пользователи будут членами групп безопасности для определения лицензирования SharePoint. По соображениям безопасности я не хочу получать информацию об этом заявлении из корпоративной AD, поскольку это означает, что пользователи смогут изменять свой статус лицензирования.
Таким образом, все пользователи фактически будут иметь учетную запись AD в обоих лесах. Единый вход, предоставляемый путем ввода их корпоративных учетных данных в процессе входа.
Есть ли способ сказать своему hosted ADFS
искать пользователя в собственном лесу AD, который соответствует incoming Email Address Claim
из Corporate ADFS
, а затем введите Role claim
из hosted forest
с указанной заявкой по электронной почте?
Пожалуйста, посмотрите картинку ниже, чтобы увидеть, чего я пытаюсь достичь (извините за быстрый рисунок MS Paint!):
Как мне выполнить шаги 4 и 5?
Текущие правила рассмотрения претензий
На Hosted ADFS
, Acceptance Transform Rules
для Corporate Claim Provider Trust
:
На Hosted ADFS
, Issuance Transform Rules
для SharePoint Relying Party
:
Да, это должно сработать. Если вы управляете правилами утверждений в размещенном ADFS и если у вас есть какой-то ключ из Corp ADFS в утверждении, то вы можете выполнить обычное правило запроса поиска AD с этим ключом.
В итоге я получил эту работу, и на самом деле это было не так плохо, как я думал - мне просто нужно было написать собственный код. Issuance Transform Rule
на моей проверяющей стороне SharePoint.
Вот что я придумал:
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", "http://schemas.microsoft.com/ws/2008/06/identity/claims/role"), query = "userPrincipalName={0};userPrincipalName,tokenGroups;MYDOMAIN\accountthatdoesnotexist", param = c.Value);
По сути, это будет означать, что если утверждение адреса электронной почты определено во входящем наборе утверждений, оно будет запрашивать AD с адресом электронной почты и находить userPrincipalName
что соответствует email address
. Затем он просто возвращает upn
и tokenGroups
атрибуты как upn
и role
претензии, которые мне нужны.
Я вставил это как правило номер 1 в свою Проверяющую сторону. Поскольку у некоторых пользователей не будет сторонних ADFS для аутентификации, я считаю, что это должно обеспечить максимальную совместимость.
После проверки кода утверждений по умолчанию при использовании шаблона отправки атрибутов AD он будет фактически запущен только в том случае, если правило получит windowsaccountname claim
(это утверждение передается Проверяющей стороне только в том случае, если пользователь входит в систему без стороннего ADFS).
Итак, у меня есть ситуация, когда, если пользователь входит в систему without a third party ADFS
, он проигнорирует мое настраиваемое правило, поскольку хранилище атрибутов Active Directory не отправляет email address claim
. Кроме того, если пользователь входит в систему WITH a third party ADFS
, он проигнорирует Send LDAP Attributes
правило, поскольку нет windowsaccountname
набор требований!
Наконец, при первой попытке я сначала подумал, что застрял, поскольку я использую только UPN, а не традиционные учетные записи domain \ username в размещенной AD, потому что я получал сообщение об ошибке в журналах событий:
Microsoft.IdentityServer.ClaimsPolicy.Engine.AttributeStore.AttributeStoreQueryFormatException:
POLICY3826:
User name 'myuser@mycorp.com' in LDAP query';userPrincipalName,tokenGroups;myuser@mycorp.com'
is not in the required 'domain\user' format.
Однако для меня хорошей новостью является то, что часть имени пользователя домена \ имени пользователя фактически игнорируется! https://technet.microsoft.com/en-us/library/adfs2-help-attribute-stores%28WS.10%29.aspx
QUERY = <QUERY_FILTER>;<ATTRIBUTES>;<DOMAIN_NAME>\<USERNAME>
Эта часть запроса определяет и определяет местонахождение контроллера домена, к которому нужно подключиться для выполнения запроса LDAP.
Также обратите внимание, что USERNAME игнорируется даже для хранилищ атрибутов Active Directory.
Итак, с небольшой настройкой, чтобы убедиться, что фильтр LDAP соответствует на userPrincipalName
а не по умолчанию (если фильтр запроса оставлен пустым) samAccountName
, теперь это работает отлично!