Note that decoding an NTLMSSP token is not sufficient to validate the
identity of a client. The information in your links does not described
how to validate NTLMv2 blobs. The only way to properly validate NTLMv2
blobs is with the NETLOGON service [1] on a domain controller in the
user's domain (or a domain with which the user's domain has a trust
relationship).
So beware - if you are simply decoding the NTLMSSP tokens, your
implementation is totally insecure. A client could access your site
using any credentials at all. Unfortunately there are many examples of
doing this sort of thing on the web but all are equally useless if not
dangerous.
Mike
[1] Actually you can also validate NTLMv2 blobs against your own
database of credentials. But of course this is of limited utility
because clients will not be logged into their workstations with those
credentials (and thus, for example, IE will not do SSO).
On Mon, Jan 11, 2010 at 8:20 AM, Cornelius Weiss <c.weiss@metaways.de> wrote:
> Hello Michael,
> I did an NTLMv2 server implementation based on the infos I found here:
> http://davenport.sourceforge.net/ntlm.html
> http://technet.microsoft.com/de-de/magazine/2006.08.securitywatch(en-us).aspx
> I wasn't able to find out how my (server) implementation can force the
> client to only send v2 blobs.
> After searching online resources, I doubt that this is even possible.
> I guess also in your implementatin as also in the mod_auth_ntlm the v1 blobs
> are send from the client if the registry of the clients is not configured to
> send v2 only.
> So if the clients can send their v1 blobs anyway, I think it's also ok to
> evaluate them.
> Looking in to the MS docs it also seems like securing NTLM configuring the
> clients.
> cu
> Cornelius
>
> Am 07.01.2010 um 21:50 schrieb Michael B Allen:
>
> Signing and sealing over HTTP is not the problem (there is no such
> thing actually). The problem is that ultimately you have to validate
> the NTLMv2 blob submitted by the client. To do that requires MSRPC and
> stuff that you really don't want to get into. We just did a Java lib
> that does NTLMv2 and it took months to get it working really well (and
> I've been doing this sort of thing for many years). Use an existing
> solution for this. The aforementioned mod_auth_ntlm_winbind is the
> Free one.
>
> Mike
>
> On Thu, Jan 7, 2010 at 1:57 PM, Cornelius Weiss <c.weiss@metaways.de> wrote:
>
> Hello Mike,
>
> thanks for response.
>
> I don't undertand why I have to deal with MSRPC/SecureChannel with NTLMv2
>
> response types.
>
> What I tried so far is to force the browser to only send NTLMv2 via
>
> HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\LMCompatibilityLevel
>
> = 3
>
> This works and communication is possible without signing and sealing.
>
> Now I'm toying around with the message flags to see how I can initialte a
>
> NTLMv2 from server side.
>
> cu
>
> Cornelius
>
> Am 07.01.2010 um 16:16 schrieb Michael B Allen:
>
> On Thu, Jan 7, 2010 at 8:56 AM, Cornelius Weiss <c.weiss@metaways.de>
>
> wrote:
>
> Hi,
>
> I need to implement NTLM auth support. NTLM is a kind of HTTP
>
> Authentication, so imho it belongs somewhere into the sope of the
>
> Zend_Auth_Http Adapter.
>
> Reading the code of Zend_Auth_Http, I realised, that I can't add NTLM
>
> support without changeing the Zend_Auth_Http class.
>
> So please advice which way to go:
>
> - Let Basic and Digest also be extra classes -> having
>
> Zend_Auth_Http_Basic
>
> / ... or
>
> - Have Basic and Digest in the Http base class and implement a plugin
>
> structure for others
>
> Hi Cornelius,
>
> Note that any solution would have to implement NTLMv2. Virtually all
>
> of the existing NTLM solutions out there with the exception of a few
>
> like our stuff and Samba's do not do NTLMv2 - they do the lowly,
>
> insecure and now obsolete NTLMv1. Authenticating clients using NTLMv2
>
> requires doing MSRPC with SecureChannel which is to say it is probably
>
> something you do not want to mess with.
>
> Mike
>
> --
>
> Michael B Allen
>
> PHP Active Directory Integration
>
> http://www.ioplex.com/plexcel.html
>
> Dipl.-Phys. Cornelius Weiss
>
> Tine 2.0 Lead Developer
>
> Metaways Infosystems GmbH
>
> Pickhuben 2, D 20457 Hamburg
>
> E-Mail: c.weiss@metaways.de
>
> Web: http://www.metaways.de
>
> Tel: +49 (0)40 317031-545
>
> Fax: +49 (0)40 317031-945
>
> Mobile: +49 (0)170 3322254
>
> --- Tine 2.0 "August (2009/11)" is released, check it out from
>
> www.tine20.org ---
>
> Metaways Infosystems GmbH - Sitz: D-22967 Tremsbüttel
>
> Handelsregister: Amtsgericht Ahrensburg HRB 4508
>
> Geschäftsführung: Hermann Thaele, Lüder-H.Thaele
>
>
>
>
>
> --
> Michael B Allen
> Java Active Directory Integration
> http://www.ioplex.com/
>
>
> Dipl.-Phys. Cornelius Weiss
> Tine 2.0 Lead Developer
> Metaways Infosystems GmbH
> Pickhuben 2, D 20457 Hamburg
> E-Mail: c.weiss@metaways.de
> Web: http://www.metaways.de
> Tel: +49 (0)40 317031-545
> Fax: +49 (0)40 317031-945
> Mobile: +49 (0)170 3322254
> --- Tine 2.0 "August (2009/11)" is released, check it out from
> www.tine20.org ---
>
> Metaways Infosystems GmbH - Sitz: D-22967 Tremsbüttel
> Handelsregister: Amtsgericht Ahrensburg HRB 4508
> Geschäftsführung: Hermann Thaele, Lüder-H.Thaele
>
--
Michael B Allen
Java Active Directory Integration
http://www.ioplex.com/
没有评论:
发表评论