Error clicking 'View in CIFS' in IE7/8: Investigation

[nicolasraoul]

Hello all,

Here is the tale of my bug hunting week.

Background: The "View in CIFS" link of the Alfresco Explorer normally opens a window showing the space as a shared folder, after prompting for a login/password if needed.
The bug: As some of you have probably experienced, it does not work with Internet Explorer 7/8 (except if you use the same login/password for Windows and Alfresco, or have already mounted the share).

I started by setting up the following environment:
Alfresco Enterprise 3.1 on Ubuntu
Internet Explorer 8 on Windows XP
Both machines wired to the same switch.

First, I reproduced the problem about 10 times. I noticed that 1 time among those 10, the bug did not appear, which means a login/password was asked for and the window opened as expected. Note: before any test, it is important to remove all existing share, using the "net use" command.

The "View in CIFS" link looks like this:
file:///\\NICOA\Alfresco

To remove DNS from the equation, I create a small web page served by an Apache server running on the same machine as Alfresco, with this link:
file:///\\192.168.0.78\Alfresco

Surprisingly, the link works if you remove the "target" attribute in the HTML link. Also, after removing everything but the IP, it works all the time:
file:///\\192.168.0.78

[size=200]Wireshark[/size]

What makes file:///\\192.168.0.78\Alfresco fail and file:///\\192.168.0.78 work?
Using the network protocol analyzer Wireshark, I investigated how IE sends network requests, and what Alfresco replies.

1) file:///\\192.168.0.78 (which works)
I thought IE would first try to log with the Windows credentials, then in case of failure try as anonymous, and in case of failure prompt for a login/password. But actually here is what happens:
- Try to log with the Windows credentials
- Try again 5 more times, always with the Windows credentials
- Prompt for a login/password

2) file:///\\192.168.0.78\Alfresco (which fails)
Here is what happens:
- Try to log with the Windows credentials, 6 times
- Try to log in as anonymous
- Try to log with the Windows credentials again
- IE shows an error message, invalid path.

I tried to understand what made one fail and the other work, comparing the network packets, but did not find any clue.

[size=200]Samba[/size]

Then I thought I would check what kind of network traffic is going on when using another CIFS implementation: Samba, instead of Alfresco JLAN. Using Ubuntu's default Samba settings, all links were working, Internet Explorer just asked for a login/password and opened the share as one would expect. That shows that this bug is not a necessary fatality. Samba works with IE7/8, so it is just a question of code before Alfresco eliminates this bug. Right now, Alfresco engineers seems to think that it is an unavoidable IE bug, and that the only solution is to *remove the link* from Alfresco Explorer: https://issues.alfresco.com/jira/browse/ETHREEOH-778 - which would be a shame. This link is very convenient, and it can be fixed.

Comparing the IE-Alfresco and IE-Samba network dialogs, they looked very different: that is because Samba was uses SPNEGO (Simple and Protected GSSAPI Negotiation Mechanism) whereas Alfresco JLAN just uses plain NTLMSSP, which means it does not use SPNEGO. To be able to compare, I needed to prevent Samba from using SPNEGO. One way to do this would have been to intercept IE's "Negotiate Protocol Request" packets and use packet forgery to remove all but the most basic dialects in this packet's list of supported dialects. But I discovered something much simpler: Just add "use spnego = no" in the [Global] section of /etc/samba/smb.conf and Samba will, as you have guessed, not use SPNEGO.

So I restarted this no-SPNEGO Samba, and guess what? It had the exact same bug as Alfresco JLAN. It appeared clear to me that IE just could not communicate with non-SPNEGO CIFS servers. The solution would be to use SPNEGO in Alfresco.

I searched for "SPNEGO" in Alfresco Enterprise's source code and found this very interesting file which is also available in Alfresco Community:
EnterpriseCifsAuthenticator.java ( http://www.koders.com/java/fidB0C074CD07AFBE151ACA7EFE5553C0F827406563.aspx?s=useSpnego#L291 )

Particularly interesting is line 291:
ConfigElement useSpnego = params.getChild("useSPNEGO");

So I added a useSPNEGO node in Alfresco/tomcat/webapps/alfresco/WEB-INF/classes/alfresco/file-servers.xml :
<authenticator type="enterprise">
  <useSPNEGO/>
  <Debug/>
</authenticator>

[size=200]Alfresco with SPNEGO[/size]

I restarted Alfresco, feeling that the bug would be solved. But it was not. So I launched Wireshark once again and started comparing Samba to Alfresco+useSPNEGO. Now that's really really close. With this setting, Alfresco really uses SPNEGO. How comes one works and the other fails? Here are the differences I have found:

• Negotiate Protocol Request: identical


• Negotiate Protocol Response: Nearly identical, but Alfresco misses negTokenInit's node: "mechListMIC" with sub-node "principal" that has a "NONE" value


• NTLMSSP_NEGOTIATE: identical


• NTLMSSP_CHALLENGE: Nearly identical, only difference is empty DNS name for Samba


• NTLMSSP_AUTH: identical


• Only Samba receives Trans2 Request GET_DFS_REFERRAL


• Session Setup AndX Response: STATUS_LOGON_FAILURE for Alfresco, accept-completed in SPNEGO enveloppe for Samba

At this point, I am asking everyone:
How do those differences make Alfresco's behaviour buggy?
Do you have any hint about what should be fixed?

Thanks a lot,
Nicolas Raoul
http://nrw.free.fr

[nicolasraoul]

I modified the source code of Alfresco Community from SVN so that the Negotiate Protocol Response is the same as what Samba would send:

SPNEGO
_ negTokenInit
__ mechTypes: 1 item
___ 1.3.6.1.4.1.311.2.2.10 NTLMSSP
__ mechListMIC
___ principal: NONE

Wireshark confirms that my customized Alfresco returns this response.
But still, Internet Explorer 8 does not behave any better.

Compared to Samba, there are also a few flags that are different. I will try to modify them.
Cheers,
Nicolas

[nicolasraoul]

I finally managed to fix this bug.
The patch I wrote is available here:
https://issues.alfresco.com/jira/browse/ETHREEOH-778

Cheers,
Nicolas.