Multiple Windows Authentication Prompts after F5 Authentication

the important thing to understand is where the subsequent authentication prompts are coming from. Assuming domain-joined clients are silently passing in an NTLM token (or even Kerberos ticket), then it would make sense that the application server is prompting for these credentials. Are you using APM? And if so, are you performing any SSO functions to the application server(s)?

APM Kerberos SSO will only intercept the 401 if you have the Send Authorization setting in the Kerberos SSO profile set to "On 401 Status Code". The "Always" option will send a preemptive Kerberos ticket. In either case, SSO must know how to retrieve a ticket to a give service, which is where I believe the problem lies. Before digging into the ugly details, let's establish that a service must be associated with a declared by a unique** service principal name (SPN), that SSO must be able to derive/find this SPN, and that the AD delegation account be able to delegate to that SPN. So in your SSO,

1. Do you have a SPN pattern defined?
2. Does the target service have a defined and unique SPN?
3. Does the hostname in that SPN reverse resolve in AD DNS?

@Kevin: I've tested to make sure that the SSO profile should work by creating a basic VIP with a basic access policy that uses it (not portal access policy though) and it's working fine. If I turn the SSO log level to Debug I can see where the Kerberos SSO profile is selected, and all the other pertinent logs are there:

Feb  8 14:21:58 xxxxx debug websso.1[99999]: 99999999:9: ssoMethod: kerberos usernameSource: session.logon.last.username userRealmSource: session.ad.last.actualdomain Realm: EXAMPLE.COM KDC:  AccountName: host/kerberos_test_user.EXAMPLE.COM@EXAMPLE.COM spnPatterh: HTTP/%s@EXAMPLE.COM TicketLifetime: 600 UseClientcert: 0 SendAuthorization: 0
Feb  8 14:21:58 xxxxx info websso.1[99999]: 99999999:9: 129e9c1a: Websso Kerberos authentication for user 'user_name' using config '/Common/KERBEROS_SSO_PROFILE'
Feb  8 14:21:58 xxxxx debug websso.1[99999]: 99999999:9: sid:129e9c1a ctx:0x5a8c1120 SPN = HTTP/server_name.EXAMPLE.COM@EXAMPLE.COM
Feb  8 14:21:58 xxxxx debug websso.1[99999]: 99999999:9: S4U ======> ctx: 129e9c1a, sid: 0x5a8c1120, user: user_name@EXAMPLE.COM, SPN: HTTP/server_name.EXAMPLE.COM@EXAMPLE.COM
Feb  8 14:21:58 xxxxx debug websso.1[99999]: 99999999:9: Getting UCC:user_name@EXAMPLE.COM@EXAMPLE.COM, lifetime:36000
Feb  8 14:21:58 xxxxx debug websso.1[99999]: 99999999:9: Found UCC:user_name@EXAMPLE.COM@EXAMPLE.COM, lifetime:36000 left:30505
Feb  8 14:21:58 xxxxx debug websso.1[99999]: 99999999:9: S4U ======> - we have cached S4U2Proxy ticket for user: user_name@EXAMPLE.COM server: HTTP/server_name.EXAMPLE.COM@EXAMPLE.COM
Feb  8 14:21:58 xxxxx debug websso.1[99999]: 99999999:9: S4U ======> OK!
Feb  8 14:21:58 xxxxx debug websso.1[99999]: 99999999:9: GSSAPI: Server: HTTP/server_name.EXAMPLE.COM@EXAMPLE.COM, User: user_name@EXAMPLE.COM
Feb  8 14:21:58 xxxxx debug websso.1[99999]: 99999999:9: GSSAPI Init_sec_context returned code 0
Feb  8 14:21:58 xxxxx debug websso.1[99999]: 99999999:9: GSSAPI token of length 2834 bytes will be sent back

However, when I try to hit the site through the other access policy (portal access with url rewriting), the only related log entries are:

Feb  8 14:21:26 xxxxx debug websso.1[99999]: 99999999:9: ssoMethod: kerberos usernameSource: session.logon.last.username userRealmSource: session.ad.last.actualdomain Realm: EXAMPLE.COM KDC:  AccountName: host/kerberos_test_user.EXAMPLE.COM@EXAMPLE.COM spnPatterh: HTTP/%s@EXAMPLE.COM TicketLifetime: 600 UseClientcert: 0 SendAuthorization: 0
Feb  8 14:21:26 xxxxx info websso.1[99999]: 99999999:9: d35aac43: Websso Kerberos authentication for user 'user_name' using config '/Common/KERBEROS_SSO_PROFILE'

One of the only differences here I guess would be that on the test VIP it's defaulting to the kerberos sso profile and the VIP is using the ssrs pool to send traffic. On the portal access VIP (that's failing), it's using a hostname (f5-w-xyz$$) for a VIP that uses that same pool. Not sure if that makes a difference.

To answer you questions though:

1. I don't have an SPN pattern defined, so it's just using the default.
2. The target VIP that's load balancing the multiple servers has an associated hostname (which I'm allowing the delegation account access to)
3. That hostname does resolve in DNS to the F5 VIP.

I did add the hostname to the F5 hosts file so it could do a reverse lookup to the F5 VIP. Then I began getting a little further...

