-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 7/10/2014 6:07 p.m., Victor Sudakov wrote: > Amos Jeffries wrote: > > [dd] > >>> Apparently so, but as I said, the very same client software >>> does work with the old "ntlm_auth" helper and does not work >>> with the new ntlm_smb_lm_auth one. >>> >>> That's why I am saying that the problem is on the >>> authenticator side and not on the client side. >> >> The client is sending corrupt packets. Old authenticator did not >> check for the corruption. New one does. > > Which renders the new authenticator useless, at least for me. > >> >> Client is still sending corrupt packets, which is why both the >> developers have said the problem is in the client. > > The developers could have at least provided the option of > compatibility with the old bugs :) There is the old good > programming creed "be conservative about what you send and liberal > about what you receive". > The packet *is* accepted. Its the security privileges which are denied. If you want to accept anything the client sends regardless of the credentials accuracy there is ntlm_fake_auth. Using ntlm_fake_auth to retrieve the Windows user account name you can use an external_acl_type helper to take that name and other fixed-point details about the client machine (IP, port, ident? etc) and assign access privileges for them more securely than SMB LM. Amos -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUM4J3AAoJELJo5wb/XPRj+jgH/0SiOGfD9aQoZKfHWXqQDZqo 0c0Mxx1jp3yyl4sJXYypNatUnSdJrH8KqVe49jPbjubbF+mwWxTvMBSDMlP1DXCa mqt7DMn8dV2ZvC4L96mwj4UUbtMOEkEBgEkgmVOqg9gehawgBfsjgHvFlVz6zkwm Fzo8WPSjcRLUW/4zD0CljS/wY3YhHqvfb+hkNZ+7He+z0OTFdsH+N4cVqRwwFSjF 78hUCGhPncISPL45szY3tAgUQtQmH+Aw7P3sDwuG8uNuED9NWVRf8iUBzfQL0PUK nfHY/A+3qRTG3PQgke+Kmviktn2e9XNSI46Ivl8rqj2N9TXNJoBzChyCbN5bJOQ= =o4ph -----END PGP SIGNATURE----- _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
