Re: [ldapext] DBIS - new IETF drafts
Andrew Findlay <andrew.findlay@skills-1st.co.uk> Fri, 10 January 2014 17:37 UTC
Return-Path: <andrew.findlay@skills-1st.co.uk>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D391ADFA4 for <ldapext@ietfa.amsl.com>; Fri, 10 Jan 2014 09:37:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rR1w36_JbX6n for <ldapext@ietfa.amsl.com>; Fri, 10 Jan 2014 09:37:43 -0800 (PST)
Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) by ietfa.amsl.com (Postfix) with ESMTP id 2044B1ADF30 for <ldapext@ietf.org>; Fri, 10 Jan 2014 09:37:43 -0800 (PST)
Received: from 9.d.e.2.e.6.a.d.5.9.e.0.f.9.4.9.1.e.7.f.0.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:8d0:f7e1:949f:e95:da6e:2ed9] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <andrew.findlay@skills-1st.co.uk>) id 1W1g1T-0008Cp-PL; Fri, 10 Jan 2014 17:37:31 +0000
Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.80.1) (envelope-from <andrew.findlay@skills-1st.co.uk>) id 1W1g1T-0007Ea-9u; Fri, 10 Jan 2014 17:37:31 +0000
Date: Fri, 10 Jan 2014 17:37:31 +0000
From: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
To: Luke Howard <lukeh@padl.com>
Message-ID: <20140110173731.GA3938@slab.skills-1st.co.uk>
References: <52C9BED5.2080900@proseconsulting.co.uk> <52CAEA7D.5030002@highlandsun.com> <1389033674.27654.32.camel@pico.ipa.ssimo.org> <52CB2030.3010403@proseconsulting.co.uk> <1389050240.27654.67.camel@pico.ipa.ssimo.org> <52CDB6B2.2080406@proseconsulting.co.uk> <52CEBEAE.5090701@stroeder.com> <20140109174321.GV3938@slab.skills-1st.co.uk> <52CFFEAC.7070208@proseconsulting.co.uk> <C6DD84E6-0D5D-4F7A-90DF-46C382D4B06A@padl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <C6DD84E6-0D5D-4F7A-90DF-46C382D4B06A@padl.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
Cc: Ldapext <ldapext@ietf.org>, Michael Ströder <michael@stroeder.com>
Subject: Re: [ldapext] DBIS - new IETF drafts
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldapext/>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jan 2014 17:37:45 -0000
On Sat, Jan 11, 2014 at 01:15:03AM +1100, Luke Howard wrote: > > Ok, so I posed this question just now, but can all LDAP servers you can think of authentication bind operations using CRYPT-style passwords? If it can be done server-side there'll be no problem here and we need never expose the hashes to clients. > > Active Directory cannot. True, but there are many things that Active Directory cannot do. It is not a general-purpose LDAP server: it is a proprietary database that happens to support an LDAP access method. As for CRYPT (at least the traditional 13-character DES version) in other servers: OpenLDAP yes IBM Tivoli Directory Server yes 389 yes OpenDJ yes Sun/Oracle DSEE yes Oracle OID yes Isode M-Vault yes ApacheDS yes Lotus Domino very unlikely The only server that I have not been able to find a clear statement of CRYPT support for is Lotus Domino - and like AD, that is really not intended as a general-purpose LDAP server. Of course these days we are not just talking about 13-character CRYPT in migration jobs. Any decent Unix-like system released in the past decade or two is likely to use a stronger hash algorithm in /etc/shadow. Support for those is much more restricted, and normally depends on the underlying OS to supply the hashing code. Some of the enterprise distros have only gained support for my preferred hash algorithms in the past couple of years, so running LDAP servers on older enterprise OSs can be rather limiting. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------
- [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Howard Chu
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Howard Chu
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Howard Chu
- Re: [ldapext] DBIS - new IETF drafts Howard Chu
- Re: [ldapext] DBIS - new IETF drafts Arthur de Jong
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Ludovic Poitou
- Re: [ldapext] DBIS - new IETF drafts Clément OUDOT
- Re: [ldapext] DBIS - new IETF drafts Andrew Findlay
- Re: [ldapext] DBIS - new IETF drafts Andrew Findlay
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Charlie
- Re: [ldapext] DBIS - new IETF drafts Luke Howard
- Re: [ldapext] DBIS - new IETF drafts Neal-Joslin, Robert (3PAR Engineering)
- Re: [ldapext] DBIS - new IETF drafts Howard Chu
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Luke Howard
- Re: [ldapext] DBIS - new IETF drafts Luke Howard
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Andrew Findlay
- Re: [ldapext] DBIS - new IETF drafts Andrew Findlay
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Michael Ströder
- Re: [ldapext] DBIS - new IETF drafts Howard Chu
- Re: [ldapext] DBIS - new IETF drafts Charlie
- Re: [ldapext] DBIS - new IETF drafts Mark R Bannister