Uploaded image for project: 'PicketBox '
  1. PicketBox
  2. SECURITY-393

Caused by: KrbException: Invalid argument (400) - Cannot find key of appropriate type to decrypt AP REP - RC4 with HMAC

    XMLWordPrintable

Details

    • Hide

      Workaround mail 1:
      Let me guess... you're probably running JBoss on a Windows machine that is joined to the Active Directory domain?

      If so, then the problem is: you have got your SPN mappings wrong. (i.e. the hostname in the URL that you are using in the browser doesn't match any SPN mapping that you have set up).

      So, when the browser asks AD for a Kerberos service ticket to HTTP/foo.example.com, AD doesn't find an explicit SPN mapping on your service object, so it doesn't use your service object. If AD doesn't find an explicit SPN mapping for HTTP/foo.example.com, it implicitly maps HTTP/foo.example.com to the AD Computer object for foo.example.com (equivalently, HOST/foo.example.com). This works nicely for Microsoft IIS but for other SPNEGO implementations it produces the rather nonobvious error that you are seeing at present.

      Workaround mail 2:

      With the caveat that I have only had a cursory look [we have our own product that supports SPNEGO and other GSSAPI / Kerberos goodness on various Java app servers (including JBoss) so we don't use the JBoss Negotiate code, nor its setup instructions]... I think the problem is that the setup instructions you followed implicitly assume that the machine where you are installing JBoss Negotiate is not joined to an Active Directory domain[*], and bad things happen if you try to use those same setup instructions for a machine that is joined to the Active Directory domain – you end up with two different objects in AD that both want to be the HOST principal, e.g. HOST/PASKTABSVR1.wamtest.wa.local in your example. (And you are going even further than that; the machine that you're using for JBoss Negotiate isn't just any member of the AD domain, it is actually a domain controller).

      A plausible guess would be that the instructions were developed for running JBoss Negotiate on a Unix or Linux (e.g. Redhat...) host that is likely not configured to enable MIT Kerberos (or whatever), so the host is not joined to the AD domain.

      Show
      Workaround mail 1: Let me guess... you're probably running JBoss on a Windows machine that is joined to the Active Directory domain? If so, then the problem is: you have got your SPN mappings wrong. (i.e. the hostname in the URL that you are using in the browser doesn't match any SPN mapping that you have set up). So, when the browser asks AD for a Kerberos service ticket to HTTP/foo.example.com, AD doesn't find an explicit SPN mapping on your service object, so it doesn't use your service object. If AD doesn't find an explicit SPN mapping for HTTP/foo.example.com, it implicitly maps HTTP/foo.example.com to the AD Computer object for foo.example.com (equivalently, HOST/foo.example.com). This works nicely for Microsoft IIS but for other SPNEGO implementations it produces the rather nonobvious error that you are seeing at present. Workaround mail 2: With the caveat that I have only had a cursory look [we have our own product that supports SPNEGO and other GSSAPI / Kerberos goodness on various Java app servers (including JBoss) so we don't use the JBoss Negotiate code, nor its setup instructions] ... I think the problem is that the setup instructions you followed implicitly assume that the machine where you are installing JBoss Negotiate is not joined to an Active Directory domain [*] , and bad things happen if you try to use those same setup instructions for a machine that is joined to the Active Directory domain – you end up with two different objects in AD that both want to be the HOST principal, e.g. HOST/PASKTABSVR1.wamtest.wa.local in your example. (And you are going even further than that; the machine that you're using for JBoss Negotiate isn't just any member of the AD domain, it is actually a domain controller). A plausible guess would be that the instructions were developed for running JBoss Negotiate on a Unix or Linux (e.g. Redhat...) host that is likely not configured to enable MIT Kerberos (or whatever), so the host is not joined to the AD domain.
    • Medium

    Description

      I am using SPNEGO for silent authentication. Referring https://www.jboss.org/community/docs/DOC-10680

      Environment specification:

      Server Machine: Microsoft windows server 2003 R2 (Name: PASKTABSVR1, Domain: wamtest.wa.local, FullName:PASKTABSVR1.wamtest.wa.local)
      KDC : windows server 2003 R2, In my case server and KDC are same machine. (Name: PASKTABSVR1, Domain: wamtest.wa.local FullName:PASKTABSVR1.wamtest.wa.local)
      Client Machine: Microsoft windows XP professional (Name: PASKTABCL1, Domain: wamtest.wa.local FullName:PASKTABCL1.wamtest.wa.local)

      I basically followed the pdf document userguide downloaded from above link (https://www.jboss.org/community/docs/DOC-10680)

      I have checked "Use DES type encryption types for this account"

      SPN setting:

      C:\Program Files\Support Tools>setspn -l PASKTABSVR1
      Registered ServicePrincipalNames for CN=PASKTABSVR1,OU=Domain Controllers,DC=wamtest,DC=wa,DC=local:
      HTTP/PASKTABSVR1.wamtest.wa.local
      NtFrs-88f5d2bd-b646-11d2-a6d3-00c04fc9b232/PASKTABSVR1.wamtest.wa.local
      ldap/PASKTABSVR1.wamtest.wa.local/ForestDnsZones.wamtest.wa.local
      GC/PASKTABSVR1.wamtest.wa.local/wamtest.wa.local
      HOST/PASKTABSVR1.wamtest.wa.local/WAMTEST
      HOST/PASKTABSVR1
      HOST/PASKTABSVR1.wamtest.wa.local
      HOST/PASKTABSVR1.wamtest.wa.local/wamtest.wa.local
      E3514235-4B06-11D1-AB04-00C04FC2DCD2/c97c1681-4636-4d4a-b7fe-94f6bf0567cf/wamtest.wa.local
      ldap/c97c1681-4636-4d4a-b7fe-94f6bf0567cf._msdcs.wamtest.wa.local
      ldap/PASKTABSVR1.wamtest.wa.local/WAMTEST
      ldap/PASKTABSVR1
      ldap/PASKTABSVR1.wamtest.wa.local
      ldap/PASKTABSVR1.wamtest.wa.local/DomainDnsZones.wamtest.wa.local
      ldap/PASKTABSVR1.wamtest.wa.local/wamtest.wa.local
      DNS/PASKTABSVR1.wamtest.wa.local

      Command used to create keytab file:

      C:\Program Files\Support Tools>ktpass -crypto DES-CBC-CRC -princ host/PASKTABS...@WAMTEST.WA.LOCAL -pass Autumn08 -mapus
      er WAMTEST\PASKTABSVR1 -out C:\pasktabsvr1.host.keytab

      Login moduoles from Jboss(login-config.xml):
      .
      ..
      ......
      <application-policy name="host">
      <authentication>
      <login-module code="com.sun.security.auth.module.Krb5LoginModule" flag="required">
      <module-option name="storeKey">true</module-option>
      <module-option name="useKeyTab">true</module-option>
      <module-option name="principal">host/PASKTABS...@WAMTEST.WA.LOCAL</module-option>
      <module-option name="keyTab">C:/pasktabsvr1.host.keytab</module-option>
      <module-option name="doNotPrompt">true</module-option>
      <module-option name="debug">true</module-option>
      </login-module>
      </authentication>
      </application-policy>

      <application-policy name="SPNEGO">
      <authentication>
      <login-module code="org.jboss.security.negotiation.spnego.SPNEGOLoginModule" flag="requisite">
      <module-option name="password-stacking">useFirstPass</module-option>
      <module-option name="serverSecurityDomain">host</module-option>
      </login-module>
      <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
      <module-option name="password-stacking">useFirstPass</module-option>
      <module-option name="usersProperties">props/spnego-users.properties</module-option>
      <module-option name="rolesProperties">props/spnego-roles.properties</module-option>
      </login-module>
      </authentication>
      </application-policy>
      .....
      ..
      .

      As per document there are three tests,
      First and second test passes, ie the client browser gets the token, in second test host login module gets authenticated ie the second test passes.
      The final test, i.e. "secured" which is the integrated test of both client and server fails with following exception:

      Caused by: KrbException: Invalid argument (400) - Cannot find key of appropriate type to decrypt AP REP - RC4 with HMAC
      at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:262)
      at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:134)
      at sun.security.jgss.krb5.InitSecContextToken.<init>(InitSecContextToken.java:79)

      I tried mapping different SPN:

      C:\Program Files\Support Tools>setspn.exe -a HTTP/PASKTABSVR1.wamtest.wa.local PASKTABSVR1
      C:\Program Files\Support Tools>setspn.exe -a HTTP/pasktabsvr1.wamtest.wa.local PASKTABSVR1 (Small case pasktansvr1)

      But it didn't help, I got same exception "Invalid argument (400) - Cannot find key of appropriate type to decrypt AP REP - RC4 with HMAC"

      Am I doing anything fundamentally wrong or this is a bug, or user doc is prepared on different environment.

      Attachments

        Activity

          People

            darran.lofthouse@redhat.com Darran Lofthouse
            nagendra_singh_krishnawat_jira Nagendra krishnawat (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: