Freigeben über

HOWTO: Sharepoint and CustomAuth, Part 1 - Soliciting Questions

  • Artikel

I have been getting a bunch of private requests from many people asking me variations of the following questions:

"I want to use Sharepoint, but I want user authentication to be done with CustomAuth [or their own Wildcard Application Mapping ISAPI DLL]. I have tried many things, but it does not seem to work. Can you help me?"

"I want to write an ISAPI Filter to capture URL/Username information during a Sharepoint request execution. It seems that Sharepoint's stsfltr.dll is doing some magic and stealing the request and information from me. Can you help?"

You know I cannot resist a good challenge, especially when I get the same sort of feedback from many different people. :-)

I now have some good contacts inside the Sharepoint team, so I can finally figure out what their ISAPI DLL is doing from the inside, and combined with knowing IIS and ISAPI, I am going to attempt to put to rest as many of the common Sharepoint-IIS integration questions that you may have.

So, what am I doing now?

Call to Action

Yup, I am going to start up a little series of blog entries devoted to the topic of Sharepoint-IIS integration... and I am hereby soliciting *YOU* for your favorite questions in this space. Feel free to ask your questions as comments or to agree with others; I take that as input as to what to focus on.

I think it is time to take this discussion public in a "Forum" sort of format on my blog so that everyone who has similar questions can simply gather here and benefit.

Because, you know, private email responses are not searchable by anyone and benefit very few people, and it takes me just as much effort... so I would rather help more people. :-)

I already have a Virtual Machine set up with Windows Server 2003 SP1, I have access to all the Sharepoint versions you can name, and I've got CustomAuth, source code, and debuggers attached and waiting...

//David

