1 2 Previous Next 17 Replies Latest reply: Jun 6, 2012 7:33 AM by user5336584 RSS

    Kerberos Header Issue for Desktop Signon

    693757
      Hello,

      As I following the PeopleBook for the Desktop Singal Signon of Kerberos protocal, here's some issue while using the FUNCLIB_LDAP.LDAPAUTH signon peoplecode to authenticate the NT Domain user while logging.

      The Peoplecode from Peoplebook is looking at KRB_USER and Authorization Header names in the Kerberos ticket from the Kerberos token. But always the PIA login as the PUBLIC user whatever NT Domain user I logged.

      Then I tried to look out the HeaderName & its value pair as below: (Note: Didn't fine any KRB_USER or Authorization header name in the request list)
      Name: Accept - image/jpeg, image/gif, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
      Name: Accept-Language - en-US
      Name: User-Agent - Mozilla/4.0 (....)
      Name: Host - www.mydoamin.com
      Name: Connection - Keep-Alive
      Name: Cookie - SignonDefault=PUBLIC; http%3a%2f%2f......

      Above is all the header name in list of request. No KRB_USER or Authorization name liked headers.


      Below is the monitor log from PIA_weblogic log:

      ####<Apr 26, 2012 2:18:44 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '11' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421124992> <BEA-000000> <KerberosSSOFilter: Requesting Kerberos token. (Connection is NOT secure)>
      ####<Apr 26, 2012 2:18:50 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421130924> <BEA-000000> <KerberosSSOFilter: Received invalid token.>
      ####<Apr 26, 2012 2:18:50 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421130949> <BEA-000000> <KerberosSSOFilter: Received invalid token.>
      ####<Apr 26, 2012 2:18:50 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421130997> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131071> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131117> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '16' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131078> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '16' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131084> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '19' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131094> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '16' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131102> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '16' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131106> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '13' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131112> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131081> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '12' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131115> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '8' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131116> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131136> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '13' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131138> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131137> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '16' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131139> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '18' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131140> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131140> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '18' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131157> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131164> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131158> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '13' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131159> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131161> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '12' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131161> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131162> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '7' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131165> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131166> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '11' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131167> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '12' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131169> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:18:51 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421131172> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:27:52 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421672310> <BEA-000000> <KerberosSSOFilter: Requesting Kerberos token. (Connection is NOT secure)>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690236> <BEA-000000> <KerberosSSOFilter: Received invalid token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690276> <BEA-000000> <KerberosSSOFilter: Received invalid token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690345> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690420> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '7' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690436> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690426> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690428> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '13' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690430> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690432> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '13' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690447> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690461> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690471> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '7' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690449> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '18' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690474> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690482> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '13' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690485> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '7' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690486> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '7' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690487> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '7' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690488> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690489> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '14' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690490> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690492> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '13' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690493> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690494> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '20' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690495> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690496> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '18' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690497> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '12' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690497> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '18' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690510> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690512> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '13' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690513> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>
      ####<Apr 26, 2012 2:28:10 PM CST> <Notice> <Stdout> <kcpl> <PIA> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1335421690513> <BEA-000000> <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>


      The Kerberos Desktopsso class are existing under PIA_HOME/..../classes/.../kerberos/ folders as well as PS_HOME/class/..../kerberos/ folders

      6 classes under PIA_HOME corresponding folder while 2 classes under PS_HOME corresponding folder.


      Due to the KRB_USER and Authorization header name not found, the Kerberos not correctly switch to corresponding desktop user.

      Here's my setup:

      1. Follow the PeopleBook guide to create Kerberos domain user, keytab file, and related conf file, web.xml
      2. Create PUBLIC user id in PIA with only Mobile Client User Role for PeopleSoft Home page access.
      3. Follow all the information related kerberos setup in PeopleBook section of desktop singal signon.

      While I type the URI like: http://www.mydomain.com/psp/<SITENAME>/EMPLOYEE/ERP/h/?tab=DEFAULT, the IE prompt the Windows Security logon prompt for Domain User & Password input, after try any domain user with valid password, the page redirected ONLY to PUBLIC user.

      Is there anyone successfully implemented the Desktop Kerberos signon? And how to fix the KRB_USER, Authorization headers not in the Request header from Kerberos Token ticket?


      Thanks,

      Saxon SI

      Edited by: Saxon SI on Apr 26, 2012 2:57 PM
        • 1. Re: Kerberos Header Issue for Desktop Signon
          Jim.Marion-Oracle
          Since you are seeing so much Kerberos output in your logs, it sounds like your installation is correct.

          I think the log shows your problem as:

          KerberosSSOFilter: Received invalid token.

          I think it is saying that it tested the Kerberos token and rejected it. Since it was rejected, you won't see the Kerberos headers.

          In your log file you also see:

          <KerberosSSOFilter: Valid session id. Not requesting Kerberos token.>

          Once you have a valid PeopleSoft session (valid PS_TOKEN), the Kerberos SSO Filter will skip the Kerberos check. If you have anonymous authentication enabled in your web profile, then if Kerberos fails, then you will automatically become the anonymous user and won't see a Kerberos challenge. To force a new session, delete your cookies.

          Have you configured krb5.conf and keytab correctly? Did you create a server user account and generate the keytab from your directory server?

          Have you set verbose to true in the servlet configuration?
          • 2. Re: Kerberos Header Issue for Desktop Signon
            693757
            Hello Jim,

            Thanks for your reply. I got what you mean.

            The "Received invalid token" is working with the "Requesting Kerberos token. (Connection is NOT secure)" log before it. - This is the process of the PIA to check the Kerberos token. As you mentioned, the token is not invalid, thus the following log "Valid session id. Not requesting Kerberos token." displayed because the Public user is logged or the valid PS user logged via login page.

            From the PeopleBook, PeopleTools 8.52: Security Administration > Implementing Single Signon, it said that the public user should be enabled in web profile to be the same as the one specified in PeopleCode. (The KRB login PeopleCode with validate the Public User with login User then go thru the function to check KRB token.) - If we trun off the public user, I believe that it should not go thru the KRB PeopleCode, due to the %SignonUserId not equal to default user id.

            In my case, I create a user id named as PUBLIC, and in the getWWWAuthConfig function, specify the default user id as PUBLIC.

            I tried to delete the Cookie from both IE and Firefox, then re-try the http://www.mydomain.com/psp/<sitename>/EMPLOYEE/ERP/?tab=DEFAULT, it still the Public User Home page.

            Below is the content of the krb5.conf, krbLogin.conf
            krb5.conf:
            *[libdefaults]*
            default_realm = MYDOMAIN.COM
            *[realms]*
            *MYDOMAIN.COM = {*
            kdc = <IP Address of Domain Controller>
            *}*

            krbLogin.conf:
            *krbServer {*
            com.sun.security.auth.module.Krb5LoginModule required
            storeKey=true
            useKeyTab=true
            keyTab="C:\app\krb\krb5.keytab"
            isInitiator=false
            principal="HTTP/www.mydomain.com";
            *};*
            krb5.keytab file using the following command to generate:

            ktpass -princ HTTP/www.mydomain.com@MYDOMAIN.COM -mapuser krbadmin@mydomain.com -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -pass saxon -out c:\app\krb\krb5.keytab
            Note: krbadmin is the new user created under Domain, after the above command complete, the krbadmin User logon name is updated as HTTP/www.mydomain.com

            In the PIA, web.xml file, adding the following just after the firest <display-name> tag.

            +<filter>+
            +<filter-name>KerberosSSO</filter-name>+
            +<filter-class>com.peoplesoft.pt.desktopsso.kerberos.KerberosSSOFilter</filter-class>+
            +<init-param>+
            +<param-name>checkSecureConnection+
            +</param-name>+
            +<param-value>false</param-value>+
            +</init-param>+
            +<init-param>+
            +<param-name>validateToken</param-name>+
            +<param-value>true</param-value>+
            +</init-param>+
            +<init-param>+
            +<param-name>verbose</param-name>+
            +<param-value>true</param-value>+
            +</init-param>+
            +</filter>+
            +<filter-mapping>+
            +<filter-name>KerberosSSO</filter-name>+
            +<url-pattern>/*</url-pattern>+
            +</filter-mapping>+

            Note: due to the CA issue of SSL of PIA login, for the checkSecureConnection above, changed from true to false to enable the non-Secure connection.
            Note: There're about 3 <display-name> tags, only add it after the first appear tag which is for <display-name>Portal</display-name>.

            The following appended in the JAVE path in webserv cmd file as well as psappsrv.cfg file.

            -Djava.security.auth.login.config=C:\krb\krbLogin.conf -Djava.security.krb5.conf=C:\krb\krb5.conf


            Is there anything need to do with Weblogic console for PIA configuration to make the KRB token correctly generated and received?



            Thanks,

            Saxon SI
            • 3. Re: Kerberos Header Issue for Desktop Signon
              user548430
              Hi Saxon,

              Your configuration on krb files such as krbLogin.conf and krb5.conf looks correct to me and so do your generation of your keytab through ktpass.
              Did you configure your setEnv.cmd for this : -Djava.security.auth.login.config=c:\krb\krbLogin.conf -Djava.security.krb5.conf=c:\krb\krb5.conf in the java path. I noticed your did on the appserver config's java path.

              Thanks
              Wellen
              • 4. Re: Kerberos Header Issue for Desktop Signon
                693757
                Hi,

                Yes, I've added in both web server setEnv.cmd & app server cfg file.

                For setEnv.cmd, the double quote is included as in the PeopleBook it is included. While for psappsrv.cfg, the double quote is not due to the sample in PeopleBook not containing the quotes.

                setEnv.cmd something like: -Djava.security.auth.login.config="c:\app\krb\krbLogin.conf" -Djava.security.krb5.conf="c:\app\krb\krb5.conf"
                psappsrv.cfg like: -Djava.security.auth.login.config=c:\app\krb\krbLogin.conf -Djava.security.krb5.conf=c:\app\krb\krb5.conf

                Thanks,

                Saxon SI
                • 5. Re: Kerberos Header Issue for Desktop Signon
                  user548430
                  After you add in the SetEnv, it is still not working ? I guess you also reboot the webserver. right ?
                  Perharps, we can do webconf just to make sure the setup is correctly in peoplesoft. Another possible problem is that the kerberos setting in AD is not setup properly.
                  Do you know how you configure or setup ? A doc with you env setup will be used for me to see.

                  Edited by: user548430 on Apr 30, 2012 5:24 PM
                  • 6. Re: Kerberos Header Issue for Desktop Signon
                    693757
                    Hi,

                    Here's the whole document I referred to for the Kerberos setup in PeopleSoft:
                    #1. PeopleBook for Kerberos Single Sigon - http://docs.oracle.com/cd/E28394_01/pt852pbh1/eng/psbooks/tsec/htm/tsec10.htm#g02899ad98268cd74_2bf892_129dcbbcb66__6fb6
                    #2. PeopleBook Appendix for Kerberos on AD- http://docs.oracle.com/cd/E28394_01/pt852pbh1/eng/psbooks/tsec/book.htm?File=tsec/htm/tsec19.htm%23g8be135a0d9b4ed53_4e113b_129efdc7183__7f02

                    Here's the steps I followed:

                    #1. Install Windows 2008 R2 EE on VMWare
                    #2. Add Role of Domain Controller for the VM, creating new domain forest & install/config DNS companion with AD installation.
                    #3. PeopleSoft Related Installation/Configuration
                    #4. Add a new domain user "krbadmin"
                    #5. Following the Appendix as Link #2 above to generate the kaytab file for my domain (corresponding SPN name, domain name, and password, kerberos user is replaced with my owner value.)
                    #6. Then Follow the PeopleSoft Kerberos setup as Link #1 above to setup krb5.conf, krbLogin.conf configuration files with proper value.
                    #7. Update the JAVA_OPTIONS_WIN in setEnv file
                    #8. Check KerberosSSO*.class exists under both PIA_HOME and PS_HOME folders.
                    #9. Update web.xml under Web server folders, follow the same value as the sample in PeopleBook except the tag checkSecureConnection set to false.
                    #10. Update JavaVM Options in psappsrv.cfg file under Application Server folder
                    #11. Create New User ID - PUBLIC in PeopleSoft PIA user profile page.
                    #12. Update PeopleCode in FUNCLIB_LDAP record for getWWWAuthConfig, and KRB_Authentication function. (Code based on the sample code in PeopleBook)
                    #13. Config Signon PeopleCode for KRB_Authentication function.
                    #14. Reboot System, DB, App Server, Batch Server, PIA
                    #15. Test Kerberos - Failed, log mostly as the one shown on the first post.

                    No clue how to fix...... All I have done is following the Steps in PeopleBook, only the corresponding value for my env is replaced while other code keep the same as the sample code in PeopleBook.

                    I didn't have any other document referred, only go thru the PeopleBook for this Kerberos setup, and for the AD setup, only follow the Add Role setup. In PeopleBook, it said Win 2003 Domain Controller in Appendix, but I am not sure if this solution of Kerberos is compatible with Win 2008 R2 AD. (I just guessing if it only works with AD based on Win 2003 or not?)

                    Any Idea?


                    Thanks,

                    Saxon SI

                    Edited by: Saxon SI on May 2, 2012 10:50 AM
                    • 7. Re: Kerberos Header Issue for Desktop Signon
                      user5336584
                      Hi

                      We have this working on PT 8.51 in environments with a Windows 2008 R2 domain controller and environments with a Windows 2003 domain controller.

                      When you checked the headers did you check whether the browser was sending the authorization header? It should start Negotiate YI..... if it is sending a Kerberos token. You can use tools such as Fiddler or HttpHeaders to check what the browser is sending.

                      If the browser is not sending a token then I'd try adding the site to your local intranet zone assuming you are using Internet Explorer. This should get rid of the domain user/password prompt and the browser will trust the site for Kerberos negotiation.

                      We had a problem on one environment with Kerberos working over http but not https - this was because one environment was running an older Java version, 1.6.0_17 - updating to the correct version of JRockit to Java 1.6.0_26 has resolved that.

                      It might also be worth running a klist command (just type "klist" in a command prompt on the client machine) to see what tokens you have after trying to authenticate. You should see an entry corresponding to the server name.

                      Another thing that could cause problems is a duplicate SPN. You can check for duplicates using the setspn command with the -x swicth (type "setspn -x" at a command prompt).

                      Hope this helps.

                      Henry
                      • 8. Re: Kerberos Header Issue for Desktop Signon
                        693757
                        Hi Henry,

                        Thank you for your input, I've done some check you mentioned as following:
                        user5336584 wrote:
                        Hi

                        We have this working on PT 8.51 in environments with a Windows 2008 R2 domain controller and environments with a Windows 2003 domain controller.

                        When you checked the headers did you check whether the browser was sending the authorization header? It should start Negotiate YI..... if it is sending a Kerberos token. You can use tools such as Fiddler or HttpHeaders to check what the browser is sending.
                        I've tried the Live Http Headers as of FF add-on to get the request/response header on Client as below FYI:

                        URL Access from FF in Client:
                        http://www.mydomain.com/psp/KCPL/EMPLOYEE/ERP/h/?tab=DEFAULT

                        Request Headers:
                        GET /psp/KCPL/EMPLOYEE/ERP/h/?tab=DEFAULT HTTP/1.1
                        Host: www.mydomain.com
                        User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
                        Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
                        Accept-Language: en-us,en;q=0.5
                        Accept-Encoding: gzip, deflate
                        Connection: keep-alive
                        Cookie: SignOnDefault=PUBLIC; KCPL-80-PORTAL-PSJSESSIONID=cQPSPjjbHpsTpVwCJ2dZlvJdYwWz5qTC!-1584708328; ExpirePage=http://www.mydomain.com/psp/KCPL/; PS_LOGINLIST=http://www.mydomain.com/KCPL; http%3a%2f%2fwww.mydomain.com%2fpsp%2fkcpl%2femployee%2ferp%2frefresh=list: %3ftab%3ddefault|%3frefresh_all_pagelets%3ddefault|%3ftab%3dremoteunifieddashboard|%3frefresh_all_pagelets%3dremoteunifieddashboard; PS_TOKENEXPIRE=4_May_2012_05:07:08_GMT; PS_TOKEN=pgAAAAQDAgEBAAAAvAIAAAAAAAAsAAAABABTaGRyAk4Abwg4AC4AMQAwABRTCw37UzDifaKUDUe4V3J/jGjsFWYAAAAFAFNkYXRhWnicHYlNDkAwFIS/IlYWLkK0/romIkKkG7F0BBd0OJO+Sb6ZN/MCWZoYI/8S4hWBi4mDjZl84WSlDNz6HnYxaOscDRZHJe8jO9Gpq5XHSC96aVBraeEHjvULpw==

                        Response Headers:
                        HTTP/1.1 200 OK
                        Date: Fri, 04 May 2012 05:07:08 GMT
                        Content-Length: 5386
                        Content-Type: text/html; CHARSET=UTF-8
                        Expires: Fri, 04 May 2012 05:27:08 GMT
                        Last-Modified: Fri, 04 May 2012 05:07:08 GMT
                        portaltopnav: true
                        ignoreportalregisteredurl: 1
                        pscache-excludeparams: c
                        portalcachecontent: true
                        pscache-handler: psft.pt8.cache.handler.MenuCacheHandler
                        Set-Cookie: http%3a%2f%2fwww.mydomain.com%2fpsp%2fkcpl%2femployee%2ferp%2frefresh=list: %3frefresh_all_pagelets%3ddefault|%3ftab%3dremoteunifieddashboard|%3frefresh_all_pagelets%3dremoteunifieddashboard; domain=.mydomain.com; expires=Fri, 04-May-2012 05:27:08 GMT; path=/
                        Set-Cookie: PS_TOKENEXPIRE=4_May_2012_05:07:08_GMT; domain=.mydomain.com; path=/
                        pscache-control: role%2cmax-age%3d-1
                        Content-Encoding: gzip
                        portalregisteredurl: http://www.mydomain.com/psc/KCPL/EMPLOYEE/ERP/s/WEBLIB_PORTAL.PORTAL_HOMEPAGE.FieldFormula.IScript_HPPoweredBy
                        X-Powered-By: Servlet/2.5 JSP/2.1
                        usesportalrelativeurl: true

                        (From PIA startManagedWebLogic PIA cmd windows, the general log for this access process is as: 1. Request Kerberos token; 2. Received Invalid token; 3. Using PUBLIC user id without Kerberos token to view the page)

                        >
                        If the browser is not sending a token then I'd try adding the site to your local intranet zone assuming you are using Internet Explorer. This should get rid of the domain user/password prompt and the browser will trust the site for Kerberos negotiation.
                        In IE, the http://*.mydomain.com & https://*.mydomain.com already inserted in the local intranet zone. In the FF, at about:config, the network.negotiate-auth.trusted.uris is set as "mydomain.com"

                        >
                        We had a problem on one environment with Kerberos working over http but not https - this was because one environment was running an older Java version, 1.6.0_17 - updating to the correct version of JRockit to Java 1.6.0_26 has resolved that.
                        For HTTPS login, in IE the Certificate Error with Red color highlighted, due to the certificate is not verified as a trusted CA. But the HTTPS can logged in and home page can displayed. (I guess the CA Error should not impact the HTTPS access, right?)

                        >
                        It might also be worth running a klist command (just type "klist" in a command prompt on the client machine) to see what tokens you have after trying to authenticate. You should see an entry corresponding to the server name.
                        Here's the output for klist on my client server where to access the PIA from FF:

                        Current LogonId is 0:0x11ae15f

                        Cached Tickets: (6)

                        #0>     Client: krbtest @ MYDOMAIN.COM
                             Server: krbtgt/MYDOMAIN.COM @ MYDOMAIN.COM
                             KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
                             Ticket Flags 0x60a00000 -> forwardable forwarded renewable pre_authent
                             Start Time: 5/4/2012 12:53:25 (local)
                             End Time: 5/4/2012 22:53:23 (local)
                             Renew Time: 5/11/2012 12:53:23 (local)
                             Session Key Type: AES-256-CTS-HMAC-SHA1-96


                        #1>     Client: krbtest @ MYDOMAIN.COM
                             Server: krbtgt/MYDOMAIN.COM @ MYDOMAIN.COM
                             KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
                             Ticket Flags 0x40e00000 -> forwardable renewable initial pre_authent
                             Start Time: 5/4/2012 12:53:23 (local)
                             End Time: 5/4/2012 22:53:23 (local)
                             Renew Time: 5/11/2012 12:53:23 (local)
                             Session Key Type: AES-256-CTS-HMAC-SHA1-96


                        #2>     Client: krbtest @ MYDOMAIN.COM
                             Server: HTTP/kcpl.mydomain.com @ MYDOMAIN.COM
                             KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
                             Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate
                             Start Time: 5/4/2012 13:03:05 (local)
                             End Time: 5/4/2012 22:53:23 (local)
                             Renew Time: 5/11/2012 12:53:23 (local)
                             Session Key Type: AES-256-CTS-HMAC-SHA1-96


                        #3>     Client: krbtest @ MYDOMAIN.COM
                             Server: cifs/kcpl.mydomain.com @ MYDOMAIN.COM
                             KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
                             Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate
                             Start Time: 5/4/2012 12:53:25 (local)
                             End Time: 5/4/2012 22:53:23 (local)
                             Renew Time: 5/11/2012 12:53:23 (local)
                             Session Key Type: AES-256-CTS-HMAC-SHA1-96


                        #4>     Client: krbtest @ MYDOMAIN.COM
                             Server: ldap/kcpl.mydomain.com @ MYDOMAIN.COM
                             KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
                             Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate
                             Start Time: 5/4/2012 12:53:25 (local)
                             End Time: 5/4/2012 22:53:23 (local)
                             Renew Time: 5/11/2012 12:53:23 (local)
                             Session Key Type: AES-256-CTS-HMAC-SHA1-96


                        #5>     Client: krbtest @ MYDOMAIN.COM
                             Server: LDAP/kcpl.mydomain.com/mydomain.com @ MYDOMAIN.COM
                             KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
                             Ticket Flags 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate
                             Start Time: 5/4/2012 12:53:24 (local)
                             End Time: 5/4/2012 22:53:23 (local)
                             Renew Time: 5/11/2012 12:53:23 (local)
                             Session Key Type: AES-256-CTS-HMAC-SHA1-96

                        Note: the Domain Controller server (a) is name as kcpl, and in the DNS I've added an alias name www pointed to kcpl. During the Kerberos SPN setup I always use www.mydonmain.com for the SPN.

                        Can you please confirm is your working environment for SPN is using www while the machine name is not www?

                        >
                        Another thing that could cause problems is a duplicate SPN. You can check for duplicates using the setspn command with the -x swicth (type "setspn -x" at a command prompt).
                        I've run it from the Domain Controller, and the output show my the no dup entries:
                        Checking domain DC=mydomain,.. DC=com
                        Processing entry 0
                        found 0 group of duplicate SPNs.

                        As I note the Process entry is 0, does this mean that my kerberos setup is corrupt or not?

                        PS: the actual domain name is replaced with mydomain for a simple understanding XD

                        Thanks,

                        Saxon SI
                        • 9. Re: Kerberos Header Issue for Desktop Signon
                          user5336584
                          Hi again

                          Looking at the headers it does not look like the browser is passing any Kerberos token. I tried this on our set up using Firefox and it was not passing the token.

                          I then looked up how to enable Kerberos on Firefox and found (among other) the following link: http://www.microhowto.info/howto/configure_firefox_to_authenticate_using_SPNEGO_and_Kerberos.html

                          So I typed in about:config into the Firefox address bar and accepted the warning that appears. I then scrolled down to the network.negotiate-auth.trusted-uris entry, double clicked and added my domain.

                          I was then able to authenticate with Firefox using Kerberos.

                          Regards

                          Henry
                          • 10. Re: Kerberos Header Issue for Desktop Signon
                            693757
                            Hi,

                            I already added the domain in the FF, and I tracked the event log in Domain Controller as following:

                            Once I access the PIA from FireFox, the NT Security log event show me the enry for Kerberos Service Ticket Operations

                            Task Category: Kerberos Service Ticket Operations
                            Event ID: 4769
                            A Kerberos service ticket was requested.

                            Account Info:
                            Acct Name: KRBTEST@MYDOMAIN.COM
                            Acct Domain: MYDOMAIN.COM
                            Logon GUID: {*...*}

                            Service Info:
                            Service Name: KCPL$
                            Service ID: MYDOMAIN\KCPL$

                            Network Info.
                            Client Address: IPv6 Address
                            Client Port: 49660

                            Addl Info:
                            Ticket Options: 0x40810000
                            Ticket Encryption Type: 0x12
                            Failure Code: 0x0
                            Transited Services: -

                            This log level is Infomation level.

                            I just found the fialure code should be larger than 0, but in the log 0x0 should be not treated as failure. Event I enabled the Registry for Kerberos log, not see any event id like 4768.

                            But this kind of log event only displayed on Domain Controller, and not found in Client server.


                            I will be back to look at this next week.


                            Thanks,

                            Saxon SI
                            • 11. Re: Kerberos Header Issue for Desktop Signon
                              user5336584
                              Hi,

                              I cannot see that the browser is sending a Kerberos ticket, either in the http trace or looking at the tickets. If it definitely is not sending any ticket then I think the next step is to speak to your network people.

                              In our case I see a Kerberos ticket of the form "Server: HTTP/servername.domain.com @ DOMAIN.COM" - I don't know if using www would have any implications (eg treating it as in the public space thus not issuing Kerberos token or hiding the www part of the URI rather than showing the full). It may be worth trying using a server name -eg peoplesoft.domain.com to see if that works.

                              It might be worth purging all you tickets (ktlist purge) and then retrying the URL. Immediately after the purge check ktlist and you should see no tickets. Try just the PeopleSoft URL and check ktlist again - in my case is has two tickets, one for the domain "Server: krbtgt/DOMAIN.COM @ DOMAIN.COM" and one for the server as above.

                              Other than that I don't have any more suggestions other than (as you are doing) investigating logs at each stage.

                              Good luck

                              Henry
                              • 12. Re: Kerberos Header Issue for Desktop Signon
                                693757
                                Hi Henry,

                                Thanks, I just re-follow the setup from PeopleBook, and using the ServerName.mydomain.com as SPN instead of WWW, and it works. (Tried bot http://servername.mydomain.com/psp/<SiteName>/EMPLOYEE/ERP/?tab=DEFAULT, and http://www.mydomain.com/psp/<SiteName>/EMPLOYEE/ERP/?tab=DEFAULT, all works fine.)

                                One more concern, as the Kerberos login required the same NT Domain logon id exists as OPRID in PS, besides, as I also enabled the LDAP to MS AD, is that possible to get these 2 signon work together? Currently, Kerber Login Signon PCode exec first, then Delivered LDAP Signon PCode. What I want is that, if the user login from desktop via Kerberos, the OPRID is not in PSOPRDEFN table, then it will auto fetch LDAP and cache the PSOPRDEFN, then logon the PS.

                                I think maybe can write some PeopleCode (LDAPSEARCH BusInterLink Object) check if the user id from Kerberos not exists, then load to PSOPRDEFN table, after it exists, then Auth the user id into PS page. This should require a lot of PeopleCode & Develop such as Sync Operation. I wonder if there's any some simple PeopleSoft delivered setup for Kerberos Login together with LDAP cache to PSOPRDEFN? (The scenario should be like, the Active Domain Admin create a new user in Domain, and assign proper attribute and group for the domain user. Then PS Admin do not need to first create the OPRID in PS, the first time new domain user login the desktop, she/he can access PIA directly. Or she/he does not need a first logon for LDAP Cache, at her/his first launch of browser, all the LDAP caching is complete behind during the Kerberos process. ) For such concen, is there some minor efforts can achieve?

                                BTW, the initial issue is solved. :)

                                Thanks for all your inputs again!


                                Thanks,
                                Saxon SI
                                • 13. Re: Kerberos Header Issue for Desktop Signon
                                  user5336584
                                  Hi

                                  I am glad you have got it working.

                                  We don't use the delivered LDAP integration as it didn't fit our requirements so we have a custom solution for integration with AD and then an internal process to create or lock user accounts when their employment starts or finishes.

                                  I doubt that there will be a delivered solution at present - the code for the Kerberos SSO was not delivered but described in PeopleBooks. BTW be careful if you do a tools upgrade as it will overwrite the FUNLIB_LDAP record and code.

                                  In terms if what you want to achieve you could add modify the existing code ldap authentication code or the Kerberos authentication function you have written based on PeopleBooks. I'd also suggest making the code from PeopleBooks a little more robust as it was an example rather than delivered code.

                                  As far as I can remember the ldap authentication finds the ID the user entered at the signon screen and if it doesn't exist then the code calls out to a directory to get details with which it can populate the user profile. I think you can do this without too much PeopleCode.

                                  So if you check the PSAuthResult and it is false (i assume this means the user did not come in via signon screen) then get the user from the Kerberos token and try SetAuthenticationResult again. If SetAuthenticationResult fails, or if you check that it is still using the default user, then you can invoke the LDAP code to create the user and then SetAuthenticationResult again after the user is created. If that fails you then need to decide if you want the user to stay logged in as the default user or to be sent back to a signon screen or error screen.

                                  (I think enabling both events in sign on PeopleCode as you have done means each would be invoked sequentially and each would fail.)

                                  Thanks

                                  H
                                  • 14. Re: Kerberos Header Issue for Desktop Signon
                                    937100
                                    Hello Saxon and Henry,

                                    Thank you for the valuable tips.
                                    I have a quick question on step 2 -
                                    Add Role of Domain Controller for the VM, creating new domain forest & install/config DNS companion with AD installation.
                                    Does the AD is used for windows login as well or just as a KDC?
                                    We are planning to implement Desktop signon and I am working on the technical details.

                                    Appreciate if you could please let me know.

                                    Thanks,
                                    Satya
                                    1 2 Previous Next