I have configured my application to use Kerberos authentication through SPNEGO with Websphere.
Here are the details
krb5.conf
[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
forwardable = true
renewable = true
noaddresses = true
clockskew = 300
[realms]
ABC.MYCOMPANY.COM = {
kdc = TEST.abc.mycompany.com:88
default_domain = mycompany.com
}
[domain_realm]
.mycompany.com = ABC.MYCOMPANY.COM
login.conf
spnego-client {
com.sun.security.auth.module.Krb5LoginModule required;
};
spnego-server {
com.sun.security.auth.module.Krb5LoginModule required
storeKey=true
useKeyTab=true
keyTab="MyServer.keytab";
};
spnego properties
Spnego properties:
spnego.allow.basic=false
spnego.allow.localhost=false
spnego.allow.unsecure.basic=false
spnego.login.client.module=spnego-client
spnego.login.server.module=spnego-server
spnego.prompt.ntlm=false
spnego.allow.delegation=true
spnego.logger.level=1
When I access my application, I get the following error
Config missing param value for: spnego.preauth.password Stack Trace : java.lang.NullPointerException: Config missing param value for: spnego.preauth.password at net.sourceforge.spnego.SpnegoAuthenticator$1.getInitParameter(SpnegoAuthenticator.java:218) at net.sourceforge.spnego.SpnegoFilterConfig.<init>(SpnegoFilterConfig.java:145) at net.sourceforge.spnego.SpnegoFilterConfig.getInstance(SpnegoFilterConfig.java:316) at net.sourceforge.spnego.SpnegoAuthenticator.<init>(SpnegoAuthenticator.java:206)
Command to create keytab file
C:\IBM\WebSphere\AppServer\java>ktpass -out c:\temp\MyServer.keytab -princ HTTP/TEST.abc.mycompany.com@ABC.MYCOMPANY.COM -mapUser wasMyServer -mapOp set -pass mypassword -crypto RC4-HMAC-NT -pType KRB5_NT_PRINCIPAL
I am not using spnego password, I want it to use keytab, I don't understand why it is throwing error saying that param is missing.
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”:
- Ensure all account options (except password never expires) are unchecked.
- Ensure the SPN HTTP/TEST.abc.mycompany.com is assigned to the account.
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
- Restart the WebSphere application service anytime you replace the keytab.
- 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:
- Open the Internet Options dialog box by choosing Internet Options either from Control Panel or from the Tools menu in Internet Explorer.
- In the Internet Options dialog box, on the Security tab, select Local Intranet, and then click Custom Level.
- In the Security Settings dialog box, under Logon, select "Automatic logon only in Intranet zone", and then click OK.
- In the Internet Options dialog box on the Security Settings tab with Local Intranet still selected, click Sites.
- In the Local intranet dialog box, click Advanced.
- 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.
- In the Local Intranet dialog, box click OK.
- In the original Local Intranet dialog box, click OK.
- Under the Advanced tab, ensure that "Enable Integrated Windows Authentication" is enabled (this is the default).
- In the Internet Options dialog box, click OK.
Reference: Configuring Internet Explorer for Automatic Logon
来源:https://stackoverflow.com/questions/42498111/spnego-authentication-issue-with-password