Forum Discussion
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?
- The-messenger
Cirrostratus
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.
I’m not sure the HTTP 401 response agent is able to work in conjunction with NTLM Auth Result. The negotiate branch is typically used for Kerberos authentication. You should follow this cookbook to implement NTLM auth:
https://devcentral.f5.com/s/articles/configuring-apm-client-side-ntlm-authentication
And after the NTLM Auth result agent, I would also expect a SSO Credential Mapping agent. Also set the access policy itself to use NTLM SSO.
- The-messenger
Cirrostratus
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):
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com