Назад | Перейти на главную страницу

ADFS - объединение утверждений от трастов провайдера и AD

В рамках реализации установки 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:

  1. Пропустить утверждение входящего адреса электронной почты, пройти через все значения

На Hosted ADFS, Issuance Transform Rules для SharePoint Relying Party:

  1. Отправлять атрибуты LDAP как утверждения (UPN -> UPN, группы токенов -> Роль, адреса электронной почты -> электронная почта)
  2. Пропустить утверждение входящего адреса электронной почты, пройти через все значения

Да, это должно сработать. Если вы управляете правилами утверждений в размещенном 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, теперь это работает отлично!