I'm trying to modify the typical Squid/ntlm_auth/winbindd arrangement to
support authenticating to multiple independent domains. I have a
prototype solution but would like to know if it would work in the
general case. (I used http://davenport.sourceforge.net/ntlm.html as a
reference for the NTLM protocol.)
In the prototype I have multiple instances of winbindd and ntlm_auth
with a multiplexing wrapper. A command added to ntlm_auth's protocol
sets the random number to be used in the NTLM Type 2 message. Squid
communicates to the wrapper, which forwards the negotiation to all
ntlm_auth instances but first sets each to use the same random number.
This means that the Type 3 message generated by the client would be
acceptable to any of the domain controllers.
In my experience the Type 2 messages generated by this method are
exactly identical, so the resulting Type 3 must be acceptable to all.
However, the client didn't request any additional server information in
my test setup. In NTLM messages there are several optional parts which I
am concerned might break this arrangement if they were present; the Type
1 message may specify the client domain, and the Type 2 may specify the
server domain/FQDN/etc.
Can anyone with more experience of NTLM tell me if this trick will work
in the real world?
Are these optional fields are ever used by real Windows systems? If so
can they be disabled through client settings?
Can I put empty or false data in the server response by patching
ntlm_auth (libsmb/ntlmssp.c:ntlm_server_negotiate)? If the client
requires that these fields are present and correct, this scheme won't
work because there's no way to know which domain the client is a member
of.
Alternatively, has anyone else ever solved this problem in a more
cunning way?
--
Harry Mason
Developer
SmoothWall Limited
1 John Charles Way
Leeds LS12 6QA
United Kingdom
1 800 959 3760 (USA, Canada and North America)
0870 1 999 500 (United Kingdom)
+44 870 1 999 500 (all other countries)
SmoothWall is registered in England: 4298247
This email and any attachments transmitted with it are confidential
to the intended recipient(s) and may not be communicated to any
other person or published by any means without the permission of
SmoothWall Limited. Any opinions stated in this message are solely
those of the author. See: http://smoothwall.net/company/email.php
for the full text of this notice.
