• Refresh your personal TGT:

  $ kinit
  Password for user123@REALM.COMPANY.ORG: *****

• Populate the credentials' cache with the service ticket (the requested endpoint should be secured):

  $ curl --negotiate -u : http://service-id.company.org/status
  No resource method found for GET, return 405 with Allow header

• The O flag reported for HTTP/service-id.company.org means that ok-as-delegate is enabled:

  $ klist -f
  Ticket cache: FILE:/tmp/krb5cc
  Default principal: user123@REALM.COMPANY.ORG
  
  Valid starting     Expires            Service principal
  02/07/17 16:02:30  02/08/17 05:02:23  HTTP/service-id.company.org@REALM.COMPANY.ORG
          renew until 02/08/17 16:02:22, Flags: FRAO

For description of flags check Kerberos ticket properties.

On Linux:

user123@host:~> ktutil
ktutil:  addent -password -p USER123@REALM.COMPANY.ORG -k 1 -e RC4-HMAC
Password for USER123@REALM.COMPANY.ORG: *****
ktutil:  wkt USER123.keytab
ktutil:  q

On Windows:

C:\> ktab -a USER123@REALM.COMPANY.ORG -k USER123.keytab
Password for USER123@REALM.COMPANY.ORG:*****
Done!
Service key for USER123@REALM.COMPANY.ORG is saved in USER123.keytab

or

C:\> ktab -a USER123@REALM.COMPANY.ORG <password> -k USER123.keytab

Now this keytab can be used in KerberosRestTemplate or in login.config (to be passed to Java via -Djava.security.auth.login.config=login.config):

// Login entry for a Kerberos client (initiator of a secure Kerberos connection):
com.sun.security.jgss.krb5.initiate {
    com.sun.security.auth.module.Krb5LoginModule required
    storeKey=true
    useKeyTab=true
    doNotPrompt=true
    principal="USER123@REALM.COMPANY.ORG"
    keyTab="USER123.keytab"
    ;
};

• Define -Dsun.security.krb5.debug=true
• Define -Dsun.security.spnego.debug=true
• Add debug=true to module configuration in login.config.

Check also:

• Troubleshooting JGSS
• Troubleshooting Kerberos Issues with Weblogic Server
• Google Search Appliance Kerberos Client – Common errors
• Common Kerberos Error Messages

Make sure you are using the browser from different machine as the server.

References:

• Setting up Kerberos on a BBSA server
• Grails + Spring Security + Kerberos + Windows 2008 R2
• SSO using SPNEGO in JBOSS 4.2.2):

To be sure also check that des-cbc-md5 (Kerberos encryption type 3) is the one listed in your keytab file:

$ klist -e -k service.keytab

[1] Service principal: HTTP/service-id.company.org@REALM.COMPANY.ORG
         KVNO: 3
         Key type: 3

Otherwise you need to regenerate the keytab file (see Cannot find key of appropriate type to decrypt AP REP, "Cannot find key of appropriate type to decrypt" error again on W2k8).

Setting the system property javax.security.auth.useSubjectCredsOnly to false allows us to relax the usual restriction of requiring a GSS mechanism to obtain necessary credentials from an existing Subject, set up by JAAS. When this restriction is relaxed, it allows the mechanism to obtain credentials from some vendor-specific location. For example, some vendors might choose to use the operating system's cache if one exists, while others might choose to read from a protected file on disk.

When this restriction is relaxed, Sun Microsystem's Kerberos mechanism still looks for the credentials in the Subject associated with the thread's access control context, but if it doesn't find any there, it performs JAAS authentication using a Kerberos module to obtain new ones. The Kerberos module prompts you for a Kerberos principal name and password. Note that Kerberos mechanism implementations from other vendors may behave differently when this property is set to false. Consult their documentation to determine their implementation's behavior.