cancel
Showing results for 
Search instead for 
Did you mean: 

Implementation issues with new software going through F5 load balancer

Andy_01_133092
Nimbostratus
Nimbostratus

We're testing our in house software on a clients site who use F5 load balancer. All their traffic goes through there. They have other applications that work fine through the F5 as well. We're setting up our software to use AD authentication. If we bypass the F5, it works as it should be.

 

If we go through the F5, we get the issue below. Clients have to go through F5, and we ask them to contact F5 for support, but they're not willing to do it since their other applications work fine with it. I need your guidance please.

 

'Server Error in '/Success' Application.

Configuration Error Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.

 

Parser Error Message: The Workstation service has not been started.

 

Source Error:

 

Line 3: Line 4: Line 5: Line 6:

 

Line 7:

 

Source File: C:\Program Files (x86)\Success Enterprise\Success\config\membership.config Line: 5

 

Version Information: Microsoft .NET Framework Version:2.0.50727.5472; ASP.NET Version:2.0.50727.5456 '

 

16 REPLIES 16

Kevin_Stewart
F5 Employee
F5 Employee

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?

 

MVA
Nimbostratus
Nimbostratus

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.

 

Andy_01_133092
Nimbostratus
Nimbostratus

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.

 

Kevin_Stewart
F5 Employee
F5 Employee

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.

 

Andy_01_133092
Nimbostratus
Nimbostratus

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.

 

Kevin_Stewart
F5 Employee
F5 Employee

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?

 

Andy_01_133092
Nimbostratus
Nimbostratus

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.

 

Kevin_Stewart
F5 Employee
F5 Employee

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.

 

Andy_01_133092
Nimbostratus
Nimbostratus

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

 

Kevin_Stewart
F5 Employee
F5 Employee

Is the software local to the domain?

 

Andy_01_133092
Nimbostratus
Nimbostratus

by local, do you mean on the same server as DC or on the network?

 

It is on the same network.

 

Kevin_Stewart
F5 Employee
F5 Employee

Local to the domain, as in running on a domain member machine and has direct access to the KDC/domain controller to request Kerberos tickets - without having to go through the F5 to do that.

 

Andy_01_133092
Nimbostratus
Nimbostratus

I have to check to see if it was on the same domain, but the client is requesting it to go through the F5, we can't do direct access to DC. This is the only way according to the client, otherwise, they don't want it setup.

 

Kevin_Stewart
F5 Employee
F5 Employee

Just consider that I'm not talking about direct access to everything, just the DC communication. I'm assuming there's another (application) server somewhere in this equation that is the endpoint of all of this, and that the DC is only needed for authentication requests. If at all possible, it would be easiest to allow application traffic through the F5 and have the client software talk to the DC directly. If the client is a non-Windows, non-domain member piece of software that is capable of Kerberos authentication, then it's still technically possible to route this traffic through a proxy, but you still need DNS resolution, a path for port 88 Kerberos traffic, and probably a keytab or two accessible to the software.

 

Just out of curiosity, does the application support any other form of authentication, like Basic?

 

Andy_01_133092
Nimbostratus
Nimbostratus

yes it does, but the client is requesting AD authentication for their purpose. This issue is coming from our development team and I'm the main IT guy whom they're requesting assistance from. Yes, I've been told that that the software is install on the application server that needs to go through the F5 to get to dc (REQUIRED by client). Hopefully, with the packet capture, it'll be clearer for you guys to assist.

 

Thank you.

 

nitass
F5 Employee
F5 Employee

just wondering how virtual server is configured. are you using one virtual server (e.g. network or wildcard virtual server) to handle AD traffic and another virtual server to handle application traffic?