[Samba] Re: [PATCH] Add winbind-backed NTLMSSP support to Cyrus-SASL
On Wed, 31 Dec 2003, Andrew Bartlett wrote: The plugin is designed to use ntlm_auth over a stdio interface, because as part of Samba, it is GPL'ed. The plugin provides a client, and an server implementation, but can only proxy it's server-side (I can provide a mode that allows for local passwords if it is required). Current Samba 3.0 CVS is required to find the NTLMSSP client code exposed. Here is my opinion, Rob's *may* differ: Having support for all of the latest NTLMSSP stuff is a great idea, but I don't think we want to have yet another dependency for Cyrus SASL, especially unreleased Samba code. This will be in Samba 3.0.2, which I expect to be released in a reasonalbly short timeframe due to issues in 3.0.1 (but the rest is up to the release manager) Ok: Here's my take on the NTLM changes. If we were to accept this, I'd want to accept it as another alternative. I don't want to suddenly require anyone who is using our NTLM plugin to have to install SAMBA. I also don't want to remove the ability to support NTLM from the same password store that we server other mechanisms from. So, I'm willing to take a patch that adds an alternate way to compile the NTLM plugin, but not one that replaces what we currently do (and not by default). I was very pleased to see what appears to be a reasonably mature NTLMSSP implemenation. However, a few things stood out - common errors in most of the NTLMSSP implentations I have seen: [snip] I'd be very interested to see patches that fix all of these internally ;) I also think that being able to use passwords that are stored in an auxprop plugin is mandatory as there might be sites which want to support MS clients but don't have an MS server to proxy to. They can always use a Samba server :-) Then they have to maintain separate password stores for their NTLM clients and for their DIGEST-MD5 clients. I don't think this is the direction we want to head. But seriously, if it is required, we can add a callback. I just don't want to add the required dependency, really. Patch against current SASL CVS, but my testing was actually with 2.1.15 I wanted to take a look at your code, but this patch does not apply cleanly to CVS -- only 1 of 7 hunks succeeds. I'll try again on the patch. http://hawkerc.net/staff/abartlet/ntlm_sasl.diff As far as the GSS-SPNEGO stuff is concerned, it looks very similar to the NTLM changes, just with different parameters passed to ntlm_auth. Am I missing something? Perhaps it makes sense to have a samba plugin that supports both NTLM and GSS-SPNEGO via ntlm_auth, and is built if --with-samba is supplied. In this case, we do not build the original NTLM plugin. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
[Samba] Re: [PATCH] Add winbind-backed NTLMSSP support to Cyrus-SASL
Andrew Bartlett wrote: Windows authentication extends far beyond the CIFS protocol the Samba implements, but it only very recently that work has been done to catch up to Microsoft's extensions in this area. This has caused many administrators pain and toil that their MS counterparts simply don't have. For them, authentication 'just works', with single-sign-on and the lot. I have worked, for over a year, with the Squid development team, in extending NTLMSSP authentication to HTTP. The squid team made a very good start (as I see Cyrus-SASL now has) in including a basic NTLMSSP implementation, and even providing a proxy-mechanism to authenticate against a Windows DC. I extended on this base, providing the ntlm_auth tool, which allows them to perform this against winbind, and without having to understand NTLMSSP as anything more than BASE64 strings. This provides a much more reliable interface, as winbind is not only faster, we can also prevent man-in-the-middle attacks. The attached patch provides this for Cyrus-SASL. In the same was that Squid now uses Winbind, all Cyrus-SASL enabled applications can use Winbind (via ntlm_auth) to authenticate their users. This provides the most current NTLMSSP implementation in the Open Source arena, as it is the one that we must maintain for Samba's internal use. The plugin is designed to use ntlm_auth over a stdio interface, because as part of Samba, it is GPL'ed. The plugin provides a client, and an server implementation, but can only proxy it's server-side (I can provide a mode that allows for local passwords if it is required). Current Samba 3.0 CVS is required to find the NTLMSSP client code exposed. Here is my opinion, Rob's *may* differ: Having support for all of the latest NTLMSSP stuff is a great idea, but I don't think we want to have yet another dependency for Cyrus SASL, especially unreleased Samba code. I also think that being able to use passwords that are stored in an auxprop plugin is mandatory as there might be sites which want to support MS clients but don't have an MS server to proxy to. Can you point me to any references to Winbind, so I at least know what we are missing? Patch against current SASL CVS, but my testing was actually with 2.1.15 I wanted to take a look at your code, but this patch does not apply cleanly to CVS -- only 1 of 7 hunks succeeds. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
[Samba] Re: [PATCH] Add winbind-backed NTLMSSP support to Cyrus-SASL
On Wed, Dec 31, 2003 at 12:49:45PM -0500, Ken Murchison wrote: Andrew Bartlett wrote: Windows authentication extends far beyond the CIFS protocol the Samba implements, but it only very recently that work has been done to catch up to Microsoft's extensions in this area. This has caused many administrators pain and toil that their MS counterparts simply don't have. For them, authentication 'just works', with single-sign-on and the lot. I have worked, for over a year, with the Squid development team, in extending NTLMSSP authentication to HTTP. The squid team made a very good start (as I see Cyrus-SASL now has) in including a basic NTLMSSP implementation, and even providing a proxy-mechanism to authenticate against a Windows DC. I extended on this base, providing the ntlm_auth tool, which allows them to perform this against winbind, and without having to understand NTLMSSP as anything more than BASE64 strings. This provides a much more reliable interface, as winbind is not only faster, we can also prevent man-in-the-middle attacks. The attached patch provides this for Cyrus-SASL. In the same was that Squid now uses Winbind, all Cyrus-SASL enabled applications can use Winbind (via ntlm_auth) to authenticate their users. This provides the most current NTLMSSP implementation in the Open Source arena, as it is the one that we must maintain for Samba's internal use. The plugin is designed to use ntlm_auth over a stdio interface, because as part of Samba, it is GPL'ed. The plugin provides a client, and an server implementation, but can only proxy it's server-side (I can provide a mode that allows for local passwords if it is required). Current Samba 3.0 CVS is required to find the NTLMSSP client code exposed. Here is my opinion, Rob's *may* differ: Having support for all of the latest NTLMSSP stuff is a great idea, but I don't think we want to have yet another dependency for Cyrus SASL, especially unreleased Samba code. This will be in Samba 3.0.2, which I expect to be released in a reasonalbly short timeframe due to issues in 3.0.1 (but the rest is up to the release manager) (BTW, when on an MS system I suggest the use of MS's SSPI interface, as that will give you 'perfect' NTLMSSP on that platform) I was very pleased to see what appears to be a reasonably mature NTLMSSP implemenation. However, a few things stood out - common errors in most of the NTLMSSP implentations I have seen: Firstly, Unicode != ASCII plus NULL bytes. i18n is no longer an 'interesting idea', it is something that people not only want to have function, but particularly those from the MS world *expect* to just function. Secondly, domains and workstations do matter. The domains you will see as soon as you move to any 'enterprise' site, with multiple trusted domains. The the 'workstation' regards the list of workstations that a user may log into, as restricted by the DC. (It may be a lame 'security' measure, but we have to get the values right, as some sites do enforce it). Naturally, things like NTLM2, KEY_EXCH are not supported, but this doesn't supprise me, as they have not yet become mandetory. (I'm told Longhorn may change this) I also think that being able to use passwords that are stored in an auxprop plugin is mandatory as there might be sites which want to support MS clients but don't have an MS server to proxy to. They can always use a Samba server :-) But seriously, if it is required, we can add a callback. Can you point me to any references to Winbind, so I at least know what we are missing? My bigest concern is the 'proxy' implementation being developed. In my time working on authentication for the Samba Team, I have seen many attempts at intergrating windows passwords into the unix world. I have seen Samba's own 'security=server', pam_smb, mod_auth_smb, the original Apache NTLM module, the original squid helpers. All of these suffered a fundemantal failing: They are inherintly insecure to a man-in-the-middle attack between the server performing the authentication proxy and the DC with the passwords. They are also highly unreliable, in our experience. This is particularly so when 'optomisations' have been added to get around the connection setup time. Winbind provides a service for managing the connection to the DC. However, more important is the difference (in samba terms) between 'security=domain' and 'security=server'. What winbind provides to ntlm_auth is the ability to specify the challange and response in the same packet, and to send this packet over a secured link. By using only one packet, we cannot 'loose' the connection between stages of the authenticaiton protocols, and if the connection is lost, we may simply retry. We can even choose to talk to a new Domain Controller (a Backup perhaps). Winbind uses the same Domain Controller docation methods as the rst of Samba. This avoids hard-coded server
