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 (as opposed to embedding a user ID in a SQL query or some other approach).

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, para sa kakulangan ng isang mas mahusay na salita, manually impersonating an AD user so that we could connect to SQL such that SQL data level security works.

Even though FBA is an ASP.NET feature, we SharePoint Nation people have taught the various search engines that if you’re querying for 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 the course of researching this, we re-read this article: ASP.NET Impersonation

More research led us to this codproject article: http://www.codeproject.com/KB/cs/cpimpersonation1.aspx

That helped us write our code, which I’ve included below. It’s not the most elegant stuff, ngunit ito ay nagtrabaho. I hope you find it helpful.

Narito ang code na nagtrabaho para sa amin:

protektado void btnSearchCarrier_Click(object sender, EventArgs e)
 {
 sumubok
 {
 ImpersonateUser iU = bago ImpersonateUser();
 // TODO: Replace credentials
 iU.Impersonate("DomainName", "UserName", "Password");

//
 CODE
//

 iU.Undo();
 }
 abutin (Exception hal)
 {

 }
 }

// Using Impersonation class as mentioned below.

publiko klase ImpersonateUser
 {
 [DllImport("advapi32.dll", SetLastError = totoo)]
 publiko statik extern bool LogonUser(
 String lpszUsername,
 String lpszDomain,
 String lpszPassword,
 int dwLogonType,
 int dwLogonProvider,
 ref IntPtr phToken);

 [DllImport("kernel32.dll", Charset = CharSet.Auto)]
 pribado extern statik bool CloseHandle(IntPtr handle);

 pribado statik IntPtr tokenHandle = bago IntPtr(0);
 pribado statik WindowsImpersonationContext impersonatedUser;

 // Kung isama mo ang code na ito sa isang DLL, siguraduhin na hinihiling na ito
 // Nagpapatakbo ng may FullTrust.
 [PermissionSetAttribute(SecurityAction.Demand, Pangalanan = "FullTrust")]
 publiko walang bisa gayahin(string DOMAINNAME, string username, string password)
 {
 sumubok
 {

 // Gamitin ang function na unmanaged LogonUser upang makuha ang token ng user para sa
 // ang tinukoy na user, domain, at password.
 const int LOGON32_PROVIDER_DEFAULT = 0;

 // Pasadong ang parameter na ito ay nagsasanhi sa LogonUser upang lumikha ng isang pangunahing token.
 const int LOGON32_LOGON_INTERACTIVE = 2;
 tokenHandle = IntPtr.Zero;

 // Hakbang -1 Tawagan LogonUser upang makakuha ng handle sa isang token sa pag-access.
 bool returnValue = LogonUser(
 Username,
 pangalan ng domain,
 password,
 LOGON32_LOGON_INTERACTIVE,
 LOGON32_PROVIDER_DEFAULT,
 Property tokenHandle); // tokenHandle - bagong security token

 kung (maling == returnValue)
 {
 int magpabasa = Marshal.GetLastWin32Error();
 Console.WriteLine("LogonUser call failed with error code : " +
 karapatan);
 magtapon bagong System.ComponentModel.Win32Exception(karapatan);
 }

 // Hakbang - 2
 WindowsIdentity newId = bago WindowsIdentity(tokenHandle);
 // Hakbang -3
 impersonatedUser = newId.Impersonate();

 }
 abutin (Exception hal)
 {
 Console.WriteLine("Exception occurred. " + ex.Message);
 }
 }


 /// <buod>
 /// Paghinto ng pagpapanggap
 /// </buod>
 publiko walang silbi ang I-undo()
 {
 impersonatedUser.Undo();
 // Magbakante ang mga token.
 kung (tokenHandle != IntPtr.Zero)
 CloseHandle(tokenHandle);
 }
 }

</dulo>

Mag-subscribe sa aking blog.

Ilang linggo pabalik, 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 (ang pangunahing tampok sa pagiging isang matalino lookup sa isang parameter na may ilang libong mga halaga mahahanap sa likod nito).

Ito ay mahusay na gumagana sa kapaligiran ng pagbuo ngunit sa pagsubok user pagtanggap (UAT) kapaligiran, it wouldn’t work. Firing up the debugger, Gusto naming makita ang mga detalye tulad ng pagbubukod na ito:

Ang mga pahintulot na ibinigay sa gumagamit 'UAT_domain mosssvc' ay hindi sapat para gawin ang kilos.(rsAccessDenied).

Kung gagawin mo ang isang live na paghahanap sa itaas error, 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" karapatan. We probably tried them all.

Sa aming kaso, the problem was that we had done a backup/restore of DEV to UAT. Somewhere in the data, something was still referring to "DEV_domain" (instead of the updated "UAT_Domain"). We created a new site, Idinagdag ang web bahagi at na malutas ang aming mga problema.

Sana ito ay i-save ang isang tao ng isang oras o dalawang down ang linya.

</dulo>

Mag-subscribe sa aking blog.