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.
Line 3: Line 4: Line 5: Line 6:
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 '
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.
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.
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.
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?
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.
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?