Forum Discussion

robert_juric_35's avatar
robert_juric_35
Icon for Altostratus rankAltostratus
Apr 23, 2018
Solved

Kerberos SSO Clients Not Getting Ticket

I'm setting up a new Kerberos SSO site. I've copied the config from a working SSO site we already have setup. In the VPE we have the 401 with negotiate and then the Kerberos authentication. Everything looks in order, but we are failing Kerberos authentication. In the logs I get a message stating:

 

"GSS-API error gss_accept_sec_context: 70000 : No credentials were supplied, or the credentials were unavailable or inaccessible "

 

Also I've taken packet captures comparing the good and the new SSO. When connecting to the good SSO I see the client reach out and get a ticket, however with the new SSO I do not see any kerberos traffic captured. What could I be missing that is not triggering the client to go get a Kerberos ticket?

 

APM
BIG-IP
security
  • robert_juric_35's avatar
    robert_juric_35
    Apr 25, 2018

    The other answer showed me the problem. In our testing, we were going directly to the virtual server IP instead of the FQDN. Since the IP didn't match what was in the UPN it was failing kerberos. As soon as we entered the FQDN as the URL everything worked fine.

     

4 Replies

Sort By
  • youssef1's avatar
    youssef1
    Icon for Cumulonimbus rankCumulonimbus
    Apr 24, 2018

    Hello,

     

    I just want to clarify your question.

     

    You have an working VPE that process kerberos auth, that's right? This policy/service is an IDP (SAML Auth)? or Web access management (Perimeter security) with sso kerberos?

     

    Regards

     

  • robert_juric_35's avatar
    robert_juric_35
    Icon for Altostratus rankAltostratus
    Apr 24, 2018

    Yes, I have one working VPE processing kerberos auth, and a new one which is not triggering the client to get a ticket. Both are setup as for IDPs.

     

  • youssef1's avatar
    youssef1
    Icon for Cumulonimbus rankCumulonimbus
    Apr 25, 2018

    Hello Robert,

     

    I understand your issue, to sum up, you have on service as IDP that authenticate user (kerberos). you have copied the VPE and attached this new vpe to a new services.

     

    it's quite normal that it does not work, because of kerberos. let me explain.

     

    Actual service idp1.mydomain.com

     

    Copied service idp2.mydomain.com

     

    In the VPE of service idp2 you have to create a new Keytab with the following spn HTTP/idp2.mydomain.com.

     

    You have to now that kerberos use dns record in its auth process. when you try to reach/auth in idp2, you system will follow this steps:

     

    • a record of idp2.mydomain.com --> ex: 1.1.1.2
    • ptr of 1.1.1.2 --> idp2.mydomain.com
    • check if spn HTTP/idp2.mydomain.com

    The problem is that spn idp2 don't exist and the keytab attached to idp2 vpe is not valid because it's spn used by idp1...

     

    Let me now if it's clear for you and if you need additional help.

     

    Regards

     

  • robert_juric_35's avatar
    robert_juric_35
    Icon for Altostratus rankAltostratus
    Apr 25, 2018

    The other answer showed me the problem. In our testing, we were going directly to the virtual server IP instead of the FQDN. Since the IP didn't match what was in the UPN it was failing kerberos. As soon as we entered the FQDN as the URL everything worked fine.