Feed Icon  

Contact

  • Bryant Likes
  • Send mail to the author(s) E-mail
  • twitter
  • View Bryant Likes's profile on LinkedIn
  • del.icio.us
Get Microsoft Silverlight
by clicking "Install Microsoft Silverlight" you accept the
Silverlight license agreement

Hosting By

Hot Topics

Tags

Open Source Projects

Archives

Ads

Single Sign-On, Impersonation, and SqlConnections

Posted in SharePoint | ASP.Net/Web Services at Wednesday, February 23, 2005 10:14 AM Pacific Standard Time

This morning I came across this article: Impersonation, Single Sign-on, and SPS. It is a very interesting article that lays out how to use Single Sign-on with impersonation. So the first thing I did was to get Single Sign-On setup using this MSDN article which was linked in the article. Wow! That was pretty easy. I actually have SSO working for the first time and now it seems pretty simple.

The next step for me was to take the sample code and try it out. I created a new WebPart library and created my new SSO sample webpart. Everything was setup just like the article (I think) but when I ran it I got the dreaded:

Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection.

Ok. So why doesn't this work. Well after doing some testing myself (using Page.User.Identity and WindowsIdentity.GetCurrent().Name) I came to the conclusion that something doesn't work, although I'm not sure what it is. It must work in some situations because Jay Nathan has done a lot of work on this (here and here), this article references it, and so does Barry's Blog here on January 24, 2005 (could we get a permalink Barry?). So these guys must be using it and it must be working.

Patrick seems to come to a different conclusion here. He seems to be saying that impersonation doesn't work and that it is easier to just use COM+ instead. A third example of impersonation can be found at this MSDN article. All three of these examples do the same thing, and in all three cases I get the same error message above when I try to connect to the database using a trusted connection.

I can solve Patrick's problem by creating a new WindowsPrincipal object and assigning it to the current context (after making a copy of the current IPrincipal in order to return things on undo). Here is an example of how to do this.

1) First you will need to change the Impersonate method on the Impersonator class:

public WindowsIdentity Impersonate()
{
    // authenticates the domain user account and begins impersonating it
    WindowsIdentity id = this.Logon();
    this.impersonationContext = id.Impersonate();
    return id;
}

2) Next you will need to store the current Principal and then set the new one.

IPrincipal p = base.Context.User;
....
WindowsPrincipal wp = new WindowsPrincipal(Impersonater.Impersonate());
base.Context.User = wp;

3) You can then do stuff using the SharePoint object model since the Context.User has now been replaced with the impersonated user. When you're done you put back the orginal user.

Impersonater.Undo();
base.Context.User = p;

Using this code both the WindowsIdentity.GetCurrent().Name and Context.User.Identity.Name return the name of the impersonated user.

All this to say that it still doesn't seem to accomplish what I need to accomplish. I still get that error and I'm really not sure why. Any ideas?

Thursday, February 24, 2005 10:19:00 AM (Pacific Standard Time, UTC-08:00)
What's up, Bryant!
<br>
<br>So are there two physical servers involved here? Looks a lot like the double-hop issue where the credentials don't get automatically delegated.
Tuesday, March 1, 2005 7:57:00 AM (Pacific Standard Time, UTC-08:00)
Ever figure this out? Did you check to make sure your SQL connection string was well-formed? The ever fun user '(null)' has happened to me before only to find (after half a day of frantic debugging and head-scratching) that I was missing a semi-colon in the connection string.
<br>
<br>I suggest this because it seems to me that if you're getting the correctly impersonated user at the level of your code, then it may well be somewhere farther down the line...
Francis
Tuesday, March 15, 2005 10:09:00 PM (Pacific Standard Time, UTC-08:00)
I'm struggling with a similar problem at the moment, and this may be of help:
<br>
<br><a target="_new" href="http://www.bluedoglimited.com/sharepointthoughts/viewpost.aspx?ID=7">http://www.bluedoglimited.com/sharepointthoughts/viewpost.aspx?ID=7</a>
<br>
<br>"The SharePoint object model, when running under the context of an IIS request, will always validate its actions against the original context of the request. Therefore, reverting to self or impersonating an admin account is absolutely worthless."
<br>
<br>Also: "Is this a bug or bad design?
<br>It's both. However, that's another topic altogether."
<br>
<br>ah well
Sunday, November 30, 2008 8:26:40 PM (Pacific Standard Time, UTC-08:00)
Avoid Losing Impersonation Tokens

In .NET Framework 1.1, impersonation tokens did not automatically flow to newly created threads. This situation could lead to security vulnerabilities because new threads assume the security context of the process. In ASP.NET 2.0 applications you can now change this default behavior by configuring the ASPNET.config file in the %Windir%Microsoft.NET\Framework\{Version} directory.

If you need to flow the impersonation token to new threads, set the enabled attribute to true on the alwaysFlowImpersonationPolicy element in the ASPNET.config file, as shown in the following example.
Copy Code

....
<configuration>
<runtime>
<alwaysFlowImpersonationPolicy enabled="true"/>
</runtime>
</configuration>
todor
Comments are closed.