Min kollega har arbejdet på en webdel i en FBA miljø. Blandt andet, webdelen trækker nogle data fra SQL server. Den store plan for dette projekt dikterer at en DBA konfigurerer datasikkerhed i SQL (i modsætning til indlejring et bruger-ID i en SQL-forespørgsel eller nogle andre tilgang).

Problemet er, at SQL server ikke ved noget om vores FBA miljø, så det ikke kan stole på os. Vi løst problemet ved, i mangel af et bedre ord, manuelt udgive en annonce bruger, således at vi kunne forbinde til SQL, SQL data niveau sikkerhed værker.

Selvom FBA er en ASP.NET-funktion, Vi SharePoint Nation mennesker har lært de forskellige søgemaskiner, hvis du forespørger for FBA, Du skal mener du vil vide, hvordan du konfigurerer FBA i SharePoint. Jeg har undladt at finde finde nogen oplysninger om, hvordan du aktiverer en FBA orienterede ASP.NET-program til at kommunikere med SQL i den måde, vi havde brug for.

I løbet af forske dette, vi læse at denne artikel: ASP.NET personifikation

Mere forskning har ført os til denne codproject artikel: http://www.codeproject.com/KB/cs/cpimpersonation1.aspx

Der hjalp os med at skrive vores kode, som jeg har inkluderet under. Det er ikke den mest elegante ting, men det virkede. Jeg håber du finder det nyttigt.

Her er den kode, der arbejdede for os:

beskyttet Ugyldigt btnSearchCarrier_Click(objektet afsender, EventArgs e)
 {
 Prøv
 {
 ImpersonateUser iU = nye ImpersonateUser();
 // TODO: Erstatte legitimationsoplysninger iU.Impersonate("DomainName", "Brugernavn", "Password");

//
 KODE
//

 iU.Undo();
 }
 fangst (Undtagelse ex)
 {

 }
 }

// Personefterligning-klassen som nævnt nedenfor.

offentlige klasse ImpersonateUser
 {
 [DllImport("advapi32.dll", SetLastError = True)]
 offentlige statisk extern bool LogonUser(
 Strengen lpszUsername,
 Strengen lpszDomain,
 Strengen lpszPassword,
 int dwLogonType,
 int dwLogonProvider,
 Ref IntPtr phToken);

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

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

 // Hvis du indarbejde denne kode i en DLL, Sørg for at kræve, at det
 // løber med FullTrust.
 [PermissionSetAttribute(SecurityAction.Demand, Navn = "FullTrust")]
 offentlige ugyldig repræsenter(streng domainName, strengen userName, streng adgangskode)
 {
 Prøv
 {

 // Brug funktionen ikke-administrerede LogonUser for at få brugeren token for
 // den angivne bruger, domæne, og adgangskode.
 CONST int LOGON32_PROVIDER_DEFAULT = 0;

 // Passerer denne parameter forårsager LogonUser til at oprette en primær token.
 CONST int LOGON32_LOGON_INTERACTIVE = 2;
 tokenHandle = IntPtr.Zero;

 // Trin -1 Kalde LogonUser for at få en handle til en adgangstoken.
 bool returnValue = LogonUser(
 userName,
 domainName,
 adgangskode,
 LOGON32_LOGON_INTERACTIVE,
 LOGON32_PROVIDER_DEFAULT,
 Ref tokenHandle); // tokenHandle - nyt sikkerheds-id

 Hvis (falsk == returnValue)
 {
 int ret = Marshal.GetLastWin32Error();
 Console.WriteLine("LogonUser mislykkedes med fejlkode : " +
 ret);
 kaste ny System.ComponentModel.Win32Exception(ret);
 }

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

 }
 fangst (Undtagelse ex)
 {
 Console.WriteLine("Der opstod en undtagelse. " + ex.Besked);
 }
 }


 /// <Resumé>
 /// Stopper repræsentationen
 /// </Resumé>
 offentlige ugyldig Fortryd()
 {
 impersonatedUser.Undo();
 // Gratis poletter.
 Hvis (tokenHandle != IntPtr.Zero)
 CloseHandle(tokenHandle);
 }
 }

</slutningen>

Abonner på min blog.

Et par uger tilbage, Jeg arbejdede med min kollega, udvikler på et projekt med SQL Server Reporting Services-plug-in til MOSS. Han var ved at udvikle en webdel, der giver en front-end til rapporten ordentlig fancy (de vigtigste træk er en klog opslag på en parameter med flere tusinde søgbare værdier bag det).

Dette var i orden stor i udviklingsmiljøet, men i accept brugertest (UAT) miljø, Det ville ikke arbejde. Fyres op fejlfindingsprogrammet., Vi ville se undtagelse detaljer som dette:

Tilladelserne tildeles brugeren 'UAT_domainmosssvc' er utilstrækkelig til at udføre denne handling.(rsAccessDenied).

Hvis du gør en live søgning på ovennævnte fejl, du finde det er helt almindeligt. Skræmmende fælles. Den værste form for fælles, fordi det har mange forskellige potentielle rod forårsager og alles løsningsforslag "føles" højre. Vi prøvet sikkert dem alle.

I vores tilfælde, Problemet var, at vi havde gjort en backup/gendannelse af DEV at UAT. Et sted i data, noget var stadig henvise til "DEV_domain" (i stedet for den opdateret "UAT_Domain"). Vi har oprettet et nyt websted, tilføjet webdelen, og at løst vores problem.

Forhåbentlig vil dette spare nogen, en time eller to ned linjen.

</slutningen>

Abonner på min blog.