Comments

  • Anonymous
    February 05, 2006
    It's a fantastic TO DO Task David!!!

    I'm working with Sharepoint Technologies adoption in Brazil (MS Gold Partner) and many clients ask to us if it's possible to do this > Custom Authentication working together with Sharepoint. :-)

    I'll appreciate your next post's.

    Regards

    Hélio Sá Moreira
  • Anonymous
    February 05, 2006
    helio_sa - when you say "Custom Authentication working together with Sharepoint" do you mean:
    1. "non-NT user accounts logging in and working with Sharepoint" or
    2. "NT user account, using a customized web page to sign in, working with Sharepoint" or
    3. Something else

    Please be specific. It helps me focus on what you actually want instead of guessing at it.

    //David
  • Anonymous
    February 05, 2006
    Re: David!

    Now I have 2 great questions related to authentication when this use "NT user account".

    1 - Delegate to third-part apps the control of user permission's (access control and privileges). NT user account...

    2 - User custom authentication page for user logon (instead of windows authentication pop-up logon when this user's access Sharepoint over Internet).

    (OWA - Outlook Web Access is great sample of custom auth pages)


    Another good question (perhaps very large and complex) is capacity to delegate full user control to third-part apps -> based on SQL Server with user/pass table!
    (forget this, only brainstorm!) :-)


    Obs.: At this projects, I'll planning to do custom ISAPI extensions ... but time and hard-work is a problem for rapid sharepoint implementation.

    Regards

    Hélio Sá Moreira
  • Anonymous
    February 06, 2006
    helio_sa -
    1. not certain how this is Sharepoint-IIS integration issue. Sounds like custom authorization scheme which while popular is outside the scope of integration.
    2. this is classic Forms auth and not necessarily tied to Sharepoint (though Sharepoint can certainly benefit from it as an application)
    3. unfortunately, delegation based on SQL-server is basically custom authorization scheme on the realm of customizations that consultants/integrators should provide...

    But, I appreciate your thoughts because it gives me an idea what users actually do, and it is useful feedback for Sharepoint team as well.

    //David
  • Anonymous
    February 06, 2006
    Hi David,

    I think that all question's can be resolved with authentication/authorization extensibility model; something documented and supported at sharepoint base control's and Object Model.

    I'd like to contribute with you and Sharepoint Team (if it's possible) talking about Sharepoint features.

    I'm beta-tester of WSS vNext (3.0) too, with great and interesting news.

    Regards and feel free to contact me.

    Thanks

    Hélio Sá Moreira
  • Anonymous
    February 06, 2006
    Hello David,

    Thanx already for your efforts. It's hard to find good info about CustomAuth. We are using it to do forms authentication with a sharepoint solution. However; we now want to authenticate users using a digital ID that is retrieved using a webservice. So the setup will be something like this:
    - user requests sharepoint page
    - sharepoint throws a 401, customauth picks up and redirects to the login page
    - the login page authenticates the user by calling a webservice, using the entered name/password combo. The webservice returns the digital ID
    - we look up the windows user account that is coupled to the digital ID in a database
    - somehow we tell customauth to use the windows useraccount to authenticate the user, either by sending a form with hidden fields to the client that posts the username/password (ugly) or an alternative where we need to adjust the isapi filter.... any suggestions?
    hope this makes sense. it might help to know that the usage of the webservice is required and not our creative invention ;-)

    As far as we know, the customauth doesn't work in combination with sharepoint using the root folder (well actually it does, but if you are authenticated and request the root folder sharepoint will throw an access denied error, requesting subfolders works fine), any ideas about that other than rewriting/adjusting CustomAuth?
  • Anonymous
    February 08, 2006
    The comment has been removed
  • Anonymous
    February 08, 2006
    Hi David,

    I've followed your prior articles on CustomAuth with interest, as I've been working on implementing CustomAuth with SharePoint for the past couple of months, with differing degrees of success.

    I'm currently in the process of being able to enter straight email addresses (versus AD User Names) with password, and being able to access SharePoint. However, I've only been able to get it to work if both Anonymous and IWA are enabled on the default SharePoint site. The CustomAuth pages are in a separate virtual directory under root with only Anonymous access.

    Obviously, there are multiple issues to having Anonymous turned on a SharePoint root, but I haven't found a work around yet. I'd be interested if anyone else has.

    Thanks,

    Steve
  • Anonymous
    February 08, 2006
    netdirector - In order to use CustomAuth, anonymous authentication has to be enabled. This is because:
    1. HSE_REQ_EXEC_URL, the ISAPI ServerSupportFunction used by CustomAuth to change the impersonated NT User Token (based on username/password you provide from the HTML FORM), cannot redirect between URLs of different authentication configuration.
    2. And since you initially login with CustomAuth using anonymous vdir (because you need to have IIS auth disabled to enable CustomAuth), accessing the remaining URLs have to have anonymous enabled.

    //David
  • Anonymous
    February 09, 2006
    David,
    Thanks for your help on this.
    Our WSS Architecture: 2 server WSS farm and will add 3rd server to farm and use it for extranet. Seems like CustomAuth does not support web farms.(if it supports, we would like to use 2 servers for extranet and have NLB). So, in this configuration, intranet site content is available on extranet.

    I am evaluating (testing) CustomAuth for EXTRANET use..
    Q1: Is it secure enough to have our intranet data exposed to internet and rely on Anonymous with CustomAuth? How secure is CustomAuth?

    Business Requirement: We would like to deny XYZ domain (intranet domain) users and allow XYZPARTNERS (for partners) domain users from extranet.
    Please note that both XYZ & XYZPARTNERS domains are trusted to the domain (ABC servers domain) extranet server is joined to.
    We dont want our business users to access their content from internet without the use of VPN (as some of our users do not have privilege of VPN and we want to stop them having access from homes).

    Q2: Can CustomAuth logon page be coded such that it authenticates only XYZPARTENERS domain users and no other domain users?

    Thanks,
    Vamsi
  • Anonymous
    February 09, 2006
    Hi David,

    Thank you for responding.

    In my scenario, I'm using a virtual directory under the default SharePoint website, ie https://sharepoint.website.com is my SharePoint site and CustomAuth resides in https://sharepoint.website.com/logon/.

    The Logon virtual directory is configured for only anonymous access. For CustomAuth to work, it seems that the default SharePoint site also needs anonymous configured, as well as IWA. This works fine... for a bit. But if anything affects the website, and SharePoint realizes that anonymous is turned on, SharePoint begins serving authentication error pages (not from the webserver, but from the SharePoint app) and I have to turn off anonymous, reset iis, and then turn it back on again. Not an ideal situation. It seems other people have it working though. Is there something obvious I'm missing?

    Thanks,

    - Steve
  • Anonymous
    February 09, 2006
    Hi David,

    Thank you for responding.

    In my scenario, I'm using a virtual directory under the default SharePoint website, ie https://sharepoint.website.com is my SharePoint site and CustomAuth resides in https://sharepoint.website.com/logon/.

    The Logon virtual directory is configured for only anonymous access. For CustomAuth to work, it seems that the default SharePoint site also needs anonymous configured, as well as IWA. This works fine... for a bit. But if anything affects the website, and SharePoint realizes that anonymous is turned on, SharePoint begins serving authentication error pages (not from the webserver, but from the SharePoint app) and I have to turn off anonymous, reset iis, and then turn it back on again. Not an ideal situation. It seems other people have it working though. Is there something obvious I'm missing?

    Thanks,

    - Steve
  • Anonymous
    February 09, 2006
    Thanks to everyone for your detailed comments of what you are trying to do and issues with it. Keep 'em coming.

    I'm going to take what has been currently commented and investigate on my free time the next few days to see what is going on...

    I have all your flood of questions on my queue to answer, so please bear with me... :-) I will be trying my best to get the answers and right design suggestions... I'm just getting myself acquainted with this "little" problem space...

    //David
  • Anonymous
    February 15, 2006
    HELP!!

    I'm having a problem with CustomAuth and Sharepoint services. Despite all kinds of attempts, I can't find any way to fix this.

    Here's what I did :

    1) http://<myWSSwebsite> only has anonymous access enabled. I installed the CustomAuth ISAPI filter by following the instructions provided in the IIS 6.0 Resource Kit.

    2) I created a directory under http://<myWSSwebsite> called "LogonForm" which has only anonymous access enabled. This directory contains the html logon page and I excluded this path from the Sharepoint managed paths.

    3) I created another directory under http://<myWSSwebsite> named "LogonSuccess" which denies anonymous access. This folder contains a simple page (eventually it will redirect to the WSS website) and I also excluded this path from the Sharepoint managed paths.

    4) I configured all that in CustomAuth.INI.

    5) When I hit the Sharepoint website, I get redirected to my logon form as expected. When I submit the form, it posts to "/LogonForm/Logon" (/LogonForm being an unmanaged path in WSS).

    I did it like that because the "/Logon" path doesn't exist and only serves as an way for CustomAuth to know it has to process the logon form credentials, and I did not want the Sharepoint ISAPI filter to throw me a 404 not found before the request ever had a chance to reach CustomAuth. That way, I expected the Sharepoint ISAPI to just let the request through (because of the unmanaged path setting).

    Well, for some reason, I still get a 404 not found when I submit my logon form. I'm kinda puzzled by this.

    What am I doing wrong?
  • Anonymous
    February 15, 2006
    Ok, stupid me... I just changed the name of my logon page folder to "/Logon", excluded this new path from the WSS managed paths, changed the post action in my logon page and the 404 not found went away.

    However, it's been replaced by a 500 internal server error which isn't any better :(
  • Anonymous
    February 18, 2006
    Guillaume - step #3 is not correct. In order for CustomAuth to apply to a URL, that URL must have anonymous authentication enabled. I detailed the reasons in an earlier comment.

    In other words, while CustomAuth allows you to use a custom HTML login page to authenticate a NT user, you need the URL to be under anonymous authentication in order to allow CustomAuth to swap the user identity into the NT user's.

    //David
  • Anonymous
    February 20, 2006
    Actually we created one ISAPI for SPS Form authentication before and it worked. However, Office 2003 use different method to authenticate the user. So the customized ISAPI will cause problem in this area.
  • Anonymous
    February 21, 2006
    oliverlu - If you are looking for an explanation or resolution, you need to provide more details. We already know that many things do not work, by-design, even if the user does not understand why.

    Please provide better details...

    //David
  • Anonymous
    March 06, 2006
    About a month ago, I solicited user questions in this blog entry on how to integrate customized authentication...
  • Anonymous
    March 09, 2006
    David,
    Thanks for your previous answers, I really appreciate it.

    I successfully implemented a SSO solution for Sharepoint Services with CustomAuth... well kinda! There's still one problem I need to address...

    I installed CustomAuth on the Sharepoint Services website, and got it to work. However, because of CustomAuth, I can't access the Sharepoint Webservices. Is there anything that can be done ???
  • Anonymous
    March 14, 2006
    I have one potentially stupid question.  If I want to build my own login page, how should it be constructed in order to play nicely with the CustomAuth ISAPI filter?  I have not seen much written up in this regard.  I am actually even having problems in getting the default mechanism to work - 404 Page Not Found is what I currently recieve.  Any help you could provide in this area would be greatly appreciated.
    Thanks,
    Mike
  • Anonymous
    March 14, 2006
    The comment has been removed
  • Anonymous
    March 15, 2006
    David,
    Much thanks for responding.  I am walking through the ini a bit more closely.  So far, the only thing I had done wrong was that "verify file exists" was checked.  I had forgotten to mention in my last post that I am trying to implement this in Sharepoint (hence writing under this thread).  Does this add any extra complexities?  Any extra steps to make it work?
    Mike
  • Anonymous
    March 15, 2006
    A couple more stupid questions about the default logon page.  Where is it?  Is it being rendered in the CustomAuth.dll?  Is it a page that should have come with the resource kit?  How do I set it up on my Sharepoint site?
  • Anonymous
    March 29, 2006
    I am new with WSS and IIS, etc. So my questions may sound relatively stupid for the well-versed in WSS.

    My current situation is that, both Active Directory authentication (hence customauth?) and companyweb site, work, but default.aspx page does not.

    In addition, while logging into http://mypublicIP/default.aspx a nice error 404 not found appears. Furthermore, Sharepoint doesn't allow me to extend the predetermined site server.

    I created another virtual server and extended it. However, I could not log into it.

    Need serious help pls.

    Thank you for your collaboration.
  • Anonymous
    April 05, 2006
    i m trying to implement customauth with sharepoint server.
    after i submit the login form it posts to
    http://mysharepoint/logon
    this return a 404 page not found
    --
    i added the path /logon to the unmanaged paths for sharepoint and tested
    --
    this return a 500 server error

    and i dont know what to do, please help
  • Anonymous
    April 12, 2006
    CustomAuth works great to let my into a Sharepoint site but when I try to open an Office document such as an Excel document in my Sharepoint site all I get is an Excel copy of my custom logon page.  Is there a way to get Office to recognize the user credentials in IE generated by CustomAuth.dll?
  • Anonymous
    April 12, 2006
    Will - This is a fundamental problem with Custom Authentication protocols - they are all arbitrary communications protocol, so you need custom code on client and server to handle it.

    In the case of CustomAuth, you need custom code on the client that knows about cookie-based-authentication and CustomAuth on the server to make things work.

    When the resource is handled completely by a web browser making a request to a web server, things work because the web browser knows the cookie-handling-logic to work with CustomAuth on the server.

    When the resource is handled by an arbitrary application like Excel making calls to a web server, things break down because Excel has no idea about the custom cookie-handling-logic, thus it cannot work against CustomAuth.

    In other words, Custom Authentication will never work with arbitrary applications that make HTTP requests to a web server which does not work like a web browser. This includes Office.

    Office and Sharepoint are designed to use standard authentication protocols and rely on NT User Tokens for security.
    - If you are using CustomAuth to perform a many-to-one mapping of User accounts, you will fail because it goes against Office/Sharepoint security design.
    - If you are using CustomAuth to merely provide a different user login experience, you may want to find a way to re-enable standard authentication for Office-based requests (check the request header) since CustomAuth is an arbitrary protocol that Office does not understand.

    //David
  • Anonymous
    April 19, 2006
    come on why there is no one answering my question??

    i m trying to implement customauth with sharepoint server.
    after i submit the login form it posts to
    http://mysharepoint/logon
    this return a 404 page not found
    --
    i added the path /logon to the unmanaged paths for sharepoint and tested
    --
    this return a 500 server error

    and i dont know what to do, please help

    i finished all the steps stated to make customauth work, but in the end i got this error, as i stated when i try to open  a sharepoint server page, it goes to the customauth login window when i click submit the error above happens, although i m sure i made all the setup steps correctly. and i tried several times and got the same error.
  • Anonymous
    April 20, 2006
    khaled - Maybe you are not aware of the customs of how support works, so let me explain.

    In general, if you require answer to an issue, the only way to get that is to pay for it.

    Free answers depend on the goodness of other people and/or your own intellect to resolve the issue. And you have to realize and accept that maybe no one wants to answer your question.

    Saying "I have a problem, please help" is not a sufficient solicitation - we all have problems to resolve.

    But complaining "why is no one answering my question" is almost surely a way to not get answers - because you are assuming your question deserves an answer when no such expectation should exist.

    //David
  • Anonymous
    May 08, 2006
    I have customauth working with sharepoint when using a debugger.  When I run without the debugger it presents the logon page, then after submitting a 500 error is returned.  It seems to be that the debugger has a different level of permissions that the normal process.  How can I determine the level of permissions?

    FYI - I've started the w3svc process( during debugging) with the application app pool and it works.
  • Anonymous
    May 11, 2006
    alan - By default, a debugger does not alter the permissions of a process nor its DLLs. So, my default assumption is that something ELSE operationally is configured differently when you are "debugging".

    How exactly are you "debugging" (what do you mean you've started the w3svc process during debugging - how are you launching the w3wp.exe without w3svc), what is the process identity of the process running CustomAuth/Sharepoint, and what is the application pool configuration during "Debugging"?

    Right now, it sounds like you are launching w3wp.exe stand-alone with different user identity than when configured in an Application Pool, hence you see different behavior. That would be by-design.

    //David
  • Anonymous
    May 12, 2006
    I've having the same problem that I see others having.  I've successfully implimented the CustomAuth.dll as an ISAPI filter in order to simulate Form based authentication with SharePoint Portal 2003.  

    However, when IIS is reset, or any changes are made to SharePoint such as webpart deployment, then SharePoint throws its own permission errors.   Then I have to switch it back to Inegrated authentication, reset iis, log in, and then switch back to Annonymous...

    Can anyone tell me in detail what is going on there?
  • Anonymous
    May 29, 2006
    I have some interesting information on CustomAuth that my colleague (Paul) and I arrived at with the help of the Microsoft news groups. We are trying to use CustomAuth to authenticate on to a WSS site that is available to a community outside of the corporate LAN / domain, hence it is hosted on a public web server with WSS installed on it. The problem we found was that some users could never see the CustomAuth built in login page and some users (particularly those using AOL as their ISP) would see a 2 minute delay between requesting a protected page and seeing the built in login page.

    After much investigation and with the help of Wade Hilmo at MS, who read some network traces and discovered that CustomAuth does not write a content length HTTP header. I guess when used on a local domain this is not a big deal, but AOL (amongst other ISPs) were having issue with the response as this entry was missing. He provided a fix to be added to the Source Code for CustomAuth, which can be downloaded from MS and this resolved the issue.

    Our full conversation can be seen on the following news group discussion thread: http://msdn.microsoft.com/newsgroups/default.aspx?&query=CustomAuth&lang=en&cr=US&guid=&sloc=en-us&dg=microsoft.public.inetserver.iis&p=1&tid=ba5dba5f-5141-4e75-acd7-f1426e10d27b

    I guess this is not hugely relevant to a lot of people, but if like us you were trying to deploy it for use over the Internet rather than as an Intranet site, this may help. It is also something that may feed in to forms authentication for the next WSS release.
  • Anonymous
    July 17, 2006
    I have a solution with CustomAuth / Sharepoint working. Has anyone made opening of Office products from Sharepoint/CustomAUth work? If so, let me know how?

    faribat@comcast.net
  • Anonymous
    July 18, 2006
    Sharon2 - While it is technically possible to open Office documents using CustomAuth/Sharepoint through a Web Browser, it ultimately does not work because the rest of the networked features within those applications use WebDAV, which simply fails against CustomAuth/Sharepoint, by-design.

    FYI: The only way for applications to work with CustomAuth is to be rewritten/extended to understand the CustomAuth protocol, and that is pretty much expected. Applications understand standard protocols; they need to be adapted to understand non-standard protocols.

    The reason:
    1. CustomAuth is a non-standard authentication protocol (that's why it's call "Custom" Auth and not "Basic" Auth or "Kerberos" Auth) which uses HTTP cookies as the authorization token.
    2. Technically, nothing in the world understand CustomAuth except for a human user who reads the returned login form, enters the username/password, and hits SUBMIT to set the authorization cookie and get everything going. This is different from other standard protocols like Basic, NTLM, Integrated, Kerberos, etc, which the Web Browser understands and can automatically negotiate/cache credentials.
    3. In particular, Web Browsers do not understand CustomAuth at all. Web Browsers just blindly display the login form and blindly pass the cookie back and forth according to Public Specifications
    4. Thus, the HTTP Client used by Office also does not understand CustomAuth protocol, and since it does not offer a web page for user to complete any authentication protocol, using Office Networked features against Sharepoint/CustomAuth cannot work and it is by-design.

    So, while user can click on the Office document and the browser will pass the cookie back/forth to complete CustomAuth and download the document to the client machine, when Office opens the file and does the rest of the WebDAV behaviors against CustomAuth/Sharepoint, that fails and thus you do not get your expected behavior.

    //David
  • Anonymous
    September 25, 2006
    Well, I have problem with CustomAuth in Sharepoint - whatever I write in logon page I'm redirected to the successLogonPage . I haven't found here enough information so I want to ask. In the next post I describe configuration details I have now.
  • Anonymous
    September 25, 2006
    I've tried to follow Guillaume's steps about configuration of Sharepoint portal root folder and "LogonForm" and "LogonSuccess" directories. I've also corrected step#3 as you said to do it. But I have another problem - in logon page whatever I write it redirects me to the successLogonPage.
    Configuration now looks like this:

    1. portal root folder
       permissions - Administrator full control, Everyone full control
                             IGA(Internet Guest Account) allow full control, deny write
      properties: Authentication only anonymous, applicationPool MSSPSAppPool

      CustomAuth is  installed as  filtr and wildcard.

    2.Logon folder
      permissions -  Administrator full control, Everyone full control
                             IGA(Internet Guest Account) allow full control, deny write
     properties: Authentication only anonymous, applicationPool defaultAppPool
     
      it's exluded from the portal

    3.Success folder(it has to be protected)
     permissions -  Administrator full control, Everyone full control
                             IGA(Internet Guest Account) inherits allow full control but is also checked deny everything
     properties: Authentication only anonymous, applicationPool MSSPSAppPool

     
     it's also  exluded from the portal


    In CustomAuth.ini I have:
    UseBuiltInLogonPage=1
    UseBuiltInLogoffPage=1
    LogonURL=/logon/loGon2222.htm
    LogonSuccessURL=http://portal.contoso.com/success/WebForm1.aspx
  • Anonymous
    September 25, 2006
    As I said I have "portal root folder" and two virtual directories "Logon folder" and "Success Folder" - subdirectories of this root folder.
    I thing there are two problems:

    1. When I try go to  http://portal.contoso.com  it redirects me to the logon page (as I expect). But when I fill logon form with wright login and password (they exist in Active Directory) it doesn't authenticate user. It redirects me again to logon page.
    Of course it's the same situation when I fill this form with wrong credentials.

    2. When I try to go to http://portal.contoso.com/success/WebForm1.aspx
    (protected page) CustomAuth doesn't work. I go there despite that I'm not authenticated.

    Could you help me?
  • Anonymous
    September 28, 2006
    I have set up a Virt Dir in IIS as an "excluded managed path" and tried to set it up for anonymous access (note: the sp site is not anonymous).  I have tried playing with permissions, web.config (authentication=none), etc., etc., etc. until I'm blue in the face. However, every IE6 and IE7 browser that hits this pate pops a auth dialog, which can be dismissed, letting the user into my app. Firefox shows no such authentication popup, nor do older IE (5.5--). The weird thing is that the page/site worked fine up till about a month or two ago, even under IE. Soooo, I am thinking it may be a security fix for IE on the browsing users' machines? Anybody have any other suggestions? Any wisdom whatsoever appreciated!