Различать пользователей Windows Auth и Forms Auth при аутентификации в одном AD с SharePoint 2010 с использованием аутентификации на основе утверждений

В настоящее время я работаю над проектом SharePoint 2010, в котором среда настраивается с помощью веб-приложения SharePoint с использованием проверки подлинности на основе утверждений. Веб-приложение создается на порту 8081 с использованием проверки подлинности Windows для проверки подлинности и расширяется до порта 80 с помощью проверки подлинности на основе форм.

Поставщик проверки подлинности с помощью форм настроен на использование того же активного каталога, что и сайт на основе проверки подлинности Windows, с использованием следующих записей в файле web.config приложения (записи также находятся в файлах web.config службы токенов централизованного администрирования и безопасности):

    <membership defaultProvider="i">
  <providers>
    <add name="i" type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" />
    <add name="FBA_AD_MP" type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="ADFBAConnectionString" enableSearchMethods="true" attributeMapUsername="userPrincipalName" />
  </providers>
</membership>

Использование этой настройки работает должным образом; пользователям, которые посещают приложение через порт 8081, предоставляется стандартная проверка подлинности Windows, а пользователи порта 80 направляются в пользовательскую форму входа. При добавлении пользователей на сайт с помощью готовых инструментов администрирования поиск конкретного пользователя, такого как [email protected], вернет два обращения: одно от поставщика проверки подлинности Windows, другое от поставщика проверки подлинности форм. Добавление обоих этих пользователей на сайт показывает, что SharePoint хранит имя учетной записи с идентификатором, добавленным впереди. Пользователь Windows auth переводится в i: 0 # .w | mydomain \ johnsmith, пользователь FBA переводится в i: 0 # .f | fba_ad_mp | [email protected].

Вот где возникает проблема. Мы создаем семейства сайтов массово, используя специально разработанный инструмент, который анализирует электронную таблицу входных данных, создает семейства сайтов и добавляет соответствующих пользователей на вновь созданный сайт, используя следующий метод:

    private static void AddUser(SPSite site, String userName, String spGroupName)
    {
        try
        {
            SPUser spUser = site.RootWeb.EnsureUser(userName);

            if (spUser != null)
            {
                site.RootWeb.Groups[spGroupName].AddUser(spUser);
            }
        }
        catch(Exception ex)
        {
            SharePointManager.Counter.Warnings++;
            SharePointManager.Logger.Warn(String.Format("\t\tUnable to add user {0} to group {1} at site {2}: {3}", userName, spGroupName, site.RootWeb.Url, ex.ToString()));
        }
    }

Переданный параметр userName, как показано в примере, будет [email protected]. Однако пользователь, добавленный на сайт, всегда является пользователем с авторизацией в Windows, i: 0 # .w | mydomain \ johnsmith.

Как мне указать, какой провайдер аутентификации опрашивать при вызове EnsureUser, чтобы я мог гарантировать, что правильный пользователь добавлен на сайт?


authentication c# sharepoint sharepoint-2010
person Preston Guillot    schedule 12.02.2010    source источник

Ответы (2)


arrow_upward
1
arrow_downward

Проблема в том, что оба поставщика членства распознают адрес электронной почты, и используется первый результат (AD). Попробуйте FBA_AD_MP: [email protected] - этот синтаксис работает в стандартных элементах управления именем пользователя (с использованием имени проверки, а не диалогового окна поиска), и я считаю, что EnsureUser работает таким же образом.

person Tom Clarkson    schedule 13.02.2010
comment
Я вижу такое же поведение средства выбора людей (не поиска), но метод обеспечения пользователя не любит этот формат. Однако он работает нормально, если я добавлю к имени пользователя i: 0 # .f | fba_ad_mp |. На данный момент я могу сделать это элементом конфигурации ... но мне любопытно, где в объектной модели я мог бы надежно найти эти префиксы для более сложных сценариев. - person Preston Guillot; 15.02.2010

arrow_upward
0
arrow_downward

Короче говоря, вам нужно преобразовать SPUser в SPClaim с помощью SPClaimProviderManager.

person Ryan Mann    schedule 19.09.2010
comment
С какой целью? Нет перегрузки SPGroup.AddUser (), которая принимает SPClaim, а также SPClaim не содержит ссылки на SPUser, специфичный для какого-либо поставщика. - person Preston Guillot; 14.02.2012