directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Beat Burgener | NetSuccess GmbH <>
Subject Re: [ApacheDS] Ceritficate for StartTLS
Date Wed, 06 Jan 2010 15:08:26 GMT

thank you for the swift reply. Remarks below:

On 06.01.2010 15:46 PM, Emmanuel LŽcharny wrote:
> Beat Burgener | NetSuccess GmbH a écrit :
>> Stefan,
>> thank you for pointing this out.
>> BTW: I just found out that I still have 1.5.4   ;-(
>> BTW2: I personally do not suggest storing the certificate data within 
>> the LDAP directory itself, although there are fields available.
>> If you have a certificate used for "", used for web, ldap 
>> and so on, compromising the LDAP account or
>> ApacheDS through LDAP protocol might reveal the private key - or am I 
>> wrong on this?
>> I know that more and more directories start storing PKI data within 
>> the storage engine (Microsoft ADS does this too),
>> but somehow I don't feel comfortable with this ...
> The question here is much more about giving people a direct access to 
> LDAP. I'm not sure it should be considered a good idea to expose your 
> LDAP server to the world.
True, I do not intend to do so, but for example if you use LDAP to 
validate "basic authentication" in web sites, there is a chance for 
brute force attacks,
as web servers are not able to lock accounts (AFAIK) - this was a recent 
question of another user... PHP with it's security issues might be an 
option to get access to an LDAP,
  and if not well protected by ACI, this might be dangerous ...
That's why I'm also looking into SSO and Kerberos solutions for 
Authentication ...
There was also a POST regarding Kerberos and ApacheDS, but AFAIR, it was 
that Kerberos is not fully supported yet?
> In many case, you will use your LDAP server as a NIS, requested ony by 
> IT services, like FTP, DNS, etc.
> If you are to use LDAP to store user data, then eiher you protect the 
> critical data (certificates) by adding ACI (good luck ...), or you 
> install a second LDAP server (probably a better idea).
I'm currently have ACI in use and I like it ... I came from M$, so ACL / 
ACI is crucial to me ..   ,-)
The only thing that is a little bit "uncomfortable" is the requirement 
to restart the server after changes ... But changes are rare, 
fortunately ...
> M$ has it wrong at the beginning, when they start telling their user 
> that AD was a LDAP server and that you should use it for your 
> applications, until they realized how dangerous it was, and they 
> created AD/AM (of course, there were other reasons like if you FU with 
> AD, you have little option but reinstaling your domain server ... :/). 
> But M$ AD is really a NIS server, not a LDAP server, with all the 
> access control needed to protect such private data as the users 
> certificates.
Well, M$ AD at least exports a more or less compliant LDAP / LDAPS 
infrastructure ... and if that is possible, "attacks" available against 
LDAP might be possible against AD too, I assume ...
I don't know what you reference NIS to, but I only know NIS as of Unix 
.... and this is a entire infrastructure on it's own far away from 
Kerberos and LDAP ...


>> BTW3: Is there a way to force StartTLS an LDAP connection using port 
>> 389 via the ApacheDS configuration?
> It's an extended operation, so yes, you can send such a resquest to 
> the server prior to any operation, on port 389. That's the way 
> everyone should use LDAP, btw. LDAPS is considered as obsolete.
>> That's why I use LDAPS, which does not support plain text connections 
>> AFAIK. For LDAP, I don't feel in the position to control that
>> as the client use StartTLS or not ...
> I don't remember is there is a way to tell ADS not to accept plain 
> text requests when not using LDAPS (Stefan ? Stefan (Z)? )
Linus van Geuns just replied that the LDAP protocol does not force to 
use the use of TLS, so if the client is configured the wrong way,
there is a risk that the LDAP Admin password is exposed ... Okey, you 
can limit access to connections using IPSec/SSL, though ...

As of Wikipedia:

A common alternate method of securing LDAP communication is using an SSL 

This is denoted in LDAP URLs by using the URL scheme "ldaps". The 
default port for LDAP over SSL 
<> is 636. The use of 
LDAP over SSL was common in LDAP Version 2 (LDAPv2) but it was never 
standardized in any formal specification. This usage has been deprecated 
along with LDAPv2, which was officially retired in 2003 

Hmmm, I see, the IT world is far from being mature ...

Thank you all for shading some light on this!

Best regards


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message