Различать пользователей Windows Auth и Forms Auth при проверке подлинности на одном AD с SharePoint 2010 с использованием проверки подлинности на основе утверждений - PullRequest
6 голосов
/ 13 февраля 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 - настраиваемая форма входа в систему. При добавлении пользователей на сайт с помощью встроенных инструментов администрирования поиск определенного пользователя, например john.smith@mydomain.com, будет возвращать два обращения: одно от поставщика проверки подлинности Windows, другое от поставщика проверки подлинности форм. Добавление обоих этих пользователей на сайт показывает, что SharePoint хранит имя учетной записи с идентификатором, добавленным спереди. Пользователь Windows Auth переведен на i: 0 # .w | mydomain \ johnsmith, пользователь FBA переведен на i: 0 # .f | fba_ad_mp | john.smith@mydomain.com.

.

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

    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 следующий пример: john.smith@mydomain.com. Однако пользователь, добавленный на сайт, всегда является пользователем, основанным на аутентификации Windows, i: 0 # .w | mydomain \ johnsmith.

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

Ответы [ 2 ]

1 голос
/ 13 февраля 2010

Проблема заключается в том, что оба провайдера членства распознают адрес электронной почты, и первый результат (AD) используется. Попробуйте FBA_AD_MP: john.smith@mydomain.com - этот синтаксис работает в стандартных элементах управления именем пользователя (с использованием контрольного имени, а не в диалоговом окне поиска), и я считаю, что EnsureUser работает точно так же.

0 голосов
/ 19 сентября 2010

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...