Forum Discussion

tiwang's avatar
tiwang
Icon for Nimbostratus rankNimbostratus
Jun 04, 2014

More kerberos problems

Hi out there

 

I have a pretty simple apm setup with a kerberos sso where I extract a user-name from a certificate and use this for ldap and afterwards get a kerberos ticket with. This Works fine on my lab where I am running

 

Sys::Version Main Package Product BIG-IP Version 11.3.0 Build 2806.0 Edition Final Date Tue Nov 13 22:34:00 PST 2012

 

but in our production environment I have some problems - the apm sso isn't querying the KDC at all - I just get the pretty common kerberos related error:

 

-f5 debug websso.0[10256]: 014d0001:7: http header [Connection][keep-alive] (len=10) Jun 4 19:31:20 hsp-gbh-f5 debug websso.0[10256]: 014d0044:7: 6e67cece: metadata len 388 Jun 4 19:31:20 hsp-gbh-f5 debug websso.0[10256]: 014d0001:7: init webssoConfig from data: 0x5a000854, len: 388 Jun 4 19:31:20 hsp-gbh-f5 debug websso.0[10256]: 014d0001:7: different sso config object received, name: /dk_dmz/DK_AE_Kerb_sso, method: 5 Jun 4 19:31:20 hsp-gbh-f5 debug websso.0[10256]: 014d0001:7: ssoMethod: kerberos usernameSource: session.sso.token.last.username userRealmSource: session.logon.last.domain Realm: DC2000DB.ADP.DK KDC: 10.14.14.21 AccountName: f5_kcd spnPatterh: HTTP/%s@DC2000DB.ADP.DK TicketLifetime: 600 UseClientcert: 0 SendAuthorization: 1 Jun 4 19:31:20 hsp-gbh-f5 debug websso.0[10256]: 014d0001:7: ctx: 0x5a002cc0, CLIENT: TMEVT_REQUEST Jun 4 19:31:20 hsp-gbh-f5 debug websso.0[10256]: 014d0001:7: ctx: 0x5a002cc0, CLIENT: TMEVT_REQUEST_DONE Jun 4 19:31:20 hsp-gbh-f5 debug websso.0[10256]: 014d0001:7: ctx: 0x5a002cc0, CLIENT: TMEVT_SESSION_RESULT Jun 4 19:31:20 hsp-gbh-f5 debug websso.0[10256]: 014d0001:7: ctx: 0x5a002cc0, CLIENT: TMEVT_SESSION_RESULT Jun 4 19:31:20 hsp-gbh-f5 debug websso.0[10256]: 014d0001:7: ctx: 0x5a002cc0, CLIENT: TMEVT_SESSION_RESULT Jun 4 19:31:20 hsp-gbh-f5 debug websso.0[10256]: 014d0041:7: 6e67cece: Could not find SSO domain, check variable assign agent setting Jun 4 19:31:23 hsp-gbh-f5 debug websso.0[10256]: 014d0001:7: Expire thread: TGTlist:0 TGTMap:0 UCClist:0 UCCmap:0

 

When I run tcpdump I can see that I am quering my dc through ldap but afterwards when the sso is started it doesn't even try so it is a very god reason for that it cannot find the domain. I have small difference here - my lab is setup complete plain - no route-domains or partions - just a "flat" f5 but our productions env has 3 partitions defined - common and dkdmz and ukdmz - could this be the reason?

 

my production env runs on:

 

root@(hsp-gbh-f5)(cfg-sync Standalone)(Active)(/Common)(tmos) show /sys version

 

Sys::Version Main Package Product BIG-IP Version 11.3.0 Build 3117.0 Edition Hotfix HF5 Date Wed Apr 17 10:53:45 PDT 2013

 

Hotfix List ID405861 ID390540 ID417157 ID403008 ID403125 ID404746 ... and a huge hotfix list...

 

APM
design
security

2 Replies

Sort By
  • kunjan's avatar
    kunjan
    Icon for Nimbostratus rankNimbostratus
    Jun 05, 2014

    Could not find SSO domain, check variable assign agent setting

     

    I think, this you can ignore as this due to the value not set for session.logon.last.domain. If you assign the domain name to it, you can get rid of it.

     

     

    If you don't see Kerberos going out, it could be due to the PTR record for the server you are trying to access is failing. It is required to fill the SPN pattern as you have left it blank. You can do tcpdump on port 53 and see if the response return good. Rightfully, you should see the error in your following logs.

     

  • tiwang's avatar
    tiwang
    Icon for Nimbostratus rankNimbostratus
    Jun 06, 2014

    hi Again thanks for your note - but the problem was much simpler - when I prepared this test-setup we just created a vm for the webserver with default settings etc and a default website - I verified that I could reach it etc - and afterwards I disabebled the default "anonymous access" and added kerberos as protocol. Funny enough this caused the website to stop listening on port 80 (which I wans't aware of) and since I for this testsetup just had added a "ping" monitor for the monitor on the webserver instead of a http-monitor it didn't fail. So - a funny coincidence which caused a lot of confusion best regards /ti