F5 is upgrading its customer support chat feature on My.F5.com. Chat support will be unavailable from 6am-10am PST on 1/20/26. Refer to K000159584 for details.

Forum Discussion

Steve_Janetzke_'s avatar
Steve_Janetzke_
Icon for Nimbostratus rankNimbostratus
Jan 23, 2014

APM Kerberos SSO profile problem with TGS-REQ

I am trying to have an SSO Profile do a Kerberos request for the credentials for a service ticket to do constrained delegation. The iRule is populating my session variables correctly, the LDAP lookup is working and the access profile kicks off the access allowed, at with point the Kerberos SSO profile takes over, but the page does not load.

 

When I do a tcpdump to troubleshoot I see the TGS-REQ has "till: 2013-12-31 15:24:57 (UTC)" assumption is this the date it is asking for the ticket to expire. It is the only date I see passed in the request. if so this makes sense why the domain would err this request I get a KRB5KRB_AP_ERR_TKT_EXPIRED from the domain - but why is the request coming in with this time? I can see in the APM log that the request is done at Jan 23 16:04:46 "Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: ctx: 0x5901cee8, CLIENT: TMEVT_REQUEST Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: ctx: 0x5901cee8, CLIENT: TMEVT_REQUEST_DONE"

 

Has anyone run into this before?

 

I checked date and hwclock and they are correct to the domain. [root@testltm:Active:Standalone] config date; hwclock Thu Jan 23 16:34:28 PST 2014 Thu 23 Jan 2014 04:34:28 PM PST -0.000961 seconds tail APM LOG EXCERPT (device and realm name changed): Jan 23 16:04:46 testltm info apd[10500]: 01490007:6: 0264338a: Session variable 'session.policy.result' set to 'allow' Jan 23 16:04:46 testltm debug apd[10500]: 01490000:7: AccessPolicyD.cpp func: "sendAccessPolicyResponse()" line: 1514 Msg: DONE WITH ACCESS POLICY - send 'we are done with access policy for this session' code Jan 23 16:04:46 testltm debug apd[10500]: 01490000:7: AccessPolicyD.cpp func: "process_request()" line: 723 Msg: ** done with the request processing ** Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: constructor Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: webssoContext constructor ... Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: 13 headers received Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: http header *[:method][GET] (len=3) Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: http header *[:uri][/] (len=1) Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: http header *[:version][HTTP/1.1] (len=8) Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: http header *[:custommeta][^KZ] (len=384) Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: http header *[Host][sjtest.dadsuswe.dads.navy.mil] (len=29) Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: http header [session-key][******] (len=32) Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: http header *[Cookie][LastMRH_Session=0264338a; F5_ST=1z1z1z1390521886z604800] (len=55) Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: http header [Accept][/] (len=3) Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: http header [Accept-Language][en-us] (len=5) Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: http header [Accept-Encoding][gzip, deflate] (len=13) Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: http header [Connection][Keep-Alive] (len=10) Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: http header [User-Agent][Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; .NET4.0E; InfoPath.3)] (len=169) Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0044:7: 0264338a: metadata len 384 Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: init webssoConfig from data: 0x5901d03c, len: 384 Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: different sso config object received, name: /Common/dadsuswe_kerb, method: 5 Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: ssoMethod: kerberos usernameSource: session.logon.last.username userRealmSource: session.logon.last.domain Realm myrealm.test.test.com KDC: AccountName: host/apmkerb spnPatterh: HTTP/%s@myrealm.test.test.com TicketLifetime: 600 UseClientcert: 0 SendAuthorization: 0 Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: ctx: 0x5901cee8, CLIENT: TMEVT_REQUEST Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: ctx: 0x5901cee8, CLIENT: TMEVT_REQUEST_DONE Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: ctx: 0x5901cee8, CLIENT: TMEVT_SESSION_RESULT Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: ctx: 0x5901cee8, CLIENT: TMEVT_SESSION_RESULT Jan 23 16:04:46 testltm debug websso.3[13393]: 014d0001:7: ctx: 0x5901cee8, CLIENT: TMEVT_SESSION_RESULT Jan 23 16:04:52 testltm debug websso.2[13343]: 014d0001:7: Expire thread: TGTlist:0 TGTMap:0 UCClist:0 UCCmap:0 Jan 23 16:04:52 testltm debug websso.1[13337]: 014d0001:7: Expire thread: TGTlist:0 TGTMap:0 UCClist:0 UCCmap:0 Jan 23 16:04:52 testltm debug websso.0[13315]: 014d0001:7: Expire thread: TGTlist:0 TGTMap:0 UCClist:0 UCCmap:0 Jan 23 16:04:52 testltm debug websso.3[13393]: 014d0001:7: Expire thread: TGTlist:0 TGTMap:0 UCClist:0 UCCmap:0 Jan 23 16:04:56 testltm debug apmd[9571]: 01490000:7: modules/Authentication/Crldp/CrldpCache.cpp func: "CrldpSweeper()" line: 129 Msg: Running CrldpSweeper Jan 23 16:04:56 testltm debug apmd[9571]: 01490000:7: modules/Authentication/Crldp/CrldpCache.cpp func: "CrldpSweeper()" line: 137 Msg: No entries in CrldpTable Jan 23 16:04:56 testltm debug apmd[9571]: 01490000:7: AccessPolicyProcessor/AccessPolicyProcessor.cpp func: "runSessionCleaner()" line: 1415 Msg: Running Session Cleaner . .. Jan 23 16:04:58 testltm debug websso.3[13393]: 014d0001:7: ctx: 0x5901cee8, CLIENT: TMEVT_ABORT_PROXY
BIG-IP Access Policy Manager (APM)
security

1 Reply

  • Kevin_Stewart's avatar
    Kevin_Stewart
    Icon for Employee rankEmployee
    Jan 24, 2014

    It's interesting that you're getting a timing error but possibly not actually submitting a Kerberos request. Do you have the ability to run WireShark some place where the Kerberos traffic can be seen? It's simplest if you can put it on the DC, but not everyone has that luxury. You can technically dump the data from tcpdump on an inside interface of the LTM, and then import into WireShark, but however you get it there, this tool will give you the most insight into what that Kerberos traffic actually looks like. What you'll want to look for is Kerberos (port 88) and DNS (port 53) traffic coming from the LTM to the DC. I've seen DNS responses foul things up, but if there's anything like a delegation, timing, or encryption issues, you'll see that in the capture. Because I don't really see any SSO information in the logs, it's very likely that something like reverse DNS could be involved.