Min kollega har jobbet med en webdel i et FBA-miljø. Blant annet, webdelen trekker data fra SQLServer. Grand plan for dette prosjektet tilsier at en DBA konfigurerer datasikkerhet i SQL (i motsetning til bygge en bruker-ID i en SQL-spørring eller noen andre tilnærming).

Problemet er at SQLServer ikke vet noe om FBA miljøet så det ikke stoler på oss. Vi løste problemet ved, mangel av et bedre ord, manuelt representerer en AD-bruker slik at vi kan koble til SQL slik at SQL-data nivå sikkerhet fungerer.

Selv om FBA er en ASP.NET-funksjon, Vi SharePoint Nation folk har undervist på ulike søkemotorer som hvis du spør for FBA, du må mener du vil vite hvordan du konfigurerer FBA i SharePoint. Jeg kunne ikke finne finne informasjon om hvordan du aktiverer et FBA orientert ASP.NET-program til å kommunisere med SQL i måten vi trengte.

I undersøker dette, Vi re-lese denne artikkelen: ASP.NET representasjon

Mer forskning førte oss til denne codproject artikkelen: http://www.codeproject.com/KB/cs/cpimpersonation1.aspx

Som hjalp oss å skrive koden vår, som jeg har tatt under. Det er ikke den mest elegante ting, bortsett fra den arbeidet. Jeg håper du finner det nyttig.

Her er koden som fungerte for oss:

beskyttet Ugyldig btnSearchCarrier_Click(objektet avsender, EventArgs kan e)
 {
 Prøv
 {
 ImpersonateUser IE = nye ImpersonateUser();
 // TODO: Erstatte legitimasjon iU.Impersonate(«Domenenavn», "Brukernavn", "Passord");

//
 KODE
//

 iU.Undo();
 }
 fange (Unntak ex)
 {

 }
 }

// Bruke representasjon klassen som nevnt nedenfor.

offentlig klassen ImpersonateUser
 {
 [DllImport("advapi32.dll", SetLastError = sann)]
 offentlig statisk extern bool LogonUser(
 Streng lpszUsername,
 Streng lpszDomain,
 Streng lpszPassword,
 int dwLogonType,
 int dwLogonProvider,
 REF IntPtr phToken);

 [DllImport("kernel32.dll", CharSet = CharSet.Auto)]
 privat extern statisk bool CloseHandle(IntPtr håndtak);

 privat statisk IntPtr tokenHandle = nye IntPtr(0);
 privat statisk WindowsImpersonationContext impersonatedUser;

 // Hvis du innlemme denne koden i en DLL, Sørg for å kreve at det
 // kjører FullTrust.
 [PermissionSetAttribute(SecurityAction.Demand, Navn = "FullTrust")]
 offentlig Ugyldig opptre(streng domenenavn, streng brukernavn, streng passord)
 {
 Prøv
 {

 // Bruk funksjonen for uovervåkede LogonUser hente token for
 // den angitte brukeren, domene, og passord.
 konst int LOGON32_PROVIDER_DEFAULT = 0;

 // Passerer denne parameteren forårsaker LogonUser opprette primærtoken.
 konst int LOGON32_LOGON_INTERACTIVE = 2;
 tokenHandle = IntPtr.Zero;

 // Trinn -1 Påloggingsøkten for å få en referanse til et tilgangstoken.
 Boolsk returnValue = LogonUser(
 Brukernavn,
 Domenenavn,
 passord,
 LOGON32_LOGON_INTERACTIVE,
 LOGON32_PROVIDER_DEFAULT,
 REF tokenHandle); // tokenHandle - ny sikkerhetskode

 Hvis (== False returnValue)
 {
 int ret = Marshal.GetLastWin32Error();
 Console.WriteLine("LogonUser kallet mislyktes med feilkode : " +
 ret);
 kaste nye System.ComponentModel.Win32Exception(ret);
 }

 // Trinn - 2
 WindowsIdentity newId = nye WindowsIdentity(tokenHandle);
 // Trinn -3
 impersonatedUser = newId.Impersonate();

 }
 fange (Unntak ex)
 {
 Console.WriteLine("Unntak oppstod. " + ex.Melding);
 }
 }


 /// <Sammendrag>
 /// Stopper representasjon
 /// </Sammendrag>
 offentlig Ugyldig angre()
 {
 impersonatedUser.Undo();
 // Gratis tokenene.
 Hvis (tokenHandle != IntPtr.Zero)
 CloseHandle(tokenHandle);
 }
 }

</slutten>

Abonner på bloggen min.

Et par uker tilbake, Jeg jobbet utvikler kollega på et prosjekt med SQL Server Reporting Services plug-in for MOSS. Han var å utvikle en webdel som inneholder en fancy front-end i rapporten riktig (den viktigste funksjonen er et smart oppslag på en parameter med flere tusen søkbare verdier bak det.).

Dette var fungerer bra i utviklingsmiljøet, men i aksept sluttbrukertesting (UAT) miljø, ville det ikke fungere. Firing opp feilsøkingsprogrammet, Vi ville se unntaksdetaljer som dette:

Tillatelsene som er gitt til brukeren 'UAT_domainmosssvc' er tilstrekkelige for å utføre denne operasjonen.(rsAccessDenied).

Hvis du gjør en live søk på over feil, du synes det er ganske vanlig. Skremmende felles. Den verste typen vanlig fordi den har mange ulike potensielle root årsaker og alles løsningsforslag "føles" høyre. Vi prøvd sannsynligvis dem alle.

I vårt tilfelle, problemet var at vi hadde gjort en sikkerhetskopiering/gjenoppretting av DEV UAT. Et sted i data, noe var fortsatt refererer til "DEV_domain" (i stedet for den oppdaterte "UAT_Domain"). Vi laget et nytt nettsted, lagt til webdelen og det løste vår problem.

Forhåpentligvis vil dette spare noen en time eller to ned linjen.

</slutten>

Abonner på bloggen min.