Freigeben über

HOWTO: Sharepoint and CustomAuth, Part 2 - Investigations Update

  • Artikel

About a month ago, I solicited user questions in this blog entry on how to integrate customized authentication protocol with Sharepoint, and I was a little overwhelmed by the responses and the variety of situations that users have posted and shared with me. I have also been pegged by a couple of MCS Consultants who really want me to provide assistance on several cases... which has surprised me since it's a very different sort of role and demand of me.

I am a member of the IIS product team, which means I work on design, development, or testing of IIS. I blog, answer newsgroup questions, consult, code-review, etc "on the side" on my own time, so its quite a change for me to somehow be "responsible" for delivering solutions at a specific time, for a consulting job that I never asked for, no less! :-)

I know, I know, this is the real world and not this abstract/fantasy world we work in called the "product development cycle". But, just humor me for a moment... :-P

Ok, I wanted to give a little update on my investigations.

I have been discussing details of how Sharepoint interacts with IIS authentication with several developer, test, and program manager members of the Sharepoint team, and they've given some interesting details on how custom authentication should work. I now need to go validate it with my own little custom ISAPI. In short, the answers are:

  1. Custom authentication is definitely possible if you stick to the web front-end. Obviously, custom authentication of Sharepoint fails when used from a client like Office because arbitrary custom authentication cannot understood by the Office client
  2. Custom authentication must modify the NT Impersonation token and the REMOTE_USER server variable of the request. This can be done with ISAPI Filter or ISAPI Extension on IIS6, so I'll try out their integration
  3. Custom authentication must disable any IIS attempt at authentication. This basically means that you need to have anonymous authentication enabled in IIS, and you should do this from within Sharepoint's admin UI instead of just changing IIS settings (Sharepoint dev tells me that if you don't modify through Sharepoint's admin UI, webfarm synchronization can fail)

Alright, I'm going to go try some integration parts now... when I next have some free time. I'll definitely publish whatever code I use for integration, explain how it works, etc. Oh don't worry, I'll get to all your other Sharepoint questions as well... it's just that IIS7 sorta has my attention right now. :-)

//David

Comments

  • Anonymous
    August 31, 2006
    David,

    Ive been picking through your blog posts regarding customauth and SharePoint and we are tryingto get it to work in our environment without success.  Ran into an interesting issue more closely related to the customauth ISAPI - With the appl. pool identity set to NETWORK_SERICE account customauth behaves as expected - when we change the identity to a domain account it fails with a 500 error.  Tried replicating the same permissions set as held by the NETWORK SERVICE account and still the same results. We even went as far as granting local admin rights to the domain account and still a no go. This is before even tackling the SharePoint part of the equation.  The behavour is puzzling.  Any insight you might have into why this happens would be appreciated.

    Thanks