Forum Discussion

David_E__Smith_'s avatar
David_E__Smith_
Icon for Nimbostratus rankNimbostratus
Jul 09, 2015

How to force a back-end authentication request?

The subject line above may be a bit misleading/confusing, and I'm in a bit over my head, so here's my scenario.

 

I'm trying to replace a Microsoft ISA server with F5 APM. For this part of my project, the back-end servers are SharePoint 2010. We have an access profile that requires all users to log into APM, check credentials against a Windows DC, and send NTLM to the back-end.

 

For sites where the back-end requires authentication for all content, everything works just fine.

 

However, for sites where some content is anonymously available (from the SharePoint point of view), I've got some unusual behavior. On one site, for instance, all pages have a "Login" box at the top. On ISA, the Login field is replaced with an identifying "you're logged in as Your-name Here"), but on the F5 it's just a login prompt.

 

Once you do something that requires special privileges (visiting a back-end page, or a page that otherwise requires some level of privilege), everything works as expected. The page header displays your name, and you can view "privileged" content without further complications.

 

My theory is this: Once you've created an F5 APM session, the F5 holds onto your credentials, but doesn't send them to SharePoint until explicitly requested (via a 401 NTLM request). Somehow, Microsoft ISA Server circumvents this, and pre-emptively sends the credentials to the back-end, or otherwise does some invisible-to-me request mangling, so that you're logged in (from SharePoint's point of view) even on your first page view.

 

So, my main question: Is there a way to replicate this behavior on the F5?

 

A tangential question: Does my theory as to why it's happening seem plausible?

 

3 Replies

  • seeing how NTLM works with a challenge response system it might be difficult to just send something as some interaction between client (APM) and server (SharePoint) is required. exactly how Microsoft might solve this for anon access i wouldn't know. you could consider trying a packet capture on the server side to investigate that.
  • David, not that it appears to matter anymore, but for posterity consider this. The different authentication methods (NTLM, Basic, Forms, Kerberos, etc.) have different protocol exchanges. For NTLM, Basic and Kerberos, the client gets a 401 and the server expects an Authorization header in every request. That's essentially what your NTLM SSO profile is doing. For a page that does forms auth, the client must POST some values to a form, in which case the server usually passes back some kind of token - a cookie usually - so that subsequent requests are seen as authenticated. APM's forms SSO looks for a form object, POSTs your credentials to that form, and then looks for the defined response to know if authentication was successful. It looks like you have a mixture of NTLM and forms auth pages. APM does support this sort of environment, but you have to specify which is which. You'd build an NTLM SSO for your regular pages, and potentially different forms SSO profiles for the different forms auth pages (if there's more than one). Then based on the request URI, you can switch the SSO profile.

     

  • Unfortunately, the packets between ISA and SharePoint all are encrypted, so that wasn't a feasible option. Ultimately, we worked around it by having the SharePoint group reconfigure the server, to disable anonymous access (so that the back-end would demand credentials on the first page view). Since we have a workaround, I'm not actually all that worried about this any longer.