Forum Discussion
So does AD auth go through the BIG-IP too, or does the client contact the DC directly and then pass a token/ticket to the app through the F5? If the latter, is the name that clients reference (the FQDN of the F5 VIP) a name that the DC knows? For example, Kerberos is dependent on the servicePrincipalName value. Every Kerberos-enabled service in the domain has an SPN that is registered in the KDC. When a client goes to request access to a service, it first contacts the KDC and requests a ticket for that service using the service's SPN. That SPN is mapped to an encryption key in the KDC, so a ticket is generated, wrapped in the encryption key of the service, wrapped again in the encryption key of the client, and then sent back. The client unwraps the first layer and passes the rest to the service. Because the service has a copy of the same encryption key the KDC used, it can unwrap the next layer and expose the ticket.
When going through a proxy, the client will still attempt to get a ticket, but it will do so using the name it has for the proxy interface. If that VIP FQDN is not the same as the SPN of the service, then the service may get a ticket from the client (through the proxy), but it won't be able to decrypt it. If you look at a wire capture, you should see the client making a port 88 Kerberos request to the KDC (domain controller) and then shoving the encrypted ticket (base64-encoded) into the Authorization header of the next (and subsequent) HTTP requests to the service. If you see that, but the application rejects it, then there's a good bet that the wrong SPN was used.