App auth breaks when put behind F5

Sorry for the delay. Started a new job and all I have is Chrome tools (chrome://net-internals). The behavior observed when putting the bigip in front of the app is we get a login dialog box. Below is the conversation:

925: URL_REQUEST
https://i2ddev.ab.abc.com/
Start Time: 2017-08-17 14:19:33.657
t=120636 [st=   0] +REQUEST_ALIVE  [dt=?]
                    --> priority = "HIGHEST"
                    --> url = "https://i2ddev.ab.abc.com/"
t=120636 [st=   0]    DELEGATE_INFO  [dt=1]
                      --> delegate_blocked_by = "NavigationResourceThrottle"
t=120637 [st=   1]    URL_REQUEST_DELEGATE  [dt=0]
t=120637 [st=   1]    URL_REQUEST_START_JOB  [dt=0]
                      --> load_flags = 37120 (MAIN_FRAME_DEPRECATED | MAYBE_USER_GESTURE | VERIFY_EV_CERT)
                      --> method = "GET"
                      --> url = "https://i2ddev.ab.abc.com/"
t=120637 [st=   1]   +URL_REQUEST_START_JOB  [dt=?]
                      --> load_flags = 37120 (MAIN_FRAME_DEPRECATED | MAYBE_USER_GESTURE | VERIFY_EV_CERT)
                      --> method = "GET"
                      --> url = "https://i2ddev.ab.abc.com/"
t=120637 [st=   1]      URL_REQUEST_DELEGATE  [dt=0]
t=120637 [st=   1]      HTTP_CACHE_GET_BACKEND  [dt=0]
t=120637 [st=   1]      HTTP_CACHE_OPEN_ENTRY  [dt=1]
                        --> net_error = -2 (ERR_FAILED)
t=120638 [st=   2]      HTTP_CACHE_CREATE_ENTRY  [dt=0]
t=120638 [st=   2]      HTTP_CACHE_ADD_TO_ENTRY  [dt=0]
t=120638 [st=   2]     +HTTP_STREAM_REQUEST  [dt=154]
t=120638 [st=   2]        HTTP_STREAM_JOB_CONTROLLER_BOUND
                          --> source_dependency = 928 (HTTP_STREAM_JOB_CONTROLLER)
t=120792 [st= 156]        HTTP_STREAM_REQUEST_BOUND_TO_JOB
                          --> source_dependency = 929 (HTTP_STREAM_JOB)
t=120792 [st= 156]     -HTTP_STREAM_REQUEST
t=120792 [st= 156]     +HTTP_TRANSACTION_SEND_REQUEST  [dt=0]
t=120792 [st= 156]        **HTTP_TRANSACTION_SEND_REQUEST_HEADERS**
                          --> GET / HTTP/1.1
                              Host: i2ddev.ab.abc.com
                              Connection: keep-alive
                              Upgrade-Insecure-Requests: 1
                              User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36
                              Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
                              Accept-Encoding: gzip, deflate, br
                              Accept-Language: en-US,en;q=0.8
                              Cookie: [76 bytes were stripped]
t=120792 [st= 156]     -HTTP_TRANSACTION_SEND_REQUEST
t=120792 [st= 156]     +HTTP_TRANSACTION_READ_HEADERS  [dt=481]
t=120792 [st= 156]        HTTP_STREAM_PARSER_READ_HEADERS  [dt=480]
t=121272 [st= 636]        **HTTP_TRANSACTION_READ_RESPONSE_HEADERS**
                          --> HTTP/1.1 401 Unauthorized
                              Content-Type: text/html
                              Server: 
                              WWW-Authenticate: Negotiate
                              WWW-Authenticate: NTLM
                              strict-transport-security: max-age=31536000
                              X-Frame-Options: SAMEORIGIN
                              X-Content-Type-Options: nosniff
                              X-XSS-Protection: 1; mode=block
                              X-UA-Compatible: IE=edge
                              Date: Thu, 17 Aug 2017 17:19:34 GMT
                              Content-Length: 1293
t=121273 [st= 637]        AUTH_CHANNEL_BINDINGS
t=121273 [st= 637]     -HTTP_TRANSACTION_READ_HEADERS
t=121273 [st= 637]      URL_REQUEST_DELEGATE  [dt=0]
t=121273 [st= 637]      URL_REQUEST_DELEGATE  [dt=0]
t=121273 [st= 637]      HTTP_TRANSACTION_DRAIN_BODY_FOR_AUTH_RESTART  [dt=0]
t=121273 [st= 637]      HTTP_TRANSACTION_DRAIN_BODY_FOR_AUTH_RESTART  [dt=0]
t=121273 [st= 637]     +AUTH_SERVER  [dt=537]
t=121273 [st= 637]       +HOST_RESOLVER_IMPL_REQUEST  [dt=1]
                          --> address_family = 0
                          --> allow_cached_response = true
                          --> host = "i2ddev.ab.abc.com:0"
                          --> is_speculative = false
t=121273 [st= 637]          HOST_RESOLVER_IMPL_IPV6_REACHABILITY_CHECK
                            --> cached = true
                            --> ipv6_available = false
t=121273 [st= 637]          HOST_RESOLVER_IMPL_CREATE_JOB
t=121273 [st= 637]          HOST_RESOLVER_IMPL_JOB_ATTACH
                            --> source_dependency = 931 (HOST_RESOLVER_IMPL_JOB)
t=121274 [st= 638]       -HOST_RESOLVER_IMPL_REQUEST
t=121810 [st=1174]     -AUTH_SERVER
t=121810 [st=1174]     +HTTP_TRANSACTION_SEND_REQUEST  [dt=1]
t=121810 [st=1174]        **HTTP_TRANSACTION_SEND_REQUEST_HEADERS**
                          --> GET / HTTP/1.1
                              Host: i2ddev.ab.abc.com
                              Connection: keep-alive
                              Authorization: Negotiate [7424 bytes were stripped]
                              Upgrade-Insecure-Requests: 1
                              User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36
                              Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
                              Accept-Encoding: gzip, deflate, br
                              Accept-Language: en-US,en;q=0.8
                              Cookie: [76 bytes were stripped]
t=121811 [st=1175]     -HTTP_TRANSACTION_SEND_REQUEST
t=121811 [st=1175]     +HTTP_TRANSACTION_READ_HEADERS  [dt=281]
t=121811 [st=1175]        HTTP_STREAM_PARSER_READ_HEADERS  [dt=281]
t=122092 [st=1456]        **HTTP_TRANSACTION_READ_RESPONSE_HEADERS**
                          --> HTTP/1.1 401 Unauthorized
                              Content-Type: text/html
                              Server: 
                              WWW-Authenticate: Negotiate
                              WWW-Authenticate: NTLM
                              strict-transport-security: max-age=31536000
                              X-Frame-Options: SAMEORIGIN
                              X-Content-Type-Options: nosniff
                              X-XSS-Protection: 1; mode=block
                              X-UA-Compatible: IE=edge
                              Date: Thu, 17 Aug 2017 17:19:34 GMT
                              Content-Length: 1293
t=122092 [st=1456]        AUTH_CHANNEL_BINDINGS
t=122092 [st=1456]     -HTTP_TRANSACTION_READ_HEADERS
t=122092 [st=1456]      URL_REQUEST_DELEGATE  [dt=0]
t=122093 [st=1457]      URL_REQUEST_DELEGATE  [dt=0]

It looks like the user provides a Kerberos token but the backend server refuses it.

What is the kerberos configuration you have done on the Active Directory and on the IIS server to make Kerberos works ?

Did you change the DNS name or you just changed the DNS record to point to the VIP ?

What is the configuration of your Virtual Server ?

I saw that NTLM is also supported but require a OneConnect profile and NTLM profile applied on a Virtual Server to make it works through BIG-IP.

I will have to reach out to the app owner to get the AD and IIS kerb config. Will get back to you. I modified local etc/hosts file so FQDN has not changed. Here is the VIP:

ltm virtual i2ddev.ab.abc.com-443-vs {
    destination 10.10.10.1:https
    ip-protocol tcp
    mask 255.255.255.255
    pool i2ddev.ab.abc.com-443-pl
    profiles {
        clientssl-i2ddev.ab.abc.com {
            context clientside
        }
        http { }
        serverssl {
            context serverside
        }
        tcp { }
    }
    source 0.0.0.0/0
    source-address-translation {
        type automap
    }
    translate-address enabled
    translate-port enabled
    vs-index 6
}

Inspecting your VS configuration, you are not using any OneConnect profile nor NTLM profile.

When you are testing in direct (without bigip) the browser use NTLM or Kerberos to authenticate to the backend server ? You can see which proto is used by inspecting Authorization header within client requests.

Maybe you can try to add a OneConnect profile and NTLM profile to allow NTLM proto to works fine.

You can have a look at OneConnect here

here is an extract from the article :

Note: NTLM's HTTP 401 responses prevent the BIG-IP system from detaching the server-side connection. As a result, a late FIN from a previous client connection may be forwarded to a new client that reused the connection, causing the client-side connection to close before the NTLM handshake completes. If NTLM authentication support is desired when using the OneConnect feature, the NTLM profile introduced in BIG-IP 10.0.0 should be configured as well. For more information, refer to the Configuring an NTLM profile chapter in the Configuration Guide for your BIG-IP product.

From what I've read if the header is big and begins with "Y" it's kerberos.

I'll try OneConnect/NTLM, but really want to get kerberos working. Will get back tomorrow with AD/IIS info. Thanks for your help.