Forum Discussion
AltostratusFastL4 VS not passing the SSO credentials properly
I have a FastL4 virtual server with SSL pass-through to the application server.
When I go directly to the application server, SSO is working properly. When I go through the F5 vs, the user is prompted for credentials.
This guest is not running APM, and turning it on is not an option.
I assume that when the guest is proxying to the application server, Kerberos is being altered.
ltm virtual /Common/mytestapp.example.com-443-vs {
destination /Common/192.168.44.140:0
ip-protocol tcp
mask 255.255.255.255
pool /Common/mytestapp.example_443_pool
profiles {
/Common/apm-forwarding-fastL4 { }
}
source 0.0.0.0/0
source-address-translation {
type automap
}
translate-address enabled
translate-port disabled
}
ltm pool /Common/mytestapp.example.com_443_pool {
load-balancing-mode least-connections-member
members {
/Common/dc01server.example.com:443 {
address 10.10.10.167
}
/Common/dc02server.example.com:443 {
address 10.20.20.229
}
}
monitor min 1 of { /Common/mytestapp.example.com_https_monitor }
}
ltm monitor https /Common/mytestapp.example.com_https_monitor {
adaptive disabled
cipherlist DEFAULT:+SHA:+3DES:+kEDH
compatibility enabled
defaults-from /Common/https
destination *:*
interval 5
ip-dscp 0
recv "Running as primary"
recv-disable "Running as standby"
send "GET /ha/health-check HTTP/1.1\r\nHost: mytestapp.example.com\r\nConnection: Close\r\n\r\n"
time-until-up 0
timeout 16
}
- Kevin_Stewart
Employee
If I may add,
You can absolutely shuttle Kerberos traffic through a non-APM LTM VIP. The biggest issue you run into though is definition of the service principal name.
For (browser-based) Kerberos to work, a client makes a request to a web server that first responds with a 401 "Authenticate" response. The client then goes directly to a KDC and requests a Kerberos ticket for this service. The server, however, doesn't tell the client its name, so the browser derives the service's name from the URL. If the URL is https://mysite.localdomain.com, then the Kerberos service principal name (SPN) is HTTP/mysite.localdomain.com.
You have two servers in a pool, presumably named "dc01server.example.com" and "dc02server.example.com". And if you're VIP resolves to a different name, then that's the name the browser (incorrectly) requests a ticket for. You have a few options here:
-
Create an AD service account, give it the VIP's name as its servicePrincipalName attribute (ex. https://mysite.localdomain.com = HTTP/mysite.localdomain.com), and if these are IIS servers, assign this AD account as the owner of the IIS application pools on both boxes. So basically, both IIS services are owned by the same AD account, and that account's SPN is the same as what the client will request a ticket for.
-
Deploy APM. APM performs the delegation and handles all of this for you.
-
Hi There,
Assuming the HTTP 401 is getting back to the client, how are you testing this? Direct browsing to VS IP? HOSTS file?
Dan
ZukeCirrostratus
Dan, thanks for your reply.
I'm updating my hosts file to point https://mytestapp.example.com to the F5 VS.
When I go through the F5 VS, I get prompted for login credentials.
When I browse to the FQDN of the active application server, https://dc01server.example.com, I'm immediately directed to an Access Denied splash page.
When I update my hosts file to point https://mytestapp.example.com to the application server, I also get prompted for login credentials.
I asked the application owner for the server's SSO settings:
- Kevin_Stewart
What application is this? And are sure you're doing Kerberos?
You should expect the server to respond with a 401, and inside the 401 "Unauthorized" response will be a header called "WWW-Authenticate" with a value of Negotiate, NTLM, Basic, or some combination of these. But what's more important is what the browser does next. You can see this in a Wireshark capture. The browser will either contact a KDC (Kerberos key distribution center) for a ticket, or respond with an NTLM challenge-response, or respond with an encoded Basic authorization header. If it is indeed Kerberos, the initial request to the KDC must include the service's servicePrincipalName (SPN). This is the SPN of the service that owns the application resources.
You need to find out what AD account is assigned to the dc01server.example.com and dc02server.example.com services, and the SPN of that account. Right now you're making a request to https://mytestapp.example.com, getting an expected 401 response from the backend servers, and the browser is trying to get a ticket for HTTP/mytestapp.example.com. If that's not correct, the browser will prompt you for login credentials.
- Zuke
CloudBees Jenkins Enterprise, and yes I was told this was using Kerberos.
I did a tcpdump on the guest and captured the initial connection. I've added the SSL cert/key to Wireshark, but it is not decrypting the application data, so I'm not seeing the data in the packets.
- Kevin_Stewart
The Kerberos traffic to the KDC happens in the clear so you should be able to see that in Wireshark without a key. Also if you do a Fiddler capture in the browser, you can see the 401 response and what the browser sends back. It’ll either be a Kerberos ticket, NTLM token, or encoded Basic user:pass.
- Kevin_Stewart
And it’s likely not decrypting the traffic because you’re probably not negotiating an RSA cipher (ex. AES256-SHA256). Diffie-Hellman and Elliptic Curve ciphers cannot be decrypted in Wireshark.
