Ошибка spnego authentication is not supported on this client

I am trying out the SPNEGO feature in Websphere 7. I want to allow basic authentication in case of client not supporting SPNEGO.

In my web.xml, I have

<login-config>
    <auth-method>BASIC</auth-method>
    <realm-name>SampleApp Login</realm-name>
</login-config> 

In admin console of Websphere,

under Security -> Global Security -> Web and SIP security -> General settings, I have "Default to basic authentication when certificate authentication for the HTTPS client fails" checked,

and under Security -> Global Security -> Web and SIP security -> SPNEGO Web authentication, I have «Allow fall back to application authentication mechanism» checked.

When I am using client supports SPNEGO (e.g. IE) to access my web app, it seems fine. However, when I switch to clients that do not support SPNEGO (e.g. Firefox), it simply shows a message «SPNEGO authentication is not supported on this client.» , without prompting me for basic authentication.

Can anyone give me some hints on what I may have missed? Thanks a lot.

Configuring SPNEGO ( Integrated Windows Authentication ) on mozilla firefox:

Enter following address in mozilla firefox web browser
about:config

It will open warning page saying changing these setting might void warranty.
Click on I’ll be careful, I promise!

In Filter field enter network.nego
This will list down preferences starting with network.nego*

Change value of network.negotiate-auth.delegation-uris to http://,https://
Change value of network.negotiate-auth.trusted-uris to http://,https://
Its done!

Configuring SPNEGO ( Integrated Windows Authentication ) on Internet Explorer:

1. At the desktop, log in to the windows active directory domain.
2. Activate Internet Explorer.
3. In the Internet Explorer window, click Tools > Internet Options > Security tab.
4. Select the Local intranet icon and click Sites.
5. In the Local intranet window, ensure that the «check box» to include all local (intranet) not listed in other zones is selected, then click Advanced.
6. In the Local intranet window, fill in the Add this Web site to the zone field with the Web address of the host name so that the single sign-on (SSO) can be enabled to the list Web sites shown in the Web sites field. Your site information technology staff provides this information. Click OK to complete this step and close the Local intranet window.
7. On the Internet Options window, click the Advanced tab and scroll to Security settings. Ensure that the Enable Integrated Windows Authentication (requires restart) box is selected.
8. Click OK. Restart your Microsoft Internet Explorer to activate this configuration.

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:IBMWebSphereAppServerkerberosMyServer.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