Feb  8 15:40:05 xxxxx debug websso.1[99999]: 99999999:9: different sso config object received, name: /Common/KERBEROS_SSO_PROFILE, method: 5
Feb  8 15:40:05 xxxxx debug websso.1[99999]: 99999999:9: ssoMethod: kerberos usernameSource: session.logon.last.username userRealmSource: session.ad.last.actualdomain Realm: EXAMPLE.COM KDC:  AccountName: host/kerberos_test_user.EXAMPLE.COM@EXAMPLE.COM spnPatterh: HTTP/%s@EXAMPLE.COM TicketLifetime: 600 UseClientcert: 0 SendAuthorization: 1
Feb  8 15:40:05 xxxxx info websso.1[99999]: 014d0014:6: 5634e025: Found HTTP 401 response for SSO configuration '/Common/KERBEROS_SSO_PROFILE' type:'kerberos'
Feb  8 15:40:05 xxxxx info websso.1[99999]: 014d0011:6: 5634e025: Websso Kerberos authentication for user 'user_name' using config '/Common/KERBEROS_SSO_PROFILE'
Feb  8 15:40:05 xxxxx debug websso.1[99999]: 014d0023:7: S4U ======> ctx: 5634e025, sid: 0x5a8472b0, user: user_name@EXAMPLE.COM, SPN: HTTP/ssrs.domain.com@EXAMPLE.COM
Feb  8 15:40:05 xxxxx debug websso.1[99999]: 99999999:9: S4U ======> - NO cached S4U2Proxy ticket for user: user_name@EXAMPLE.COM server: HTTP/ssrs.domain.com@EXAMPLE.COM - trying to fetch
Feb  8 15:40:05 xxxxx debug websso.1[99999]: 99999999:9: S4U ======> trying to fetch S4U2Proxy ticket for user: user_name@EXAMPLE.COM server: HTTP/ssrs.domain.com@EXAMPLE.COM

But after this, I don't see anything else relating kerberos.

It's very likely then that the SSO is unable to derive the correct SPN for the target service. One option would be to create a separate VIP+SSO+access policy per portal site and then point the portal config at these VIPs. That way you can specifically define SPNs per application using a SPN pattern.

But then a DNS PTR record may also solve the problem. ;)

Okay, so there are few things to consider here:

1. First and foremost APM needs to know what the SPN is for each target application. You can either set this manually with the SPN pattern in the SSO profile, or in lieu of that APM will perform a reverse DNS lookup using the server's IP address to get its hostname (ex. server1.domain.com) and then convert that to a SPN (ex. http/server1.domain.com@DOMAIN.COM). If you don't see the correct SPN in the APM log, then that's very likely the first problem.

    

2. APM is going to perform Kerberos constrained delegation and protocol transition to the target application through a separate delegation account. This account should a) be set to "Trust this user for delegation to specified services only" and "use any authentication protocol", and b) have defined all of the HTTP SPNs for the applications that it will delegate to.

    

I assume that the SSO profile is going to create the ticket then for ssrs.example.com, right (http/ssrs.example.com SPN)?

It should, yes.

Is there a way to get APM to use the pool member instead of the VIP's hostname for the service son?

That's actually how it's designed to work. In the absence of an SPN Pattern in the Kerberos SSO profile, APM will reverse resolve the pool member IP and derive the SPN from the returned host name. If there is no reverse record for a given IP, you can also wire up each pool member IP to a local Hosts entry on the BIG-IP and use the %s wildcard in the SPN pattern:

http/%s

Thanks @Kevin,

After what you just said I tested something, just to see if it would work.

• Reference:
  • APM Portal Access (
  • SSRS VIP ( (accessed by https://apm.domain.com/f5-w-687474703A2F2F737372732E6578616D706C652E636F6D$$/)
  • Pool Members (

With the SSO profile set to the default SPN, APM tries to feth S4UProxy ticket for the user and server = http/ssrs.example.com@INTERNAL.LOCAL and I never see the

S4U ======> OK!

However, if I update the SPN to user one of the servers instead (http/server1.internal.local) then it works and I see everything inspect in the logs. This seems to work on any of the pool members (not just server1).

So for some reason using ssrs.example.com doesn't work, but manually specifying an spn for one of the servers does... Does that make any sense to you? Trying to figure out why it would fail. (The service account running SSRS has the SPN associated with it for HTTP/ssrs.example.com and HTTP/server1.example.com and the other pool members). Does that account need Delegation specified on it?

Thanks for you help!

You absolutely do need the APM delegation account to have the http/ssrs.example.com SPN included. I'm assuming you already have the individual server SPNs in the delegation list (else they wouldn't work either). So, the account running SSRS, is it one single account in the AD that's running all of the SSRS services on a all of the servers? The fact that http/server1.example.com works, but http/ssrs.example.com doesn't sort of suggests that the SSRS service is actually owned by the local system and not this other account.

The AD delegation account (host/kerberos_user) must have the SPN of each and every account that it is allowed to delegate to. You've indicated that the pool members' individual SPNs are assigned, but if you're attempting to request a ticket for http/ssrs.example.com, then that SPN also needs to be in the delegation list. But more important, if Kerberos SSO works when specifying the server SPN (server1.example.com), that's a good indication that the ssrs account is indeed not the owner of the service.