My colleague has been working on a web part in an FBA environment. Among other things, the web part pulls some data from SQL server. The grand plan for this project dictates that a DBA configures data level security in SQL (in teenstelling met die inbedding van 'n gebruiker-ID in 'n SQL-navraag of 'n ander benadering).

The problem is that SQL server doesn’t know anything about our FBA environment so it can’t trust us. We solved this problem by, vir 'n gebrek van 'n beter woord, manually impersonating an AD user so that we could connect to SQL such that SQL data level security works.

Selfs al FBA is 'n ASP.NET-funksie, ons die SharePoint Nasie mense geleer het om die verskillende soekenjins dat as jy bevraagteken vir FBA, you must mean you want know how to configure FBA in SharePoint. I failed to find find any information on how to enable an FBA oriented ASP.NET application to communicate with SQL in the way we needed.

In die loop van die ondersoek, ons weer lees hierdie artikel: ASP.NET imiteren

Meer navorsing gelei het tot hierdie codproject artikel: http://www.codeproject.com/KB/cs/cpimpersonation1.aspx

Wat gehelp het om ons skryf ons kode, which I’ve included below. It’s not the most elegant stuff, maar dit het gewerk. I hope you find it helpful.

Hier is die kode wat vir ons gewerk het:

beskerm nietig btnSearchCarrier_Click(voorwerp sender, EventArgs e)
 {
 probeer
 {
 ImpersonateUser IE = nuwe ImpersonateUser();
 // ALLE: Plaas geloofsbriewe
 ("Domain Name", "Gebruikersnaam", "Password");

//
 KODE
//

 iU.Undo();
 }
 vang (Uitsondering ex)
 {

 }
 }

// Die gebruik van imiteren klas soos hieronder vermeld.

openbare klas ImpersonateUser
 {
 [DllImport("Advapi32.dll", SetLastError = waar)]
 openbare statiese eksterne Bool LogonUser(
 String lpszUsername,
 String lpszDomain,
 String lpszPassword,
 int dwLogonType,
 int dwLogonProvider,
 ref IntPtr phToken);

 [DllImport("Kernel32.dll", Charset = CharSet.Auto)]
 private eksterne statiese Bool Close Handle(IntPtr hanteer);

 private statiese IntPtr tokenHandle = nuwe IntPtr(0);
 private statiese WindowsImpersonationContext impersonatedUser;

 // As jy hierdie kode insluit in 'n DLL, seker wees om dit te eis dat
 // lopies met FullTrust.
 [PermissionSetAttribute(SecurityAction.Demand, Noem = "FullTrust")]
 openbare nietig voorhou(string domein, string gebruikersnaam, string wagwoord)
 {
 probeer
 {

 // Gebruik die onbeheerde LogonUser funksie te kry die gebruiker teken vir
 // die gespesifiseerde gebruiker, domein, en wagwoord.
 konst int LOGON32_PROVIDER_DEFAULT = 0;

 // Aparte slaag van hierdie parameter veroorsaak LogonUser 'n primêre teken te skep.
 konst int LOGON32_LOGON_INTERACTIVE = 2;
 tokenHandle = IntPtr.Zero;

 // Stap -1 Bel LogonUser 'n handvatsel te verkry tot 'n toegang teken.
 die Bool returnValue = LogonUser(
 gebruikersnaam,
 Domeinnaam,
 wagwoord,
 LOGON32_LOGON_INTERACTIVE,
 LOGON32_PROVIDER_DEFAULT,
 ref tokenHandle); // tokenHandle - nuwe sekuriteit gebrand

 indien (valse == returnValue)
 {
 int ret = Marshal.GetLastWin32Error();
 Console.WriteLine("LogonUser oproep misluk met foutkode : " +
 reg);
 gooi nuwe System.ComponentModel.Win32Exception(reg);
 }

 // Stap - 2
 WindowsIdentity newId = nuwe WindowsIdentity(tokenHandle);
 // Stap -3
 impersonatedUser = newId.Impersonate();

 }
 vang (Uitsondering ex)
 {
 Console.WriteLine(Msgstr "Uitsondering het voorgekom. " + ex.Message);
 }
 }


 /// <opsomming>
 /// Tops nabootsing
 /// </opsomming>
 openbare nietig Undo()
 {
 impersonatedUser.Undo();
 // Vry om die tekens.
 indien (tokenHandle != IntPtr.Zero)
 Close Handle(tokenHandle);
 }
 }

</einde>

Skryf in op my blog.

'N Paar weke terug, I was working with my developer colleague on a project involving SQL Server Reporting Services plug-in for MOSS. He was developing a web part that provides a fancy front-end to the report proper (die belangrikste kenmerk van 'n slim lookup op 'n parameter met 'n paar duisend soekbare waardes agter dit).

Dit was groot werk in die omgewing nie, maar in die gebruiker aanvaarding toets (UAT) omgewing, it wouldn’t work. Firing up the debugger, ons sal sien uitsondering besonderhede soos hierdie:

Die regte aan gebruikers 'UAT_domain mosssvc' onvoldoende is vir die uitvoering van hierdie aksie.(rsAccessDenied).

As jy 'n live soektog op die bogenoemde fout, you find it’s quite common. Scarily common. The worst kind of common because it has many different potential root causes and everyone’s suggested solution "feels" reg. We probably tried them all.

In ons geval, the problem was that we had done a backup/restore of DEV to UAT. Somewhere in the data, iets was nog verwys na "DEV_domain" (in plaas van die updated "UAT_Domain"). We created a new site, bygevoeg op die web deel en wat ons probleem opgelos.

Hopelik sal iemand 'n uur of twee te red in die ry.

</einde>

Skryf in op my blog.