Min kollega har arbetat på en webbdel i en FBA miljö. Bland annat, webbdelen drar vissa data från SQL server. Den stora planen för detta projekt dikterar att en DBA konfigurerar datasäkerhet i SQL (i stället för att bädda in ett användar-ID i en SQL-fråga eller några andra tillvägagångssätt).

Problemet är att SQL server inte vet något om vår FBA miljö så det inte kan lita på oss. Vi löste detta problem genom att, i brist på bättre ord, manuellt härma en AD-användare så att vi kunde ansluta till SQL så att SQL data nivå säkerhet fungerar.

Trots att FBA är en ASP.NET-funktion, Vi SharePoint Nation människor har undervisat i olika sökmotorer som om du frågan för FBA, Du måste menar du vill veta hur till konfigurera FBA i SharePoint. Jag kunde inte hitta hitta någon information om hur du aktiverar en FBA orienterade ASP.NET ansökan att kommunicera med SQL på det sätt vi behövde.

I forska i detta, Vi läser denna artikel: ASP.NET-personifiering

Mer forskning ledde oss till denna codproject artikel: http://www.codeproject.com/KB/cs/cpimpersonation1.aspx

Som hjälpte oss att skriva vår kod, som jag har tagit under. Det är inte den mest eleganta saker, men det fungerade. Jag hoppas du tycker det är bra.

Här är koden som arbetat för oss:

skyddade void btnSearchCarrier_Click(objekt avsändare, EventArgs e)
 {
 försök
 {
 ImpersonateUser iU = nya ImpersonateUser();
 // TODO: Ersätta referenser iU.Impersonate("Domännamn", "Användarnamn", "Lösenord");

//
 KODEN
//

 iU.Undo();
 }
 fånga (Undantaget ex)
 {

 }
 }

// Personifiering-klassen som nämns nedan.

offentliga klass ImpersonateUser
 {
 [DllImport("advapi32.dll", SetLastError = sant)]
 offentliga statisk extern bool LogonUser(
 Sträng lpszUsername,
 Sträng lpszDomain,
 Sträng lpszPassword,
 int dwLogonType,
 int dwLogonProvider,
 Ref IntPtr phToken);

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

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

 // Om du införliva denna kod i en DLL-fil, se till att kräva att den
 // kör med FullTrust.
 [PermissionSetAttribute(SecurityAction.Demand, Namn = "FullTrust")]
 offentliga void personifiera(sträng domännamn, String användarnamn, sträng lösenord)
 {
 försök
 {

 // Använda ohanterade av funktionen LogonUser för att få användaren token för
 // den angivna användaren, domän, och lösenord.
 CONST-utskottet int LOGON32_PROVIDER_DEFAULT = 0;

 // Passerar denna parameter orsakar LogonUser skapa en primär token.
 CONST-utskottet int LOGON32_LOGON_INTERACTIVE = 2;
 tokenHandle = IntPtr.Zero;

 // Steg -1 Anropa LogonUser för att få ett handtag till en åtkomst-token.
 bool returnValue = LogonUser(
 Användarnamn,
 Domännamn,
 lösenord,
 LOGON32_LOGON_INTERACTIVE,
 LOGON32_PROVIDER_DEFAULT,
 Ref tokenHandle); // tokenHandle - ny säkerhetstoken

 om (falskt == returnValue)
 {
 int ret = Marshal.GetLastWin32Error();
 Console.WriteLine("LogonUser anrop misslyckades med felkod : " +
 ret);
 kasta nya System.ComponentModel.Win32Exception(ret);
 }

 // Steg - 2
 WindowsIdentity newId = nya WindowsIdentity(tokenHandle);
 // Steg -3
 impersonatedUser = newId.Impersonate();

 }
 fånga (Undantaget ex)
 {
 Console.WriteLine("Undantag inträffade. " + ex.Meddelande);
 }
 }


 /// <Sammanfattning>
 /// Hållplatser personifiering
 /// </Sammanfattning>
 offentliga void ångra()
 {
 impersonatedUser.Undo();
 // Gratis tokens.
 om (tokenHandle != IntPtr.Zero)
 CloseHandle(tokenHandle);
 }
 }

</slutet>

Prenumerera på min blogg.

Ett par veckor tillbaka, Jag arbetade med kollegan utvecklare på ett projekt som omfattar SQL Server Reporting Services plug-in för MOSS. Han utvecklade en webbdel som tillhandahåller en front-end till betänkandet rätt fancy (den viktigaste funktionen är en smart sökning på en parameter med flera tusen sökbara värden bakom det).

Detta fungerade bra i utvecklingsmiljön men i användare acceptanstest (UAT) miljö, Det skulle inte fungera. Bränning upp debugger, Vi skulle se undantagsinformation såhär:

Behörigheterna som beviljats användare 'UAT_domainmosssvc' är otillräckliga för att utföra den här åtgärden.(rsAccessDenied).

Om du gör en levande söka på ovanstående fel, du tycker det är ganska vanligt. Scarily gemensamma. Den värsta formen av gemensamma eftersom det har många olika potentiella roten orsakar och allas föreslagna lösning "känns" rätt. Vi har förmodligen försökt dem alla.

I vårt fall, problemet var att vi hade gjort en backup/återställning av DEV att UAT. Någonstans i data, något fortfarande hänvisar till "DEV_domain" (i stället för den uppdaterade "UAT_Domain"). Vi skapat en ny webbplats, lagt till webbdelen och som löste våra problem.

Förhoppningsvis kommer att detta spara någon timme eller två ner linjen.

</slutet>

Prenumerera på min blogg.