Forum Discussion

The-messenger's avatar
The-messenger
Icon for Cirrostratus rankCirrostratus
Jun 13, 2019

HTTP - basic NTLM auth

I need to setup HTTP auth/NTLM authentication. Much appreciation in advance.

The app is posting this and is receiving an unexpected response:

 

[2019-06-13T14:22:40.607513 #78983]  INFO -- request: GET https://big-ip-url/api/1/tokens/retrieve

User-Agent: "Faraday v0.15.4"

Authorization: "NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAgAAAAAAAAACAAAABFZGVuLmxvY2Fs”

 

[2019-06-13T14:22:40.762985 #78983]  INFO -- response: Status 302

[2019-06-13T14:22:40.763055 #78983] DEBUG -- response: server: "BigIP"

connection: "Close"

content-length: "0"

location: "/my.policy"

set-cookie: "LastMRH_Session=a22ed998;path=/;secure, MRHSession=coooooookie;path=/;secure, MRHSHint=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/"

 

Traditionally, IIS would return an unauthorized along with the www-authenticate header which is then used to issue another request with the username and password. Since that is not what is being returned, it is throwing an error. I’m assuming the F5 should take what is being returned by IIS and just tag that on to what it is sending back?

 

This is the example of what the app expects to be returned by your IIS

 

server: "Microsoft-HTTPAPI/2.0"

www-authenticate: "NTLM TlRMTVNTUAACAAAADgAOADgAAAAFgokCor0fjbFZe2oAAAAAAAAAAJIAkgBGAAAACgA5OAAAAA9UAFIAQQBJAE4ARABDAAIADgBUAFIAQQBJAE4ARABDAAEADgBTAEUAUgBWAFIAXwAxAAQAFgB0AHIAYQBpAG4ARABDAC4AbgBlAHQAAwAmAHMAZQByAHYAcgBfADEALgB0AHIAYQBpAG4ARABDAC4AbgBlAHQABQAWAHQAcgBhAGkAbgBEAEMALgBuAGUAdAAHAAgAx4/FcEMh1QEAAAAA"

date: "Wed, 12 Jun 2019 17:22:41 GMT"

content-length: "341"

6 Replies

  • It seems that the virtual server has an APM access policy. Since the first GET request doesn’t contain a valid MRHSession cookie, APM will start the access policy, and redirects the client to the configured policy. In your case I would expect the access policy to include NTLM auth and NTLM sso. What does your policy look like?

  • Thanks!

    On the attempts I've seen I've tracked them to the Negotiate path. If I'm on the right track, I imagine I can trim this VPE down, once I have this working.

    I'm waiting for the developer to test again.

     

    • The-messenger's avatar
      The-messenger
      Icon for Cirrostratus rankCirrostratus

      That's where I started with this but not being confident of what the developer is sending, thought I would try to put some more in the VPE.

      set back to just ntlm

      Added some logging (splunk formatted)

      when HTTP_REQUEST {
       
        if { [ACCESS::session data get session.ntlm.last.result] eq 1 } {
        ECA::disable
        } else {
        ECA::enable
        ECA::select select_ntlm:/Common/DC2-LTM-NTLM
        }
       
      	 # Get Client request and browser information
      set pol_client_browser [HTTP::header User-Agent]  
      set pol_http_host [HTTP::host]
      set pol_http_uri [HTTP::uri]
      set pol_http_header [HTTP::request]
       
       log -noname local0. "pol_client_browser=\"$pol_client_browser\" --pol_http_host=\"$pol_http_host\" -- pol_http_uri=\"$pol_http_uri\" -- pol_http_header=\"$pol_http_header\""
       
      }

      With logging set on this now, I can see the header data. Looks like the app is trying to get/use a token from the application behind the big-ip with the URI /api/1/tokens

      GET /api/1/tokens/retrieve HTTP/1.1 User-Agent: Faraday v0.15.4 Authorization: NTLM TlRMTVNTA;;KDKKKKDFJJFJFIIKDKKKDAAAAAAA Accept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3 Accept: */* Connection: keep-alive Keep-Alive: 30 Host: doxlyapi.HOST.COM

  • So, after confirming that the NTLM auth on the client side is successful, add the SSO credential mapping agent to the successful branch. In the policy tab itself add the NTLM SSO profile. So it will do serverside NTLM auth to the backend IIS server.

  • I have to rectify my previous answer. NTLM SSO (server side auth) is not possible when using NTLM auth (client side auth). When using NTLM auth (client side auth) you can only use Kerberos SSO (server side auth). See the compatibility matrix in this article (table 3.1):

     

    https://support.f5.com/csp/article/K08200035