Diferencie entre os usuários do Windows Auth e Forms Auth ao autenticar contra o mesmo anúncio com o SharePoint 2010 usando autenticação baseada em reivindicações

Question

Atualmente, estou trabalhando em um projeto do SharePoint 2010, onde o ambiente é configurado com um aplicativo da Web do SharePoint usando autenticação baseada em reivindicações. O aplicativo da Web é criado na porta 8081 usando a autenticação do Windows para autenticação e estendido à porta 80 usando autenticação baseada em formulários.

O provedor de autenticação de formulários está configurado para usar o mesmo diretório ativo que o site baseado em autenticação do Windows, usando as seguintes entradas no web.config do aplicativo (as entradas estão nos arquivos Web.config da administração central de administração e segurança):

    <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>

O uso dessa configuração funciona conforme o esperado; Os usuários que visitam o aplicativo na porta 8081 recebem um desafio de autenticação do Windows padrão, os que na porta 80 são direcionados para o formulário de login personalizado. Ao adicionar usuários ao site através das ferramentas de administração de fora da caixa, uma pesquisa por um usuário específico como john.smith@mydomain.com retornará dois hits, um do provedor de autenticação do Windows, um do provedor de autenticação dos formulários. Adicionar esses dois usuários a um site revela que o SharePoint armazena o nome da conta com um identificador anexado à frente. O usuário do Windows Auth é traduzido para i: 0#.w | MyDomain Johnsmith, o usuário do FBA é traduzido para i: 0#.f | fba_ad_mp | john.smith@mydomain.com.

Aqui é onde entra o problema. Estamos criando coleções de sites a granel usando uma ferramenta construída personalizada que analisa uma planilha de entrada, cria coleções de sites e adiciona os usuários apropriados ao site recém -criado usando o seguinte método:

    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()));
        }
    }

O paramter de nome de usuário aprovado é, seguindo o exemplo, john.smith@mydomain.com. No entanto, o usuário adicionado ao site é sempre o usuário baseado em autenticação do Windows, i: 0#.w | MyDomain Johnsmith.

Como especificar qual provedor de autenticação para pesquisar ao ligar para garantir o User para garantir que o usuário correto seja adicionado ao site?

Answer 1

O problema é que ambos os provedores de associação reconhecem o endereço de email e o primeiro resultado (AD) é usado. Experimente FBA_AD_MP: john.smith@mydomain.com - que a sintaxe funciona nos controles padrão do nome de usuário (usando o nome da verificação em vez da caixa de diálogo de pesquisa), e acredito que o GEMSER funcione da mesma maneira.

Answer 2

Em resumo, você precisa converter o spuser em um spclaim usando o spclaimproviderManager