RFR 7150092: NTLM authentication fail if user specified a different realm
weijun.wang at oracle.com
Thu Jun 12 06:07:49 UTC 2014
Please review the code change at
The problem is that in NTLM, the server might prompt for a domain name (in Type 2 message), and the client can also provide one. Before this fix, if the two are different, the client chooses the one from the server. After this fix, the client will always uses its own even if it's empty. This is confirmed by looking at the behavior of IE/Firefox/Chrome. The server sent domain name was designed to be used to create the NTLMv2 response but it's now obsoleted by alist. Chrome/Firefox simply ignore it, so will Java. (IE does use it if there is no alist)
There are some other small changes:
96-108: No one sends hostname and domain in the Type 1 message, so they are removed. Everyone adds a 0x4 flag which means Request Target.
Removed old 137-139: That's the major change.
159: I used to detect whether there is an alist by looking at the length. This is not accurate if the domain is very long. The correct way is to look at the flag (0x800000 means alist is there)
98: Adds a flag 0x10000 which means the target name (line 99) written into the message is a domain
135: Always uses the client provided domain to search for password. This is also a part of the major change.
If user has not responded to NameCallback and/or RealmCallback, it means they accept the default value.
ntdomain could be empty or null, the 2-arg constructor of RealmCallback could fail in this case. Use 1-arg constructor.
According to my observation of IE/Firefox/Chrome, when user does not type in a domain name in the password prompting dialog, the domain sent to server is an empty string, and the host name is always full name. Update Java to be the same.
Update the test to reflect code changes.
More information about the security-dev