Distinguere tra gli utenti di Windows Auth e Form Auth durante l'autenticazione contro la stessa AD con SharePoint 2010 utilizzando l'autenticazione basata su affermazioni

Question

Attualmente sto lavorando su un progetto SharePoint 2010 dove l'ambiente è configurato con un'applicazione Web di SharePoint utilizzando l'autenticazione basata reclami. L'applicazione web è stato creato sulla porta 8081 utilizzando l'autenticazione di Windows per autenticazione, ed esteso alla porta 80 con autenticazione basata su form.

Il provider di autenticazione basata su form è configurato per utilizzare la stessa directory attiva come il sito di Windows autenticazione basato, utilizzando le seguenti voci nel web.config dell'applicazione (le voci sono in amministrazione centrale e la sicurezza servizio token web.config file pure ):

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

Con questa configurazione funziona come previsto; gli utenti che visitano l'applicazione sulla porta 8081 vengono presentati con una sfida Windows standard di autenticazione, quelli sulla porta 80 sono diretti al form di login personalizzato. Quando si aggiungono gli utenti al sito tramite il fuori gli strumenti di amministrazione di dialogo, la ricerca di un particolare utente come john.smith@mydomain.com tornerà due colpi, uno dal provider di autenticazione di Windows, uno dal fornitore di forme di autenticazione. Aggiungendo sia di questi utenti a un sito rivela che SharePoint memorizza il nome account con un identificatore aggiunto al fronte. L'utente di Windows auth è tradotto per i: 0 # .w | mydomain \ JohnSmith, l'utente FBA è tradotto per i:. 0 # .F | fba_ad_mp | john.smith@mydomain.com

.

Ecco dove il problema entra in gioco Stiamo creando raccolte siti in massa utilizzando uno strumento su misura che analizza un foglio di calcolo di ingresso, crea raccolte siti, e aggiunge gli utenti appropriati al sito appena creato utilizzando il seguente metodo:

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

Il paramter userName passato è, seguendo l'esempio, john.smith@mydomain.com. Tuttavia, l'utente aggiunto al sito è sempre l'utente di Windows autenticazione basato, i:. 0 # .w | mydomain \ JohnSmith

Come faccio a specificare che provider di autenticazione per il polling quando si chiama EnsureUser quindi posso garantire che l'utente corretto si aggiunge al sito?

Answer 1

Il problema è che entrambi i provider di appartenenze riconoscono l'indirizzo e-mail, e il primo risultato (AD) si abitua. Prova FBA_AD_MP:. John.smith@mydomain.com - che la sintassi funziona nei controlli nome utente standard (utilizzando il nome di controllo piuttosto che la finestra di ricerca), e credo che EnsureUser funziona allo stesso modo

Answer 2

In breve è necessario convertire SPUser a uno SPClaim utilizzando lo SPClaimProviderManager