Implementation issues with new software going through F5 load balancer

Can you elaborate on what the application is attempting to do and how it works?

Are you simply layer 4 (IP) load balancing through the F5? Or applying any application logic?

Are you terminating SSL at the F5?

Is AD authentication in the form of NTLM or Kerberos?

I agree with the previous response asking for more information but I'd like to throw out I've resolved an in-house app issue on the F5 that uses AD for authentication; enable persistence, we used source-address.

This is a shot from the hip, so more information is needed to accurately troubleshoot; VIP configuration, tcpdumps showing application behavior, etc, etc.

It connects to the domain controller to do ad authentication for access to the program, that's all. If we bypass F5, works fine. It will default to kerberos and fall back to NTLM if kerberoes fail. I think we're just going through the F5, no other logic involve.

SSl is involve. We did a packet capture and everything shows it connecting fine. As not having the F5 in front of us, Mel, you configure those on the F5?

Thanks again guys for the response.

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.

No, if our software connects directly to DC, everything works fine. AD authentication and such.

But if we go through the F5 to get to dc, that's when it fails. No passing of token.

But if we go through the F5 to get to dc, that's when it fails. No passing of token.

And that's the nature of my first question. Does the client actually have to go through the F5 to get to the DC or does it just use the F5 to get to the app? When you're talking about Kerberos specifically, the client will make at least TWO requests - one to the KDC (an accessible domain controller in its environment), and then the other to the application. Have you defined, or do you require that the client attempt to contact the domain controller through the F5? Are these local clients that would otherwise already have access to the KDC, locally?

Is this a simple load balancing VIP, or are you establishing an SSL VPN?

I don't really know the nature of the F5 setup. But they're just using the F5 for load balancing. We don't have to go through the F5 to get to DC, that's not the requirement, but the client want the software to go through the F5 to get to the dc.

but the client want the software to go through the F5 to get to the dc

Still struggling to understand this part. If we're strictly talking Kerberos here, the client (presumably internal) has direct access to the KDC and can make Kerberos requests for services. The client in this case is either a user and a browser or some piece of software. Once the client receives the Kerberos ticket, it forwards that to the server it wants to talk to. If that's the scenario that you're referring to, then it makes sense that it works without the F5 and not with the F5 - because invariably the name that you use to access the F5 virtual server is not the name/SPN of the server BEHIND the F5. There's nothing special about the F5 setup. It should simply pass that request (and ticket) through the virtual server to the back end service.

If, for whatever reason, you need the client software to access the domain controller THROUGH the F5, then there's a lot more involved. At the very least the client accesses the KDC on port 88. Other services like RPC, NetBIOS, and DNS use other ports. It isn't impossible, but it's not fun trying to proxy AD domain traffic. I'm hoping this is not what you're trying to do.

The bottom line is that you need to understand what the application is trying to accomplish, and how it's trying to do it - who it needs to talk to and how it communicates.

A packet capture will help.

Yes, the software needs to access the domain controller THROUGH the f5. I will try to post up a packet capture soon. Thanks

Is the software local to the domain?