SPNEGO authentication issue with password

假装没事ソ 提交于 2019-12-06 11:55:26

While you didn't tag your question with Active-Directory, you must be running it because you are trying to use RC4-HMAC-NT, which used to be the dominant encryption algorithm to Microsoft Active Directory. I say used to be, because starting with Windows Server 2008 R2, AES26-SHA1 became the default encryption algorithm. That said, the Active Directory account wasMyServer needs to be configured to comply with the Kerberos Protocol. It should be a user account, not a computer account, according to WebSphere setup instructions, and to give you the flexibility to run the Kerberized service on the application server properly. That said, on the "Account" tab for the user account “wasMyServer”:

  1. Ensure all account options (except password never expires) are unchecked.
  2. Ensure the SPN HTTP/TEST.abc.mycompany.com is assigned to the account.

Reference: Administering SPNEGO within WebSphere Application Server: Tips on using Kerberos service principal names

EDITS:

KRB5.CONF

There appears to be a problem inside your krb5.conf. You have only these two lines showing as supporting RC4-HMAC:

default_tkt_enctypes = rc4-hmac des-cbc-md5
default_tgs_enctypes = rc4-hmac des-cbc-md5

To fully enable the RC4-HMAC encryption type, add the additional line underneath:

permitted_enctypes = rc4-hmac des-cbc-md5

(As a side note, no one uses des-cbc-md5 encryption type anymore, but I left it in there)

The DNS domain name needs to be consistent throughout this file. For simplicity sake, the DNS domain name and Kerberos realm name should match (apart from the Kerberos realm name being specified in UPPER case). They don't have to match, but it makes troubleshooting orders of magnitude harder when they don't match.

Since you clarified that your AD domain name is abc.mycompany.com, I suggest to use a krb5.conf file which looks like this:

[libdefaults]
    default_realm = ABC.MYCOMPANY.COM
    default_keytab_name = FILE:C:\IBM\WebSphere\AppServer\kerberos\MyServer.keytab
    default_tkt_enctypes = rc4-hmac des-cbc-md5
    default_tgs_enctypes = rc4-hmac des-cbc-md5
    permitted_enctypes = rc4-hmac des-cbc-md5
    forwardable  = true
    renewable  = true
    noaddresses = true
    clockskew  = 300
[realms]
    ABC.MYCOMPANY.COM = {
        kdc = TEST.abc.mycompany.com:88
        default_domain = abc.mycompany.com
    }
[domain_realm]
    .abc.mycompany.com = ABC.MYCOMPANY.COM
   abc.mycompany.com = ABC.MYCOMPANY.COM

Reference: Secure Communications Using Stronger Encryption Algorithms

SPNs

All SPNs must be unique within any given Kerberos realm. In the event of a duplicate SPN, run the below command to find the AD accounts to which duplicate SPNs are registered, and remove the SPN from the account which the SPN is not being used. The hint for that, is that the SPN to the AD account with which the keytab was generated is the only place where the SPN should be registered. So for this case, only the AD account wasMyServer should have the SPN HTTP/TEST.abc.mycompany.com. To find all duplicate SPNs in the Directory, run the following in a Windows Command Shell on a computer joined to the AD domain:

setspn -X

The output will list all AD accounts to which duplicate SPNs are registered, and you can take corrective action according to my guidance. The command:

setspn -D HTTP/TEST.abc.mycompany.com wasMyServer

...will remove a duplicate SPN from an AD account name. Or you can remove it within the AD Users and Computers GUI as well. Run the above command to clean the AD account each time right before you re-create the keytab.

Keytab

  1. Restart the WebSphere application service anytime you replace the keytab.
  2. Validate the keytab on the WAS server by running the following command. The validation pulls a Kerberos ticket from the KDC so if it is successful, that means nothing is wrong with the keytab.

kinit -k -t MyServer.keytab HTTP/TEST.abc.mycompany.com

Note: kinit does not come with Windows, but it does come with Java JRE/JDK, so you need to either place a copy of the keytab into the same directory where kinit exists or otherwise ensure <JAVA HOME> is in the system PATH in order to run the command successfully.

Web Browser

Ensure that your web browser is configured to send Windows credentials (essentially, a SPNEGO token containing a Kerberos service ticket) to the application server automatically. To do this, follow the below instructions.

Internet Explorer:

  1. Open the Internet Options dialog box by choosing Internet Options either from Control Panel or from the Tools menu in Internet Explorer.
  2. In the Internet Options dialog box, on the Security tab, select Local Intranet, and then click Custom Level.
  3. In the Security Settings dialog box, under Logon, select "Automatic logon only in Intranet zone", and then click OK.
  4. In the Internet Options dialog box on the Security Settings tab with Local Intranet still selected, click Sites.
  5. In the Local intranet dialog box, click Advanced.
  6. In the next dialog box (also titled Local intranet), type the URL of your web site (for example, http://test.abc.mycompany.com) in the "Add this Web site to the zone" box, and then click Add.
  7. In the Local Intranet dialog, box click OK.
  8. In the original Local Intranet dialog box, click OK.
  9. Under the Advanced tab, ensure that "Enable Integrated Windows Authentication" is enabled (this is the default).
  10. In the Internet Options dialog box, click OK.

Reference: Configuring Internet Explorer for Automatic Logon

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!