Horizon Client authentication failure

Hi Bluzdoggy, I would open a support case, as they will be able to review log files to determine at which point authentication is failing and more quickly get your environment working.

With that said, do you see the Access policy completing successfully for both clients or only HTML? There is an option in the iApp that might help a little during certificate selection, I point this out as I noted you are not passing certificate authentication when using the horizon client. This could mean you are not sending a certificate at all, or perhaps are not sending one that matches your allowed CA issued certs. Modify the question "Which CA certificate bundle do you want to use for your advertised certificate authorities?" to none. Doing so will make it so the client is able to view all client certificates rather then just certificates issued by the CA root certificate selected. Of course you will need to select a valid certificate (one that has been issued by a CA selected in question "Which CA certificate bundle do you want to use for your trusted certificate authorities?", and is valid).

You could also be hitting a time out issue regarding client side ssl handshake timeout, as the default is set to 10 seconds. This means you have to enter smartcard pin and sent client certificate within 10 seconds of making your initial connection. The iApp will set this value on your client ssl profile to 60 seconds but I mention it in case you selected a pre-configured ssl client profile or for some reason are taking longer than 60 seconds to send certificate.

Want to thank you your insight into nixing the advertised certs. I now get the initial cert prompt and enter my pin, however, the failure happens at the same place. This is the same with altering the timeouts - I just set them all to indefinite for now. I will be opening a ticket, but first I am going try one other method that does not employ the iApp. It can be found here: https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-third-party-integration-12-1-0/8.htmlconceptid and quite different as it comes at the problem with a true sso approach.

try to see if the correct certificate is send and if it matches the CA. if you go HTML 5 do you then the certificate part work fine?

Boneyard, I was able to access the logs on the connection server today. I actually can see the cert getting there from the client and the browser (it is the same cert - and the correct one at that). The UPN is extracted correctly as well. If I'm going there from the client, the next thing I see in the log is "Unverified CHANGEKEY message discarded, machine 'cn=ca70f223-b584-4cc4-a489-230b73bf92b6,ou=servers,dc=vdi,dc=vmware,dc=int' does not exist. All I see in the APM log at that point is "notice apmd[8946]: 01490005:5: /Common/horizon.app/horizon:Common:5f616461: Following rule 'fallback' from item 'View Client Cert Inspection' to ending 'Deny.'" The client's explanation is even more vague with "Authentication Failure."

I understand that all the failures are reactionary to the Connection server not being able to find a machine that it wants to send me to. The part I don't understand is why the same connection from a web browser goes on to the SAML part of the connection (which I can see in APM but not sure where to find it on the Horizon side.

Following rule 'fallback' from item 'View Client Cert Inspection' to ending 'Deny.'" means Client cert inspection failed (there was not a valid client certificate received by the big-ip). I would verify the client certificate has not expired and was issued by the certificate authority you have selected (root ca certificate for CA should be attached to your client ssl profile as "Trusted Certificate Authorities").

I would set your logging level to debugging (check out the apm log profile you set in the iapp) and tail your apm (/var/log/apm) log while attempting to connect. Also set your ssl logging level to debug (modify /sys db log.ssl.level value Debug) and tail your ltm logs at the same time.

Openssl s_client is a good way to test client certificates. Check out this solution article for a few additional client certificate trouble shooting tips: 14819

Greg, how is that possible when the same exact cert (and access policy) is being used whether the connection initiates from the horizon client or the web browser? The connection is granted from the browser but denied from the client.

Client cert inspection fails when a certificate is not received or the certificate received does not pass validation. Maybe the middle ware for your smart card is not working well with Horizon Client and the client certificate is not being received by the BIG-IP. I would check out your ltm and apm logs while connecting with horizon client to verify a certificate is being passed.

I have been diligently working on this. I also have a ticket open with F5. SSL dumps show a valid 3 way handshake. I believe there is an issue with something regarding the transition from the client ssl to the server ssl. I see a 404 error from the broker when it sends back to the F5:

HTTP/1.1 404 Not Found

As the connection continues to try to complete the logs show the F5 assigning a "fake" GUID in the xml file that it wants to pass to the broker:

aaaaaaaa-bbbb-cccc-ddddddddddddddddd

Any time I go straight to the broker from the client (F5 not in the signal path) there is no issue with the connection.

ssl offloading / bridging whatever you want to call it won't modify the content. the fact you get a 404 with the F5 and not without it i would suggest looking into the configuration. can you actually view the data on both sides with and without the f5? it should be easy enough to then determine what happens.

Got a good tip from the guy working the ticket with me from F5. I get an expected cert behavior now since I put the trusted CAs and intermediate CAs all in one bundle (never had to do that before - but then again I've never used horizon's client through an F5 either). Now I get prompted for my cert and enter my PIN - and now I'm failing at the SAML level. The error from the client says: "SAML Authenticator disabled/removed. Please contact your Administrator for help." When I look at the log from the connection server (which is the SP), I see that it has submitted authentication to the IdP (F5), the F5 then sends back an assertion to the SP where I start to see errors like: "Could not match with any enabled SAML authenticator for the given issuer in the assertion" and "SAML access denied because of invalid assertion/artifact" and "Enabled SAML Authenticator's Issuer/entityId not matched with SAML Artifact /Assertion." Any ideas?