F5 BigIP LTM 6900

There are a number of solutions depending on your Citrix environment. I haven't done any of this with Presentation Server 4.5, but the absolute easiest configuration involves 11.4 and APM replacing the Web Interface. Do you have APM, and would you want to replace WI?

Which version? I assume you're using the Kerberos SSO option in the Citrix remote desktop resource agent? If so, turn up the APM SSO logs to debug and tell me what you see when you try to connect to the app.

Kevin,

I'm working with Al on this issue. I set the APM logs to debug and compared the output with our working site and they appear the same. I see the authentication take place and the webpage icons being transferred. When I click on an applicaiton I see three GET requests for launch.ica. The user/pass authenticated site then opens the client and connects while the Kerberos SSO site only sits and spins in chrome and does nothing in IE. Below is the APM log starting after the Policy completes and I click on an application for each of the sites.

user/pass site: Feb 26 10:59:41 rca-fs-fscbip02 debug tmm[13024]: 01490000:7: Request (GET /f5vdi/citrix/ica/QUZGU0NfWEFfNjUjQUFBQUFBOkNpdHJpeCBBcHAgQ2VudGVy/launch.ica?0.05834986548870802 HTTP/1.1 Host: citrixgw2.domain.com Connection: keep-alive Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 DNT: 1 Referer: https://citrixgw2.domain.com/vdesk/webtop.eui?webtop=/Common/Citrix-SG1.app/citrix_webtop&webtop_type=webtop_full Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Cookie: F5_VDI_e259a1b4=0; F5_VDI_30d5e773=0; F5_VDI_88a14d50=0; F5_VDI_bfe0adec=0; F5_VDI_bb12c60c=0; F5_VDI_41d27baf=0; F5_VDI_c82d89c2=0; F5_VDI_99a8f620=0; F5_VDI_34014abe=0; F5_VDI_e0b82482=0; F5_VDI_f6decc44=0; F5_VDI_64fd6f4d=0; F5_VDI_9d0c678c=0; F5_VDI_a4d30fa9=0; F5_VDI_52a171c2=0; F5_VDI_7e0490e9=0; TIN=900000; LastMRH_Session=f58fb010; MRHSession=ce85f46094 Feb 26 10:59:41 rca-fs-fscbip02 debug tmm[13024]: 01490000:7: Client-type (apm-webtop) Feb 26 10:59:41 rca-fs-fscbip02 debug tmm[13024]: 01490000:7: Request GET /f5vdi/citrix/ica/QUZGU0NfWEFfNjUjQUFBQUFBOkNpdHJpeCBBcHAgQ2VudGVy/launch.ica?0.05834986548870802 HTTP/1.1 Host: citrixgw2.domain.com Connection: keep-alive Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 DNT: 1 Referer: https://citrixgw2.domain.com/vdesk/webtop.eui?webtop=/Common/Citrix-SG1.app/citrix_webtop&webtop_type=webtop_full Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Cookie: F5_VDI_e259a1b4=0; F5_VDI_30d5e773=0; F5_VDI_88a14d50=0; F5_VDI_bfe0adec=0; F5_VDI_bb12c60c=0; F5_VDI_41d27baf=0; F5_VDI_c82d89c2=0; F5_VDI_99a8f620=0; F5_VDI_34014abe=0; F5_VDI_e0b82482=0; F5_VDI_f6decc44=0; F5_VDI_64fd6f4d=0; F5_VDI_9d0c678c=0; F5_VDI_a4d30fa9=0; F5_VDI_52a171c2=0; F5_VDI_7e0490e9=0; TIN=900000; LastMRH_Session=f58fb010; MRHSession=ce85f460941 Feb 26 10:59:41 rca-fs-fscbip02 debug tmm[13024]: 01490000:7: Request GET /f5vdi/citrix/ica/QUZGU0NfWEFfNjUjQUFBQUFBOkNpdHJpeCBBcHAgQ2VudGVy/launch.ica?0.05834986548870802 HTTP/1.1 Host: citrixgw2.domain.com Connection: keep-alive Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 DNT: 1 Referer: https://citrixgw2.domain.com/vdesk/webtop.eui?webtop=/Common/Citrix-SG1.app/citrix_webtop&webtop_type=webtop_full Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Cookie: F5_VDI_e259a1b4=0; F5_VDI_30d5e773=0; F5_VDI_88a14d50=0; F5_VDI_bfe0adec=0; F5_VDI_bb12c60c=0; F5_VDI_41d27baf=0; F5_VDI_c82d89c2=0; F5_VDI_99a8f620=0; F5_VDI_34014abe=0; F5_VDI_e0b82482=0; F5_VDI_f6decc44=0; F5_VDI_64fd6f4d=0; F5_VDI_9d0c678c=0; F5_VDI_a4d30fa9=0; F5_VDI_52a171c2=0; F5_VDI_7e0490e9=0; TIN=900000; LastMRH_Session=f58fb010; MRHSession=ce85f460941 Feb 26 10:59:59 rca-fs-fscbip02 notice tmm3[13025]: 01490521:5: 7e0490e9: Session statistics - bytes in: 18721, bytes out: 11914

Kerberos Site: Feb 26 10:58:19 rca-fs-fscbip02 debug tmm2[13025]: 01490000:7: Request (GET /f5vdi/citrix/ica/QUZGU0NfWEFfNjUjQUFBQUFBOkNhbGM2NQ/launch.ica?0.03865986783057451 HTTP/1.1 Host: citrixgw2.domain.com Connection: keep-alive Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 DNT: 1 Referer: https://citrixgw2.domain.com/vdesk/webtop.eui?webtop=/Common/CitrixGW2_Webtop&webtop_type=webtop_full Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Cookie: F5_VDI_e259a1b4=0; F5_VDI_30d5e773=0; F5_VDI_88a14d50=0; F5_VDI_bfe0adec=0; F5_VDI_bb12c60c=0; F5_VDI_41d27baf=0; F5_VDI_c82d89c2=0; F5_VDI_99a8f620=0; F5_VDI_34014abe=0; F5_VDI_e0b82482=0; F5_VDI_f6decc44=0; F5_VDI_64fd6f4d=0; F5_VDI_9d0c678c=0; F5_VDI_a4d30fa9=0; F5_VDI_52a171c2=0; LastMRH_Session=7e0490e9; MRHSession=048facd0db6b902c8f0ed3c67e0490e9; F5_fullWT=1; F5_VDI_7e0490e9=0; Feb 26 10:58:19 rca-fs-fscbip02 debug tmm2[13025]: 01490000:7: Client-type (apm-webtop) Feb 26 10:58:19 rca-fs-fscbip02 debug tmm2[13025]: 01490000:7: Request GET /f5vdi/citrix/ica/QUZGU0NfWEFfNjUjQUFBQUFBOkNhbGM2NQ/launch.ica?0.03865986783057451 HTTP/1.1 Host: citrixgw2.domain.com Connection: keep-alive Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 DNT: 1 Referer: https://citrixgw2.domain.com/vdesk/webtop.eui?webtop=/Common/CitrixGW2_Webtop&webtop_type=webtop_full Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Cookie: F5_VDI_e259a1b4=0; F5_VDI_30d5e773=0; F5_VDI_88a14d50=0; F5_VDI_bfe0adec=0; F5_VDI_bb12c60c=0; F5_VDI_41d27baf=0; F5_VDI_c82d89c2=0; F5_VDI_99a8f620=0; F5_VDI_34014abe=0; F5_VDI_e0b82482=0; F5_VDI_f6decc44=0; F5_VDI_64fd6f4d=0; F5_VDI_9d0c678c=0; F5_VDI_a4d30fa9=0; F5_VDI_52a171c2=0; LastMRH_Session=7e0490e9; MRHSession=048facd0db6b902c8f0ed3c67e0490e9; F5_fullWT=1; F5_VDI_7e0490e9=0; F Feb 26 10:58:19 rca-fs-fscbip02 debug tmm2[13025]: 01490000:7: Request GET /f5vdi/citrix/ica/QUZGU0NfWEFfNjUjQUFBQUFBOkNhbGM2NQ/launch.ica?0.03865986783057451 HTTP/1.1 Host: citrixgw2.domain.com Connection: keep-alive Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 DNT: 1 Referer: https://citrixgw2.domain.com/vdesk/webtop.eui?webtop=/Common/CitrixGW2_Webtop&webtop_type=webtop_full Accept-Encoding: gzip,deflate,sdch Accept-Language: en-US,en;q=0.8 Cookie: F5_VDI_e259a1b4=0; F5_VDI_30d5e773=0; F5_VDI_88a14d50=0; F5_VDI_bfe0adec=0; F5_VDI_bb12c60c=0; F5_VDI_41d27baf=0; F5_VDI_c82d89c2=0; F5_VDI_99a8f620=0; F5_VDI_34014abe=0; F5_VDI_e0b82482=0; F5_VDI_f6decc44=0; F5_VDI_64fd6f4d=0; F5_VDI_9d0c678c=0; F5_VDI_a4d30fa9=0; F5_VDI_52a171c2=0; LastMRH_Session=7e0490e9; MRHSession=048facd0db6b902c8f0ed3c67e0490e9; F5_fullWT=1; F5_VDI_7e0490e9=0; F

Kevin,

I just tried it again and noticed the two new log entries Feb 26 12:04:26 rca-fs-fscbip02 err vdi[3148]: 01490000: {47a.C} DB: error: SessionDB:18 Feb 26 12:04:26 rca-fs-fscbip02 err vdi[3148]: 01490000: {47a.C} Remote Desktop '': failed to handle '/f5vdi/citrix/ica/': SessionDB:18

Interesting. I've experienced the "err vdi" message before on 11.4 and 11.5 and have an open case on it. That's why I asked to set APM SSO to debug. Before I suggest opening a new case to coincide with what I've seen, let's review some of the baseline required configurations:

Virtual server:

• HTTP profile
• Client SSL profile
• SNAT (as required)
• Access Profile (your access policy - reviewed next)
• Connectivity Profile (default settings are fine)
• VDI & Java Support option checked

Citrix Remote Desktop profile:

• Destination: Host Name or IP Address (there is an issue with using a pool - not sure if it's fixed yet - for now point it at a single XenApp server)
• Auto Logon: Enable
• Broker Authentication: Kerberos
• Kerberos SSO configuration (your Kerberos SSO profile)

Access Profile (VPE):

• Given that this is for DoD CAC, I'm assuming you've created some process to query the AD for userPrincipalName to get the sAMAccountName for the Kerberos SSO.
• Advanced Resource Assign:
  • A simple webtop
  • Your Citrix remote desktop resource

XenApp servers:

• IIS CtxAdminPool and CtxScriptsPool application pools set to use LocalSystem (CTX130480)
• IIS authentication for Default Web Site set to Windows Authentication only (Anonymous not required)
• XenApp Hotfix rollup 3
• The following registry entry (CTX124603)
  • HKLM\SYSTEM\CurrentControlSet\Control\TerminalServer
  • IgnoreRegUserConfigErrors (DWORD) = 1
• XenApp global policy enabled for "Trust XML requests"

Domain controller:

• XenApp servers set to delegate HTTP/ and HOST/ to themselves, HTTP/ to other XenApp servers, and CIFS/ and LDAP/ to the domain controllers, using the "use Kerberos only" delegation option (CTX124603)

This is the absolute minimum requirement for XenApp with Kerberos SSO (although I didn't list specific Kerberos SSO settings), so you may have additional configurations. You're also getting the application list, so I have to assume that Kerberos SSO is working. If your settings are more or less the same as mine, I'd go ahead and open a new case as this is likely similar to an existing/known issue.

I'm a bit confused now. You said this is for (DoD) CAC authentication, but then you're apparently doing client side Kerberos auth. You don't have an SSO profile applied to the access policy? You're not using "IIS-integrated" mode on the XML broker(s)?

I do have a Kerberos SSO profile applied to the policy (which doesn't seem to be doing anything) but I use a Kerberos AAA profile in the access policy. I'm guessing this is the main point where I'm going wrong.

I see. The Kerberos AAA, Kerberos Auth agent, and 401 agent are for client side Kerberos, where the client can retrieve its own Kerberos ticket from a local KDC. I'm assuming that's not your intention. Server side Kerberos is controlled via the Kerberos SSO profile applied to the access policy.

Is Citrix XML broker IIS integration a requirement for CAC authentication? I don't remember seeing that anywhere. It's easy enough to setup and there isn't any reason I can't go that way.

It's sadly not documented anywhere (publicly) that I know of, but in order to authenticate to an XML broker with anything other than user/pass, you need to enable IIS-integration.

So, if I understand what needs to happen: I need to drop the client side (401 response) method and request a certificate from the user. Then take that cert's SAN and map it to the user's UPN in AD using a Kerberos SSO policy? Am I thinking correctly on this?

Sort of. Here's a play-by-play of how it would work:

1. APM configured with On-Demand Cert Auth agent to collect the client certificate (you could also skip this and request the cert in the client SSL profile).

2. APM then extracts the UPN from the cert. The easiest way to do this is with an iRule agent in the VPE (right after ODCA):

3. Because you're using a (DoD) CAC, the UPN in the cert(s) will not match the UPN in the AD. To complicate that further, because APM is not officially a member of the Windows domain, it cannot participate in the Enterprise Canonical Naming mechanism that AD uses when an AD client uses an alternate UPN suffix. It's like a CNAME for Kerberos that tells the client/server which domain the user belongs to based on a GC query. In other words, the UPN on the cert is EDIPI@mil, and even though you've established "mil" as an alternate UPN suffix in the AD domain, APM will not follow the redirect. To get around this behavior, you use a rather simple trick of performing a quick LDAP or AD query (LDAP is faster) with the cert UPN to fetch the user's sAMAccountName.

   LDAP SearchFilter: userPrincipalName=%{session.cert.upn}
   

4. You then apply the SAM value as the username source in your Kerberos SSO profile, and then apply the Kerberos SSO profile to the Citrix remote desktop config. Assuming all of the other Kerberos stuff is configured correctly, this is how you authenticate to the XML broker.

   Kerberos SSO Username Source: session.ldap.last.attr.sAMAccountName
   

5. Apply all of the settings from my previous post and you should be good to go. If you run into Kerberos issues, we can address those afterwards.

Okay, this is a Kerberos issue. A few things to check:

Configuration:

1. Create a user account in the AD to serve as the delegation service account. For the User Logon Name, create an arbitrary SPN value (ex. host/krb-sso.realm.com). The pre-Windows 2000 name doesn't matter. Copy this SPN as you'll need it later.

    

2. If you right click on the tree in AD Users and Computers, you'll see an option to set View to Advanced. Once you've done that, open up the account you just created. You should see an Attribute Editor tab now. Go to that tab, find the servicePrincipalName field, and add the SPN from before to this field.

    

3. Close and re-open the account properties. By virtue of the servicePrincipalName value, you should now see a Delegation tab. Go to that tab, select "Trust this user for delegation to specified services only", and "Use any authentication protocol". Now find and select the HTTP/ SPN of the XML broker(s) in the delegation window.

    

4. In the Kerberos SSO profile, you should already have session.ldap.last.attr.sAMAccountName as the Username Source. In the Account Name field, paste the same SPN value from before.

    

Troubleshooting:

1. Verify time skey - no more than 5 minutes usually, but better to be in sync.

    

2. Verify that the BIG-IP can resolve both forward (A) and reverse (PTR) for the DOMAIN itself, and all of the XML brokers.

    

3. In the BIG-IP shell, edit (vi) the /etc/krb5.conf file. Arguably this shouldn't be necessary, but I've already seen it cause problems on a few 1.4 and 11.5 systems. Set the dns_lookup_realm value to false, set the dns_lookup_kdc value to true, set the default_realm value to your local REALM (all uppercase), and remove all references to EXAMPLE.COM.

    

4. Verify that there are no duplicate SPNs in the AD (setspn -x).

    

You also mentioned that you don't have HF3 on XenApp yet. If this is for 6.5, make sure that you at least have XA650W2K8R2X64025. And finally, if all else fails, install WireShark on the DC, as this will be the very best way to troubleshoot Kerberos errors.

We already have this account already created. I do have a question about this though:

The AD user service account used for delegation needs the user logon name (UPN) to be a SPN value (ex. host/krb-svc.domain.com). You don't need to specify the additional @REALM in the name, because that's already implied in the drop down box to the right. The servicePrincipalName attribute in this account should be the same value. There was a time when things could go wrong if the SPN wasn't all lower case, but not sure if that's a factor anymore. I'm also not sure if the $ sign would cause a problem. I've not tested that.

I don't have access to the AD user and computers but when I query the user I get the following properties: TrustedForDelegation : True TrustedToAuthForDelegation : False I think I mentioned before that we set the user up for unconstrained delegation. This should provide the same delegation rights, just be less secure, correct?

The delegation service account MUST BE SET to "Trust this user for delegation to specified services only", and "Use any authentication protocol" with constrained delegation to the specified HTTP/ SPNs of the XML brokers. APM Kerberos SSO actually does Protocol Transition, which requires constrained delegation.

yes, the Kerberos SSO is set to use the session.ldap.last.attr.sAMAccountName as the Username Source. I was able to see the mapping in the SSO log. However, the SSO log did show this line which had me worried until it continued on and found the UCC Feb 28 15:15:23 BIP02 debug websso.3[18866]: 014d0001:7: ssoMethod: kerberos usernameSource: session.ldap.last.attr.sAMAccountName userRealmSource: session.logon.last.domain Realm: REALM.NAME.COM KDC: AccountName: host/$service.account.name.domain.name.com spnPatterh: HTTP/%s@REALM.NAME.COM TicketLifetime: 600 UseClientcert: 0 SendAuthorization: 0 The pattern had a variable in it instead of a service name. Does this need to be fixed?

This SPN pattern in the log is normal. I assume you don't have any value in the SPN Pattern block in the Kerberos SSO profile?

Let's validate a few settings:

1. IIS CtxAdminPool and CtxScriptsPool application pools set to use LocalSystem (CTX130480)

2. IIS authentication for Default Web Site set to Windows Authentication only (Anonymous not required)

3. XenApp Hotfix rollup 3 - you need at least XA650W2K8R2X64025

4. The following registry entry (CTX124603)

   HKLM\SYSTEM\CurrentControlSet\Control\TerminalServer
       IgnoreRegUserConfigErrors (DWORD) = 1
   

5. XenApp global policy enabled for "Trust XML requests"

6. The XML brokers must be configured to delegate HTTP and HOST to themselves, HOST to all other XenApp servers, and CIFS and LDAP to the DCs (Use Kerberos only)

7. The XenApp servers must be configured to delegate HOST to themselves, CIFS and LDAP to the DCs, and HTTP to the XML brokers

This should be the bare minimum configuration required. Are you testing with a browser or Receiver directly?